[Openmcl-devel] macroexpand-all

[Ron Garret]

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.

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.

rg


On Jun 24, 2014, at 12:54 PM, Taoufik Dachraoui <dachraoui.taoufik at gmail.com> wrote:

> well, macros are expanded before runtime; the specs 'read time' is in my informal 'read time'; for me 'read time' is 
> everything before 'run time'; So 'read time' is the time taken to transform an expression to another (macro characters,
> macro forms, ...) one that can be executed (evaluated).
> 
> 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; 
> as you see, at the end of your reply you are addressing exactly my concern; this proves that you understood what I 
> am trying to explain.
> 
> So if I understand, ((...) ...) is useful but the only issue is that CL standard does not allow it. 
> 
> Well, this does not explain why the designer of CL did choose to make ((...) ...) a syntax error, and this is
> what I want to learn.
> 
> Taoufik
> 
> 
> 
> On Tue, Jun 24, 2014 at 8:50 PM, Ron Garret <ron at flownet.com> wrote:
> 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
> >
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20140624/be1f48ed/attachment.htm>