[Openmcl-devel] macroexpand-all

[Taoufik Dachraoui]

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/9315fa4a/attachment.htm>