Re: Something I don't understand about macros and special operators
- From: "Kaz Kylheku" <kkylheku@xxxxxxxxx>
- Date: 19 Oct 2005 10:03:12 -0700
K. Ari Krupnikov wrote:
> CL-USER> (macroexpand-1 '(mydefun carmap (function &rest lists)
> (apply #'mapcar function lists)))
> (DEFUN CARMAP (FUNCTION &REST LISTS) (APPLY #'MAPCAR FUNCTION LISTS))
>
> CLISP seems to be interpreting 'function' before expanding the macro,
> in some cases (as if I'd written #'). Is this expected behavior? Is it
> because finction is a special operator?
The important thing to understand is that the input and output of the
MACROEXPAND-1 function here are both /data/, not /code/. The /data
object/ (FUNCTION X), an ordinary list, is specially recognized and
rendered as the /text notation/ #'X. That of course has to do with its
role as an operator; Lisp programmers more frequently use the #'X
notation to the (FUNCTION X) one. Similarly (QUOTE X) gets rendered as
'X. But the semantics of these operators is not involved in the
rendering in any way. It's just a ``dumb filter'' in the Lisp printer
which looks for these patterns and provides an alternate text rendering
for them.
You have to understand that #'X and (FUNCTION X) are exactly the same
object: they are the same list under the EQUAL function, and in fact if
you quote them one more time, they may even be EQ!!! That is to say, if
you write '#'X in one part of the program, and '(FUNCTION X) somewhere
else, these two equivalent list literals may get merged into one object
in the compiled image. The two notations are equivalent in the same
sense that, for instance, #xFF and 255 are equivalent. If you type #xFF
into your Lisp, it will come back as 255, unless you fiddle with the
*print-base*.
But the object (FUNCTION &REST ARGS) cannot be rendered in the #'
notation, and so it is printed plainly. The printer has to watch out
for such anomalous cases and take care that they are printed without
loss of information.
But CLISP's printer is not so kind toward ``secret'' expressions headed
by its own internal symbols in the SYSTEM package. If you generate
these with extra arguments, they may still print using the special
notation, with your extra data disappearing:
For instance try these (I'm trying them on CLISP 2.33):
'(SYSTEM::BACKQUOTE X) ==> `X
'(SYSTEM::BACKQUOTE X Y) ==> `X # What happened to Y?
'(SYSTEM::BACKQUOTE X Y Z) ==> `(SYSTEM::BACKQUOTE X Y Z)
Y disappeared because the extra argument of a backquote is used for
stashing extra information during the processing of backquotes which
originally did not have any additional argument. That info must not be
printed. So the Y is assumed to be that extra info added by the
backquote processor, rather than information that came from the user.
This is okay because the user should not be using symbols in the SYSTEM
package as data anyway! So there is no reason to read and write lists
headed by SYSTEM::BACKQUOTE with perfect information fidelity.
It's kind of like sticking your fork into a toaster.
.
- References:
- Something I don't understand about macros and special operators
- From: K. Ari Krupnikov
- Something I don't understand about macros and special operators
- Prev by Date: Re: Request for comments on this code and ways to improve it.
- Next by Date: Re: Request for comments on this code and ways to improve it.
- Previous by thread: Re: Something I don't understand about macros and special operators
- Next by thread: CL failure stories?
- Index(es):
Relevant Pages
|
