Macros -> declarations

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 10 May 85 01:51 EDT
    From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

    (DEFMACRO DEF-MY-MACRO (NAME BVL &BODY (BODY '(...default body...))
					   (DECLS '((DECLARE (SPECIAL *FOO*))))
					   (DOC "a macro"))
      ...)

    I believe that attacking the problem of DECLARE at the level people have been
    attacking it gives up programmer flexibility to no good end (not to mention
    introducing an incompatible change to the language semantics). A change
    like these syntax extensions to DEFMACRO that I've been speaking about would
    make life easy for the macro writer without giving up the macro-writing 
    freedoms I was originally supporting.

I think this is a good suggestion.  Of course we ought to think about it a bit before
adopting it, but I haven't seen any problems of Common Lisp changing too fast lately!

    Date: 16 May 85 14:53 PDT
    From: Masinter.pa@Xerox.ARPA

    The only reason for this issue is because the interpreter has to look
    ahead for SPECIAL declarations. SPECIAL declarations are the only ones
    that have any semantic import. Furthermore, SPECIAL declarations are the
    only ones that are textually retroactive, in that they apply to things
    that appeared BEFORE the declaration rather than after.

This last sentence is not true.  Actually, there are almost no declarations
in Common Lisp that are -not- textually retroactive, because declarations
are placed in the -middle- of the form to which they apply.

    Rather than hacking around the deficiencies of DECLARE, why not change
    it? Put SPECIAL declarations where they belong, next to the variable.
    Leave all the other declarations where they are. Most of these issues
    then become moot, and we can even consider freeing up some of the
    restrictions on declarations; it would seem reasonable to allow
    declarations anywhere in an implicit PROGN to refer to the stuff that
    follows.

I don't think it is only SPECIAL declarations that need to be attached to
variable bindings.  Consider the data-type declarations.

One point I'd like to make in this connection is that making SPECIAL
declarations locally, rather than globally with DEFVAR, is generally not
something we should be encouraging.  It's worth noting that the main use
of local SPECIAL declarations in Maclisp-like languages in the past has
been to simulate what FLET does better.  Now that we have full lexical scoping,
we can probably dispense with local SPECIAL declarations.

Perhaps the SPECIAL declaration should be phased out, so we can say that
DECLARE never has "semantic import", but is only a hint to the compiler
or otherwise an "annotation."  The SPECIAL proclamation would remain, of
course.  If people feel it is necessary, some way to change the SPECIAL
status of a name locally could be retained, but it need not be DECLARE.
It could be a special [multiple puns intentional] version of LET.

This wouldn't change the fact that macro writers need a PARSE-BODY,
since losing an annotation that makes the code run efficiently is almost
as unacceptable as losing an annotation that makes the code run
correctly or one that documents the code.

    Date: Thu, 16 May 1985  22:45 EDT
    From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>

    Personally, I like the idea.  I've felt for some time that we ought to
    separate SPECIAL declarations from all the others, even if that means
    that Common Lisp ends up looking a little different from Maclisp.  But
    we should only make this move so late in the game if just about everyone
    else feels likewise.

Agreed.

    Date: 17 May 85 14:55:49 EDT
    From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>

    As an implementor, I would be only too happy to flush the current
    (incomplete) tests for SPECIAL declarations in favor of something
    that is in the lambda list.  The idea of using the pname is
    obviously a bad one, but I don't see any problem with things
    such as
	(foo &special bar)

We haven't bothered to remove support for &SPECIAL from our system yet,
so we could hardly complain if it became a standard instead of an obsolete
holdover from the past!  Again, though, I think there is little real need
for local SPECIAL declarations.