[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: issue DECLARATION-SCOPE
- From: Jon L White <email@example.com>
- Date: Fri, 28 Oct 88 23:30:24 PDT
- Cc: firstname.lastname@example.org, email@example.com
- In-reply-to: David A. Moon's message of Wed, 26 Oct 88 23:52 EDT <19881027035211.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
re: First of all, the "free"/"bound" distinction isn't some crazy
categorization that we can just remove.
I've never claimed that; I've only claimed that embellishing it, and using
it for the purpose of explaining DECLARE scoping is not only unnecessary,
but adding to the confusion surrounding the issue. [Incidentally, the
"crazy" in my msg came from a characterization of the "prohibition found
on p158 of CLtL", which happily is a matter of the past now that
DECLARE-TYPE-FREE is virtually approved. The whole point of my msg
was to glory in the fact that declaration scoping is now free of this
"crazy" constraint; until this time, scoping had to have an explicit
exception for "free" type declarations.]
re: . . . It [the "free"/"bound" distinction] means exactly the same
thing as your phrase "the name-bindings, if any, to which they apply".
Well, I've never gotten that impression from the lengthy exposition in the
current proposal. More to the point, the applicability of a declaration
must be specified somewhere in the standards document *** and this must be
done purely independently of the scoping issue ***. My claim is that this
independent specification can already be presumed when discussing the
That is, somehow, one comes to understand:
(1) that SPECIAL and TYPE declarations never apply to function bindings;
(2) that INLINE and FTYPE declarations never apply to variable bindings;
(3) that OPTIMIZE and DECLARATION never apply to either kind of binding;
(4) and that (<declaration> X) never applies to a binding of Y.
This "understanding" is for the most part distributed throughout the
individual declaration definitions. Surely, you can appreciate the
importance of this point -- that the name-applicibility issue for bindings
must be specified independently of how the declaration scoping issue is
decided, and it certainly will not depend on which of the three alternative
scoping proposals is chosen!
re: . . . The major point is your claim that it's
obvious that the scope of a free declaration should be just the body of
the special form, and not include any additional code, such as
initialization forms. ...
That wasn't my claim [or, not exactly]. Restating it (for the nth time!):
(1) the scope should always include the body form, and
(2) it should also include any correlated name binding ... which by
the _already-specified_ rules of lexical scoping for variables
would include certain init-forms in LET* [but of course wouldn't
include any in plain LET].
Part of the simplicity of the approach I've been advocating is that we
reduce the thorny part of the scoping issue for DECLARE to the *** already
solved *** scoping issue for lexical variables. There certainly is no need
to bring in the "free/bound declaration" distinction for the purpose of
understanding lexical variable scoping.
Indeed, not arbitrarily including init-forms in the declaration is slightly
different from the opaque (even if "unambiguous") prescriptions given in
CLtL; I claim it is a difference for the better, and will directly spell
out three significant improvements when I put the claim into proposal
format [Larry: I should have this done before next Wednesday].
re: ... Perhaps we would choose to adopt this after
discussion, but it's not obviously correct, it's not obviously simpler
than setting the scope to the entire special form, and most importantly
it is an incompatible change, directly contradicting the scope defined
by CLtL ... If you don't see that, look at the "defun few" example in
the middle of page 155 of CLtL.
Quoting from the original DECLARATION-SCOPE proposal by Hornig, as well as
the version you most recently sent me privately, the categorey is listed
as CHANGE -- meaning "incompatible change". At stake is not whether one
or the other is "an incompatible change", but which of the two alternative
semantics is more natural, easier to specify, and less likely to be
confusing to end-users.
re: My reason for preferring that the scope of a free declaration is the
entire special form is to avoid an incompatible change.
Not only does the Category CHANGE, from you own version of the proposal,
imply incompatible change, but you have apparently forgotten the
"Current practice:" section of that proposal, which says in part:
". . . Most implementations implement
the rules in CLtL. Symbolics currently implements rules based on
Zetalisp which are different from both this proposal and Common Lisp.
Symbolics plans to change to Common Lisp rules in the future."
The question, of course, is just what should "Common Lisp rules" be?
Since many folks have been grossly confused by CLtL, and since your own
proposal calls for a CHANGE, then let us strive to obtain a Change For
The Better. I might note that at least some part of one other system
seems to implement the rules I've been praising.
-- JonL --