[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: rms at MIT-AI
- From: JONL at MIT-MC (Jon L White)
- Date: Tue, 3 Jul 79 07:14:00 GMT
- Cc: (BUG LISP) at MIT-MC
- Original-date: 3 JUL 1979 0314-EDT
Date: Wed, 28 Jun 79 22:17:34 GMT
Original-Date: 06/28/79 18:17:34 EDT
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)
(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.