Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!styx!ames!ucbcad!ucbvax!decvax!tektronix!tekcrl!tekchips!willc
From: willc@tekchips.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <1043@tekchips.TEK.COM>
Date: Thu, 12-Feb-87 13:36:56 EST
Article-I.D.: tekchips.1043
Posted: Thu Feb 12 13:36:56 1987
Date-Received: Sat, 14-Feb-87 23:09:25 EST
References: <2545@well.UUCP> <1131@spice.cs.cmu.edu>
Reply-To: willc@tekchips.UUCP (Will Clinger)
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 44
Keywords: Flame Repeat Original Common LISP Tide

Jeffrey Jacobs (jjacobs@well.UUCP):
>I can accept SCHEME, where you always know
>that it's lexical, but CL could drive you crazy (especially if you were 
>testing/debugging other people's code).

Robert P Krajewski (rpk@mc.lcs.mit.edu):
>Huh ?  Whether or not a variable is lexical can be determined by looking at
>its lexical context (practically an axiom, eh ?).  So if it's being used
>freely, you can assume it's special.

Rob MacLachlan (ram@spice.cs.cmu.edu):
>I have also never heard anyone but you claim that mixed 
>lexical/dynamic scoping makes programs hard to understand, and I have to
>deal with some real dimbulb users as part of my job.  In contrast, I have
>frequently heard claimed (and personally experienced) obscure bugs and
>interactions due to the use of dynamic scoping.

Thanks to proclamations and DEFVARs (which perform proclamations), it
is not possible to tell whether a Common Lisp variable is lexical simply
by looking at its lexical context.  See page 157 of CLtL.  This is a major
lose.  As Mr Jacobs observed, it drives you crazy when you try to read
code.

I certainly agree with Mr MacLachlan's point that dynamic scoping makes
programs hard to understand.

Rob MacLachlan (ram@spice.cs.cmu.edu):
>For one, Common Lisp is hardly unique in having both dynamic and static
>variables.  Every Lisp that I know of allows dynamic binding, and every Lisp
>that I know of will use also statically bind variables, at least in compiled
>code.  I believe that Scheme allows fluid binding; certainly T does.

Neither the 1985 nor 1986 Scheme reports talk about dynamic (fluid)
variables.  The reason is that many different semantics are possible for
dynamic variables, each with their own best use, and Scheme is powerful
enough that these various semantics can be implemented by portable Scheme
code.  We reasoned that programmers can load whichever variety of dynamic
variables they want out of a code library.  The standard procedure library
described in the Scheme reports doesn't describe any of the possibilities
for dynamic variables because we wanted to avoid premature standardization.

Peace from a real dimbulb user,
Will Clinger
willc%tekchips@tektronix.csnet