Path: utzoo!attcan!uunet!husc6!bloom-beacon!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: What's the value of lexical scoping?
Keywords: Scope, Binding, Locals, Break, Future of LISP
Message-ID: <21847@think.UUCP>
Date: 12 Jun 88 19:01:44 GMT
References: <24508@ucbvax.BERKELEY.EDU> <515@dcl-csvax.comp.lancs.ac.uk> <452@aiva.ed.ac.uk> <519@dcl-csvax.comp.lancs.ac.uk>
Sender: usenet@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 128

In article <519@dcl-csvax.comp.lancs.ac.uk> simon@comp.lancs.ac.uk (Simon Brooke) writes:
>The Xerox community has got used to a scheme under which, among other
>things, all globals are marked out with asteriscs:
>	*thisIsAGlobal*
>and locals are not:
>	thisIsALocal
>Even common lisp people, despite the fact that they use a language which
>throws away 50% of all the information in it's input stream (that really
>is unbelievable!), could adopt a simple convention like this. Then you
>won't fall down *that* kind of hole.

The above is the same convention as is used by the Common Lisp
community.  All the special variables defined in CLtL use this naming
scheme.  I don't know whether the convention was developed at Xerox or
not, but it has been used at MIT since about 1981 (unfortunately, a
large part of the MIT Lisp Machine OS was written before the
convention caught on, and many of the old non-starred names still
exist in the Symbolics system).

>Secondly, the argument that Lisp should become more like conventional
>languages so that people switching to it will find it easier to learn.
>Douglas Rand expressed it thus:
>]	... most programmers, especially those who are transplants from 
>]	'normal' languages like FORTRAN, PL/1, C, and PASCAL will expect
>]	lexically scoped behaviour.
>I don't buy this. The reason these people are switching to LISP is because
>they are *dissatisfied* with the *expressiveness* of their current
>language. They know that LISP is significantly different; they know they
>are going to have to re-learn. What they don't want is to find, when
>they've put in that effort, that we have castrated LISP to the extent that
>it gives them no advantage over what they've left.

First of all, the original text said "especially", not "only", meaning
that even people who aren't switching are likely to expect
lexically-scoped behavior.  Lexical scoping simplifies understanding
of a program, because one can look at a function call and the function
definition and determine the behavior, without having to know the
entire history of the call tree.

Second, just because some feature is used in the traditional languages
does not mean that it should automatically be excluded from Lisp.
Lexical scoping is a good thing, and we should not be prejudiced just
because it was used in algebraic languages first.

>The argument advanced by Patrick Arnold:
>
>]	the potential for a procedure (function) to capture variables from
>]	the environment ... violates the "black box" notion of a
>]	procedure 
>
>seems to me to be the same thing in different clothes. The '"black box"
>notion of a procedure' cannot come from LISP, because LISP has no
>procedures. 

Huh?  I think you are using too restricted a definition of
"procedure".  In the above context, I think "procedure", "function",
and "subroutine" should all be considered synonymous.

>	     It comes, in fact, from conventional programming in the ALGOL
>tradition. Part of the power and expressiveness of LISP is that we can,
>when we want to, and when we know what we're doing, write functions which
>are sensitive to changes in their environment. If you don't like this, you
>will find that there are plenty of other *very good* languages (Pascal, 
>Modula, Ada - even Scheme) which cater for your needs. Don't come and mess
>up the one language which has the expressiveness to do this.

This distinction implies that only Lisp allows one to write functions
that are dependent upon the environment.  All the other languages
mentioned allow functions and procedures to refer to global variables.
The only unique feature of Lisp is that it does not force formal
parameter variables to be lexically-scoped local variables.  I don't
see this as a major feature, and I doubt computer science would have
been held back had Lisp required programmers to write:

(defun do-something (new-read-base)
  (let ((*read-base* new-read-base))
    ...))

or even

(defun do-something (new-read-base)
  (fluid-let ((*read-base* new-read-base))
    ...))

instead of

(defun do-something (*read-base*)
  ...)

>One last point, quickly. Douglas Rand says:
>
>]	... 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 folly.
>
>This is, in my opinion (not, I admit, widely shared as yet) one of the
>worst of the Common LISP messes. It is the nature of LISP that code is
>built up incrementally. You build your system on the top of my system. Let
>us say that you are a mortal and I am a hearty adventurer. How are you to
>know which tokens I have declared special? Well, I *ought* to have
>documented them; or you could always read the source file; or, as a last
>gasp, you could always, *every single time you use a new variable* ask the
>system whether I've already declared it special. But are you *really*
>going to do these things? No. Mixing your binding schemes is asking for
>trouble - and trouble of a particularly nasty sort.

Packages, while they are not perfect, are the solution to the above
problem.  You can make sure that your variables don't collide with
mine by using a different package from me.  Yes, if you make use of
inherited packages, you run into the above problem.  One solution is
to not use inherited packages when you are not intimately familiar
with the system whose package you are inheriting from; another is to
make use of the *naming scheme* mentioned above (unfortunately, if the
provider of the system doesn't follow this convention, you lose).

>Perhaps what is being said in all this is that what we actually need is
>two standard languages: say ISO Scheme and ISO Dynamic LISP...?

A dynamic-only Lisp would be a bad idea.  We had one -- Maclisp -- and
we've abandoned it.  Most of the Common Lisp designers are former
Maclisp developers and programmers, and they consciously chose to
switch to lexical scoping by default.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
uunet!think!barmar