<div dir="ltr">Macros can be expanded at run-time only if there is another read-time ... (macros are expanded when they are read by the compiler, and the<div>compiler can be used at run-time), I wanted to abstract all those details and go directly to my concern.</div>
<div><br></div><div>If we go back to the specs and forget about the designers if they had other things to think about or not:</div><div><br></div><div>3.1.2.1.2 .... "<span style="color:rgb(0,0,0);font-family:Times;font-size:medium">If the </span><a rel="DEFINITION" href="26_glo_c.htm#car" style="font-family:Times;font-size:medium"><i>car</i></a><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"> of the </span><a rel="DEFINITION" href="26_glo_c.htm#compound_form" style="font-family:Times;font-size:medium"><i>compound form</i></a><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"> is not a </span><a rel="DEFINITION" href="26_glo_s.htm#symbol" style="font-family:Times;font-size:medium"><i>symbol</i></a><span style="color:rgb(0,0,0);font-family:Times;font-size:medium">, then that </span><a rel="DEFINITION" href="26_glo_c.htm#car" style="font-family:Times;font-size:medium"><i>car</i></a><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"> must be a </span><a rel="DEFINITION" href="26_glo_l.htm#lambda_expression" style="font-family:Times;font-size:medium"><i>lambda expression</i></a><span style="color:rgb(0,0,0);font-family:Times;font-size:medium">, in which case the </span><a rel="DEFINITION" href="26_glo_c.htm#compound_form" style="font-family:Times;font-size:medium"><i>compound form</i></a><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"> is a </span><a rel="DEFINITION" href="26_glo_l.htm#lambda_form" style="font-family:Times;font-size:medium"><i>lambda form</i></a><span style="color:rgb(0,0,0);font-family:Times;font-size:medium">." ...</span></div>
<div><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Times;font-size:medium">What if this is replaced by:</span></div><div><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"><br>
</span></div><div><div>3.1.2.1.2' .... "<span style="color:rgb(0,0,0);font-family:Times;font-size:medium">If the </span><a rel="DEFINITION" href="https://mail.google.com/mail/26_glo_c.htm#car" style="font-family:Times;font-size:medium"><i>car</i></a><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"> of the </span><a rel="DEFINITION" href="https://mail.google.com/mail/26_glo_c.htm#compound_form" style="font-family:Times;font-size:medium"><i>compound form</i></a><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"> is not a </span><a rel="DEFINITION" href="https://mail.google.com/mail/26_glo_s.htm#symbol" style="font-family:Times;font-size:medium"><i>symbol</i></a><span style="color:rgb(0,0,0);font-family:Times;font-size:medium">, then that </span><a rel="DEFINITION" href="https://mail.google.com/mail/26_glo_c.htm#car" style="font-family:Times;font-size:medium"><i>car</i></a><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"> is either a </span><i style="font-family:Times;font-size:medium"><a rel="DEFINITION" href="https://mail.google.com/mail/26_glo_l.htm#lambda_expression" style="font-family:Times;font-size:medium">lambda expression</a></i><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"> in which case the </span><a rel="DEFINITION" href="https://mail.google.com/mail/26_glo_c.htm#compound_form" style="font-family:Times;font-size:medium"><i>compound form</i></a><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"> is a </span><i style="font-family:Times;font-size:medium"><a rel="DEFINITION" href="https://mail.google.com/mail/26_glo_l.htm#lambda_form" style="font-family:Times;font-size:medium">lambda form</a> or it is </i><i style="font-family:Times;font-size:medium">a </i><i style="font-family:Times;font-size:medium"><a rel="DEFINITION" href="26_glo_m.htm#macro_form" style="font-family:Times;font-size:medium">macro form</a> </i><i style="font-family:Times;font-size:medium">...</i><span style="color:rgb(0,0,0);font-family:Times;font-size:medium">" ...</span></div>
</div><div><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Times;font-size:medium">Does this contradict anything else in the spec?</span></div>
<div><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"><br></span></div><div><span style="color:rgb(0,0,0);font-family:Times;font-size:medium">-Taoufik</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Jun 24, 2014 at 10:20 PM, Ron Garret <span dir="ltr"><<a href="mailto:ron@flownet.com" target="_blank">ron@flownet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>No. Macros can be expanded at run-time, or they can be expanded before run-time (but after read time) in a separate phase called compile-time. This is how CCL works, but not all Common Lisps work that way. If you do not separate compile-time/macroexpansion-time in your mental model you will be confused.</div>
<div><br></div><div>And CL was not designed by a single person, it was designed by a committee. My guess as to the reason the committee decided to make ((…) …) a syntax error is that deciding on what the semantics of this construct should be is not so easy, and they had other fish to fry. But I wasn’t there.</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>rg</div></font></span><div><div class="h5"><div><br><div><div><div><br><div><div>On Jun 24, 2014, at 12:54 PM, Taoufik Dachraoui <<a href="mailto:dachraoui.taoufik@gmail.com" target="_blank">dachraoui.taoufik@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">well, macros are expanded before runtime; the specs 'read time' is in my informal 'read time'; for me 'read time' is <div>everything before 'run time'; So 'read time' is the time taken to transform an expression to another (macro characters,</div>
<div>macro forms, ...) one that can be executed (evaluated).<div><div><br></div><div>I am not confused, and it is not an issue for me right now; it is just I am not strictly abiding to the standard wordings; </div><div>as you see, at the end of your reply you are addressing exactly my concern; this proves that you understood what I </div>
<div>am trying to explain.</div><div><br></div><div>So if I understand, ((...) ...) is useful but the only issue is that CL standard does not allow it. </div><div><br></div><div>Well, this does not explain why the designer of CL did choose to make ((...) ...) a syntax error, and this is</div>
<div>what I want to learn.</div><div><br></div><div>Taoufik</div><div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 24, 2014 at 8:50 PM, Ron Garret <span dir="ltr"><<a href="mailto:ron@flownet.com" target="_blank">ron@flownet.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well, macros are never expanded at read time, so you have some fundamental confusion there. The reader (which is what is operating at read time) converts a sequence of characters into Lisp data structures. Macros convert Lisp data structures into other Lisp data structures, so they cannot possibly operate at read time.<br>
<br>
You are also making a mistaken assumption about how macro expansion works. You should read section 3.1.2.1.2 of the spec, and pay particular attention to the third and fourth paragraphs. (You should also read all four of the sub-sections, and particularly 3.1.2.1.2.2.)<br>
<div><br>
> Now if the compiler behaves as I described above, does this cause any language design issue or anything?<br>
<br>
</div>That is a matter of some debate. On the one hand, it changes the semantics of the language in a way that is directly contradictory to the spec. The spec REQUIRES that ((…) …) is a syntax error unless the car of the list is a lambda form. On the other hand, extending the language to do something reasonable with ((…) …) is necessarily backwards-compatible for code that does not generate such errors. So CL purists tend to recoil in horror when they see combination-hook, but IMHO it’s a useful extension to the language, particularly in cases where you want to do some hard-core functional programming without cluttering up the code with a zillion FUNCALLs. But not-entirely-unreasonable people can and do disagree.<br>
<span><font color="#888888"><br>
rg<br>
</font></span><div><div><br>
On Jun 24, 2014, at 11:32 AM, Taoufik Dachraoui <<a href="mailto:dachraoui.taoufik@gmail.com" target="_blank">dachraoui.taoufik@gmail.com</a>> wrote:<br>
<br>
> Hi<br>
><br>
> Thank you for the reply, even though the tweak is great it is not what I meant really. I am mostly<br>
> interested to know why the compiler, as defined by the standard, at read time do not expand all<br>
> macro forms whenever it encounters one, even when the operator of the expression is a<br>
> macro form. Any expression is evaluated only after macro expansions, so I expect that any<br>
> expression, even ((...) ...), must be considered valid if after macro expansion it generates a valid<br>
> expression.<br>
><br>
> Your tweak shows that there is a need (you did it to be able to do interesting things) and it is what<br>
> we intuitively expect when we (at least myself) learn about macros at first sight.<br>
><br>
> Now if the compiler behaves as I described above, does this cause any language design issue or<br>
> anything?<br>
><br>
> Kind regards<br>
> Taoufik<br>
><br>
><br>
><br>
> On Tue, Jun 24, 2014 at 5:37 PM, Ron Garret <<a href="mailto:ron@flownet.com" target="_blank">ron@flownet.com</a>> wrote:<br>
> This is defined in CL to be a symtax error. The head of a form can be a symbol or a lambda expression but not a macro. You will notice that not only does this code not macroexpand, it won’t run either.<br>
><br>
> It is possible to tweak macroexpand-all and the CCL compiler so that both accept ((…) …) syntax. I’ve attached the code to do the latter; the former is left as an exercise.<br>
><br>
> rg<br>
><br>
> On Jun 24, 2014, at 4:39 AM, Taoufik Dachraoui <<a href="mailto:dachraoui.taoufik@gmail.com" target="_blank">dachraoui.taoufik@gmail.com</a>> wrote:<br>
><br>
> > Hi<br>
> ><br>
> > Is there a reason why macroexpand-all does not expand macros placed in the<br>
> > head of a list:<br>
> ><br>
> > ? (defmacro g (x y) `(lambda (,x) ,y))<br>
> > G<br>
> > ? (macroexpand-all '((g x (+ x 1)) 3))<br>
> > ((G X (+ X 1)) 3)<br>
> ><br>
> > What if it is the case what could be the issue?<br>
> ><br>
> > -Taoufik<br>
> > _______________________________________________<br>
> > Openmcl-devel mailing list<br>
> > <a href="mailto:Openmcl-devel@clozure.com" target="_blank">Openmcl-devel@clozure.com</a><br>
> > <a href="http://lists.clozure.com/mailman/listinfo/openmcl-devel" target="_blank">http://lists.clozure.com/mailman/listinfo/openmcl-devel</a><br>
><br>
<br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></div></div></div></blockquote></div><br></div>