[Openmcl-devel] macroexpand-all

[Ron Garret]

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.

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

> Now if the compiler behaves as I described above, does this cause any language design issue or anything?

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.

rg

On Jun 24, 2014, at 11:32 AM, Taoufik Dachraoui <dachraoui.taoufik at gmail.com> wrote:

> Hi
> 
> Thank you for the reply, even though the tweak is great it is not what I meant really. I am mostly 
> interested to know why the compiler, as defined by the standard, at read time do not expand all
> macro forms whenever it  encounters one, even when the operator of the expression is a 
> macro form. Any expression is evaluated only after macro expansions, so I expect that any
> expression, even ((...) ...), must be considered valid if after macro expansion it generates a valid
> expression.
> 
> Your tweak shows that there is a need (you did it to be able to do interesting things) and it is what
> we intuitively  expect when we (at least myself) learn about macros at first sight.
> 
> Now if the compiler behaves as I described above, does this cause any language design issue or 
> anything?
> 
> Kind regards
> Taoufik
> 
> 
> 
> On Tue, Jun 24, 2014 at 5:37 PM, Ron Garret <ron at flownet.com> wrote:
> 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.
> 
> 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.
> 
> rg
> 
> On Jun 24, 2014, at 4:39 AM, Taoufik Dachraoui <dachraoui.taoufik at gmail.com> wrote:
> 
> > Hi
> >
> > Is there a reason why macroexpand-all does not expand macros placed in the
> > head of a list:
> >
> > ? (defmacro g (x y) `(lambda (,x) ,y))
> > G
> > ? (macroexpand-all '((g x (+ x 1)) 3))
> > ((G X (+ X 1)) 3)
> >
> > What if it is the case what could be the issue?
> >
> > -Taoufik
> > _______________________________________________
> > Openmcl-devel mailing list
> > Openmcl-devel at clozure.com
> > http://lists.clozure.com/mailman/listinfo/openmcl-devel
>