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

Issue: DECLARATION-SCOPE (Version 2)

    Date: Wed, 3 Feb 88 19:39:14 PST
    From: Jon L White <edsel!jonl@labrea.Stanford.EDU>

    I'm not a little dismayed at the verbosity of this proposal.  

Hornig can correct me, but I believe that was in response to requests
for clarity and specificity.

								  Does the
    following 3-sentence summary encompass most of the statement of problem:

      (1) Some declarations only affect how a particular instance of a binding
	  is interpreted.  [these are called 'bound' in the terminology of
	  the proposal].

      (2) Some don't.  [i.e, they affect something else other than some
	  property of a particular instance of a binding.]

Sorry, but I can't figure out what precisely the above two sentences mean.

      (3) Except for SPECIAL,  no declaration in category (1) is permitted
	  to have any other interpretation.

There appear to be several types of declarations that can be either free
or bound, depending on whether they appear attached to a binding of the
variable or function that they declare, or appear someplace else.  The
major error in the existing declaration scoping, I feel, was the idea
that pervasive or non-pervasive could be a property of a declaration
specifier, independent of context.

    [Thus (3) prevents the following "natural" extension of declare IGNORE:
       (locally 
	 ...
	 (let ((x <computation>))
	   (declare (ignore x))
	   <body-without-x>)
	 ...)
     <==> 
       (locally (declare (ignore x)) 
	 ...
	 (let ((x <computation>))
	   <body-without-x>)
	 ...)
    ]

I can't figure out what you intend this supposedly natural extension to
mean.  The ignore declaration would apply to all references to x inside
its scope, except for references shadowed by an inner binding of the
name x.  But this is nonsense!  The ignore declaration applies to the
absence of references; the only way it applies to references is the
minor feature that CLtL suggests the compiler ought to warn if you
declare a variable to be ignored and then reference it.

    The proposal, then, is presumably to clarify that

      (4) The scope of a `bound' declaration is exactly the scope of the
	  associated [lexical] variable or function.  

    [Since only SPECIAL is permitted to have both 'free' and 'bound' meanings,
    then (4) really only applies to it,  for otherwise, the scope of a 'bound'
    declaration is simply the one binding it is attached to.]

It's not true that special is the only such declaration.

    A primary consequence of this is that 
	 (let ((x <computation>))
	   (declare (special x))
	   <body>)
    is not equivalent to
	 (locally (declare (special x))
	   (let ((x <computation>))
	     <body>))
    nor is it equivalent to 
	 (locally (declare (special x))
	   (let ((x <computation>))
	     (declare (special x))
	     <body>))
    because the LOCALLY form would be permitted to affect the references in
    <computation> and the scope of the variable 'x' does not include the
    form <computation>.  

The above is true unless I have misunderstood what you're saying.

    On the other hand, because the following SPECIAL declaration is not
    linked to the binding(s) occuring in the surrounding LET, then
	 (let ((x <computation>))
	   (declare (special y))
	   <body>)
    is equivalent to
	 (locally (declare (special y))
	   (let ((x <computation>))
	     <body>))
    in which case the declaration *does* affect the (free) references to
    'y' found in <computation>.

That's correct too, I believe.  It's also the same as in CLtL.

    Is this indeed the intended effect?  If so, is this the answer to the
    questions about how to gag the compiler messages about "free" variables
    appearing in &optional (etc) init forms of defuns?

I can't figure out what that question has to do with any of this.  Perhaps
those questions were on some mailing list that I am happily not a member of?

    Now, I think (3) above has some nasty consequences; in particular the
    inability to give local type declarations over a lexical interval.
    MacLisp wasn't scoped like this.  I vaguely remember discussion a long
    time ago that the reason why Common Lisp variable declarations aren't
    scoped like this is because of the inadvertent capturing of lexically-
    apparent declarations by macroexpanded code.  [Indeed, some implementations
    of DEFSUBST still have the bug that they have macro-expansion semantics
    rather than function-call semantics.]  

    It would be a shame if the declarational scheme had to be castrated simply 
    because no one could figure out a better solution to the captured lexical 
    environment problem.  I really don't see that having one construct --
    ordinary macros -- that can lose referential transparency is so bad; we
    certainly need a "safe" version thereof, like DEFSUBST should be; but
    this hardly seems the time to grossly revise the semantics of macro
    expansion, which  have other problems with lack of transparency.  [Someone
    may point out that the phrase "Kohlbecker's Thesis" ought to be invoked
    here.]

    If the macro-induced lack of "referential transparency" isn't a factor
    at all in CL's prohibition against allowing "pervasive" declarations to
    affect bindings found in enclosed forms, then I apologies for the above
    two-paragraph excursion.

I can't figure out what any of this means.  Perhaps you're still going on
about the fact that Hornig refuses to include in his DECLARATION-SCOPE proposal
the unrelated proposal to change what CLtL says about TYPE, namely that
it affects only variable bindings (not references)?  I'm on Hornig's side
there; it's not a good idea to bundle unrelated proposals together.  If you
want to change the rules for TYPE, and by the way I agree with you that
they should be changed, just write a CL-Cleanup proposal to do so and let
it stand on its own merits.  It's completely and totally independent of
Hornig's proposal.  It can go into the language with exactly the same
semantics regardless of whether Hornig's proposal is approved or rejected.
The only difference would be whether the description of a TYPE declaration
that is not attached to a binding uses the word "free" or uses the word
"pervasive".

    But I still would like to see a more succinct
    3-or-4-sentence summary of this proposal's problem description.

It seems clear that my attempt to revise the proposal to make it clearer,
in response to the mail discussion, didn't work.  I'm willing to spend
some more time helping with this proposal, but since I don't really understand
what's unclear about it to you, I don't see what to change.  Perhaps you
could tell me what questions it doesn't answer.