[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(macro . atom)



Consider the following macro definitions:

		  (defmacro MACW (&whole w) `(- ,(cdr w)))
		  (defmacro MACR (&rest r) `(- ,r ))

and  uses of them:

(a)				(MACW . 1)
(b)				(MACR . 1)


I tried these on 3 CL implementations, with the following results:
1) Implementation 1 accepted both forms, binding w to (MACW . 1) in (a)
   and r to T in (b)
2) Implementation 2 treated case (a) the same as implementation 1, but
    rejected (b), saying that T was not a list.
3) Implementation 3 rejected both cases, saying that T was not a list.
   Interestingly, it gladly accepted both forms as arguments to
   MACROEXPAND-1, binding w and r the same as implementation 1.

Question#1 -- what is the allowable behavior of an implementation in 
 the case of (MACR . T)?  Are all 3 valid?

Question#2  -- what about the case of (MACW . T)?  Should my MACW code
   be portable, or am I just lucky that 2 of these implementations let me
   get away with it?  

----------------------------------------------------------------
Relevant sections of CLtL:
  On P.54, it states that only certain forms are "meaningful":
self-evaluating forms, symbols, and "lists".  If (MACW . T) and (MACR . T)
are "meaningful", they must be lists.
  On Pp. 26-27, we have definitions of LIST and DOTTED LIST.  (My examples
are dotted lists).  In the middle of P.27 is a rather odd paragraph.  First
it seems to say that uses of the term LIST in the book include dotted
lists, and the the term "true list" will be used if dotted lists are
to be excluded.  It then says that if the book specifies that an
argument must be a "list",  it really means "true list"; that a
dotted list is an error.
 A discussion of Destructuring macro arguments appears on P.146 .  It
allows dotted lists as or within individual arguments in macro
calls -- e.g. (mac (foo . fum)), (mac (3 (foo . fum) 4)), and I read into
that an implication that I can expect &rest args (at least embedded ones)
to bind to dotted lists or non-NIL atoms.  [I'd like to think that there
is nothing special about non-embedded &rest args -- that they, too, could
bind to dotted lists or non-NIL atoms.   But I can't say that anything
on P.146 really implies that.]

P.146 also allows dotted lists in the lambda list of a macro definition, but
states that they are equivalent to something that could be written with
&rest.
----------------------------------------------------------------
So, just what is the intent of the use of "list" on pp. 54-59?  Are dotted
lists portable as macro calls?  If so, is &whole the only portable way
to accept them?  What about as function calls? [there is no &whole
for function lambda lists.]

Incidentally, I believe I have a justifiable reason to want a dotted list
to be acceptable as a macro form.  It would be slightly more convenient
if I could use a macro lambda list with an &REST in it, rather than
resorting to &WHOLE, but that's no big deal.

I would like to see the issue clarified so that
a) dotted lists are legal as macro calls (but not as function calls if
   that forces added run-time costs in APPLY or ordinary function calling.)
b) &rest parameters in  macro lambda lists may bind to dotted lists or
   non-NIL atoms.  This applies to top-level as well as embedded &rest
   parameters.


Neil