[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DECLARE SPECIAL Considered Confusing
- To: ALAN@AI.AI.MIT.EDU
- Subject: Re: DECLARE SPECIAL Considered Confusing
- From: NGALL@G.BBN.COM
- Date: Wed, 23 Jul 1986 07:00:00 -0000
- Cc: Common-Lisp@SU-AI.ARPA
- In-reply-to: <[AI.AI.MIT.EDU].73400.860721.ALAN>
- Sender: NGALL@G.BBN.COM
Date: Mon, 21 Jul 86 16:02:37 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: DECLARE SPECIAL Considered Confusing
In-Reply-To: Msg of 20 Jul 1986 18:52-EDT from NGALL at G.BBN.COM
Actually, the more I think about this as a simplification, the more I like
it. So here is a counter-proposal for rationalizing the semantics of
1. All declarations are completely pervasive. That is, if you write
(locally (declare (special foo)) ...)
then every occurance of FOO within the body is taken to be a special
reference or a special binding. The only way to escape from the effects of
a declaration within the body, is to explicitly shadow the declaration with
another. This applies to -all- declarations: FTYPE, INLINE, etc.
How do I shadow the SPECIAL declaration if "every occurance of FOO is
taken to be a ... special binding"? E.g., How can I bind X lexically
in the body of the following: (defun foo (x) (declare (special x))...)
2. Declarations that occur in the bodies of special forms (DEFUN, LET, DO,
etc.), and in LAMBDA expressions, are taken to mean the same thing as if
the entire form was enclosed in a LOCALLY containing the same declarations.
(let ,pairs ,@dcls ,@body)
(locally ,@dcls (let ,pairs ,@body))
are completely equivalent.
(Since LAMBDA expressions aren't forms, the equivalent using LOCALLY isn't
always completely straightforward to construct. For example, this case:
((lambda ,vars ,@dcls ,@body) ,@vals)
is equivalent to using LOCALLY as follows:
(funcall (locally ,@dcls (function (lambda ,vars ,@body))) ,@vals)
Question: Why isn't LOCALLY just called PROGN?
Answer: Because PROGN doesn't allow declarations :-).
Your proposal completely contradicts the spirit of lexical scoping by
allowing a declaration OUTSIDE THE LEXICAL SCOPE of an entity to
AFFECT that entity. Thus the programmer must look outside the lexical
scope of the entity to determine its type, whether it is special,
whether it is inline, etc. This is BAD language semantics. Sure
PROCLAIM is BAD too, but lets not compound the error.
Also, it makes no sense for one binding to shadow another if the
declarations aren't shadowed also. This is what DCW was alluding to.
It will just confuse the user to have a flat namespace for
declarations and a shadowing namespace for bindings.