More words on the scoping of declarations

[mike%acorn@mit-live-oak.arpa]

    Date: Mon, 18 Aug 1986  13:56 EDT
    From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
    
    .....
    
        It is evident that you do have a theory of variable binding, but
    you don't really attempt to formalize it to the point where
    declartion semantics becomes obvious.  You theory is based on the idea
    that declaration scoping should follow the same scope rules as
    variables.  It is a property of this theory that a declaration for a
    specific name cannot refer to multipel variables which have the same
    name.
    
        So far as the application of the theory goes, the main problem
    that I see is with LET* and possibly other places where sequential
    bindings happen.  It is not obvious to me what the scope of
    delcarations in LET* should be, even if we disallow repeated variable
    names.

The scoping of a declaration in a let* should be as close as possible
to that of a let. I think repeated names should be allowed, and the
innermost one should be the one to which the declaration applies.

(let*  ((a (foo a))
        (b a)
        (a 7))
 (declare (type fixnum a)
          (type frobboz b))
  ...a...b...)

The only "a" which is a fixnum here is the one which gets the value 7.
Semantically, the form should be equivalent to:

(let ((a (foo a)))
 (let ((b a))
  (declare (type frobboz b))
   (let ((a 7))
     (declare (type fixnum a))
     ... a ...b..)

This means that the semantics of declaration in let* is exactly as
if you moved the declarations up into a nested let construct,
except for the case of a repeated identifier, where the innermost
name is the one the declaration applies to.
There are of course ambiguous cases where expressing exactly the 
declarations you want requires breaking up a let* into two nested
let*'s so that you can stick a declare in between. I don't see this
as a tragedy. It's still better than the situation in most programming
languages, where the names of identifiers are often chosen to reflect
their type......

In summary, two things. (1) I think Pavel's proposal is right.
(2) I think the "theory" should be extended to reflect the "innermost"
principle for sequential binding constructs.

...mike beckerle
   Gold Hill Computers