Issue: DECLARATION-SCOPE (Version 2)

[Jon L White <edsel!jonl@labrea.Stanford.EDU>]

re: It seems clear that my attempt to revise the proposal to make it clearer,
    in response to the mail discussion, didn't work. ... 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.

Here's one, taken from our interchange:

  {JonL}
      [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.]
  {Moon}
    It's not true that special is the only such declaration.

I didn't fully believe that either, but taking the words from your
rewriting of the proposal:

    The following is a complete listing of the types of declarations and
    their class (`bound' or `free'):

    SPECIAL declarations may be either `bound', affecting both a binding and
    references, or `free', affecting only references, depending on whether
    the declaration is attached to a variable binding, as described above.

    TYPE declarations may only be `bound' (see next section).

    FTYPE and FUNCTION declarations may only be `free' (see next section).

    INLINE declarations may only be `free' (see next section).

    NOTINLINE declarations may only be `free' (see next section).

    IGNORE declarations may only be `bound'.

    OPTIMIZE declarations may only be `free'.

All except SPECIAL are restricted to one kind or the other, and this is
alleged to be a complete list.


Now, I would prefer to see SPECIAL, NOT/INLINE, and TYPE declarations all
have the same scoping rules.  For example, if the "cleanup" proposal for
NOT/INLINE declarations on lexical functions were accepted, then a form like:

    (locally (declare (notinline car))			[1]
      (flet ((car (z)					[2]
               (list (cdr z) (car z))))			[3]
	(declare (inline car))				[4]
	. . . 
	(print (car x))))				[5]

wouldn't be ambiguous, as it apprently now is.  If NOTINLINE were scoped 
like this proposal for SPECIAL, then it would be clear that the declaration 
on line [4] applies only to the "car" defined on line [2], and that the 
usage of "car" on line [3] isn't affected by it {see how nice and parallel 
that is to the SPECIAL rules}; on the other hand, the usage on line [3] is 
affected by the 'free' declaration on line [1].  I hope that this is your 
preference too.

One of the problems I had in reading the proposal was figuring out what 
you meant by "'bound' declaration".  I realize that this isn't a specific 
question that you can "answer", but it was a concern.  Apparently, in 
return, you couldn't figure out my question as to its meaning.  I had 
asked if it was like:
      (1) Some declarations only affect how a particular instance of a binding
	  is interpreted.  [these are called 'bound' in the terminology of
	  the proposal].
If I may try again, let me point to the declare on line [4] above.  It 
applies to the *particular* instance of the binding of the name "car" 
on line [2], does it not?  It says "interpret this function as an inline
version of something named car".  It doesn't separately apply to the usage 
on line [5], because [5] is a reference to the lexical name established 
by [2] and its properties are completely determined by that binding on 
line [2].  Furthermore, unlike MacLisp's scoping rules, the declare on 
line [4] would have no effect on any inner re-bindings (by FLET) of "car" 
such as might occur in the part elided ". . .".  That's why I say "a
particular instance of a binding".

If this still isn't clear to you, and if no one else is particularly
concerned about it, then maybe we could take any further comments "off-line".


You have also expressed confusion as to what the non-standard code

   (locally (declare (ignore x))
     (let ((x 3))
       (mumble)))

could possibly mean.  I thought I stated it by giving an equivalent in
standard code.  That is, unlike existing practice, but *like* MacLisp, 
I could imagine it to mean the same as:

     (let ((x 3))
       (declare (ignore x))
       (mumble))

It shouldn't be too hard to believe that such a translation can be done
fully mechanically.  Since this kind of declaration inheritance was
the norm in MacLisp, and since you used MacLisp for years, I didn't 
realize you'd have trouble remembering it [the "norm", in particular
for SPECIAL and TYPE declarations].

I know only too well that such a interpretation of 'pervasive', or 'free',
declarations conflicts with meaning given for them by CLtL -- that any 
inner binding of a name is completely shielded from any outer, lexical 
declarations.  This is one of the two parts that differ substantially from 
MacLisp -- the other being that a declare before the body of a special form 
is not generally equivalent to the same declare wrapped LOCALLY around the 
form.  But since PROCLAMations stick with the name, and are not walled-out 
by ordinary bindings, then it's not too hard to imagine some 'free' 
declarations operating this way.  [One might use the term "shadowed" rather 
than "walled-out", but I dislike it since there is another technical meaning
for "shadow"; also, the allegedly shadowing binding isn't by itself 
providing an alternate "shadowing" declaration.]


I perceive the current dilemma, which "DECLARATION-SCOPE" proposes
to alleviate in some small way, as stemming from Common Lisp's partial
attempt to cure the problem of captured lexical declarations during macro 
expansion.  That's all I intended to say in the two-paragraph essay near 
the end of my msg.  Consequently, I'm totally amazed at your reply to it:
    . . . 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, . . . 
especially since I publicly lauded this proposal when it came out, and
have never expressed dissatisfaction with Hornig's handling of it.  I 
remember remarking on the similarity of the two issues -- they are *not*
totally unrelated -- but that has nothing at all to do with the conjecture 
about "macroexpansions capturing lexical declarations".



-- JonL --