doug@zaphod.UUCP (06/03/88)
First - I hope this actually makes it out. Most of my postings have stayed local. The reasons for lexical scoping don't end with efficiency. It's true that compiled code with lexical references is much more efficient then dynamically scoped code but that isn't the whole story. The second good reason for lexical scoping is to solve the fexpr problem. This is what happens when you get a collision between a parameter and a global variable in dynamically scoped LISP. So: > (setq x 50) ;; Change the global variable x 50 > (defun bar (x) ;; Creates a new dynamic variable x (print x) (foo x) x) BAR > (defun foo (y) (print x) (setq x 20) ;; An attempt to change the Global x (print x) y) FOO > (bar 100) 100 ;; Parameter X in BAR 100 ;; Parameter X referenced from FOO by dynamic scope 20 ;; Parameter X changed in FOO 20 ;; Returned from BAR > (print x) 50 ;; Hasn't changed because of dynamic shadowing This can cause exceedingly subtle bugs in code that don't mean to exploit this kind of scoping rule. This can also happen between parameters, it needn't include a global variable. Consider that this also causes problems for the writers of the language itself as if a particular function like MAPCAR uses a parameter used by a user and that user is APPLYing his own function that modifies a dynamically scoped variable xyzzy he will change the wrong one. A third argument, although weak, is to argue that most programmers, especially those who are transplants from 'normal' languages like FORTRAN, PL/1, C and PASCAL will expect lexically scoped behavior. Making LISP lexically scoped then makes it consistent with expected behavior. A last argument is that many LISPs have been implemented and used where the interpreter is dynamic but the compiled code is lexical. This is even nastier. So Common LISP preserves the ability to screw yourself for the hearty adventurer types (you can always do a (declare (special ..))) but saves the rest of us mere mortals from our own folly. Douglas Rand Internet: doug@zaphod.prime.com Usenet: primerd!doug Phone: (617) - 879 - 2960 Mail: Prime Computer, 500 Old Conn Path, MS10C-17, Framingham, Ma 01701 -> The above opinions are probably mine.
johnl@ima.ISC.COM (John R. Levine) (06/05/88)
In article <26500002@zaphod> doug@zaphod.prime.com writes: > >First - I hope this actually makes it out. Most of my postings have stayed >local. > >The reasons for lexical scoping don't end with efficiency. It's true that >compiled code with lexical references is much more efficient then dynamically >scoped code but that isn't the whole story. > >The second good reason for lexical scoping is to solve the fexpr problem. >This is what happens when you get a collision between a parameter and >a global variable in dynamically scoped LISP. ... That's really a better reason. Every time I have used a dynamically scoped language (Lisp, APL, Snobol4) I have been bitten quite painfully by strange bugs due to unintended aliasing of names. In APL, many people treat the dynamic scoping effectively as a bug and create strange local variable names that are carefully intended not to collide with globals or names in other routines. I always had the impression that Lisp's dynamic scoping was an accidental effect of the a-list that Lisp 1.5 on the 7094 used to keep argument bindings. Then, like most accidental effects, people started taking advantage of it and it became enshrined in conventional use. The 1962 Lisp 1.5 manual notes that compiled functions have lexically bound variables (although like everthing else in the book, it is explained in a way that makes it almost incomprehensible) and explains how to make your function's variables special or common, so it seems reasonable to assume that from the first the semantics of the binding strategy were muddled. -- John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something Rome fell, Babylon fell, Scarsdale will have its turn. -G. B. Shaw