Welcome! Please see the About page for a little more info on how this works.

0 votes
in core.async by

https://clojurescript.org/guides/promise-interop

this is given as the way to setup core.async for <p! :

(:require
   [cljs.core.async :refer [go]]
   [cljs.core.async.interop :refer-macros [<p!]])

We are using current shadow-cljs and node target, and we find that this recipe leaves 'go' exposed as a function, not a macro.

replacing with :refer-macros [go] fixes the issue

1 Answer

0 votes
by

can you explain what issue you are running into? What does exposed as a function mean?

/t/async ❯❯❯ clj -A:cljs:async -m cljs.main -re node -r
ClojureScript 1.10.773
cljs.user=> (require '[clojure.core.async :as a :refer [go]])
nil
cljs.user=> (doc go)
-------------------------
cljs.core.async/go
([& body])
Macro
  Asynchronously executes the body, returning immediately to the
  calling thread. Additionally, any visible calls to <!, >! and alt!/alts!
  channel operations within the body will block (if necessary) by
  'parking' the calling thread rather than tying up an OS thread (or
  the only JS thread when in ClojureScript). Upon completion of the
  operation, the body will be resumed.

  Returns a channel which will receive the result of the body when
  completed

nil
cljs.user=>(let [x (go 3)] (go (prn (a/<! x))))
#object[cljs.core.async.impl.channels.ManyToManyChannel]
cljs.user=> 3

Moreover, this should be fine.

relevant part from above:
> Implicit macro loading: If a namespace is required or used, and that namespace itself requires or uses macros from its own namespace, then the macros will be implicitly required or used using the same specifications. Furthermore, in this case, macro vars may be included in a :refer or :only spec. This oftentimes leads to simplified library usage, such that the consuming namespace need not be concerned about explicitly distinguishing between whether certain vars are functions or macros. For example:

by
This change happened in https://clojure.atlassian.net/browse/ASYNC-119 in Release 0.3.465 on 2017.11.17
by
Probably a bad choice of words.  What I should have said was when the documentation is followed, macroexpanding a '(go...)' form does not expand the 'go' macro, and just leaves it as is, which is interpreted as an undefined function.

when the :refer is changed to :refer-macros, then '(go ...' is macroexpanded properly
by
Did you see the rest of my answer? What version are you on? I reprod with latest cljs and latest core.async and had no issues.
...