Ah right, I see now. Ya, so it seems macros are fully expanded first, and then constant are inlined, and then code is evaled.
So there's really no way to specify a global to be used within a macro itself, unless you resolve it explicitly within your macro, using resolve or eval, or if you use the reader eval when calling you macro. On Wednesday, 7 November 2018 02:20:06 UTC-8, juan.facorro wrote: > > Sorry, I now understand what you mean. > > The unfolding logic that I proposed before was completely missing the fact > that the foo macro is not: > > (defmacro foo > [x] > `(+ 10 ~x)) > > But: > > (defmacro foo > [x] > (+ 10 x)) > > The following assertion from the previous post is blatantly wrong with the > correct macro definition above: > >> This tries to macroexpand the expression, which in this case will result in >> `(foo bar)` being expanded into `(+ 10 foo)`. > > So when evaluating (foo bar) we do get the exception you mention, of > course, since on macroexpansion we are trying to add 10 and the symbol bar > . > > It is still the case as before though that the macroexpansion of (foo > bar)happens > before the symbol bar is resolved and analyzed as a constant expression. > > Sorry for the mess and confusion. > > On Wednesday, November 7, 2018 at 11:04:27 AM UTC+1, juan.facorro wrote: >> >> That's strange, this is what I get in the REPL when evaluating that >> expression: >> >> $ clj >> Clojure 1.9.0 >> user=> (. clojure.lang.Numbers (add 10 100)) >> 110 >> user=> >> >> >> >> On Wednesday, November 7, 2018 at 10:01:20 AM UTC+1, Didier wrote: >>> >>> Hey, thanks for the deep dive, but I'm not sure I either understand, or >>> that it is correct. >>> >>> So what we end up with is the equivalent to analyzing the expression `(. >>>> clojure.lang.Numbers (add 10 100))`. >>>> >>> >>> When I run my example, I get: >>> >>> ClassCastException clojure.lang.Symbol cannot be cast to java.lang. >>> Number clojure.lang.Numbers.add >>> >>> When I macroexpand-1 my example, I also get the same ClassCastException. >>> >>> But if we follow your step by step, you make it sound like it would work >>> and return 110. >>> >>> So at which step would this exception be thrown? And why? >>> >>> >>> On Thursday, 15 March 2018 11:11:24 UTC-7, Didier wrote: >>>> >>>> I was hoping that ^:const would be able to inline any symbol value and >>>> that it would do so before macroexpanssion so that: >>>> >>>> (def ^:const bar {:a 100}) >>>> >>>> (defmacro foo >>>> [x] >>>> (:a x)) >>>> >>>> (foo bar) >>>> >>>> Would return: >>>> >>>> 100 >>>> >>>> The same way that: >>>> >>>> (foo {:a 100}) >>>> >>>> does. >>>> >>>> Then I read that ^:const only inlines primitive values (which >>>> disappointed me), but so I thought that this would work: >>>> >>>> (def ^:const bar 100) >>>> >>>> (defmacro foo >>>> [x] >>>> (+ 10 x)) >>>> >>>> (foo bar) >>>> >>>> but that also doesn't work. >>>> >>>> So now I believe that ^:const inlines after macroexpanssion. >>>> >>>> I feel it would be really cool to be able to factor some input to >>>> macros into constants, is this something I could open a ticket for, to >>>> extend ^:const so it can inline all literal values and also does the >>>> inlining before macroexpanssion so that the above would work? >>>> >>> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.