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.

Reply via email to