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...
······@hamp.hampshire.edu (everything) writes:
>Does anybody know why Steele and Sussman decided on the "one-space"
>for Scheme over the "n-space" which LISP uses?
Well I can't speak for Steele or Sussman, but to me there seem to be
two clearly compelling arguments, one theoretical and one practical,
although they turn out to be closely connected:
1. In the whole Lisp culture we make a big fuss about procedure-as-data,
a/k/a first-class procedures, a/k/a a procedure is just as good a thing
as a number or a list. Well, if that's true, it follows that a procedure
ought to be able to be the value of a variable.
2. And the practical argument is, look at the horrible ugly syntactic
contortions that CL has to use, to get around its choice: that #' business.
Try explaining that to a freshman computer science student!
P.S. Besides Scheme, I also hack Logo, which is a cousin of Lisp but
lacks lambda, so procedures are far from being first class. Because of that,
in Logo it makes perfectly good sense to me that the procedure namespace is
separate from the variable namespace. Logo doesn't pretend to treat procedures
as data (although it does have an equivalent of EVAL, so *expressions* are data).
From: Robert Munyer
Subject: Re: Symbol space in Scheme v. Lisp
Date:
Message-ID: <3g1an2$cr@Mercury.mcs.com>
In article <··········@agate.berkeley.edu>,
Brian Harvey <··@anarres.CS.Berkeley.EDU> wrote:
>······@hamp.hampshire.edu (everything) writes:
>>Does anybody know why Steele and Sussman decided on the "one-space"
>>for Scheme over the "n-space" which LISP uses?
It's also worth considering the opposite question: why doesn't Lisp
use the same "one-space" that Scheme uses?
My guess is that it's because unlike Scheme, Lisp used to be
dynamically scoped. A Scheme-style "one-space" loses big when you
have dynamic scoping.
Consider the following simplified implementation of MAPCAR:
(defun x-mapcar (f l)
(cond ((null l) nil)
(t (cons (funcall f (first l))
(x-mapcar f (rest l))))))
In a lexically scoped modern Lisp, this implementation will work.
In a dynamically scoped Lisp like MACLISP, this will work only if
the function you pass as the first argument does not use F or L as
a free variable. For example, it won't work when called like this:
(let ((l '(a)))
(x-mapcar #'(lambda (x) (cons x l))
'(1 2 3)))
[This, by the way, is one of the reasons dynamic scoping is bad.]
But if you have dynamic scoping AND a Scheme-style one-space, the
problem gets worse. In that kind of Lisp, the function x-mapcar
above will not work if the function you pass as its first argument
happens to call a function named F or L, directly OR INDIRECTLY.
For example, this won't work:
(defun f (x) (+ x 1))
(defun g (x) (+ (f x) 1))
(x-mapcar #'g '(1 2 3))
I suspect the idea that a symbol should have a "function value"
distinct from its "regular value" was intended to make it possible
to write a function like G that calls a function like F, without
having to worry about bindings created by a function like X-MAPCAR.
-- Robert
------------------------------------------------------------------------
robert munyer software r & d ······@munyer.com
>······@hamp.hampshire.edu (everything) writes:
>>Does anybody know why Steele and Sussman decided on the "one-space"
>>for Scheme over the "n-space" which LISP uses?
In article <··········@agate.berkeley.edu>,
My guess is that it's because unlike Scheme, Lisp used to be
dynamically scoped. A Scheme-style "one-space" loses big when you
have dynamic scoping.
As a point of interest, the Guile interpreter has had to resolve these
two worlds into one system. On the one hand, we have to support elisp
with its property bindings, value bindings, and function bindings for
every symbol (and yes, elisp is a dynamicly scoped lisp). On the
other hand, we also want to support standard Scheme.
Property and function bindings can be implemented in Standard Scheme,
but not without sacrificing performance and causing storage leaks.
So, we've added slots for these values to symbols but do not make use
of them when running Scheme.
Meanwhile, for the Scheme side, we've made variables into first class
objects which are distinct from the symbols that name them. This
enables us to have a module system written mostly in Scheme without
having to create new symbol universes for every namespace (a la common
lisp) and without having to perform expensive source->source
transforms on Scheme (which is how a prototype worked).
(Distinct symbol universes are also a feature of guile, but not one
used as the basis of modules.)
(Volunteers are release testing an alpha version of libguile which
i hope to release more widely Quite Soon).
-t
When the announcement of the Guile project came up, I had an immediate
concern. Will the project try to be "as compatible as possible" with
Common Lisp?
I received some response then, but I would like to know what the state
of the project is.
E.g. when Tom Lord says...
---------------------
This enables us to have a module system written mostly in Scheme without
having to create new symbol universes for every namespace (a la common
lisp) and without having to perform expensive source->source
transforms on Scheme (which is how a prototype worked).
---------------------
I wonder: will I have a 'defpackage' in Guile? Will I use the '::' and
':' notation to access symbols in other modules?
I think that not going in this direction will not be a very good
thing.
Happy Lisping
--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: ·······@cs.nyu.edu
...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht
·······@mosaic.nyu.edu asks:
Will the [Guile] project try to be "as compatible as possible" with
Common Lisp?
There is no such goal for Guile. In my post, i pointed out a way in
which Guile was different from, not similar to Common Lisp.
I wonder: will I have a 'defpackage' in Guile? Will I use the
'::' and ':' notation to access symbols in other modules?
We do have packages which are not quite the same as the Common Lisp
entities of the same name (for instance, we change the
symbol->variable mapping instead of the string->symbol mapping).
We do not impose syntax on symbol names. :: and : have no special
meaning in a symbol name in Guile.
-t
In article <·········@mercury.mcs.com>, Robert Munyer <······@MCS.COM> wrote:
> In a dynamically scoped Lisp like MACLISP, this will work only if [...]
Actually, to be safe, I should have said EARLY Maclisp. I think
that later versions supported lexical scoping in certain situations.
-- Robert
In article <··········@Mercury.mcs.com> ······@MCS.COM (Robert Munyer) writes:
>In article <·········@mercury.mcs.com>, Robert Munyer <······@MCS.COM> wrote:
>> In a dynamically scoped Lisp like MACLISP, this will work only if [...]
>
>Actually, to be safe, I should have said EARLY Maclisp. I think
>that later versions supported lexical scoping in certain situations.
Well, *compiled* MacLisp was lexically scoped, though "lexical
closures" weren't really supported. (It's possible that there
was a hack that handled functions passed as arguments ("downward
funargs") but not functions returned out of scope as results
("upward funargs").)
But I don't think this was a question of early vs late. Most Lisp
compilers have provided lexical scoping even when the interpreter
for the same implementation used dynamic scope, and programmers who
didn't "write for the compiler" often had problems when they
eventually tried compiling. In MacLisp, a variable could be
declared "special" to tell the compiler to make it dynamically
scoped.
A number of variations are possible. Franz Lisp, which still exists,
works in the way I've described for MacLisp. Common Lisp has
"special" declarations but uses the same scoping rules in both
interpreters and compilers. InterLisp took the opposite approack from
MacLisp: variables were normally dynamically scoped even in compiled
code. VAX NIL and an IBM 360 Lisp implemented the "partial" lexical
scoping of MacLisp in their interpreter as well as in their compiler.
(Does anyone know whether Lisp/VM continued this practice?)
"Special" comes from Lisp 1.5. Lisp 1.5 also had "dynamic closures".
That is, you could close over (capture the bindings of) dynamically
scoped variables. (Think of an interpreter that uses an a-list for
the values of dynamic/special variables. The closure could just
include the whole current a-list.) FUNCTION in Lisp 1.5 produced such
a closure and could be used to solve the various scoping problems that
occur when functions are passed as arguments. (You could also return
such functions as results.)
(In Lisp 1.5, the value of (FUNCTION f) was (FUNARG f a-list),
hence the term "funarg".)
Some MacLisp-related Lisps (and perhaps some versions of MacLisp)
had a form of dynamic closure (ie to hold the bindings of dynamically
scoped variables) for which you had to explicitly list the variables
to "close over". (So-called fclosures in Franz Lisp are an example.)
-- jd
From: Barry Margolin
Subject: Re: Symbol space in Scheme v. Lisp
Date:
Message-ID: <3g41gq$7e9@tools.near.net>
In article <··········@agate.berkeley.edu> ··@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
>······@hamp.hampshire.edu (everything) writes:
>>Does anybody know why Steele and Sussman decided on the "one-space"
>>for Scheme over the "n-space" which LISP uses?
>1. In the whole Lisp culture we make a big fuss about procedure-as-data,
>a/k/a first-class procedures, a/k/a a procedure is just as good a thing
>as a number or a list. Well, if that's true, it follows that a procedure
>ought to be able to be the value of a variable.
Common Lisp allows procedures to be the value of a variable:
(setq foo (symbol-function 'oddp))
Now the value of the variable FOO is the predicate that tests for oddness.
You can then write (COMPLEMENT FOO), and its value will be a function that
tests for evenness.
The difference in Common Lisp is that when a symbol (or any other data
type) appears in the car of a form, it's not evaluated as an ordinary
expression, but as a function name. So you can't then write:
(foo 3)
((complement foo) 3)
you have to write:
(funcall foo 3)
(funcall (complement foo) 3)
Procedures in Common Lisp are just as "first class" as they are in Scheme.
When referring to a data type, "first class" means that objects of that
type can be passed as parameters, returned as values, and stored in data
structures -- Common Lisp (and most other Lisp dialects) permits all these.
What isn't first class is the function position in function-call forms --
its contents are interpreted differently from the rest of the elements.
Scheme isn't immune from this "specialness" of the head of the form -- this
is the only place where unquoted syntactic keywords are permitted. Once
Scheme determines that the function position isn't a syntactic keyword it
applies normal evaluation rules to it; once Common Lisp determines that the
function position isn't a special operator it applies functional evaluation
rules to it (some Common Lispers have coinced the term "efunctuation" to
refer to this process).
--
Barry Margolin
BBN Internet Services Corp.
······@near.net
In article <··········@agate.berkeley.edu> ··@anarres.CS.Berkeley.EDU (Brian Harvey) writes:
>······@hamp.hampshire.edu (everything) writes:
>>Does anybody know why Steele and Sussman decided on the "one-space"
>>for Scheme over the "n-space" which LISP uses?
>
>Well I can't speak for Steele or Sussman, but to me there seem to be
>two clearly compelling arguments, one theoretical and one practical,
>although they turn out to be closely connected:
>
>1. In the whole Lisp culture we make a big fuss about procedure-as-data,
>a/k/a first-class procedures, a/k/a a procedure is just as good a thing
>as a number or a list. Well, if that's true, it follows that a procedure
>ought to be able to be the value of a variable.
But in an n-space Lisp, a procedure can still be the value of a
variable (as you presumably already know). I think the real issue
here is that n-space Lisps make this a somewhat exceptional case
(in that it requires more work, as in point 2).
>2. And the practical argument is, look at the horrible ugly syntactic
>contortions that CL has to use, to get around its choice: that #' business.
>Try explaining that to a freshman computer science student!
And don't forget funcall.
-- jeff
In article <··········@gort.oit.umass.edu>,
everything <······@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.
--
·············@rheged.dircon.co.uk (Simon Brooke)
How many pentium designers does it take to change a lightbulb?
1.99904274017
In article <··········@rheged.dircon.co.uk> ·····@rheged.dircon.co.uk (Simon Brooke) writes:
>OK, Stick-my-neck-out time again.
>
>I don't know which LISP 1.5 (the LisP which was first widely used)
>was, but I *think* it was a LISP2.
Lisp 1.5 was rather strange. There were separate function values
(the properties EXPR, FEXPR, SUBR, etc), but you could also use
variables w/o having to resort to FUNCALL. The FEXPR (etc) values
were checked first. Also, the function position of a function call
could be a form that would be evaluated. Repeated evaluation of
variables and other forms was possible.
>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.
I'm not sure the Scheme folk were completely indifferent to existing
code (and programming knowledge, which includes syntax), but I'll
leave that to someone else.
Your view of Common Lisp (not capitalization) is basically right
in that it was more pragmatic. But I think your accout of the
details is somewhat misleading.
Some of the people involved in the design of Common Lisp may have
wanted to "coalesce as much as possible of the LisP community around a
single variant of the language", I don't know. But if so, it didn't
have all that much effect on the contents of the language. Moreover,
CL started out as a way to unify several successors to MacLisp.
Other varieties of Lisp had considerably less importance.
After X3J13 started, by which time CLtL I already existed, people
did occasionally argue that the language should change in a way
that would decrease the difference between CL and some other kind
of Lisp, but such arguments were fairly rare, and they were not
usually successful.
Existing code did make a difference, but it did not prevent fairly
radical changes (e.g. to full lexical scoping). Moreover, there a
number of cases where significant existing stuff was left out. For
instance, Flavors was almost a de facto standard as an O-O extension
among the Lisps closest to Common Lisp. Flavors were used heavily in
ZetaLisp / Lisp Machine Lisp, and they were an important part of VAX
NIL. Some ZetaLisp Flavors implementation code had been ported to
Franz Lisp. Indeed, a number of Common Lisps have provided a version
of Flavors at one time or another. And yet they were not added to
Common Lisp.
It's also important to realize that many things were cleaned up in
Common Lisp (for instance, compilers and interpreters had to use
the same scoping rules), and many things were more precisely defined
than they had been in the usual reference manuals for other Lisps.
Most things in Common Lisp are there for fairly good reasons.
-- jeff
From: Barry Margolin
Subject: Re: Symbol space in Scheme v. Lisp
Date:
Message-ID: <3g6e0v$8o1@tools.near.net>
In article <··················@mc.lcs.mit.edu> ···@martigny.ai.mit.edu writes:
>Sorry, but I don't recall seeing this rationale written down
>anywhere. I suggest writing to Sussman directly (···@martigny.ai.mit.edu)
>for the "official" story.
Didn't Pitman and Sussman author a paper about this in Lisp Pointers about
five years ago?
--
Barry Margolin
BBN Internet Services Corp.
······@near.net