Hi, I discovered a difference in the way macroexpand
works in clojurescript vs clojure, when given non-seqable arguments like keywords:
user=> (macroexpand :abc)
:abc
user=> (macroexpand 123)
123
These work fine in clojure but throw a "X is not seqable" error in CLJS.
Is this a bug or some sort of undefined behaviour?yeah, my thinking is that if you call macroexpand in the cljs context, it'll evaluate whatever you pass into it as it's being defined in that context, eg it's being defined in the cljs context.
So if you :refer-macros something that is using :abc
, do you get the same result as if you defined :abc
in clj context or cljs? I'm unsure, just a hunch of what could be going on here
What does it mean to "use" :abc? It's a literal non-namespaced keyword, I just used a keyword as an example. The same happens with numbers, booleans, anything that's not seqable. (macroexpand true)
there is bunch of differences in how clojure and clojurescript handles macros. For example you wouldn't define macros in cljs files at all but in clojure files, then :refer-macros them into cljs context. Maybe related to that? Check out https://clojurescript.org/about/differences if you haven't already, especially the macros section
yes I'm aware of those differences, but this seems like an unrelated issue about how the macroexpand
function handles edge cases where the input is not some kind of quoted list.
So, I'm getting a rather odd(opaque to me) error when building a project: https://gist.github.com/LeifAndersen/151858e84d0779df4fcb464a9cd4ebaf But it runs fine when building/running with figwheel: https://gist.github.com/LeifAndersen/483f22c99606cf7484fc9a99a5b3ca2a Does anyone have any ideas what my cause this error?
If it helps at all, the source code for the project is here: https://github.com/LeifAndersen/interactive-syntax-clojure
https://github.com/LeifAndersen/interactive-syntax-clojure/blob/main/src/interactive_syntax/core.cljs#L61 looks like this is the issue - invoking false as a function
OOOH, right.
I keep forgetting that #(...)
is not a macro for (fn [] ...)
but (fn [] (...))
thanks!
not sure why building it would execute that - but maybe the analysis phase catches or something
That would make sense.
Given that figwheel doesn't execute it.
and just fyi - the cause is buried, but it's here for future reference 🙂 https://gist.github.com/LeifAndersen/151858e84d0779df4fcb464a9cd4ebaf#file-gistfile1-txt-L274
@danvingo That would explain why I couldn't find it. Thanks. 🙂
I'll make sure to look deeper next time.
all good, took me a while to get used to visually filtering stack traces
I think if you use Clojure 1.10.1 you should get a much better error report focused on the cause with that.
looks like you are though, so must be something else dumping the full exception stack then
I guess it must be cljs doing that, maybe an area that could be easily improved with the newer facilities in Clojure 1.10