If you're doing it in a macro, then <! won't compile if it's not in a go block anyway. But I have to ask, why?

i understand it won't compile, my problem is that it will raise the error too late for me. i'd like to write a macro that will fail immediately if it is not in a go block, similar to calling <! directly i am writing a macro that does two things: 1. send an async http request. the http-send fn returns a channel 2. take from that channel using <!. if my macro is called outside of a go block, it will fail on 2. i want it to fail before 1 occurs i.e. before sending the http request

Roughly, something like

(defmacro send!
  [req]
  `(let [p# (a/promise-chan)]
     (http/send req (fn [resp#] (a/put! p# resp#)))
     (a/<! p#)))

but the send will still occur instead of not execute and crash

i want to avoid the send

It won't. This macro won't even compile (not talking about run, but compile) if it's not in a go block.

but I would just return a channel instead of hiding it behind magic

Having had to deal with something very similar just a few days ago =\

i don't understand why

that is, why won't it compile

the stage where there's a put/take come after the send

ach, my bad, <! is defined as a function and not a macro, it will only throw at runtime

which brings us back to my other recommendation anyway, use a function and not a macro, return a channel and handle it in the go block

Which, when you say "I have a macro that does two things", should raise a flag - why not compose two separate things?

the first stage is happening in a different function that sends http and async puts on a chan and returns that chan

Use some function like this to turn an async function to a function which returns a channel:

(defn afn->p
  [af]
  (fn [ctx]
    (let [p (a/promise-chan)]
      (af ctx (fn [result] (a/put! p result)))
      p)))

So just work with a bare channel. In this context you should treat it like a promise or a completion stage

thanks. i was hoping theres a way around that 😕 i'm writing a helper function to on board code which doesn't yet support async.core channels

Can you elaborate a bit? core.async is great but it's not necessarily a fit in every situation. Why should code support it to begin with? Shouldn't it be generic and be open to adaptation by building an abstraction layer / good separation of existing layers?

<!! will take from a channel in a blocking way. That might be what you want. But to @UK0810AQ2’s point - core.async isn’t necessarily a fit in every situation

Hi. yes, i will do that tomorrow, sorry for long delay

thank you for all the assistance

it works fine:

((apply juxt (list true? false? string?)) "foo")

the problem is that '(true? false? string?) doesn’t evaluate to what you think it does. evaluate it in the repl

a hint, what is 'true? ?

Ahh I see, it's creating a list of symbols… I guess I need to refresh my memory on how quoting works

Thank you!

you’re welcome

It's symbolsturtles all the way down 😉