Path: utzoo!attcan!uunet!mcvax!ukc!dcl-cs!simon
From: simon@comp.lancs.ac.uk (Simon Brooke)
Newsgroups: comp.lang.lisp
Subject: Re: What's the value of lexical scoping?
Keywords: Scope, Binding, Locals, Break, Future of LISP
Message-ID: <519@dcl-csvax.comp.lancs.ac.uk>
Date: 10 Jun 88 11:39:07 GMT
References: <24508@ucbvax.BERKELEY.EDU> <515@dcl-csvax.comp.lancs.ac.uk> <452@aiva.ed.ac.uk>
Reply-To: simon@comp.lancs.ac.uk (Simon Brooke)
Organization: Department of Computing at Lancaster University, UK.
Lines: 105

Before I start: thanks to Jeff Dalton for his piece, and I accept his
correction. I was clearly wrong to claim that Marty Kent neccesarily
shared my opinion of CL. Also, Jeff is perfectly right to suggest that I
would prefer Scheme - which appears a clean, elegant, well designed
language - to CL. But for the rest....

Things are bubbling! good. Let's look at some of the arguments that have
been advanced. Firstly, the objection to dynamic binding that's most
commonly advanced: namely, that you fall down holes when you confuse
locals with globals. As John Levine writes:

]	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.

If, in a lexically scoped lisp, you refer to a global variable
thinking it's a local, or vice-versa, you'll still fall down a hole.
Lexical scoping does not obviate the need for good software engineering
practice - namely, in this case a *naming scheme*.

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.

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.

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. 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.

The key point I want to make is one which Patrick made admirably:

]	...dynamic binding... makes some forms of abatraction easier to 
]	handle (this is important for programming in the large).

Precisely so. And it is precisely for it's ability to handle abstraction
that we choose LISP as a language. If we reduce its power to do so, we
reduce it's value to 'just another programming language' - and one,
furthermore, which is greedy of machine resources and doesn't integrate
well with others.

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.

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...? I do not
reject the value of standardisation. To be able to transfer programs -
and, perhaps even more important, programming experience - from one
computing environment to another will be of steadily increasing importance
as LISP becomes accepted as a tool for some types of commercial
programming.

Happy Lisping!

** Simon Brooke *********************************************************
*  e-mail : simon@uk.ac.lancs.comp                                      * 
*  surface: Dept of Computing, University of Lancaster,  LA 1 4 YW, UK. *
*                                                                       *
*  Neural Nets: "It doesn't matter if you don't know how your program   *
***************  works, so long as it's parallel" - R. O'Keefe **********