This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-05-17
Channels
- # announcements (10)
- # aws (10)
- # babashka (11)
- # beginners (77)
- # calva (9)
- # cider (10)
- # cljdoc (7)
- # cljs-dev (47)
- # clojure (47)
- # clojure-uk (4)
- # clojurescript (87)
- # community-development (15)
- # conjure (14)
- # core-async (25)
- # cursive (6)
- # fulcro (6)
- # helix (3)
- # joker (2)
- # nrepl (1)
- # off-topic (1)
- # pathom (9)
- # pedestal (6)
- # re-frame (22)
- # reitit (15)
- # shadow-cljs (26)
- # spacemacs (16)
- # testing (2)
- # tools-deps (12)
- # uncomplicate (10)
- # xtdb (22)
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 take
ing 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}))
Still trying to find the error heremacroexpand-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
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
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