[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
More words on the scoping of declarations
- To: RAM@C.CS.CMU.EDU
- Subject: More words on the scoping of declarations
- From: email@example.com
- Date: Mon, 25 Aug 86 23:09 EST
- Cc: Pavel.pa@XEROX.COM, Common-Lisp@SU-AI.ARPA
- Sender: firstname.lastname@example.org
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
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
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))
(declare (type fixnum a)
(type frobboz 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
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.
Gold Hill Computers