Re: Reassessing the state of Lisp
Peter Brett
> Newer revisions of some popular languages (C, Scheme, Perl,
> Dylan, ...) were redesigned by Victor Frankenstein (of fame for C#, C+
> +, R6RS Scheme, Perl 6, ...). Imagine the damage that has been done by
> this guy...
I'm curious -- R6RS seems to have caused a lot of controversy, but I'm
having difficulty understanding why. Can someone please point me to
some previous discussions (or documents) that would be useful in
understanding why people feel so strongly about R6RS?
Thanks in advance,
Peter
--
Peter Brett <pe...@peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre
Rainer Joswig
> Rainer Joswig <jos...@lisp.de> writes:
> > Newer revisions of some popular languages (C, Scheme, Perl,
> > Dylan, ...) were redesigned by Victor Frankenstein (of fame for C#, C+
> > +, R6RS Scheme, Perl 6, ...). Imagine the damage that has been done by
> > this guy...
>
> I'm curious -- R6RS seems to have caused a lot of controversy, but I'm
> having difficulty understanding why. Can someone please point me to
> some previous discussions (or documents) that would be useful in
> understanding why people feel so strongly about R6RS?
>
> Thanks in advance,
>
> Peter
This is a good read:
http://www.r6rs.org/ratification/results.html
Andrew Reilly
> Rainer Joswig <jos...@lisp.de> writes:
>
>> Newer revisions of some popular languages (C, Scheme, Perl, Dylan, ...)
>> were redesigned by Victor Frankenstein (of fame for C#, C+ +, R6RS
>> Scheme, Perl 6, ...). Imagine the damage that has been done by this
>> guy...
>
> I'm curious -- R6RS seems to have caused a lot of controversy, but I'm
> having difficulty understanding why. Can someone please point me to
> some previous discussions (or documents) that would be useful in
> understanding why people feel so strongly about R6RS?
There are voter rationales posted on the r6rs site www.r6rs.org
somewhere, most of which are nicely argued.
It seems to me that the main points of contention are that 1) r6rs
doesn't specify behaviour for a traditional REPL environment, being based
instead on the running of whole programs ("scripts"), and 2) a move to
insist on (case sensitive) Unicode for program text and strings.
There are several r6rs implementations available now, though, so it's
possible to try, and form ones own opinion.
Cheers,
--
Andrew
Benjamin L. Russell
wrote:
>Rainer Joswig <jos...@lisp.de> writes:
>
>> Newer revisions of some popular languages (C, Scheme, Perl,
>> Dylan, ...) were redesigned by Victor Frankenstein (of fame for C#, C+
>> +, R6RS Scheme, Perl 6, ...). Imagine the damage that has been done by
>> this guy...
>
>I'm curious -- R6RS seems to have caused a lot of controversy, but I'm
>having difficulty understanding why. Can someone please point me to
>some previous discussions (or documents) that would be useful in
>understanding why people feel so strongly about R6RS?
See the following arguments against ratification:
Chris Hanson [1]
http://www.r6rs.org/ratification/results.html#X78
Shiro Kawai [2]
http://www.r6rs.org/ratification/results.html#X99
Taylor R. Campbell [3]
http://www.r6rs.org/ratification/results.html#X100
and most especially the following one:
Nils M. Holm [4]
http://www.r6rs.org/ratification/results.html#X94
In particular, the following paragraph from the argument by Holm seems
to be a theme running through many arguments against ratification:
>The principal reason for my ``no'' vote is entirely contained in the
>first sentence of the introduction to every Scheme Report I have read
>so far:
>
>``Programming languages should be designed not by piling feature on
> top of feature, but by removing the weaknesses and restrictions that
> make additional features appear necessary.''
>
>R6RS contradicts this principle by including a lot of features in the
>language itself. Many of these features are certainly necessary in a
>``real-world'' programming language, but these features are included at
>the cost of simplicity and orthogonality. They are included arbitrarily
>and not by applying the principle outlined at the beginning of the
>Scheme Reports.
Scheme started out as a simple language. Its simplicity was the main
reason for its beauty. Even the entire specification for R5RS Scheme
could be summed in only 50 pages. Scheme distinguished itself from
most other programming languages by its emphasis on elegance.
The R6RS specification increased the size of this specification by
approximately three times. Some may argue that R6RS essentially
changed Scheme to a cleaned-up version of Common Lisp. R6RS added
many features to the core language which some say should have been
delegated to extension libraries. It can be argued that, in a sense,
Scheme lost its beauty. Worse, R6RS did this in a way which was
difficult to undo in future iterations of the specification. Scheme
gained some functionality at the expense of the one attribute which
truly distinguished the language from most other programming
languages: elegance.
Some users argue that these changes were necessary for the evolution
of Scheme. However, a counterargument advanced by such users as Holm
is that such changes could have been better introduced in the form of
extension libraries, while still retaining only a minimal core
language. Furthermore, some users, such as Kawai [2], argue that the
ratification process had been rushed, and that not enough time had
been given to the discussion process. Still others, such as Campbell
[3], go so far as to argue that what emerged was "not Scheme."
-- Benjamin L. Russell
[1] Hanson, Chris. "R6RS Ratification Vote." R6RS.Org. 6 Jan. 2008. 5
Aug. 2009. <http://www.r6rs.org/ratification/results.html#X78>.
[2] Kawai, Shiro. "R6RS Ratification Vote." R6RS.Org. 6 Jan. 2008. 5
Aug. 2009. <http://www.r6rs.org/ratification/results.html#X99>.
[3] Campbell, Taylor R. "R6RS Ratification Vote." R6RS.Org. 6 Jan.
2008. 5 Aug. 2009.
<http://www.r6rs.org/ratification/results.html#X100>.
[4] Holm, Nils M. "R6RS Ratification Vote." R6RS.Org. 6 Jan. 2008. 5
Aug. 2009. <http://www.r6rs.org/ratification/results.html#X94>.
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
Pascal Costanza
> The R6RS specification increased the size of this specification by
> approximately three times. Some may argue that R6RS essentially
> changed Scheme to a cleaned-up version of Common Lisp.
I actually think that Common Lisp is a cleaned-up version of R6RS
Scheme. ;) ;) ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
tfgordon
Seriously, why reopen this debate. The election is over. A decision
has been made. R6RS has been ratified.
There are now about six R6RS implementations: IronScheme, Ikarus,
Larceny, Mosh, PLT, and Ypsilon. (Hopefully Chez Scheme will follow
soon.)
And quite a few R6RS libraries, even though most of these are ports of
existing code.
A Steering Committee for R7RS has been formed. Life goes on. If you
want to discuss something, let's discuss how to evolve R6RS into R7RS
in
a way which meets the concerns of those who opposed R6RS, but in a way
which provides a migration path for those who have invested in R6RS
and put
their trust in this process.
-Tom Gordon
Grant Rettke
> -- Benjamin L. Russell
Ben covered everything pretty fairly, though it is sort of like
opening up old wounds.
The committee worked for free, and no one is perfect, so it is easy to
pick on them.
Everyone loves R5RS, so honestly, is there any way to improve it?
Perhaps Nils had it perfect.
Why not channel all of the energy into fixing things in R7RS?
Nothing is written in stone; and the continued existence of R5RS
systems is certainly proof of that.
Grant Rettke
> Benjamin L. Russell wrote:
> > The R6RS specification increased the size of this specification by
> > approximately three times. Some may argue that R6RS essentially
> > changed Scheme to a cleaned-up version of Common Lisp.
>
> I actually think that Common Lisp is a cleaned-up version of R6RS
> Scheme. ;) ;) ;)
Hi Pascal,
An interesting Common Lisp advocacy strategy that you might try is to
get Schemers to come on board with Common Lisp in addition to Scheme.
Think about it, there are what, a handful of new Schemers every year
that you want to snipe, versus hundreds of Schemers who can already
appreciate the strengths of both languages.
A handful or hundreds?
Your choice.
Pascal J. Bourguignon
You're under-estimating schemers I'd say. My guess is that more
students are taught scheme than Common Lisp.
--
__Pascal Bourguignon__
Peter Keller
> Why not channel all of the energy into fixing things in R7RS?
While I don't want to pick sides on whether or not R5RS or R6RS is better
or worse. I will say that scheme must always evolve. Sometimes branches
become dead ends, and other times they don't.
But no matter what happens: Keep moving!
I come from the point of view of a compiler writer. I'm in the middle
of a scheme compiler project, and I must say that having a schism in
the community over R6RS has dampened my willingness to continue since I
don't want to put a lot of time into something that may end up being an
evolutionary dead end.
If R7RS starts getting worked on and the best of R5RS and the best of R6RS
are taken and placed into it, things will get better and the community
will converge again.
Thank you.
-pete
Grant Rettke
wrote:
> Grant Rettke <gret...@gmail.com> writes:
> > Hi Pascal,
>
> > An interesting Common Lisp advocacy strategy that you might try is to
> > get Schemers to come on board with Common Lisp in addition to Scheme.
>
> > Think about it, there are what, a handful of new Schemers every year
> > that you want to snipe, versus hundreds of Schemers who can already
> > appreciate the strengths of both languages.
>
> > A handful or hundreds?
>
> > Your choice.
>
> You're under-estimating schemers I'd say. My guess is that more
> students are taught scheme than Common Lisp.
Pascal C: Yet more evidence for your new approach!
Benjamin L. Russell
wrote:
>Grant Rettke <gre...@gmail.com> wrote:
>[...]
>
>... I must say that having a schism in
>the community over R6RS has dampened my willingness to continue since I
>don't want to put a lot of time into something that may end up being an
>evolutionary dead end.
>
>If R7RS starts getting worked on and the best of R5RS and the best of R6RS
>are taken and placed into it, things will get better and the community
>will converge again.
Agreed. In that case, it might be a good idea to get the R7RS design
and ratification process started earlier than usual.
The original report, "Scheme: An Interpreter for Extended Lambda
Calculus" [1], was published on December 22, 1975.
The first revision, "The Revised Report on Scheme: A Dialect of Lisp"
[2], was published on January 1, 1978 [3], approximately two years
later.
The second revision, "The Revised Revised Report on Scheme, or An
UnCommon Lisp" (a.k.a. "R2RS") [4], was published on August 1, 1985
[5], approximately seven years and one month later.
The third revision, "Revised^3 Report on the Algorithmic Language
Scheme" (a.k.a. "R3RS") [6], was published on September 1, 1986 [7],
approximately one year and one month later.
The fourth revision, "Revised^4 Report on the Algorithmic Language
Scheme" (a.k.a. "R4RS") [8], was published on November 1, 1991 [9],
approximately five years and two months later.
The fifth revision, "Revised^5 Report on the Algorithmic Language
Scheme" (a.k.a. "R5RS") [10], was published on February 20, 1998,
approximately six years and three months later.
Lastly, the controversial sixth revision, "Revised^6 Report on the
Algorithmic Language Scheme" (a.k.a. "R6RS") [11], was published on
September 26, 2007, approximately nine years and seven months later.
The last span, between R5RS and R6RS, was nine years and seven months;
given the schismatic situation regarding R6RS, it would probably not
be wise to wait that long for the next revised report.
Is there anything that can be done to start the design and
ratification process for R7RS sooner?
-- Benjamin L. Russell
[1] Sussman, Gerald Jay, and Guy Lewis Steele Jr. "Scheme: An
Interpreter for Extended Lambda Calculus." Massachusetts Institute of
Technology Artificial Intelligence Laboratory. 22 Dec. 1975.
<http://dspace.mit.edu/bitstream/handle/1721.1/5794/AIM-349.pdf?sequence=2>.
[2] Steele, Guy Lewis, Jr., and Gerald Jay Sussman. "The Revised
Report on Scheme: A Dialect of Lisp." 1 Jan. 1978.
<http://dspace.mit.edu/bitstream/handle/1721.1/6283/AIM-452.pdf?sequence=2>.
[3] "DSpace@MIT : The Revised Report on SCHEME: A Dialect of LISP."
DSpace at MIT, Massachusetts Institute of Technology. 4 Oct. 2004. 6
Aug. 2009. <http://dspace.mit.edu/handle/1721.1/6283>.
[4] Abelson, Hal, William Clinger (editor), Gerald Jay Sussman et. al.
"The Revised Revised Report on Scheme, or An UnCommon Lisp." 1 Aug.
1985.
<http://dspace.mit.edu/bitstream/handle/1721.1/5600/AIM-848.pdf?sequence=2>.
[5] "DSpace@MIT : The Revised Revised Report on Scheme or An Uncommon
Lisp." DSpace at MIT, Massachusetts Institute of Technology. 1 Oct.
2004. 6 Aug. 2009. <http://dspace.mit.edu/handle/1721.1/5600>.
[6] Rees, Jonathan (editor), William Clinger (editor), G. J. Sussman
et. al. "Revised^3 Report on the Algorithmic Language Scheme." 1 Sept.
1986.
<http://dspace.mit.edu/bitstream/handle/1721.1/6700/AIM-848a.pdf?sequence=2>.
[7] "DSpace@MIT : Revised Report on the Algorithmic Language Scheme."
DSpace at MIT, Massachusetts Institute of Technology. 8 Oct. 2004. 6
Aug. 2009. <http://dspace.mit.edu/handle/1721.1/6700>.
[8] Clinger, Jonathan (editor), Jonathan Rees (editor), G. L. Steele
Jr. et. al. "Revised^4 Report on the Algorithmic Language Scheme." 1
Nov. 1991.
<http://dspace.mit.edu/bitstream/handle/1721.1/6424/AIM-848b.pdf?sequence=2>.
[9] "DSpace@MIT : Revised Report On The Algorithmic Language Scheme."
DSpace at MIT, Massachusetts Institute of Technology. 4 Oct. 2004. 6
Aug. 2009. <http://dspace.mit.edu/handle/1721.1/6424>.
[10] Kelsey, Richard, William Clinger, Jonathan Rees (editors) et. al.
"Revised^5 Report on the Algorithmic Language Scheme." 20 Feb. 1998.
<http://www.schemers.org/Documents/Standards/R5RS/HTML/>.
[11] Sperber, Michael, R. Kent Dybvig, Matthew Flatt (editors) et. al.
"Revised^6 Report on the Algorithmic Language Scheme." 26 Sep. 2007.
<http://www.r6rs.org/final/html/r6rs/r6rs.html>.
tfgordon
> Is there anything that can be done to start the design and
> ratification process for R7RS sooner?
The process has already been started, with the election of a Steering
Committee for R7RS.
http://www.r6rs.org/steering-committee/
It's members are:
Marc Feeley
Jonathan A Rees
William D Clinger
The first thing the Steering Committed did was expand the committee to
five members by adding
Olin Shivers and Chris Hanson to the committee.
http://www.wisdomandwonder.com/link/2850/already-postive-change-for-r7rs
You may notice that *all* of the members of the Steering Committee
voted against R6RS, with the
exception of Olin Shivers, who didn't vote.
http://www.r6rs.org/ratification/results.html
So apparently the opponents of R6RS did a better job of mobilizing
their voters for the election of the
Steering Committee than they did when R6RS was ratified.
I think R7RS is in good hands and am optimistic that R7RS will be able
to bring the community together again.
There is a web site for R7RS, but nothing's been posted yet:
Maybe someone on the Steering Committee could give us a status report?
-Tom Gordon
w_a_x_man
> > The R6RS specification increased the size of this specification by
> > approximately three times. Some may argue that R6RS essentially
> > changed Scheme to a cleaned-up version of Common Lisp.
>
> I actually think that Common Lisp is a cleaned-up version of R6RS
> Scheme. ;) ;) ;)
Expert opinion on Commune Lisp:
"an unwieldy, overweight beast"
"A monstrosity"
"sucks"
"an aberration"
"incomprehensible"
"a nightmare"
"no future"
"a significantly ugly language"
"hacks"
"bad"
In context:
Brooks and Gabriel 1984, "A Critique of Common Lisp":
Every decision of the committee can be locally rationalized
as the right thing. We believe that the sum of these
decisions, however, has produced something greater than its
parts; an unwieldy, overweight beast, with significant costs
(especially on other than micro-codable personal Lisp
engines) in compiler size and speed, in runtime performance,
in programmer overhead needed to produce efficient programs,
and in intellectual overload for a programmer wishing to be
a proficient COMMON LISP programmer.
-----
Bernard Lang:
Common Lisp did kill Lisp. Period. (just languages take a
long time dying ...) It is to Lisp what C++ is to C. A
monstrosity that totally ignores the basics of language
design, simplicity and orthogonality to begin with.
-----
Gilles Kahn:
To this day I have not forgotten that Common Lisp killed
Lisp, and forced us to abandon a perfectly good system,
LeLisp.
-----
Paul Graham, May 2001:
A hacker's language is terse and hackable. Common Lisp is not.
The good news is, it's not Lisp that sucks, but Common Lisp.
Historically, Lisp has been good at letting hackers have their
way. The political correctness of Common Lisp is an aberration.
Early Lisps let you get your hands on everything.
A really good language should be both clean and dirty:
cleanly designed, with a small core of well understood and
highly orthogonal operators, but dirty in the sense that it
lets hackers have their way with it. C is like this. So were
the early Lisps. A real hacker's language will always have a
slightly raffish character.
Organic growth seems to yield better technology and richer
founders than the big bang method. If you look at the
dominant technologies today, you'll find that most of them
grew organically. This pattern doesn't only apply to
companies. You see it in sponsored research too. Multics and
Common Lisp were big-bang projects, and Unix and MacLisp
were organic growth projects.
-----
Jeffrey M. Jacobs:
Common LISP is the PL/I of Lisps. Too big and too
incomprehensible, with no examiniation of the real world of
software engineering.
... The CL effort resembles a bunch of spoiled children,
each insisting "include my feature or I'll pull out, and
then we'll all go down the tubes". Everybody had vested
interests, both financial and emotional.
CL is a nightmare; it has effectively killed LISP
development in this country. It is not commercially viable
and has virtually no future outside of the traditional
academic/defense/research arena.
-----
Dick Gabriel:
Common Lisp is a significantly ugly language. If Guy and I
had been locked in a room, you can bet it wouldn't have
turned out like that.
-----
Paul Graham:
Do you really think people in 1000 years want to be
constrained by hacks that got put into the foundations of
Common Lisp because a lot of code at Symbolics depended on
it in 1988?
-----
Daniel Weinreb, 24 Feb 2003:
Having separate "value cells" and "function cells" (to use
the "street language" way of saying it) was one of the most
unfortuanate issues. We did not want to break pre-existing
programs that had a global variable named "foo" and a global
function named "foo" that were distinct. We at Symbolics
were forced to insist on this, in the face of everyone's
knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all
the specific things like this, but if we had had fewer
compatibility issues, I think it would have come out looking
more like Scheme in general.
-----
Daniel Weinreb, 28 Feb 2003:
Lisp2 means that all kinds of language primitives have to
exist in two versions, or be parameterizable as to whether
they are talking about the value cell or function cell. It
makes the language bigger, and that's bad in and of itself.
Pascal J. Bourguignon
> Expert opinion on Commune Lisp: [...]
> "an unwieldy, overweight beast" [...]
> In context:
> Brooks and Gabriel 1984, "A Critique of Common Lisp": [...]
So you mean that while R6RS was ill-received at it's inception, a few
years later it will be as highly praised as Common Lisp is nowadays?
--
__Pascal Bourguignon__
William D Clinger
>
> -Tom Gordon
The Scheme Language Steering Committee will give a status
report at the 2009 Workshop on Scheme and Functional
Programming, in Boston on 22 August.
See http://www.schemeworkshop.org/ and click on "2009".
Will
Elena
> Brooks and Gabriel 1984, "A Critique of Common Lisp":
>
> Every decision of the committee can be locally rationalized
> as the right thing. We believe that the sum of these
> decisions, however, has produced something greater than its
> parts; an unwieldy, overweight beast, with significant costs
> (especially on other than micro-codable personal Lisp
> engines) in compiler size and speed, in runtime performance,
> in programmer overhead needed to produce efficient programs,
> and in intellectual overload for a programmer wishing to be
> a proficient COMMON LISP programmer.
>
> -----
>
> Bernard Lang:
>
> Common Lisp did kill Lisp. Period. (just languages take a
> long time dying ...) It is to Lisp what C++ is to C. A
> monstrosity that totally ignores the basics of language
> design, simplicity and orthogonality to begin with.
> -----
>
>
> A hacker's language is terse and hackable. Common Lisp is not.
>
> The good news is, it's not Lisp that sucks, but Common Lisp.
>
> Historically, Lisp has been good at letting hackers have their
> way. The political correctness of Common Lisp is an aberration.
> Early Lisps let you get your hands on everything.
That pretty much summarizes my feelings towards CL. That's why I have
turned to PLT Scheme as the Lisp to learn, despite its lack of native
threads. After having learned both C++ and Perl, I think I've paid my
dues when it comes to learn languages more complex than it is needed.
Pascal J. Bourguignon
>> The good news is, it's not Lisp that sucks, but Common Lisp.
>>
>> Historically, Lisp has been good at letting hackers have their
>> way. The political correctness of Common Lisp is an aberration.
>> Early Lisps let you get your hands on everything.
>
> That pretty much summarizes my feelings towards CL. That's why I have
> turned to PLT Scheme as the Lisp to learn, despite its lack of native
> threads. After having learned both C++ and Perl, I think I've paid my
> dues when it comes to learn languages more complex than it is needed.
I don't understand how the presence of a standard prevents anybody to
innovate or have his way.
In the case of CL, it is even allowed to use the trade mark "Common
Lisp" to define subsets of the language, and it is of course possible
to define implementation specific features.
So assuming you'd want to make a CL with call/cc (to take an example),
you could first define a subset of CL without the features of CL that
would bother you in definining continuations, and then add a
SYS:CALL/CC feature, and you could proudly announce CLontinuation,
"a subset of Common Lisp with continuations".
Users would then gladly use your implementation because for all things
that are not continuation, they could write their code portably
between CLontinuation and SBCL or CLISP. Ie. they could use libraries
that use only the subset you defined over all the CL implementations.
Also, have a look at: http://paste.lisp.org/display/84252
A subset of Scheme (r5rs) is already a subset of Common Lisp, you
could write programs that would work identically in Scheme
implementations and in Common Lisp implementations. So in a way, all
the experiments you may do with Scheme are also experiments done on CL :-)
--
__Pascal Bourguignon__
tfgordon
> A subset of Scheme (r5rs) is already a subset of Common Lisp, you
> could write programs that would work identically in Scheme
> implementations and in Common Lisp implementations. So in a way, all
> the experiments you may do with Scheme are also experiments done on CL :-)
This must be pretty small subset of an already small version of
Scheme, R5RS.
So not many of the "experiments" I do could be done this way.
And your argument works both ways. A CL programmer who restricts
himself to
such a subset would already writing Scheme programs.
I'll assume you were joking.
-Tom G.
Pascal J. Bourguignon
I wrote that CL package exporting only this subset, so I guess you
could say I'm not just joking. Next rainy Sunday, I may write a
benchmark to compare CL implementations vs. Scheme implementations,
using only this subset :-)
--
__Pascal Bourguignon__
Peter Brett
> On Mon, 03 Aug 2009 09:44:13 +0100, Peter Brett <pe...@peter-b.co.uk>
> wrote:
>
>>Rainer Joswig <jos...@lisp.de> writes:
>>
>>> Newer revisions of some popular languages (C, Scheme, Perl,
>>> Dylan, ...) were redesigned by Victor Frankenstein (of fame for C#, C+
>>> +, R6RS Scheme, Perl 6, ...). Imagine the damage that has been done by
>>> this guy...
>>
>>I'm curious -- R6RS seems to have caused a lot of controversy, but I'm
>>having difficulty understanding why. Can someone please point me to
>>some previous discussions (or documents) that would be useful in
>>understanding why people feel so strongly about R6RS?
>
> [ Snip useful information -- thanks Benjamin! ]
I'm sorry, I didn't mean to start a flamewar!
Quod factus est, factus est. It doesn't seem to me to be particularly
worth arguing about now -- as other people have said, much better to
make constructive and well reasoned suggestions to the R7RS committee
than to complain about R6RS on c.l.scheme...
Thanks to those who responded.