[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Misfeature: macros expanding into declarations
- To: Fahlman@CMU-CS-C
- Subject: Misfeature: macros expanding into declarations
- From: Tim McNerney <TIM@MIT-MC>
- Date: Sat, 4 May 85 18:26:24 EST
- Cc: TIM@MIT-MC, common-lisp@SU-AI, RAM@CMU-CS-C
- In-reply-to: Msg of Sat 4 May 1985 15:09 EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Date: Sat, 4 May 1985 07:36 EDT
From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>
The Common Lisp feature of allowing a macro to expand into
declarations ought to be flushed; it complicates much code while
giving no useful return.
Although this "misfeature" makes life much harder on the Lisp implementor and
the macro writer, its semantics are not without utility. Let me illustate
this with a couple of simple examples:
;;; Example 1
(defmacro declare-my-specials ()
'(declare (special *foo* *bar* *baz))
;; Once this is done, you can use this in all the functions which
;; use these special variables like so:
(defun frob1! (a b)
(declare-my-specials)
...)
(defun frob2 (x)
(declare-my-specials)
...)
;;; Example 2
(defmacro declare-inlines ()
(declare (special *debugging-p*))
(if *debugging-p* ;Compile time flag
'(declare (notinline car cdr)
'(declare (inline car cdr eq)))
;; Then this declaration macro can be used is time-critical code like so:
(defun %eq-seconds-p (list-1 list-2)
(declare-inlines)
(eq (cadr list-1) (cadr list-2)))
I am not saying that permitting macros to expand into declarations as stated
on p. 154 is a good mechanism for achieving this effect, but there should be
some way of getting the functionality suggested in the above examples.
From: Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Note that we are not arguing against the ability of a macro to turn into
some top-level form such as a DO that, among other things, contains
declarations. We are arguing for the elimination of the feature
described on page 154, in the paragraph starting "It is permissible..."
I don't think that is reasonable to require the programmer to define macros
like DEFUN-WITH-MY-SPECIALS or DEFUN-WITH-DEBUGGABLE-INLINES or anything of
the sort. At top level, these stand a good chance of confusing editors and
human readers.
For the sake of Lisp implementers and macro writers, I would suggest that
this mechanism be flushed in favor of a user-extensible DECLARE. The DEFTYPE
macro is seriously deficient in this role. Rather than using
(DECLARE-MY-SPECIALS) above, I could use (DECLARE (MY-SPECIALS)) or something
of the sort after defining MY-SPECIALS in some way.
From: Rob MacLachlan <RAM at CMU-CS-C.ARPA>
The largest issue that I see is that writing macros that parse
declarations becomes much more complicated. Every macro writer must
duplicate the non-trivial code which expands macros looking for
declarations.
If this feature must remain, then there should be standard
functions for parsing declarations in the language. This might
not be a bad idea anyway...
This is a great suggestion! This would save a lot of duplicated effort.
Case in point:
;Insert form after any declarations. This is about the fifth place
;in the system that knows how to do this; somebody fix this.
(DEFUN INSERT-INTO-BODY (FORM BODY)
(LOOP WHILE (AND (CDR BODY)
(OR (STRINGP (CAR BODY))
(AND (LISTP (CAR BODY))
(EQ (CAAR BODY) 'DECLARE))))
COLLECT (POP BODY) INTO DECLARATIONS
FINALLY (RETURN (NCONC DECLARATIONS (NCONS FORM) BODY))))
--From sys:sys2;flavor.lisp.564 (c) 1985 Symbolics, Inc.
Of course the common lisp version would be much hairier if the "misfeature"
were allowed to remain.
Tim