Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!ucbvax!dewey.soe.berkeley.edu!mkent
From: mkent@dewey.soe.berkeley.edu (Marty Kent)
Newsgroups: comp.lang.lisp
Subject: What's the value of lexical scoping?
Message-ID: <24508@ucbvax.BERKELEY.EDU>
Date: 2 Jun 88 23:16:37 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: mkent@dewey.soe.berkeley.edu (Marty Kent)
Organization: School of Education, UC-Berkeley
Lines: 49

I've been wondering lately why it is that "modern" lisps like Common Lisp
and Scheme are committed to lexical scoping.  To me, the only *obvious*
effect of lexical scoping is that it makes it very much more difficult to
write reasonable debugging tools (so the system writers don't bother with
it). Actually I have in mind the lisps for the Mac II, which are Allegro
Common Lisp and MacScheme.  (Since it lacked a compiler last I heard, I
haven't taken XLisp seriously. Perhaps there are other "serious" lisp
systems available for the Mac or Mac II, if there are any, I'd love to
hear about them...)

(To return to my main stream...) With dynamic scoping, you can actually
implement a break loop by just reading, eval'ing and printing.  With
Common Lisp's way of evaluating calls to EVAL in a null lexical
environment, it seems to me that in order to set up a decent break package
one has to know about the implementation of the runtime stack, the
structure of stack frames etc. (NOTE: by "a decent break package" I mean
one in which you can *at the very least* examine the values of locals on
the stack at break-time.) In fact, with Allegro Common Lisp the situation
is even worse, because the compiler doesn't save the names of locals in
the stack frames, which makes it pretty much impossible to scan at runtime
to resolve a name-based reference. 

It seems to me the Common Lisp specification missed out by not mandating
certain runtime stack manipulation primitives, a la (for instance)
Interlisp.  

I realize that discarding variable names from compiled code makes for
faster and smaller object modules, but it seems to me this kind of
"optimization" should be dependent on something like the setting of
"speed" in an optimize declaration.

Well, I don't really mean  to just sit here and bitch,  what I'm really
hoping is that someone will tell me either:
1) actually it's easy to set up a decent runtime debugger using stock
Common Lisp functions, you simply have to ...
or
2) while it's true that Common Lisp's scoping makes it difficult to write
debuggers, lexical scoping is still a good trade-off because it buys
you...

I'd be glad to hear about either of these alternatives, or some new way of
looking at the situation...


Marty Kent  	Sixth Sense Research and Development
		415/642 0288	415/548 9129
		MKent@dewey.soe.berkeley.edu
		{uwvax, decvax, inhp4}!ucbvax!mkent%dewey.soe.berkeley.edu
Kent's heuristic: Look for it first where you'd most like to find it.