[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Macros -> declarations
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
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
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.
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
(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.