Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-vax.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mit-vax!rpk
From: rpk@mit-vax.UUCP
Newsgroups: net.lang.lisp
Subject: Shallow binding and deep binding
Message-ID: <511@mit-vax.UUCP>
Date: Mon, 28-Nov-83 20:08:47 EST
Article-I.D.: mit-vax.511
Posted: Mon Nov 28 20:08:47 1983
Date-Received: Wed, 30-Nov-83 02:01:41 EST
References: <4055@umcp-cs.UUCP>
Organization: MIT, Cambridge, MA
Lines: 31

I don't know if, when a variable is lambda-bound under a deep-binding
scheme, the ``current'' value is put in the value cell and old value is left
on the stack.  If that is true, then a problem arises when the Lisp
environment supports multiprocessing.  Suppose one executes in process A

   (LET ((*BASE* 10.))
      (DO-IT))

where *BASE* is 8 globally, and process B looks at *BASE*.  Process B should
get the top level value of *BASE*, not the value that process A bound.
I would think that, instead, the new value would be pushed on the stack,
along with some bookeepping to find the previous value.

One way to speed up variable lookup that is used in MacLisp and ZetaLisp is
to tell the compiler that only ``special'' variables will really be
lambda-bound; all other local variables and arguments will be considered
``non-special''  This gives you efficiency in compiled code at the expense
of compatibility with the interpreter.  ``Special'' variable references are
turned into routines that do lookup on the binding stack by symbols; all
other variable references are turned into stack references.

Most Lisps are dynamically scoped, but Common Lisp will be lexically scoped.
The special/non-special distinction described above is >>almost<< compatible
with lexical scoping, since the default is that bindings from ``superior''
stack frames will not be inherited into the current stack frame.  Common
Lisp also allows ``fluid'' variable declaration, which is just the
``special'' declaration.
-- 
``Bob''  Robert P. Krajewski      ARPA: RpK@MC
			     MIT Local: RpK@OZ
                                  UUCP: ...!genradbo!mit-eddie!mitvax!rpk