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?
Summary: A defence of NLAMBDA, and opposition to SETF, PROG and other uglies
Message-ID: <525@dcl-csvax.comp.lancs.ac.uk>
Date: 16 Jun 88 09:52:37 GMT
References: <24508@ucbvax.BERKELEY.EDU> <515@dcl-csvax.comp.lancs.ac.uk> <199@esosun.UUCP>
Reply-To: simon@comp.lancs.ac.uk (Simon Brooke)
Organization: Department of Computing at Lancaster University, UK.
Lines: 71

In article <199@esosun.UUCP> jackson@esosun.UUCP (Jerry Jackson) disagrees
with some of the things which I see as valuable in LISP. I'd like to
advance some defence of them, point by point. Fistly:

>CL supports dynamic binding for those cases where
>it is useful (I admit they definitely exist), although dynamic binding
>is quite clearly a *BUG* (the names you give to local variables should not
>matter...)
>
If you wish to gain information from your environment, then clearly, the
names of the symbols you use do matter. If you bind your locals either
in an arg list or in a let statement, then they don't matter. If you
*don't* do this, then you are using globals, which will get you into equal
trouble no matter what binding scheme you use. So this argument is simply
not tenable. I agree that we can debate (and disagree) about which binding
scheme is preferable, but it makes no sense to describe those you don't
like as bugs.

>NLAMBDA -- cannot be made efficient (unless you consider a run-time call
>to EVAL efficient)
>
No, I agree that it cannot. I use LISP for it's expressiveness, not its
efficiency; and while I appreciate that generally you can do with a macro
all that you can do with an NLAMBDA, few people can read a macro of more
than moderate complexity. We use LISP to convey information, not only to a
machine but also to other people. Writing code they can't read doesn't
achieve this object.

>PROG,GO -- For people who never have to write powerful tools I would
>agree that these are not necessary, but if you had ever tried to compile
>a special purpose language to lisp and make it reasonably efficient, you
>would appreciate the value of having things like PROG and GO as 
>compilation targets
>
Whilst we still programme largely for von Neumann architectures, there is
need for an iterative construct in LISP; however, there are many more
elegant iterative structures than PROG available to the designers of
modern LISPs. If you are using PROG for any purpose other than iteration,
then (if I were advising you - and of course, you might not accept my
advice) I would suggest that you probably need a clearer analysis of your
problem. Myself, I would never use GO or GOTO in any language.

>tokens in parameter lists -- Isn't it really obvious that something
>like member with a few options is better than the excessive proliferation
>of look-alike functions (ala memq memql memqual ...)
>
Obviously it it, but it isn't at all obvious to me that sticking tokens in
the parameter list even helps with this.

>SETF -- I can't believe my eyes... This is one of the BEST things about
>CL... I don't know what to say.  Anyone who has actually USED CL with setf
>for a while knows what I'm talking about.
>
So you actually like overwriting cons cells without knowing what else is
pointing to them !? Either you aren't serious, or you haven't looked at
what SETF does. We all *know* REPLACs are dangerous; we all use them with
care (I hope). But SETF allows us to overwrite a cons cell without even
getting hold of it to identify it first! That is *terrifying*! and you are
going to put that horror into the hands of the innocent?

>HAVE YOU EVER USED LISP????? 

Yes. Why do you think I care about it so much?


** Simon Brooke *********************************************************
*  e-mail : simon@uk.ac.lancs.comp                                      * 
*  surface: Dept of Computing, University of Lancaster,  LA 1 4 YW, UK. *
*                                                                       *
* Thought for today: The task of a compiler is to take programs ... and *
******************** mutilate them beyond recognition [Elson] ***********