[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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 
scoping issue.

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 --