Fork me on GitHub

Hi, I discovered a difference in the way macroexpand works in clojurescript vs clojure, when given non-seqable arguments like keywords:

user=> (macroexpand :abc)
user=> (macroexpand 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?


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 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.


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)


So, I'm getting a rather odd(opaque to me) error when building a project: But it runs fine when building/running with figwheel: Does anyone have any ideas what my cause this error?


If it helps at all, the source code for the project is here:


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 🙂


@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

Alex Miller (Clojure team)19:10:03

I think if you use Clojure 1.10.1 you should get a much better error report focused on the cause with that.

Alex Miller (Clojure team)19:10:02

looks like you are though, so must be something else dumping the full exception stack then

Alex Miller (Clojure team)19:10:45

I guess it must be cljs doing that, maybe an area that could be easily improved with the newer facilities in Clojure 1.10