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

[no subject]

ALAN said today "hey, you know, there are a whole *hell* of a lot
of symbols which are |FOOBAR MACRO| now in maclisp, sounds like
time for a MACRO-SUBR property". We talked about this for
a while, (many obvious problems, many not so obvious), and
came up with the following scheme, which will save
space and hair.

(defmacro <name> <argument-list>
          <body>)

Will give <name> a MACRO property of MACRO-HANDLER and
a MACRO-EXPR property of whatever is made from the <argument-list>
and the <body>. When compiled a MACRO-SUBR property will be given.
Then the MACRO-HANDLER will deal with all the displacing and
number-of-arguments checking, and perhaps even with the destructuring.
[The ARGS property could be used for the number-of-arguments check.]

Presently, macros turn into gross stuff, example:

(defmacro aset (val ar &rest l) `(store (funcall ,ar ,@l) ,val))

(grindef aset)

(DEFUN ASET MACRO (ASET-MACROARG) 
  (COMMENT ARGLIST = (VAL AR &REST L))
  (OR (MACROFETCH ASET-MACROARG)
      (MACROMEMO ASET-MACROARG
		 (PROGN (AND (NOT (NOT (< (LENGTH ASET-MACROARG) 3)))
			     (ERROR '|Wrong number args to a macro call|
				    ASET-MACROARG))
			(LET (((VAL AR . L) (CDR ASET-MACROARG)))
			     `(STORE (FUNCALL ,AR ,@L) ,VAL)))
		 'ASET)))

Not only is this a waste of time to look at, it wastes space
in sorely pressed maclisp.
With the ALAN/GJC scheme (grindef aset) would show

(DEFUN (ASET MACRO-EXPR) (ASET-MACROARG)
       (LET (((VAL AR . L) (CDR ASET-MACROARG)))
	    `(STORE (FUNCALL ,AR ,@L) ,VAL)))

In summary, the only thing which would have to be changed is
Defmacro and Grindef.

p.s. The advantage of having a Handler do the destructuring
(which we haven't shown here), is that it could afford (in space) to do
it correctly! Presently a compiled "defmacro" gets no error checking
in maclisp. e.g. (defmacro foo ((a . b) . c) `(bar ',a ',b . ,c))
(foo 1 2 3) macroexpands into (bar 'nil '#1 2 3). 

The hacker general has long determined that having macros expand into
totally random pointers generated by HLRZ and HRRZ is hazardous
to your health.