Path: news.media.mit.edu!bloom-beacon.mit.edu!spool.mu.edu!howland.reston.ans.net!agate!anarres.CS.Berkeley.EDU!bh From: bh@anarres.CS.Berkeley.EDU (Brian Harvey) Newsgroups: comp.lang.logo Subject: Re: LOGO Compilers Continued Date: 23 Mar 1994 00:07:11 GMT Organization: University of California, Berkeley Lines: 61 Message-ID: <2mo17f$b73@agate.berkeley.edu> References: <2mktqo$dm3@agate.berkeley.edu> NNTP-Posting-Host: anarres.cs.berkeley.edu tim@harlequin.com (Tim McNerney) writes: > I had always thought that dynamic scoping was fundamental to the >template-based object system in Gary Dresher's original ObjectLisp. Well, there's *also* object scoping in Object Logo, and it's separate from procedure-invocation scoping. When you refer to a variable, Object Logo checks both the (lexical) procedure context and the current object's inheritance structure. The rule is that the name had better not be found in both, or it's an error. The dynamic/lexical distinction doesn't really apply to object variable scoping, but it's true that object variables are somewhat dynamic-like in the sense that they don't follow referential transparency. You can, on the fly, create a new object variable in some parent of an object and change the meaning of programs run by that object. >IMHO, programs which use dynamic scoping are harder to understand than >programs which use lexical scoping, or which use dynamic scoping only >sparingly, and which clearly indicate their use. (sigh.) I guess Andy diSessa and I are the only two people left in the world who still like dynamic scope. Here's why: 1. When you say dynamically scoped programs are harder to understand, what you really mean is that once you've learned a rather complicated model of evaluation, with environments and so on, you can more easily get through the sort of horrible program where there are several unrelated variables all with the same name. But those are going to be hard to understand no matter what scope rules are used! If you think about a program in which all variable names are distinct, then dynamic scope gives you a much simpler model, because there's no such thing as a variable that exists but isn't available right now. In technical lingo, a variable's scope is identical with its extent. In kid lingo, local variables are created when you enter a procedure and destroyed when you leave, and the variables you can see are the ones that exist right now. (If you do use the same name twice, then you have to add "unless one variable shadows another.") 2. In Logo we don't have first-class procedures, but we do have first-class expressions. That is, we can invent a control structure that works like WHILE [:X < 10] [PRINT :X MAKE "X :X+1] whereas in a lexically scoped language in order to get the value of X into WHILE you have to encapsulate it in a closure by saying (WHILE (LAMBDA () (< X 10)) (LAMBDA () (DISPLAY X) (SET! X (+ X 1)))) and those no-argument procedures need explaining. (Or you can write a macro to hide them, but *that* needs explaining too.) 3. A special case of #1 is that lexically scoped languages come with debuggers that have special languages with special commands like "move to the dynamically next frame" that you don't understand until two months into the class! In Logo the debugging language is Logo. P.S. In a language with lambda, like Scheme, there is also an advantage to lexical scope because you can use it to create local state variables. But in Object Logo, the variables available under lexical scope are always a subset of the ones that would be available under dynamic scope, so lexical scope is just a restriction. "You're not smart enough to keep your own program straight so we'll do you a favor by not letting you do things we don't approve of."