Newsgroups: comp.lang.misc,comp.lang.lisp,comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!agate!overload.lbl.gov!lll-winken.llnl.gov!uwm.edu!caen!newsxfer.itd.umich.edu!gatech!swrinde!pipex!dircon!rheged!simon
From: simon@rheged.dircon.co.uk (Simon Brooke)
Subject: Re: Symbol space in Scheme v. Lisp
Message-ID: <D2vG9H.58E@rheged.dircon.co.uk>
Organization: none. Disorganization: total.
References: <3fv8pn$llu@gort.oit.umass.edu>
Date: Mon, 23 Jan 1995 18:48:52 GMT
Lines: 63
Xref: glinda.oz.cs.cmu.edu comp.lang.misc:20112 comp.lang.lisp:16476 comp.lang.scheme:11832

In article <3fv8pn$llu@gort.oit.umass.edu>,
everything <gpzF93@hamp.hampshire.edu> wrote:

>In Scheme symbols contain only one value.  In LISP, however, symbols
>can contain several values (function, value, class, and others using
>property lists).  

>Does anybody know why Steele and Sussman decided on the "one-space"
>for Scheme over the "n-space" which LISP uses?

>Also, does anybody have any relevant references regarding this issue?

>thanks...

OK, Stick-my-neck-out time again. 

First history: in the early days both LISP1 and LISP2 implementations
were common. A LISP1 is a LisP with a single name-space; Scheme is a
LISP1. A LISP2 is a LisP with two or more name spaces; Common LISP is
a LISP2.

I don't know which LISP 1.5 (the LisP which was first widely used)
was, but I *think* it was a LISP2.

Of the implementations that followed, InterLisp and Portable Standard
Lisp were the most important LISP1s, and I guess MACLISP and LISP
Machine LISP were the most important LISP2s. 

Second, your question: my view is that the reason for the difference
is that the Scheme people were involved in a sort of clean room
redesign. They didn't care whether existing code could be ported to
their system, they wanted to demonstrate language issues as clearly
and cleanly as possible. Scheme is the result, and although they made
choices which I would not have, it looks very elegant to me.

The Common LISP development people had a different imperative. They
wanted to coalesce as much as possible of the LisP community around a
single variant of the language, and that involved holding onto
features which were perhaps less elegant, but which people were used
to using or which were essential to implementation hacks in important
bits of code. Common LISP is in a sense a pragmatic redesign: 'look,
we've got these parts in the parts bin, what's the most popular
compromise we can make out of it?'. Personally I still deeply dislike
some parts of that compromise, but it's what we've got for now.

A useful paper is __Gabriel, R. and Pitman, K: Technical Issues of
Separation in Function Cells and Value Cells: in Lisp & Symbolic
Computing, vol 1 no 1 pp 81-101__. I take this as an acceptance that a
single name space in Common LISP would have been a better thing, but
it has to be said that the conclusion is ambiguous and wiser heads
than mine have seen the paper as arguing the direct opposite.
Whichever, it does clearly set out the issues.

I started something of a flamewar about the design of Common LISP a
few months back. If it would be useful to people I could, as an act of
contrition, produce a digest of the arguments on each side.


-- 
--------simon@rheged.dircon.co.uk (Simon Brooke)

	How many pentium designers does it take to change a lightbulb?
		1.99904274017
