[Openmcl-devel] macroexpand-all

[Taoufik Dachraoui]

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/5cbd6669/attachment.htm>