<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 class=""><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 class="HOEnZb"><font color="#888888"><br>
rg<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Jun 24, 2014, at 11:32 AM, Taoufik Dachraoui <<a href="mailto:dachraoui.taoufik@gmail.com">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">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">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">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>