lexical scope & program development

[willc%tekchips%tektronix.csnet@CSNET-RELAY.ARPA]

    Date: Fri, 31 Jan 86 12:37 EST
    From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>

    I believe that all the problems you've been talking about have to do
    with the poor interaction between lexical scoping and incremental
    programming.  These poor interactions are discussed in the paper "The
    Art of the Interpreter:  Parts Zero, One, and Two" by Guy Steele and
    Gerry Sussman.  They are not incidental design flaws of Common Lisp;
    they are part of the deep nature of lexical scoping.  I don't think they
    represent a "time bomb" in the language.  They just show how lexical
    scoping, itself, has problems when it comes to program development, when
    used in this way....

People here who have constructed an incremental programming environment
for a lexically scoped language tell me that lexical scope was among the
least of their worries.

If a lexically scoped interactive language takes the point of view that
all unbound variables are really variables bound to locations in which
undefined values are stored (so that all definitions are viewed as
assignments rather than bindings), and variable fetches that yield
such values are trapped, then most of the problems cited in the
paper by Steele and Sussman go away.  There remain needs for (1) temporary
assignments (as in the current MIT Scheme dynamic variable semantics);
(2) module facilities that can hide or expose variables (as in the Common
Lisp package system or MIT Scheme environments); and (3) debugging facilities
(as in a debugger).

A dynamically scoped top level only solves problem (1), and solves it only
for top level variables.  Since (1) must be solved for lexical variables
anyway, a dynamically scoped top level is neither necessary nor useful.

The real problem with lexical scope and interactive program development
is that lexical scope is a hiding mechanism, and hiding hinders the
debugging process.  It seems to me that the solution is a good debugger
that can expose the hidden, for example by allowing the programmer to
crawl through the environment of a closure and to evaluate code in any
environment that can be reached that way.  (I realize that some compilers
don't keep enough information around to support such a debugger, or they
perform so much optimization that it's impractical, but in such a case
I'd say that it is the compiler, not lexical scope, that is incompatible
with interactive program development.)

William Clinger
willc@tektronix.csnet
Tektronix Computer Research Laboratory