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.