shivers@centro.soar.cs.cmu.edu (Olin Shivers) (06/20/88)
If, in a lexically scoped lisp, you refer to a global variable
thinking it's a local, or vice-versa, you'll still fall down a hole.
Lexical scoping does not obviate the need for good software engineering
practice - namely, in this case a *naming scheme*.
This is an uninformed statement. You can always tell a local variable when you
see one in a lexically scoped program -- its definition (or binding site) is
found at some syntactically related place in the program. That's why it's
called a "lexical" variable: the variable's declaration/definition is
*lexically* (or textually) apparent.
For example, suppose we have the following code written in a dynamically
scoped lisp, like Maclisp:
(defun foo1 (n) (bar))
(defun foo2 (n) (bar))
(defun bar () n)
Now, what variable binding is the reference to N in BAR referring to? It could
be the one in FOO1, the one in FOO2, or some other one sitting in some other
file that's going to be loaded into our Lisp at run time. That's why
dynamic variable binding is *not* lexical: you can't textually go from a
variable reference to its binding. In a lexically scoped lisp, you can.
So it's easy to distinguish globals from locals.
Not only does lexical scoping make life easier for the poor programmer, who
never has to say, "Where is this mystery variable defined?" but it also makes
life easier on the compiler, which can generate more optimal code for the same
reason.
These issues are covered at length in the Steele/Sussman Lambda papers,
of which perhaps the best is "The Art of The Interpreter." The Abelson/Sussman
book, *Structure and Interpretation of Computer Programs* also treats this
sort of stuff.
-Olin