Fork me on GitHub
#clojurescript
<
2020-10-19
>
yuhan13:10:18

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?

victorb13:10:21

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

yuhan14:10:26

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.

victorb10:10:28

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

yuhan11:10:33

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)

leif18:10:51

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?

leif18:10:22

If it helps at all, the source code for the project is here: https://github.com/LeifAndersen/interactive-syntax-clojure

leif18:10:33

OOOH, right.

leif18:10:12

I keep forgetting that #(...) is not a macro for (fn [] ...) but (fn [] (...)) thanks!

dvingo18:10:19

not sure why building it would execute that - but maybe the analysis phase catches or something

leif18:10:29

That would make sense.

leif18:10:37

Given that figwheel doesn't execute it.

dvingo18:10:22

and just fyi - the cause is buried, but it's here for future reference 🙂 https://gist.github.com/LeifAndersen/151858e84d0779df4fcb464a9cd4ebaf#file-gistfile1-txt-L274

leif18:10:53

@danvingo That would explain why I couldn't find it. Thanks. 🙂

leif18:10:59

I'll make sure to look deeper next time.

dvingo18:10:37

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