[no subject]

[JONL at MIT-MC (Jon L White)]

From:     RMS@MIT-AI
Date: Wed, 28 Jun 79 22:17:34 GMT
Original-Date: 06/28/79 18:17:34 EDT
Subject:
    To: (BUG LISP) at MIT-AI
    Maclisp DEFMACRO doesn't use *MACROARG* to hold the form
    which makes it incompatible with Lispm DEFMACRO.
    It is necessary to use *MACROARG* to tell for certain
    whether an optional arg was supplied or not.

There are 3 reasons why the maclisp DEFMACRO does not use *MACROARG*
in imitation of the LISPM defmacro:
1) It is not a documented feature of defmacro in the LISPM manual,
   so any dependence upon it is a kludge that deserves to lose randomly.
2) In order to determine how many args are actually being passed, when
   there are &optional (or &rest) variables, it would be nice to have a 
   method consistent between both DEFUN and DEFMACRO.  Using *MACROARG*
   defeats this goal.  Admittedly, there is no "ARG" function for either
   DEFUN or DEFMACRO, but having pored over much LISPM and MACLISP
   code, I can say that using some distinctive marker as the default
   value for the optional variable *is* is consistent and workable.
   [This "distinctive marker" may have to be suitable constructed from
   a description of the program - I doubt that a single marker would work
   for all possible programs].
3) There is an inherent flaw in scoping, when using just a single name
   such as *MACROARG*, illustrated by the following:
	(DEFMACRO BLETCH (A &OPTIONAL B)
	   `(RUN ,a (RLIST ,(cond ((cddr *MACROARG*) b)
				  (default-value-for-b))
			    ,a)))
	(DEFMACRO RLIST (X Y) `(LIST ,y ',(eval x)))  
   Admittedly, this sort of thing, explicit calling of EVAL, leads one
   to all sorts of non-modularity bugs, but here the problem is even
   more obscured, since there is nothing in the code to suggest that
   the "free(?)" variable *MACROARG* will be captured by the scope 
   of RLIST.  The maclisp DEFMACRO uses a name constructed by string-
   appending the macro name to "-MACROARG", so that *MACROARG* in the
   definition of BLETCH above would become BLETCH-MACROARG;  however
   I'm not fully satisfied with that, for I'm sure there are some
   glitch cases even there.