Re: What if ^:const could inline everything before macroexpanssion?

[Didier]

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.

Re: What if ^:const could inline everything before macroexpanssion?

[juan.facorro]

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.

Re: What if ^:const could inline everything before macroexpanssion?

[juan.facorro]

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.

Re: What if ^:const could inline everything before macroexpanssion?

[Didier]

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.

Re: What if ^:const could inline everything before macroexpanssion?

[juan.facorro]

The compiler seems to currently use the *:const* hint, to know that it 
should return the analyzed expression value for the var (as if it was 
quoted) instead of the *VarExpr* (which would mean a deref at run-time) 
(see here 

).

For the code you posted, my understanding of what the compiler does is:

(def ^:const bar 100)
;; `bar` is created with {:const true} metadata attached to it.

(defmacro foo
  [x]
  (+ 10 x))
;; `foo` macro is created with the function body provided. 

(foo bar)

The list expression `(foo bar)` is identified as a seq so it's analyzed as 
one here <;; 
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L7084>
. This tries to macroexpand the expression, which in this case will result in 
`(foo bar)` being expanded into `(+ 10 foo)`. 

This new expression `(+ 10 foo)` gets analyzed as a seq again, but on 
macroexpansion there's nothing to do, so it's unchanged. 

There are some checks for the first form in the seq which include:

   1. Is it `nil`?
   2. Is it  a var (or does it  resolve to a var) with `:inline` metadata 
   specified which applies to the current number of args (here 
   

   )?
   3. Is it the symbol `fn*`?
   4. Is it any of the special forms?
   5. Otherwise consider it as a function invocation expression.
   
In our example the `+` symbol resolves to the function `clojure.core/+` 
which does have `:inline` metadata for inlining. The inlining works sort of 
like macroexpansion and the `(+ 10 foo)` expression will end up  being `(. 
clojure.lang.Numbers (add 10 foo))` (see here 
 
and here 

).

This expression gets analyzed as a seq as well.  The `.` is a special form 
(see here 
),
 
but that's not important. What we care about at this point is that the 
compiler hasn't tried to resolved the symbol `foo` so far, it will try to 
do so while parsing this DOT expression here 
.
 
This will finally result in the `:const` metadata entry being used in here 

 and 
the constant expression being returned.

So what we end up with is the equivalent to analyzing the expression `(. 
clojure.lang.Numbers (add 10 100))`. 

The JVM probably includes constant folding optimization, but I doubt it's 
able to figure out that `clojure.lang.Number/add` 

 
is number addition.

I hope this helps in somw way. It was a fun exercise. :)

Cheers!

On Monday, November 5, 2018 at 12:07:44 AM UTC+1, Didier wrote:
>
> Macroexpansion is given the raw forms that are read, and I think 
>> that's a good thing. Inside a macro you can always call 
>> macroexpand yourself if you want to (or resolve values another 
>> way) but there's no way to "undo" automatic macroexpansion. 
>>
>
> That's a good point. I guess resolving the constant inside the macro still 
> performs the compile time optimization of in-lining.
>
> I guess my question now becomes, when does const actually expands? Or what 
> does it do exactly? In my mind, it is supposed to inline its usage. So does 
> it do so after expansion?
>  
> On Thursday, 15 March 2018 18:15:16 UTC-7, Carlo Zancanaro wrote:
>>
>> On Thu, Mar 15 2018, Didier wrote: 
>> > 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? 
>>
>> Macroexpansion is given the raw forms that are read, and I think 
>> that's a good thing. Inside a macro you can always call 
>> macroexpand yourself if you want to (or resolve values another 
>> way) but there's no way to "undo" automatic macroexpansion. 
>>
>> As one particular example, how would this work in your world? If 
>> the `bar` is replaced ahead of time in the usage of `l` then it 
>> cannot be shadowed as an identifier. 
>>
>>   (def ^:const bar {:a 100}) 
>>   (defmacro l [name value & body] 
>> `(let [~name ~value] 
>>   ~@body)) 
>>   (l bar 1 
>>  (+ bar 1)) 
>>
>> If you want to factor out things for macros (particularly macros 
>> that you don't control) you can try doing so at read time, with 
>> something that evaluates at read time, like so: 
>>
>>   (def bar {:a 100}) 
>>   (defmacro foo [x] 
>> (:a x)) 
>>   (foo #=(eval bar)) ;; => 100 
>>
>> It's a 

Re: What if ^:const could inline everything before macroexpanssion?

[Didier]

>
> Macroexpansion is given the raw forms that are read, and I think 
> that's a good thing. Inside a macro you can always call 
> macroexpand yourself if you want to (or resolve values another 
> way) but there's no way to "undo" automatic macroexpansion. 
>

That's a good point. I guess resolving the constant inside the macro still 
performs the compile time optimization of in-lining.

I guess my question now becomes, when does const actually expands? Or what 
does it do exactly? In my mind, it is supposed to inline its usage. So does 
it do so after expansion?
 
On Thursday, 15 March 2018 18:15:16 UTC-7, Carlo Zancanaro wrote:
>
> On Thu, Mar 15 2018, Didier wrote: 
> > 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? 
>
> Macroexpansion is given the raw forms that are read, and I think 
> that's a good thing. Inside a macro you can always call 
> macroexpand yourself if you want to (or resolve values another 
> way) but there's no way to "undo" automatic macroexpansion. 
>
> As one particular example, how would this work in your world? If 
> the `bar` is replaced ahead of time in the usage of `l` then it 
> cannot be shadowed as an identifier. 
>
>   (def ^:const bar {:a 100}) 
>   (defmacro l [name value & body] 
> `(let [~name ~value] 
>   ~@body)) 
>   (l bar 1 
>  (+ bar 1)) 
>
> If you want to factor out things for macros (particularly macros 
> that you don't control) you can try doing so at read time, with 
> something that evaluates at read time, like so: 
>
>   (def bar {:a 100}) 
>   (defmacro foo [x] 
> (:a x)) 
>   (foo #=(eval bar)) ;; => 100 
>
> It's a bit messy, but it draws attention to the fact that there's 
> something unusual happening with evaluation order. 
>
> Carlo 
>

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

Re: What if ^:const could inline everything before macroexpanssion?

[Carlo Zancanaro]

On Thu, Mar 15 2018, Didier wrote:
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?


Macroexpansion is given the raw forms that are read, and I think 
that's a good thing. Inside a macro you can always call 
macroexpand yourself if you want to (or resolve values another 
way) but there's no way to "undo" automatic macroexpansion.


As one particular example, how would this work in your world? If 
the `bar` is replaced ahead of time in the usage of `l` then it 
cannot be shadowed as an identifier.


 (def ^:const bar {:a 100})
 (defmacro l [name value & body]
   `(let [~name ~value]
 ~@body))
 (l bar 1
(+ bar 1))

If you want to factor out things for macros (particularly macros 
that you don't control) you can try doing so at read time, with 
something that evaluates at read time, like so:


 (def bar {:a 100})
 (defmacro foo [x]
   (:a x))
 (foo #=(eval bar)) ;; => 100

It's a bit messy, but it draws attention to the fact that there's 
something unusual happening with evaluation order.


Carlo

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


signature.asc
Description: PGP signature

Re: What if ^:const could inline everything before macroexpanssion?

[overtoxic9]

if that < is the prefix that's should work or that programs crappy.

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

What if ^:const could inline everything before macroexpanssion?

[Didier]

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.