Hi all, is there a reason this snippet throws Could not resolve var: -has?

(macroexpand-1
 '(go
    (let [[v ch :as ret] (a/alts! [-has -insert])]
      ret)))

What are -has and -insert here? They should be channels

They are. Taken from vectors of channels, like (has i) with has being (vec (repeatedly (+ 1 limit) chan)), and -insert is similarly defined. I drilled down into this trying to debug why I was takeing from nil in a much larger piece of code:

(defn rec-set
  [limit]
  (let [has (vec (repeatedly (+ 1 limit) chan))
        insert (vec (repeatedly (+ 1 limit) chan))
        s0 (chan)]
    (loop [i 0]
      (when (< i limit)
        (let [i+1 (inc i)
              -has (has i)
              +has (has i+1)
              -insert (insert i)
              +insert (insert i+1)]
          (go
            (let [n
                  (loop []
                    (a/alt!
                      -has ([_] (>! s0 false) (recur))
                      -insert ([v] v)))]
              (loop [n n]
                (a/alt!
                  -has
                  ([m]
                   (cond
                     (<= m n) (>! s0 (= m n))
                     (> m n)  (>! +has m))
                   (recur n))
                  -insert
                  ([m]
                   (cond
                     (< m n) (do (>! +insert n) (recur m))
                     (> m n) (do (>! +insert m) (recur n))
                     (= m n) (recur n)))))))
          (recur (inc i)))))
    {:has (has 1) :insert (insert 1) :s0 s0})) 

macroexpand-1 may just not not work on go macro calls with free variables (because the go macro is very complicated internally, even doing its own macro expansion)

Which is to say, symbol resolution errors typically occur later in the compilation process than macro expansion, so you can usually expand macros with free symbols just fine, but the go macro is a compiler in a macro, which means when macro expanding it you can get errors from later stages in the compilation process. Just a guess, I am not at a repl to test it out

damn, makes debugging the big form harder

If that is the case you just need to make the symbols not free

But I doubt macroexpand core async forms is ever going to make it easier to understand

That would be tricky because the error I'm getting is that I'm trying to take! from nil, meaning one of the alt s is borked

But if I just print all the -+has and -+insert chans non of them are nil

I would start by sticking asserts before each alt

That's an excellent idea

won't it throw in the executor pool, though?

That is fine

And I would double check that your error is actually coming from that code

I forget if vectors as functions behave like get or nth

Get returns nil for unkown indices, nth throws

So if vectors as functions act like get, you can replace with calling nth to get earlier errors to track things back closer to the source

omg

I found the error

it's so silly

My error was in the api. The code is good

Thanks for giving it a look over 🙃

Looking over macro expanded go blocks is extremely tedious, and ideally only something to do if you are sure there is a bug in the go macro

Well, the bug was as it most often is, between the chair and the keyboard