In 3.1.2.1.2.2 (Macro Forms), it says:
An implementation is free to implement any macro operator as a
special operator, but only if an equivalent definition of the macro
is also provided.
Can someone help me understand the implications of this statement?
Does that mean that the implemenattion is allowed to have a compiler
that recognizes some particular macro form and compile it directly
rather than macro expanding it and then compiling the resulting code?
If so, why does it matter if there's also an equivalent macro
definition?
My guess at an answer is that maybe as a user I may want to write some
sort of code walker and other than the 27 special forms listed in
3.1.2.1.2.1, I should be able to macro expand any cons that isn't a
function call or lambda expression and then manipulate that code, even
if the compiler would have compiled the macro directly had I not
mucked with it. Is that something like the reason?
-Peter
--
Peter Seibel ·····@javamonkey.com
The intellectual level needed for system design is in general
grossly underestimated. I am convinced more than ever that this
type of work is very difficult and that every effort to do it with
other than the best people is doomed to either failure or moderate
success at enormous expense. --Edsger Dijkstra
From: Joe Marshall
Subject: Re: Macros as Special Operators
Date:
Message-ID: <isu74jrq.fsf@ccs.neu.edu>
Peter Seibel <·····@javamonkey.com> writes:
> In 3.1.2.1.2.2 (Macro Forms), it says:
>
> An implementation is free to implement any macro operator as a
> special operator, but only if an equivalent definition of the macro
> is also provided.
>
> My guess at an answer is that maybe as a user I may want to write some
> sort of code walker... Is that something like the reason?
yes.
Peter Seibel <·····@javamonkey.com> wrote in message news:<··············@localhost.localdomain>...
> In 3.1.2.1.2.2 (Macro Forms), it says:
>
> An implementation is free to implement any macro operator as a
> special operator, but only if an equivalent definition of the macro
> is also provided.
>
> Can someone help me understand the implications of this statement?
> Does that mean that the implemenattion is allowed to have a compiler
> that recognizes some particular macro form and compile it directly
> rather than macro expanding it and then compiling the resulting code?
It's the prohibition against redefining standard functions and macros
which gives the implementor *this* particular freedom. If a program
which redefines a standard macro or function is considered broken,
then the compiler can ignore that possibility. When it encounters a
call of that macro or function, it can do whatever it wants to bring
about the standard behavior. Rather than expand the macro normally, or
call a function, it can insert some inline machine code, say.
> If so, why does it matter if there's also an equivalent macro
> definition?
Because if the spec says that X is a macro, then a conforming program
can then assume that certain things work, like (macroexpand '(X ...)),
(symbol-function 'X) and so on. If these were allowed randomly break
on standard macros, then there would no point in stating that they are
macros. ;)
> My guess at an answer is that maybe as a user I may want to write some
> sort of code walker and other than the 27 special forms listed in
> 3.1.2.1.2.1, I should be able to macro expand any cons that isn't a
> function call or lambda expression and then manipulate that code, even
> if the compiler would have compiled the macro directly had I not
> mucked with it. Is that something like the reason?
That's an unlikely reason, because an implementation can have
additional special forms. So it's not the case that all macros must
reduce to that set of 27 which you can then handle and be done with
it. Requiring things that are specified as macros to really be macros
does not really help the code walker writer in any way that is obvious
to me. When you expand that cons, you can still get something that
contains special forms, and non-standard ones too.