Lisp or Scheme?

341 views
Skip to first unread message

Danja

unread,
Jan 5, 2001, 12:55:01 PM1/5/01
to
Hi,

I'm primarily a Java programmer but have recently started looking at XSLT.
This is essentially a (limited) functional language for transforming XML,
though it has a few procedural bits strapped on. I've barely looked at
functional languages in the past, so I thought I'd try and get a feel for
them by playing with Lisp. Maybe I'll get some fresh ideas that I can use in
Java too.

What I'm after is a standard, 'clean' version with free implementation on
the MS Windows platform (many of my existing tools are here). I was
wondering whether anyone had any advice on what to go for.

Am I right in thinking that Scheme has a simpler set of basic functions, and
so should be easier to learn?

Cheers,
Danny.


Johan Kullstam

unread,
Jan 5, 2001, 1:26:01 PM1/5/01
to
"Danja" <danny_avo...@panlanka.net> writes:

> Hi,
>
> I'm primarily a Java programmer but have recently started looking at XSLT.
> This is essentially a (limited) functional language for transforming XML,
> though it has a few procedural bits strapped on. I've barely looked at
> functional languages in the past, so I thought I'd try and get a feel for
> them by playing with Lisp. Maybe I'll get some fresh ideas that I can use in
> Java too.
>
> What I'm after is a standard, 'clean' version with free implementation on
> the MS Windows platform (many of my existing tools are here). I was
> wondering whether anyone had any advice on what to go for.

i would try clisp.

> Am I right in thinking that Scheme has a simpler set of basic
> functions, and so should be easier to learn?

if by "learn" you mean know the whole thing, then yes, scheme is
smaller and therefore there is less of it to learn.

however, functionality that you do not use need not bother you.
however a lack in functionality may force you to implement something
low-level in order to get where you wanted to go. thus, in a rich
language it can be easier to learn to do something useful.

--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
sysengr

glauber

unread,
Jan 5, 2001, 1:45:54 PM1/5/01
to
In article <9351qv$90kmv$1...@ID-57931.news.dfncis.de>,


Hello, Danny,

check http://www.alu.org (Association of Lisp Users) for free Lisp
implementations. I'm partial to CLISP, but unless you already have emacs set
up, you may be better off with Corman Lisp, since your platform is Windows.

As for Lisp x Scheme, they're very similar. Lisp has more stuff built in, so
it's usually easier for novices like me. Scheme is good too, but it requires
more work, initially.

XSLT is a descendant of DSSSL, which contained most of the Scheme language in
it. I think most Lisp/Scheme people wouldn't recognize any of it in XSLT.

One last note: there are several nice implementations of Scheme in Java (no
Common Lisp yet, that i know of). Search for kawa in your favourite Internet
search engine, for one of them. Kawa can interact freely with Java, can
compile Scheme code into .class files, etc.

g

--
Glauber Ribeiro
thegl...@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"


Sent via Deja.com
http://www.deja.com/

Steven Haflich

unread,
Jan 5, 2001, 1:51:54 PM1/5/01
to
Danja wrote:

> I'm primarily a Java programmer but have recently started looking at XSLT.
> This is essentially a (limited) functional language for transforming XML,
> though it has a few procedural bits strapped on. I've barely looked at
> functional languages in the past, so I thought I'd try and get a feel for
> them by playing with Lisp. Maybe I'll get some fresh ideas that I can use in
> Java too.

By all means you should learn Lisp, but that advice in this forum is
rather
like adice that you should brush your teeth every day.

However, you shouldn't learn Lisp as a way to learn about XSLT. XSLT is
not at all a functional language (like Lisp, C, Pascal, FORTRAN, COBOL)
but
is instead a pattern-matching-and-replace language. It is a rather
limited
on at that, since it permits only a single rewrite of each source form
or
subform.

See www.lisp.org for info about free implementations of Comon Lisp,
Scheme,
and other dialects. See xml.apache.org and look around for Xalan to
find a
free implementation of XSLT.



> What I'm after is a standard, 'clean' version with free implementation on
> the MS Windows platform (many of my existing tools are here). I was
> wondering whether anyone had any advice on what to go for.
>
> Am I right in thinking that Scheme has a simpler set of basic functions, and
> so should be easier to learn?

This is a religious issue, rather like asking whether Christianity or
Islam
is easier to learn. Common Lisp is certainly larger than Scheme, but
the set
of operations necessary for simple learning is probably not much
different.
The extended features of CL probably make it easier to use for any
specific
purpose, since so many commonly-needed idioms are built in.

felix

unread,
Jan 5, 2001, 2:25:50 PM1/5/01
to
>
>Am I right in thinking that Scheme has a simpler set of basic functions,
and
>so should be easier to learn?
>

Scheme is definitely easier to learn: You just have to understand a
relatively
small set of concepts, which you can apply in nearly every possible way.
Common LISP still keeps a load of old cruft that can be confusing.
Furthermore, implementations like MzScheme (check out <www.schemers.org>)
offer a wealth of functionality, and a nice set of development tools.


cheers,
felix


Eugene Zaikonnikov

unread,
Jan 5, 2001, 2:33:38 PM1/5/01
to
Hi,

* "Danny" == Danja <danny_avo...@panlanka.net> writes:

Danny> I've barely looked at functional languages in the past, so I
Danny> thought I'd try and get a feel for them by playing with
Danny> Lisp. Maybe I'll get some fresh ideas that I can use in Java
Danny> too.

Well, in some aspects Java is much closer to Lisp than, say, C++. It
also has GC, similar argument passing semantics and rudimentary
introspection mechanisms. There also exists a Scheme implementation
(Kawa (no relation with IDE of the same name)) which compiles directly
to Java bytecode. Guy Steele, one of the guys behind the Java project,
is also a key person in Scheme and Common Lisp history.

Danny> What I'm after is a standard, 'clean' version with free
Danny> implementation on the MS Windows platform (many of my existing
Danny> tools are here). I was wondering whether anyone had any advice
Danny> on what to go for.

As for CL, take a look at these:

- CLISP (clisp.cons.org), lightweight, free, compiles to bytecode, no
GUI;
- CormanLisp (www.corman.net), compiles to native code, free for
personal use, with inline assembler and provides COM interface to
the world;
- Allegro CL (www.franz.com), compiles to native, limited commercial
trial, includes Delphi-like GUI builder;
- Xanalys (www.xanalys.com) also has a trial of their good commercial
Lisp environment.

Can't speak about current Scheme implementations, but surely Scheme
people will enlighten you.

Danny> Am I right in thinking that Scheme has a simpler set of basic
Danny> functions, and so should be easier to learn?

The basic functions of CL and Scheme overlap alot, but CL has loads of
useful standard functions and a standard object system. Scheme makes
effort in being as elegant and non-redundant language as possible and
is widely used in academia, while CL is mostly focused on doing
practical stuff (the above doesn't means that Scheme isn't used in
industry or that Common Lisp is not elegant at all).

--
Eugene

brl...@my-deja.com

unread,
Jan 5, 2001, 3:22:35 PM1/5/01
to
Scheme's primary use has traditionally been CS education. It is
very suitable for learning functional programming; a variety of
textbooks use it.

"Danja" <danny_avo...@panlanka.net> writes:

> What I'm after is a standard, 'clean' version with free implementation on
> the MS Windows platform (many of my existing tools are here). I was
> wondering whether anyone had any advice on what to go for.

I highly recommend DrScheme, which was designed with learning in mind.
A coworker has used it with success.

If you're doing Java-based web programming and are interested in Scheme,
please do give BRL a try, especially if you're doing database-driven
pages.
http://brl.sourceforge.net/

Learning either Scheme or CL will give you a head start on learning the
other. They have a lot in common.

--
(for-each (lambda (str) (display (string-append (make-string (- 40
(quotient (string-length str) 2)) #\space) str)) (newline)) '(""
"Bruce Lewis" "MIT 1990" " http://brl.sourceforge.net/
")) ; I rarely read mail sent to brl...@my-deja.com

Marco Antoniotti

unread,
Jan 5, 2001, 3:45:17 PM1/5/01
to

"felix" <fe...@anu.ie> writes:

> >
> >Am I right in thinking that Scheme has a simpler set of basic functions,
> and
> >so should be easier to learn?
> >
>
> Scheme is definitely easier to learn: You just have to understand a
> relatively
> small set of concepts, which you can apply in nearly every possible
> way.

Including the first application of Scheme: reimplementing what is not there.


> Common LISP still keeps a load of old cruft that can be confusing.

Oh yeah. DEFSTRUCT is cruft, 2D arrays is cruft, a standard and
advanded Object System is cruft. Come on....

> Furthermore, implementations like MzScheme (check out <www.schemers.org>)
> offer a wealth of functionality, and a nice set of development tools.

Essentially a reimplementation of what is already there and standard
in Common Lisp.

Cheers

--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp

Craig Brozefsky

unread,
Jan 5, 2001, 6:38:05 PM1/5/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> > Furthermore, implementations like MzScheme (check out <www.schemers.org>)
> > offer a wealth of functionality, and a nice set of development tools.
>
> Essentially a reimplementation of what is already there and standard
> in Common Lisp.

<toke on joint>

"Man, this time we're gonna nail it! It's gonna be cleaner, and
simpler, and just fuckin' better, man!"

"That's right, dude. It's gonna friggin' rock, man!"

<another pull on the bong>

"We got a unified namespace, continuations, and hygienic macros.
We're so stacked! Muthafuckin' CL can't touch us. They might call
it re-inventing the wheel, but it's gonna be the roundest damn wheel
there ever was."

"Dude, where's my car?"


PS: I have a secret crush on scheme which I cannot deny.

Eli Barzilay

unread,
Jan 5, 2001, 7:25:06 PM1/5/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> "felix" <fe...@anu.ie> writes:
> > Furthermore, implementations like MzScheme (check out
> > <www.schemers.org>) offer a wealth of functionality, and a nice
> > set of development tools.
>
> Essentially a reimplementation of what is already there and standard
> in Common Lisp.

So what? Is it bad for Allegro to reimplement what is standard in
Common Lisp? Or, given the fact that this functionality is standard
in MzScheme, would you say that it is "essentially" a reimplementation
of what is already there and standard in MzScheme?

--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!

Friedrich Dominicus

unread,
Jan 6, 2001, 4:12:23 AM1/6/01
to
"Danja" <danny_avo...@panlanka.net> writes:

> Hi,
>
> I'm primarily a Java programmer but have recently started looking at XSLT.
> This is essentially a (limited) functional language for transforming XML,
> though it has a few procedural bits strapped on. I've barely looked at
> functional languages in the past, so I thought I'd try and get a feel for
> them by playing with Lisp. Maybe I'll get some fresh ideas that I can use in
> Java too.
>
> What I'm after is a standard, 'clean' version with free implementation on
> the MS Windows platform (many of my existing tools are here). I was
> wondering whether anyone had any advice on what to go for.

Now as I read trough the answers I do not find suggestions here. Now
there are some free implementatons of Common Lisp but I do not know if
one can get them to work easily on Windows. I'm using LispWorks for
Linux from
Xanalys here. You can get a free but somwhat restricted version for
Windows too. I downloaded that too and it seems to work
smoothless. The nice point about LispWorks is the good
documentation. It's a bit out-dated but helps you to find
through. Common Lisp is a really big language and even if people do
not like to here it a bit Perl is included "there is more than one way
to do it" ;-)

There is another relativly cheap version available called Corman
Lisp. It seems to work fine too.


Now to Scheme. I started learning Lispish languages with using
DrScheme and that things seems to work on a lot of platforms. Diverse
Unices, Windows, MacOS. The documentation is excellent too and it
comes with a bunch of extensions. And fills a big gap Scheme is still
leaving out. Scheme is really minimalistic, neverthless powerful. But
to get some work done needs usually extensions not covered by
Standard Scheme. Common Lisp offers here undoubtly much more. The
basics in both languages are nearly the same. But the differences show
up short after you have written some programs.

Because you are using Java quite a lot you might be interested in
Schemes which can be easily combined with Java. There are AFAIK two
implementations for Scheme but none for Common Lisp.

The Schemes are Kawa http://www.gnu.org/software/kawa/
and silk http://www.norvig.com/SILK.html

>
> Am I right in thinking that Scheme has a simpler set of basic functions, and
> so should be easier to learn?

The basic stuff is equally easy to graps in either Scheme or Common
Lisp maybe a bit easier in Scheme. At least that is what I found. But
I can recommend to learn both. You'll better judge yourself what suits
your needs.

Regards
Friedrich

Kirill Lisovsky

unread,
Jan 6, 2001, 7:00:10 AM1/6/01
to
In article <9351qv$90kmv$1...@ID-57931.news.dfncis.de>,
"Danja" <danny_avo...@panlanka.net> wrote:

> I'm primarily a Java programmer but have recently started looking at
XSLT.

If you are interested in XSL Transformations in Scheme:
http://www.lh.com/~oleg/ftp/Scheme/web.html#eval-SXML

> What I'm after is a standard, 'clean' version with free implementation
on
> the MS Windows platform (many of my existing tools are here). I was
> wondering whether anyone had any advice on what to go for.

SILK is another Java-based Scheme implementation which is especially
useful for Servlet/Server Pages development:
http://www.cs.brandeis.edu/silk/silkweb/index.html

> Am I right in thinking that Scheme has a simpler set of basic
functions, and
> so should be easier to learn?

It is widely used for teaching, not necessary in the universities...

Best regards,
Kirill.
--
Kirill Lisovsky
liso...@acm.org
http://www.pair.com/lisovsky/

Danja

unread,
Jan 6, 2001, 12:30:05 PM1/6/01
to
Hi,
Thanks to everyone for the extremely helpful responses. Very interesting -
e.g. I didn't realise that so much had been done on the (web) server side.
Apologies for touching the apparently sensitive CL vs Scheme area ;-)

I've had a look at the resources mentioned (thanks again), and I think I'm
going to have a play with Dr.Scheme and then try Silk with some of my own
Java stuff. No offence to the CL lobby - the clinchers were the availability
of free Windows software, the development path Scheme -> DSSSL -> XSLT
(which I wasn't aware of before, thanks once more), and the Java facilities
of Silk.

Thanks too for the historical note about the dudes behind the development of
Scheme.

Cheers,
Danny.

"Danja" <danny_avo...@panlanka.net> wrote in message
news:9351qv$90kmv$1...@ID-57931.news.dfncis.de...

Marco Antoniotti

unread,
Jan 6, 2001, 1:12:17 PM1/6/01
to

Eli Barzilay <e...@barzilay.org> writes:

> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > "felix" <fe...@anu.ie> writes:
> > > Furthermore, implementations like MzScheme (check out
> > > <www.schemers.org>) offer a wealth of functionality, and a nice
> > > set of development tools.
> >
> > Essentially a reimplementation of what is already there and standard
> > in Common Lisp.
>
> So what? Is it bad for Allegro to reimplement what is standard in
> Common Lisp? Or, given the fact that this functionality is standard
> in MzScheme, would you say that it is "essentially" a reimplementation
> of what is already there and standard in MzScheme?

It ain't in R^nRS, it ain't in Scheme. End of the story.

Remember: the main design goal of Scheme is the shortness of the R^nRS.

Christophe Rhodes

unread,
Jan 6, 2001, 2:17:08 PM1/6/01
to
[ apologies for this -- I promise that I won't contribute any more to
this discussion ]

Marco Antoniotti <mar...@cs.nyu.edu> writes:

> It ain't in R^nRS, it ain't in Scheme. End of the story.

This strikes me as a particularly blinkered view on life. It may be
`true', for some values of the word, but it's not a particularly
useful definition. This is like saying, to take an example from a
related but distinct field, "It ain't in the dictionary, it ain't
English". Languages evolve. They really do. When does Theseus' ship
stop being Theseus' ship?



> Remember: the main design goal of Scheme is the shortness of the R^nRS.

Well, speaking as someone who learnt to programme via Scheme, and is
now happy with CL as a development tool, one of Scheme's other aims
(teaching) seems to have been successful. Single data points aren't
terribly useful, I know, but then I don't think the above is either.

Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
(FORMAT T "(~@{~w ~}~3:*'~@{~w~^ ~})" 'FORMAT T "(~@{~w ~}~3:*'~@{~w~^ ~})")

Joe Marshall

unread,
Jan 6, 2001, 5:41:57 PM1/6/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

>
> It ain't in R^nRS, it ain't in Scheme. End of the story.

If it ain't in R^nRS, it ain't in R^nRS, but it might be in
MzScheme/DrScheme, MIT Scheme, Scheme 48, SIOD, Bigloo, Open Scheme,
Scheme lib (Aubrey Jaffer's stuff), EdScheme, Kawa, etc, etc,

The larger Scheme implementations have quite a rich set of
`non-standard' features, and Jaffer's Scheme lib is portable to quite
a few of the other Schemes.

> Remember: the main design goal of Scheme is the shortness of the R^nRS.

This isn't true. Scheme has evolved over the years and has been
influenced by many design goals. I think the main design goals of the
various implementations have been to satisfy a pragmatic need.

The main goal of R^nRS has been to come up with a common set of core
elements that most or all Scheme implementations have, and most or all
Scheme implementors agree are `essential' to the language. R^nRS is
what everyone agrees is canonical, implementable, and pretty much `the
right thing'.


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----

Marco Antoniotti

unread,
Jan 6, 2001, 5:54:37 PM1/6/01
to

Christophe Rhodes <cs...@cam.ac.uk> writes:

> [ apologies for this -- I promise that I won't contribute any more to
> this discussion ]
>
> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > It ain't in R^nRS, it ain't in Scheme. End of the story.
>
> This strikes me as a particularly blinkered view on life. It may be
> `true', for some values of the word, but it's not a particularly
> useful definition. This is like saying, to take an example from a
> related but distinct field, "It ain't in the dictionary, it ain't
> English". Languages evolve. They really do. When does Theseus' ship
> stop being Theseus' ship?

The problem is that Scheme has not been evolving. The main reason
being that "evolving", in this case, would mean "becoming" CL. :)

>
> > Remember: the main design goal of Scheme is the shortness of the R^nRS.
>
> Well, speaking as someone who learnt to programme via Scheme, and is
> now happy with CL as a development tool, one of Scheme's other aims
> (teaching) seems to have been successful. Single data points aren't
> terribly useful, I know, but then I don't think the above is either.

I still think that SICP is one of the best book about "programming"
ever written. The fact that it is in Scheme is its main drawback.
The point being that there is *no* reason not to use CL instead of
Scheme as a teaching tool.

Alas, we can go back in history only to see that we were not there at
the time. Personally I believe that Scheme *is* more elegant than CL
in many ways, and maybe, had the people deciding what went and what did
not go in the standard been a little braver, we would not have this
split nowadays. Not that I am in any position to criticize.

Let's just remember that tombs are full of hindsights. :)

Eli Barzilay

unread,
Jan 6, 2001, 8:20:12 PM1/6/01
to
Joe Marshall <j...@content-integrity.com> writes:

> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> >
> > It ain't in R^nRS, it ain't in Scheme. End of the story.
>
> If it ain't in R^nRS, it ain't in R^nRS, but it might be in
> MzScheme/DrScheme, MIT Scheme, Scheme 48, SIOD, Bigloo, Open Scheme,
> Scheme lib (Aubrey Jaffer's stuff), EdScheme, Kawa, etc, etc,

That's right - if you restrict yourself to `pure' Scheme, then you
couldn't do much, but such a restriction would be pretty just as
ridiculous as Lisp users implementing their own networking/threading
or whatever. Complaining about the absent of these things would get
an answer of "any good CL implementation that has them".


> > Remember: the main design goal of Scheme is the shortness of the R^nRS.

> [...]


> The main goal of R^nRS has been to come up with a common set of core
> elements that most or all Scheme implementations have, and most or
> all Scheme implementors agree are `essential' to the language.
> R^nRS is what everyone agrees is canonical, implementable, and
> pretty much `the right thing'.

Right, you can just treat the Scheme `Standard' as that common core,
nobody expects you to build any serious thing on top of that bare
standard. In this sense, the CL Standard is closer to something you
can actually work with, but still there are holes that implementations
fill. And even if you go through the nightmare of trying to abstract
such features into the standard (as done with the file system
interface), you'll still have problems with any new thing that people
happen to use in the future.

Eli Barzilay

unread,
Jan 6, 2001, 8:33:00 PM1/6/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> The problem is that Scheme has not been evolving.

The standard hasn't been evolving much. Implementations evolved a
*lot*.


> The main reason being that "evolving", in this case, would mean
> "becoming" CL. :)

As much as I like CL's great power, Scheme implementations have been
evolved in ways that are pretty different. Of course, a lot of the
functionality that these implementations provide is stuff that you
have in CL (after all, I'd be surprised to find a Scheme hacker that
doesn't know and had experience with Lisp), but what's so bad about
that as long as you as a user of an implementation can access that
functionality? I really don't think that the original intent of
Scheme was to have a language that is inherently less powerful than
Lisp, just a core that is cleaner, that allows expansion, in a
healthier way (were `healthier' in this context is probably a good
subject for flamewars).


> I still think that SICP is one of the best book about "programming"
> ever written. The fact that it is in Scheme is its main drawback.

The fact that the authors themselves consider Scheme as being one of
its major advantages indicates that something is fishy in your views.


> The point being that there is *no* reason not to use CL instead of
> Scheme as a teaching tool.

Yes, this is the kind of statements that would have high chances to
start a flame.


> Alas, we can go back in history only to see that we were not there
> at the time. Personally I believe that Scheme *is* more elegant
> than CL in many ways, and maybe, had the people deciding what went
> and what did not go in the standard been a little braver, we would
> not have this split nowadays. Not that I am in any position to
> criticize.

I think that many people like myself would love to see a `cleaned'
version of CL by adding all of its stuff on top of Scheme (IIRC, xlisp
was trying to do something similar). But the problem is that the
world keeps moving, and many concepts that are deep in the core of
Lisp (e.g, packages instead of modules) turned out to have better
solutions than these in Lisp, which makes Scheme implementation
diverge on them instead of converging back to Lisp.

Rob Warnock

unread,
Jan 6, 2001, 10:37:10 PM1/6/01
to
Eli Barzilay <e...@barzilay.org> wrote:
+---------------
| ...many concepts that are deep in the core of Lisp (e.g, packages

| instead of modules) turned out to have better solutions than these
| in Lisp, which makes Scheme implementation diverge on them instead
| of converging back to Lisp.
+---------------

In particular (since MzScheme *was* mentioned), the PLT groups's[*] work
on first-class compilation "units" (modules) seems quite significant
[see <URL:http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node54.htm>
for technical details], and is backed up with both theoretical research
<URL:http://www.cs.rice.edu/CS/PLT/Publications/index.shtml#papers> and
several years of practical experience in implementing large systems with it
[the whole DrScheme/MrEd/MzScheme layering is based on units-with-signatures].

It would be interesting to see if there would be any benefit to adding
a similar scheme (no pun intended) to Common Lisp. [Or conversely, whether
there is any point in trying to extend MzScheme's single-inheritance object
system to multiple-inheritance.]

Or perhaps these two worlds are inherently incompatible with nothing
to learn from each other (which, if true, would be sad, IMHO).


-Rob

[*] I use the plural possessive here, since with the graduation
of several of their PhD's, the original Rice University PLT
(Programming Languages Team) has spawned additional "colonies"
at Brown & Utah (see <URL:http://www.cs.rice.edu/CS/PLT/>).

-----
Rob Warnock, 31-2-510 rp...@sgi.com
SGI Network Engineering http://reality.sgi.com/rpw3/
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA

Lieven Marchand

unread,
Jan 7, 2001, 7:48:54 AM1/7/01
to
Eli Barzilay <e...@barzilay.org> writes:

> I think that many people like myself would love to see a `cleaned'
> version of CL by adding all of its stuff on top of Scheme (IIRC, xlisp
> was trying to do something similar).

You could check out the IS-LISP standard for an attempt in that
direction. It's an interesting read and what they left out / changed
w.r.t CL could be a fine starting point for discussion.

> But the problem is that the world keeps moving, and many concepts
> that are deep in the core of Lisp (e.g, packages instead of modules)
> turned out to have better solutions than these in Lisp, which makes
> Scheme implementation diverge on them instead of converging back to
> Lisp.

Since standard Scheme doesn't have a module system, which
implementation's do you consider superior to CL packages? I've found
not much wrong with them once you take the time to understand
them. Most criticism seems to come from people who expect them to be a
static lexical concept like Ada packages, which they are not.

--
Lieven Marchand <m...@village.uunet.be>
Glaðr ok reifr skyli gumna hverr, unz sinn bíðr bana.

Oliver Bandel

unread,
Jan 6, 2001, 7:02:14 PM1/6/01
to

In comp.lang.scheme Erik Naggum <er...@naggum.net> wrote:
> * Johan Kullstam <kull...@ne.mediaone.net>

> | if by "learn" you mean know the whole thing, then yes, scheme is
> | smaller and therefore there is less of it to learn.

> This is not the whole truth. Learning to use a language also means
> getting into the culture surrounding the language, as used by other
> people. This includes such things as idioms. I have found Scheme very
> hard to get into for this reason. It is somewhat like C++ in this way:
> The language itself is nearly useless, but once you get into it, you see
> that "billions and billions" of idioms and arcane ways to do non-trivial
> things that the language does not _really_ support need to be mastered as
> well. Since Common Lisp is so amazingly rich and powerful as is, there
> is little idiom and most everything can be done in a straight-forward
> way. There is an inverse relationship between language size and code
> size when the language has grown in size because very smart people have
> thought very carefully about what would make user programs smaller.

But to learn the language and it's pure semantic, it's maybe
better to start with a small language. When one knows, who
it works, one can use the bigger one, if needed and do the
things very lazy, reusing existing code/libraries.

If you want to learn C, you better start with a Unix-machine,
not with windows, and with Kernighan&Ritchies C-Programming
book, not with any other, describing big, but non-standard
libraries, as M$ it's libs.

After learning the basics of the language, one can choose
any library and is not afraid, when changing from one
platfor to another: If one knows, that C is pure and
the bloat is all libraries, then no confusion starts,
if one changes the plattform.
Many people, coming from win to linux doesn't know,
that C is small and that the libraries they used for
long time, are not part of the language itself.

Maybe it's littlebid different in the case of Lisp,
but one then - I think, with my Lisp-beginners knowledge -
is conatrained to ude Common Lisp. If I see it right,
that's the only standardized Lisp (?!).


> | however, functionality that you do not use need not bother you.

> On the contrary, the more you know about, the more you realize that you
> can do with existing language support and thus don't have to do yourself,
> the more you need, and thus over time the more you use. This is probably
> how Perl "succeeded", in the same way bacteria succeed.

Well, Perl itself is powerful enough and it's libraries are too.

All the additional Packages on CPAN are not part of Perl itself.

Comparing in this way, one can use Scheme and any library
developed for this language and name it Scheme too. But
that's not the language. It's a library, wiritten in that
language, but not part of it.

> | however a lack in functionality may force you to implement something
> | low-level in order to get where you wanted to go. thus, in a rich
> | language it can be easier to learn to do something useful.

> Exactly.

But as a beginner of a new language it may be better to learn a lot.
And that's done be doing it. And thats done by programming from
the scratch.

That's the same, when using Perl: Many people know little about
Perl-programming, but a lot of Modules. They look into books
or in on the CPAN and to a trial-and-error programming.
They would be better programmers if the read books like
"Programming Perl" and doing it from scratch.
After that - when they know enough of Perl -, they can use
the Modules (and better as in the other way).
(And it's really an advantage, when one knows how to program
in C.)

Tschüß,
Oliver

Johan Kullstam

unread,
Jan 7, 2001, 12:53:59 PM1/7/01
to
Oliver Bandel <oli...@first.in-berlin.de> writes:

> In comp.lang.scheme Erik Naggum <er...@naggum.net> wrote:
> > * Johan Kullstam <kull...@ne.mediaone.net>
> > | if by "learn" you mean know the whole thing, then yes, scheme is
> > | smaller and therefore there is less of it to learn.
>
> > This is not the whole truth. Learning to use a language also means
> > getting into the culture surrounding the language, as used by other
> > people. This includes such things as idioms. I have found Scheme very
> > hard to get into for this reason. It is somewhat like C++ in this way:
> > The language itself is nearly useless, but once you get into it, you see
> > that "billions and billions" of idioms and arcane ways to do non-trivial
> > things that the language does not _really_ support need to be mastered as
> > well. Since Common Lisp is so amazingly rich and powerful as is, there
> > is little idiom and most everything can be done in a straight-forward
> > way. There is an inverse relationship between language size and code
> > size when the language has grown in size because very smart people have
> > thought very carefully about what would make user programs smaller.
>
> But to learn the language and it's pure semantic, it's maybe
> better to start with a small language. When one knows, who
> it works, one can use the bigger one, if needed and do the
> things very lazy, reusing existing code/libraries.

everybody always starts small and works up. you can choose
1) a small simple language
2) a small and simple subset of a large rich language
in both cases you can learn. but in the former, you have to move to
something else. in the latter you have room to grow.

--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]

Don't Fear the Penguin!

Eli Barzilay

unread,
Jan 7, 2001, 1:00:26 PM1/7/01
to
Lieven Marchand <m...@village.uunet.be> writes:

> You could check out the IS-LISP standard for an attempt in that
> direction. It's an interesting read and what they left out / changed
> w.r.t CL could be a fine starting point for discussion.

Any pointers? Last time I've seen it, it didn't look too popular...
The problem is probably that between CL and Scheme no one will go for
it.


> Since standard Scheme doesn't have a module system, which
> implementation's do you consider superior to CL packages?

If wasn't clear from my previous posts, I'm using MzScheme. They have
an excellent system for seperate units, and an even much better module
system on its way (which should be out shortly). Lots of good ideas
and clean design went into it.


> I've found not much wrong with them once you take the time to
> understand them. Most criticism seems to come from people who expect
> them to be a static lexical concept like Ada packages, which they
> are not.

Like any other Scheme hacker that started with Lisp, I have no
problems at all with CL packages. But it has its limits... It
generally feels like something that started as a hack around an
existing language so you get seperate "namespaces" but still no
problems with old code. Not that I have anything against such hacks
(CLOS is another such hack which is one of the most beautiful things I
have ever seen), but the huge advantage of Scheme implementation is
that they don't have any historic chains to restrict them. Also, IMO,
because you can consider this thing an advantage of Lisp, then people
who use these two dialects of a great concept have such bitter fights.

Eli Barzilay

unread,
Jan 7, 2001, 4:11:43 PM1/7/01
to
Erik Naggum <er...@naggum.net> writes:

> Huh? What _is_ Scheme these days but restrictive historic chains? Once
> a virtual incubation chamber for fledgling ideas, many of which were
> really good, with much debate and spirited discussions that had far-flung
> repercussions, what's left of this once flexible language design is a
> "standard" so rigid that they can't even change the wording, and every
> good idea in Scheme is picked up in a better way by other languages that
> have not coagulated. What's left in Scheme is first-class continuations,
> which is probably not a good idea, after all.

1. There's a bit more than just continuations there (and I refuse to
get myself in the continuations-good-or-bad flame).
2. You're talking about Scheme - the standard, see below.


> However, _any_ implementation can have as much or little historic chains
> to restrict them as they wish. It is a very grave mistake to think that
> following a standard is restricting you in any way. I'm not saying you
> [...]
> [...]
> [...]

My main point is that the standard CL spec is taken by implementations
in a fundamentally different way than the way the Scheme Standard is
taken by Scheme implementations. There are these cases which CL
implementaions have to treat the standard similarly (or live without
sockets, ffi etc), but mostly they have a more well-defined path.
Scheme implementations always take the standard as the guide-line for
the core language, as the basis that they're supposed to add stuff
onto -- I have never seen any Scheme implementation that implements
the standard and nothing else, and the though of using something like
that deserve what your approach to Scheme is.


> You have implicitly argued that Common Lisp has historic chains that
> restrict an implememtation from implementing a module system like the
> _undoubtedly_ nifty thing that your favorite-among-thousands Scheme
> implementation has done. I suggest you show us those chains and just how
> they restrict a Common Lisp implementation. Or retract ths silly claim.

Again, I will not go into comparison of approaches (btw, CL does not
have any `modules' to begin with -- packages are not seperate units of
compilation), what I said is that when Lisp was developed to have
packages for symbols there were (a) not many alternatives at that
time, and (b) even if they were, since the language spec contains much
more you cannot play with ideas that damage the language as a whole.
I think that there is nothing wrong in my logic: define your 2
properties of your language and it is possible to extend it in many
ways, define 2000 properties of your language and it becomes harder to
extend it in a consistent way.


> | Also, IMO, because you can consider this thing an advantage of Lisp, then
> | people who use these two dialects of a great concept have such bitter
> | fights.
>

> Was that meant to be "advantage over Lisp"? I can't make sense of what
> you've written otherwise. Today, Scheme is nothing more than a dialect
> of _Algol_ with a somewhat Lispy syntax and a few good ideas thrown in
> for good measure. It used to be much more, but has been surpassed by
> almost everything.

No, what I said is that Lisp people treat their spec in a very
different way than Scheme people. This is the constant source of
flamewars, for example, you attack the Scheme standard, when people
try to defend their Scheme implementation.


> What makes for the bitter fights is that Scheme
> people want to call their pet language a Lisp, which actually hurts
> Common Lisp by instilling in people who do not yet know whom to trust or
> not, that all the silly problems they have with Scheme apply to _all_
> Lisps.

I don't believe that the problems that Scheme faces are related much
to the problems that Lisp has, certainly not as a philosophy since in
that aspect they are very different (but again, not when you compare
CL to some specific Scheme implementation). Second, I think that
people who call Scheme `Lisp' are pretty rare, a `dialect of Lisp' is
more common probably because people tend to generalize based on the
visual form of the language.


> If Scheme people could refrain from calling their Algol dialect a
> Lisp, a lot less animosity would result.

Also, of you refrain from calling their Scheme implementaion an Algol
dialect.


> I'm happy to leave people alone
> who only hurt themselves, provided they agree to go away and do it out of
> my sight, of course. Most Scheme people do. Some insist on posting yet
> more of their unfounded and vague nonsense about Common Lisp here.

I think I have established a long history of no posts here... My only
attempted point is to try to make people that it is not Scheme that
you should be talking about, but Scheme implementation. If you have
something against `pure Scheme' users (which probably don't exist)
then these problems don't apply to people who say anything about
Scheme here.

Lieven Marchand

unread,
Jan 7, 2001, 3:06:55 PM1/7/01
to
Eli Barzilay <e...@barzilay.org> writes:

> Lieven Marchand <m...@village.uunet.be> writes:
>
> > You could check out the IS-LISP standard for an attempt in that
> > direction. It's an interesting read and what they left out / changed
> > w.r.t CL could be a fine starting point for discussion.
>
> Any pointers? Last time I've seen it, it didn't look too popular...
> The problem is probably that between CL and Scheme no one will go for
> it.
>

Oh, I didn't mean to use as primary language, although there is a
commercial implementation now. I meant as a data point in comparing
the design space between CL and Scheme. E.g., unlike Scheme, they've
kept most of the CL reader syntax (#char stuff) but they didn't make
the reader programmer extendible, so no set-macro-character.

>
> > Since standard Scheme doesn't have a module system, which
> > implementation's do you consider superior to CL packages?
>
> If wasn't clear from my previous posts, I'm using MzScheme. They have
> an excellent system for seperate units, and an even much better module
> system on its way (which should be out shortly). Lots of good ideas
> and clean design went into it.
>

Any design document available or should I wait for the new release?

> Like any other Scheme hacker that started with Lisp, I have no
> problems at all with CL packages. But it has its limits... It
> generally feels like something that started as a hack around an
> existing language so you get seperate "namespaces" but still no
> problems with old code. Not that I have anything against such hacks

I don't know. Most people with comments like yours want either a
module system that enforces encapsulation or a Ada-like package system
that verifies correct types/existence of functions etc. I don't see CL
packages as a hack. I see them as a solution to a different problem,
letting different worlds coexist in one Lisp system. I don't know
where the package system was developed, but I think a fine example of
this is the Symbolics Lisp system, where you can have ZetaLisp and
Common Lisp and a number of other syntaxes coexisting and
cooperating. The CL package system is a dynamic solution to these kind
of problems, so it's bound to disappoint people who want a static
module system.

> (CLOS is another such hack which is one of the most beautiful things I
> have ever seen), but the huge advantage of Scheme implementation is
> that they don't have any historic chains to restrict them. Also, IMO,
> because you can consider this thing an advantage of Lisp, then people
> who use these two dialects of a great concept have such bitter fights.

You seem to call everything that can be implemented with macrology a
hack. I agree CLOS is a beautiful system, and one of best products of
a standardisation (sub)committee I know of, but the fact that one
original implementation was as a macro layer above CLtL1 (PCL) just
shows how versatile Lisp + a good macro system is. It shouldn't be
used as argument to call the product a hack.

Eli Barzilay

unread,
Jan 7, 2001, 4:29:33 PM1/7/01
to
Lieven Marchand <m...@village.uunet.be> writes:

> Any design document available or should I wait for the new release?

It's probably a bit too early now...


> I don't know. Most people with comments like yours want either a
> module system that enforces encapsulation or a Ada-like package system
> that verifies correct types/existence of functions etc.

Actually I don't have any string opinion about using module system X
or Y. I was just giving it as an example.


> I don't see CL packages as a hack. I see them as a solution to a
> different problem, letting different worlds coexist in one Lisp

> system. [...]


> You seem to call everything that can be implemented with macrology a

> hack. [...]

This seems like a good point to use the jargon file -- looks like you
use hack in the first sense (a quick job that produces what is needed,
but not well), but I'm using the second one (an incredibly good, and
perhaps very time-consuming, piece of work that produces exactly what
is needed). I refer to most of my programs as "hacks". I hoped the
CLOS example would clarify that (being something I admire), certainly
no relation to something that can be implemented with or without
macros.

Rob Warnock

unread,
Jan 7, 2001, 10:02:13 PM1/7/01
to
Lieven Marchand <m...@village.uunet.be> wrote:
+---------------

| Eli Barzilay <e...@barzilay.org> writes:
| > I think that many people like myself would love to see a `cleaned'
| > version of CL by adding all of its stuff on top of Scheme ...

|
| You could check out the IS-LISP standard for an attempt in that
| direction. It's an interesting read and what they left out / changed
| w.r.t CL could be a fine starting point for discussion.
+---------------

Also see Henry Baker's paper "Critique of DIN Kernel Lisp Definition"

<URL:http://linux.rice.edu/~rahul/hbaker/CritLisp.html>
<URL:http://linux.rice.edu/~rahul/hbaker/CritLisp.ps.Z>

ISO/DIN DKLisp was another attempt to start with a "small & clean" kernel,
"a minimal language on top of which a larger language can be built."
Baker makes some telling points against *both* Common Lisp & Scheme...


-Rob

Reini Urban

unread,
Jan 8, 2001, 12:41:54 AM1/8/01
to
Eli Barzilay wrote:
>If wasn't clear from my previous posts, I'm using MzScheme. They have
>an excellent system for seperate units, and an even much better module
>system on its way (which should be out shortly). Lots of good ideas
>and clean design went into it.

scheme48 already has all this.
and better functionality than mzscheme, in several regards, btw.
just no graphics.

--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html

Eli Barzilay

unread,
Jan 8, 2001, 2:18:27 AM1/8/01
to
rur...@sbox.tu-graz.ac.at (Reini Urban) writes:

> scheme48 already has all this.
> and better functionality than mzscheme, in several regards, btw.
> just no graphics.

1. Everything I could dig on Scheme48 is pretty dusty.

2. Scheme48 is specifically mentioned in the PLT proposal.

3. Why would you want to start a Scheme flamewar in this NG?

Marco Antoniotti

unread,
Jan 8, 2001, 12:05:26 PM1/8/01
to

Eli Barzilay <e...@barzilay.org> writes:

The key observation here is that Scheme implementations *cannot* and
*must* diverge from the standard, simply because the standard is so
restrictive that it is impossible to do anything with it.

In Common Lisp the number of "deviations" is actually circumscribed to
pretty much defined "libraries" for which each implementation defines
a specific interface. Given that the implementations are few, it is
still possible to write portable programs.

> > You have implicitly argued that Common Lisp has historic chains that
> > restrict an implememtation from implementing a module system like the
> > _undoubtedly_ nifty thing that your favorite-among-thousands Scheme
> > implementation has done. I suggest you show us those chains and just how
> > they restrict a Common Lisp implementation. Or retract ths silly claim.
>
> Again, I will not go into comparison of approaches (btw, CL does not
> have any `modules' to begin with

Scheme does not have modules. Remember, it ain't in R^nRS, it ain't
in Scheme. CL has packages, which can be used as modules and are,
especially in conjunction with "community defined standard" or
"specific vendor/implementation definitions": defsystem is one of
these objects. Note that here I am concerned about the "use" of the
system. If you object that I cannot write a "library" (a .dll or a
.so or a .a) in CL, I will respond with the request that you check
what each CL vendor/implementor actually does. You can also check the
old and not much used WACL in the AI.Repository.

The bottom line does not change. CL has DEFSTRUCT, Scheme does not.

> -- packages are not seperate units of
> compilation), what I said is that when Lisp was developed to have
> packages for symbols there were (a) not many alternatives at that
> time, and (b) even if they were, since the language spec contains much
> more you cannot play with ideas that damage the language as a whole.
> I think that there is nothing wrong in my logic: define your 2
> properties of your language and it is possible to extend it in many
> ways, define 2000 properties of your language and it becomes harder to
> extend it in a consistent way.
>
>
> > | Also, IMO, because you can consider this thing an advantage of Lisp, then
> > | people who use these two dialects of a great concept have such bitter
> > | fights.
> >
> > Was that meant to be "advantage over Lisp"? I can't make sense of what
> > you've written otherwise. Today, Scheme is nothing more than a dialect
> > of _Algol_ with a somewhat Lispy syntax and a few good ideas thrown in
> > for good measure. It used to be much more, but has been surpassed by
> > almost everything.
>
> No, what I said is that Lisp people treat their spec in a very
> different way than Scheme people. This is the constant source of
> flamewars, for example, you attack the Scheme standard, when people
> try to defend their Scheme implementation.

Exactly. I agree on this. Now, the value of the standard is
paramount. I just mplemented a non trivial piece of code and it runs
on ACL, CMUCL, CLisp and LWW. (Sorry, I do not have other CL
implementations at hand). On two OS's.

There is no way I could have not achieved the same level of
portability using Scheme, simply because any two implementations just
differ too much.

What puzzles me is the strenght by which "Schemers" (I love that
name!) refuse to acknowledge this key point.

...

> I think I have established a long history of no posts here... My only
> attempted point is to try to make people that it is not Scheme that
> you should be talking about, but Scheme implementation. If you have
> something against `pure Scheme' users (which probably don't exist)
> then these problems don't apply to people who say anything about
> Scheme here.

I believe we agree on this here. The problem is the godzillion
different Scheme implementations out there, all subtly incompatible
and all trying to be different from CL.

Cheers

PS. As an aside on SICP. The fact that it uses Scheme, may be another
historical quirk. CL was not available when SICP was being shaped
at MIT. And, AFAIK, MacLisp was indeed quite "dirty" to be given
in the hands of freshmen. So, let's not confound history and
market forces with technical merit. It should be obvious to many
that they don't always mix well.

Marco Antoniotti

unread,
Jan 8, 2001, 12:10:07 PM1/8/01
to

Eli Barzilay <e...@barzilay.org> writes:

> rur...@sbox.tu-graz.ac.at (Reini Urban) writes:
>
> > scheme48 already has all this.
> > and better functionality than mzscheme, in several regards, btw.
> > just no graphics.
>
> 1. Everything I could dig on Scheme48 is pretty dusty.
>
> 2. Scheme48 is specifically mentioned in the PLT proposal.
>
> 3. Why would you want to start a Scheme flamewar in this NG?

A case in point. The vendor/implementor flamewars on CLL most of the
time refer to the degree of adherence to the standard and (with one
notable exception) are always minor.

I do not recall any "major" flawar pitting one implementation against
the other. The competition is about performance and usability, not
about what CL feature that is not in R^nRS is being implemented or not
in implementation X. :)

Marco Antoniotti

unread,
Jan 8, 2001, 12:16:09 PM1/8/01
to

Joe Marshall <j...@content-integrity.com> writes:

> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> >
> > It ain't in R^nRS, it ain't in Scheme. End of the story.
>
> If it ain't in R^nRS, it ain't in R^nRS, but it might be in
> MzScheme/DrScheme, MIT Scheme, Scheme 48, SIOD, Bigloo, Open Scheme,
> Scheme lib (Aubrey Jaffer's stuff), EdScheme, Kawa, etc, etc,
>
> The larger Scheme implementations have quite a rich set of
> `non-standard' features, and Jaffer's Scheme lib is portable to quite
> a few of the other Schemes.

Then why hasn't this set of features made it into the R^nRS? Also,
what is the content of Scheme Lib? (This is a rethorical question).

> > Remember: the main design goal of Scheme is the shortness of the R^nRS.
>
> This isn't true. Scheme has evolved over the years and has been
> influenced by many design goals. I think the main design goals of the
> various implementations have been to satisfy a pragmatic need.
>
> The main goal of R^nRS has been to come up with a common set of core
> elements that most or all Scheme implementations have, and most or all
> Scheme implementors agree are `essential' to the language. R^nRS is
> what everyone agrees is canonical, implementable, and pretty much `the
> right thing'.

CL is canonical, implementable and pretty much 'the right thing' as
well.

Marco Antoniotti

unread,
Jan 8, 2001, 12:22:45 PM1/8/01
to

Eli Barzilay <e...@barzilay.org> writes:

> Joe Marshall <j...@content-integrity.com> writes:
>
> > Marco Antoniotti <mar...@cs.nyu.edu> writes:
> >
> > >
> > > It ain't in R^nRS, it ain't in Scheme. End of the story.
> >
> > If it ain't in R^nRS, it ain't in R^nRS, but it might be in
> > MzScheme/DrScheme, MIT Scheme, Scheme 48, SIOD, Bigloo, Open Scheme,
> > Scheme lib (Aubrey Jaffer's stuff), EdScheme, Kawa, etc, etc,
>
> That's right - if you restrict yourself to `pure' Scheme, then you
> couldn't do much, but such a restriction would be pretty just as
> ridiculous as Lisp users implementing their own networking/threading
> or whatever. Complaining about the absent of these things would get
> an answer of "any good CL implementation that has them".

We are not talking about threading (and yes, most CL implementations
have threading, and most of them follow a common ancestral API).

We are talking about STRUCTS and 2D Arrays.

If you restrict yourself to ANSI CL you can do much more
than what you can do if you restrict yourself to R^nRS.

Not only, if you restrict yourself to ANSI CL you can do much much much more
than what you can do if you restrict yourself to k Scheme implementations.

> Right, you can just treat the Scheme `Standard' as that common core,
> nobody expects you to build any serious thing on top of that bare
> standard. In this sense, the CL Standard is closer to something you
> can actually work with,

Then why do you use Scheme implementation X (and not Y)?

> but still there are holes that implementations
> fill. And even if you go through the nightmare of trying to abstract
> such features into the standard (as done with the file system
> interface), you'll still have problems with any new thing that people
> happen to use in the future.

People using CL are well aware of the limitations of the standard, but
most of the time they can leverage the much greater power of the
substrate to come up with truly portable solutions.

Eli Barzilay

unread,
Jan 8, 2001, 1:14:52 PM1/8/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> We are not talking about threading (and yes, most CL implementations
> have threading, and most of them follow a common ancestral API).
>
> We are talking about STRUCTS and 2D Arrays.

Which is what I said - different levels of drawing the lines.


> If you restrict yourself to ANSI CL you can do much more
> than what you can do if you restrict yourself to R^nRS.

If it wasn't clear enough that this is exactly what I said then: I
think that if you restrict yourself to ANSI CL you can do much more


than what you can do if you restrict yourself to R^nRS.


> Not only, if you restrict yourself to ANSI CL you can do much much
> much more than what you can do if you restrict yourself to k Scheme
> implementations.

I don't think that 1000 is a correct ratio.


> > Right, you can just treat the Scheme `Standard' as that common core,
> > nobody expects you to build any serious thing on top of that bare
> > standard. In this sense, the CL Standard is closer to something you
> > can actually work with,
>
> Then why do you use Scheme implementation X (and not Y)?

Because I like it, because I agree with it's design decisions,
whatever. Why do you use OS A and not B?


> People using CL are well aware of the limitations of the standard, but
> most of the time they can leverage the much greater power of the
> substrate to come up with truly portable solutions.

People using Scheme are well aware of the limitations of the standard.
What they do with this awareness is, as I said, different than
solutions that are portable to all Schemes.

Eli Barzilay

unread,
Jan 8, 2001, 1:19:04 PM1/8/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> A case in point. The vendor/implementor flamewars on CLL most of the
> time refer to the degree of adherence to the standard and (with one
> notable exception) are always minor.
>
> I do not recall any "major" flawar pitting one implementation against
> the other. The competition is about performance and usability, not
> about what CL feature that is not in R^nRS is being implemented or not
> in implementation X. :)

Well, if you read c.l.s, you will have to admit that _much_ less blood
is spilled in flamewars there. Examples not needed.

Eli Barzilay

unread,
Jan 8, 2001, 1:43:45 PM1/8/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> The key observation here is that Scheme implementations *cannot* and
> *must* diverge from the standard, simply because the standard is so
> restrictive that it is impossible to do anything with it.

There seem to be some sort of misunderstanding. Take a language is
with a complete standard that says: "programs in this language are
written in ASCII". You claim that this is restrictive to the point of
being able to do nothing with it, I claim that this is such a low
restriction that most programming languages on this planet can be
considered as valid extensions.


> In Common Lisp the number of "deviations" is actually circumscribed
> to pretty much defined "libraries" for which each implementation
> defines a specific interface.

Same in Scheme, different quantity.


> Given that the implementations are few, it is still possible to
> write portable programs.

True, but I never considered this any practical advantage for
everything I did in Lisp (not had to do, chose to do). I always used
a single implementation (well except for one huge project on that
Allegro 3 for Windows which is getting impossible to run).


> Scheme does not have modules. Remember, it ain't in R^nRS, it ain't
> in Scheme.

If it ain't in the standard, it ain't in the standard. That's all. I
don't program in "R^nRS".


> CL has packages, which can be used as modules and are,

Ugh... This is a different story.


> especially in conjunction with "community defined standard" or
> "specific vendor/implementation definitions": defsystem is one of
> these objects.

Given your own text above, I am tempted to do the same here, but I
won't.


> Note that here I am concerned about the "use" of the system. If you
> object that I cannot write a "library" (a .dll or a .so or a .a) in
> CL, I will respond with the request that you check what each CL
> vendor/implementor actually does. You can also check the old and
> not much used WACL in the AI.Repository.

No, I wasn't talking about these libraries. But forget it, it _is_ a
different story.


> The bottom line does not change. CL has DEFSTRUCT, Scheme does not.

Hmm... Must make people who program in _Scheme_ pretty stupid. Ever
seen one?


> > No, what I said is that Lisp people treat their spec in a very
> > different way than Scheme people. This is the constant source of
> > flamewars, for example, you attack the Scheme standard, when people
> > try to defend their Scheme implementation.
>
> Exactly. I agree on this. Now, the value of the standard is
> paramount.

But we've just agreed that it is treated very differently, therefore
even for similar values of value, it would still be taken differently.


> I just mplemented a non trivial piece of code and it runs
> on ACL, CMUCL, CLisp and LWW. (Sorry, I do not have other CL
> implementations at hand). On two OS's.

I did the same and it runs on every dialect of MzScheme. On six OS's.


> There is no way I could have not achieved the same level of
> portability using Scheme, simply because any two implementations
> just differ too much.

If you were using Scheme, you were probably using a single
implementation.


> What puzzles me is the strenght by which "Schemers" (I love that
> name!) refuse to acknowledge this key point.

What keypoint? Portability among Lisp implementations? I already
said I never used more than a single environment, so why would this
point be so important to become a key?

(I hate that name, I also hate Lispers and whatever. I prefer program
before my er.)


> I believe we agree on this here. The problem is the godzillion
> different Scheme implementations out there, all subtly incompatible
> and all trying to be different from CL.

I don't think that "being different than CL" is a major design goal.


> PS. As an aside on SICP. The fact that it uses Scheme, may be another
> historical quirk. CL was not available when SICP was being shaped
> at MIT. And, AFAIK, MacLisp was indeed quite "dirty" to be given
> in the hands of freshmen. So, let's not confound history and
> market forces with technical merit. It should be obvious to many
> that they don't always mix well.

And you know that if it was then they'd use it?

Lieven Marchand

unread,
Jan 8, 2001, 12:09:58 PM1/8/01
to
rp...@rigden.engr.sgi.com (Rob Warnock) writes:

> Also see Henry Baker's paper "Critique of DIN Kernel Lisp Definition"
>
> <URL:http://linux.rice.edu/~rahul/hbaker/CritLisp.html>
> <URL:http://linux.rice.edu/~rahul/hbaker/CritLisp.ps.Z>
>
> ISO/DIN DKLisp was another attempt to start with a "small & clean" kernel,
> "a minimal language on top of which a larger language can be built."
> Baker makes some telling points against *both* Common Lisp & Scheme...
>

I think ANSI CL fulfills all but one of his demands, the exception
being the ridiculous one of size of specification. It would be an
enormous editorial effort for very little gain but it is perfectly
possible to separate CLTS into a small core and a large library. I
don't think this has any advantages for either students of the
language or for experienced programmers. A lot of functional
programming languages are defined like this with a small core that
usually gets a denotational definition and a standard prelude. It just
seems to confuse most students confronted with it.

Joe Marshall

unread,
Jan 8, 2001, 1:51:53 PM1/8/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> Joe Marshall <j...@content-integrity.com> writes:
>
> > Marco Antoniotti <mar...@cs.nyu.edu> writes:
> >
> > >
> > > It ain't in R^nRS, it ain't in Scheme. End of the story.
> >
> > If it ain't in R^nRS, it ain't in R^nRS, but it might be in
> > MzScheme/DrScheme, MIT Scheme, Scheme 48, SIOD, Bigloo, Open Scheme,
> > Scheme lib (Aubrey Jaffer's stuff), EdScheme, Kawa, etc, etc,
> >
> > The larger Scheme implementations have quite a rich set of
> > `non-standard' features, and Jaffer's Scheme lib is portable to quite
> > a few of the other Schemes.
>
> Then why hasn't this set of features made it into the R^nRS?

It is difficult to get a R^nRS authors group together.

Even though Jaffer's library is reasonably portable, it isn't
necessarily what `everyone' wants as a standard.

Features are included in R^nRS by unanimous consent of its authors.

To use an example, virtually every `serious' Scheme implementation has
a DEFSTRUCT-like mechanism, and most, if not all, of the Scheme
authors would like to see some DEFSTRUCT standard within Scheme.
However, there are different opinions on how such a thing should be
implemented, what exact syntax and semantics it should have, how it
should interface into the type system, etc. etc.

These differences have in the past prevented structures from being put
in R^nRS. Nonetheless, it is possible to write Scheme code that uses
DEFSTRUCT, and reasonable to expect to be able to port it (with some
small amount of effort) to any of the `serious' Scheme implementations.

> Also, what is the content of Scheme Lib? (This is a rethorical question).

It's on the web, take a look. (A rhetorical answer.)

> > > Remember: the main design goal of Scheme is the shortness of the R^nRS.
> >
> > This isn't true. Scheme has evolved over the years and has been
> > influenced by many design goals. I think the main design goals of the
> > various implementations have been to satisfy a pragmatic need.
> >
> > The main goal of R^nRS has been to come up with a common set of core
> > elements that most or all Scheme implementations have, and most or all
> > Scheme implementors agree are `essential' to the language. R^nRS is
> > what everyone agrees is canonical, implementable, and pretty much `the
> > right thing'.
>
> CL is canonical, implementable and pretty much 'the right thing' as
> well.

I agree. I'm not trying to argue Scheme vs. Common Lisp. I'm just
pointing out that R^nRS is not the same sort of document as CLtL.

Joe Marshall

unread,
Jan 8, 2001, 2:00:59 PM1/8/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> > > | Also, IMO, because you can consider this thing an advantage of Lisp, then
> > > | people who use these two dialects of a great concept have such bitter
> > > | fights.
> > >
> > > Was that meant to be "advantage over Lisp"? I can't make sense of what
> > > you've written otherwise. Today, Scheme is nothing more than a dialect
> > > of _Algol_ with a somewhat Lispy syntax and a few good ideas thrown in
> > > for good measure. It used to be much more, but has been surpassed by
> > > almost everything.
> >
> > No, what I said is that Lisp people treat their spec in a very
> > different way than Scheme people. This is the constant source of
> > flamewars, for example, you attack the Scheme standard, when people
> > try to defend their Scheme implementation.
>
> Exactly. I agree on this. Now, the value of the standard is
> paramount. I just mplemented a non trivial piece of code and it runs
> on ACL, CMUCL, CLisp and LWW. (Sorry, I do not have other CL
> implementations at hand). On two OS's.
>
> There is no way I could have not achieved the same level of
> portability using Scheme, simply because any two implementations just
> differ too much.
>
> What puzzles me is the strenght by which "Schemers" (I love that
> name!) refuse to acknowledge this key point.

Huh? Any serious Schemer is all too familiar with this particularly
sore point.

> PS. As an aside on SICP. The fact that it uses Scheme, may be another
> historical quirk. CL was not available when SICP was being shaped
> at MIT. And, AFAIK, MacLisp was indeed quite "dirty" to be given
> in the hands of freshmen. So, let's not confound history and
> market forces with technical merit. It should be obvious to many
> that they don't always mix well.

I wouldn't be so sure. Sussman and Abelson have had access to
CommonLisp for years, yet they still prefer to work with MIT Scheme.

Eli Barzilay

unread,
Jan 8, 2001, 2:25:29 PM1/8/01
to
Erik Naggum <er...@naggum.net> writes:

> [...] yet suppose it is possible to implement only the standard,
> doesn't that say the standard is good enough for real life
> implementations?

The CL one? Yes. For a lot. (And the Scheme one for 1000 times less).


> Is that _bad_ in any way?

Definitely not. I didn't claim that something is bad, only that it is
different..


> Is the occasional whining that something is not in the standard
> actually representative of anything?

No. (And I wouldn't be surprised if the number of such whiners is the
same in CL and in Scheme). Did I say it was?


> Your weird argument tells me one thing: Scheme the standard is
> useless and impractical,

Impractical yes. It is useful as a core language definitions.


> and the specification is of extremely low value in real life,

By the same argument it has a lot of value, not in the CL-value sense.


> while Common Lisp the standard is practically useful in real life.
> I _completely_ fail to see this as an argument in favor of Scheme.

What is supposed to be the argument in favor of Scheme? That the CL
std is useful in real life or that the Scheme one is much thinner?
For both I don't see any argument in favor of Scheme either. If it
sounded like I did, then there was a communication bug.


> | Again, I will not go into comparison of approaches (btw, CL does
> | not have any `modules' to begin with -- packages are not seperate
> | units of compilation), what I said is that when Lisp was developed
> | to have packages for symbols there were (a) not many alternatives
> | at that time, and (b) even if they were, since the language spec
> | contains much more you cannot play with ideas that damage the
> | language as a whole.
>

> OK, try and listen, now: Could you please _explain_ how your
> playing with new idea damages the language? I don't buy that line
> one bit, you see. It doesn't really help your case just to repeat
> it.

Take the idea in that Baker article that was posted on this thread:
cons cells are always immutable. It certainly qualifies for being a
"new idea". Now imagine adding it to Lisp and adding it to Scheme.
In the second case you don't break much because there is not much
there, but in the first case you have a *lot* of standard and a *lot*
to change, the not-so-great "damage as a whole" phrase I used is
existing things in your language that needs fixing after you add a
feature.


> | I think that there is nothing wrong in my logic: define your 2
> | properties of your language and it is possible to extend it in
> | many ways, define 2000 properties of your language and it becomes
> | harder to extend it in a consistent way.
>

> There is obviously something seriously wrong with your "logic".

See above example.


> You _actually_ argue that adding that new property _has_ to be
> done in an inconsistent way, otherwise 2 or 2000 properties
> wouldn't matter.

No, I argue that you have to think more before you add a property to a
pile of 2000 consistent ones trying to have the result consistent as
well.


> Ironically, I quite agree with you for a small set of properties,
> such as in Scheme, but it is obviously false for a large set of
> properties. [...]

If you're implying that it is hard in the small case according to the
same line of Scheme is kept ridiculously small, then this is
irrelevant. Scheme implementations add features. And because the
standard is so small they can do it in may ways, which portability go
with the wind. But see other post.


> | No, what I said is that Lisp people treat their spec in a very
> | different way than Scheme people. This is the constant source of
> | flamewars, for example, you attack the Scheme standard, when
> | people try to defend their Scheme implementation.
>

> And the difference is? [...]

The CL standard defines an almost complete language. The Scheme
standard defines a small core. (I'm sure I said this at least five
times.)


> Oh, just watch the Scheme people market themselves. They want the
> remaining goodwill that "Lisp" has, but only work to destroy it.

I did. A lot. Really a lot. I didn't see this.


> If so, I'd recruit you if I want to insult Scheme even more.

...


> | I think I have established a long history of no posts here...
>

> Why do you think everything I say in response to an article by you is
> _about_ you?

Please not the "_about_ you" trick... What I said wasn't about me, it
was about my posts.


> Don't you desire to communicate ideas that have a wider field of
> application that just yourself?

Are you sure that that I shouldn't me desire to communicate ideas that
have a wider field of application that just myself?
(said Emacs).


> | My only attempted point is to try to make people that it is not
> | Scheme that you should be talking about, but Scheme
> | implementation.
>

> So write up a specification for what those implementations
> implement, and I'll be happy to talk about those specifications.

It's all on-line.


> If you have a language that so prides itself [...] have nothing to
> show but a bunch of poorly documented implementations, the less I
> think of Scheme.

It's MzScheme. It's on-line.
And again, I wasn't saying anything about my implementation.


> Now, I used to think highly of Scheme. I have worked my way
> through SICP and used to like the book enough to start on SICP2,
> but as time has passed and I have had reason to evaluate things in
> more than the light of academic values, Scheme has become less and
> less attractive, to the point where I think I loathe the
> anti-specification stance that you and many other Scheme people so
> strongly favor.

As long as we're in the life story department, I also started with
SICP and admired it, then moved to Lisp and loved every second and now
I'm back to Scheme mainly because it fits best the stuff I do. If I
would do what you do for a living, I would chose Lisp too. Not that
there is anything wrong with trying to make money with Scheme, but the
power you get from a good compiler and the most important point: a
dynamic environment combined is really something special. (To make it
clear, I am talking about Lisp here.) Maybe in time Scheme
implementations will get to such a level, but why should I worry for
that now?


> Yet, it is pretty weird that a language with such a theoretical
> bent can attract so many anti-theoretical pragmatists.

Whew, at least I can get out alive from this one.

Jochen Schmidt

unread,
Jan 8, 2001, 2:35:07 PM1/8/01
to
Eli Barzilay wrote:
>> I just mplemented a non trivial piece of code and it runs
>> on ACL, CMUCL, CLisp and LWW. (Sorry, I do not have other CL
>> implementations at hand). On two OS's.
>
> I did the same and it runs on every dialect of MzScheme. On six OS's.

Oh *WOW* you've hit him to ground with this amazing defense - now you
have to take your dagger and cut out his heart before he is standing up
_gratulations_!

BTW: CLISP alone supports > 26 OS's so you should make sure your next
argument doesn't make such a nice boomerang like this.

How I hate this *#$% flamewars!!!

Regards,
Jochen

Eli Barzilay

unread,
Jan 8, 2001, 2:56:55 PM1/8/01
to
Jochen Schmidt <j...@dataheaven.de> writes:

> BTW: CLISP alone supports > 26 OS's so you should make sure your
> next argument doesn't make such a nice boomerang like this.

Wow, you really killed _me_ now. I am completely ashamed. I have
failed my heritage and my ancestors. Forgive me for my sins. I will
die now. (and I didn't even know how to count.)

Oh, _how_ do you hate this *#$% flamewars!!!

Marco Antoniotti

unread,
Jan 8, 2001, 4:49:23 PM1/8/01
to

Joe Marshall <j...@content-integrity.com> writes:

> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > ...
> > ...
>
> ...

Much deleted about the difficulties about changing the standard.

>
> These differences have in the past prevented structures from being put
> in R^nRS. Nonetheless, it is possible to write Scheme code that uses
> DEFSTRUCT, and reasonable to expect to be able to port it (with some
> small amount of effort) to any of the `serious' Scheme
> implementations.

Why should I have to port it when I can use a language that ensures me
that *all* implementations will have DEFSTRUCT and that all
implementations of it will adhere to a standard?

>
> > Also, what is the content of Scheme Lib? (This is a rethorical question).
>
> It's on the web, take a look. (A rhetorical answer.)

I took a look. So what's in it? :) (The rethorical question stands).

...

> > > Scheme implementors agree are `essential' to the language. R^nRS is
> > > what everyone agrees is canonical, implementable, and pretty much `the
> > > right thing'.
> >
> > CL is canonical, implementable and pretty much 'the right thing' as
> > well.
>
> I agree. I'm not trying to argue Scheme vs. Common Lisp. I'm just
> pointing out that R^nRS is not the same sort of document as CLtL.

Fair enough.

I guess I just got up with the wrong foot this morning... :)

Marco Antoniotti

unread,
Jan 8, 2001, 4:59:48 PM1/8/01
to

Joe Marshall <j...@content-integrity.com> writes:

> Marco Antoniotti <mar...@cs.nyu.edu> writes:
>
> > PS. As an aside on SICP. The fact that it uses Scheme, may be another
> > historical quirk. CL was not available when SICP was being shaped
> > at MIT. And, AFAIK, MacLisp was indeed quite "dirty" to be given
> > in the hands of freshmen. So, let's not confound history and
> > market forces with technical merit. It should be obvious to many
> > that they don't always mix well.
>
> I wouldn't be so sure. Sussman and Abelson have had access to
> CommonLisp for years, yet they still prefer to work with MIT Scheme.

That is their choice. Mine was a more general remark. And please
remember that I got up with the wrong foot this morning :)

Cheers

Marco Antoniotti

unread,
Jan 8, 2001, 5:07:22 PM1/8/01
to

Eli Barzilay <e...@barzilay.org> writes:

... much deleted.


>
> As long as we're in the life story department, I also started with
> SICP and admired it, then moved to Lisp and loved every second and now
> I'm back to Scheme mainly because it fits best the stuff I do. If I
> would do what you do for a living, I would chose Lisp too. Not that
> there is anything wrong with trying to make money with Scheme, but the
> power you get from a good compiler and the most important point: a
> dynamic environment combined is really something special. (To make it
> clear, I am talking about Lisp here.) Maybe in time Scheme
> implementations will get to such a level, but why should I worry for
> that now?

Maybe because eventually this will lead to a re-specification of CL? :)
Have you thought about this possibility? What arguments can you make
that this will not happen?

Eli Barzilay

unread,
Jan 8, 2001, 5:45:48 PM1/8/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> Maybe because eventually this will lead to a re-specification of CL? :)
> Have you thought about this possibility? What arguments can you make
> that this will not happen?

I also said that Lisp has a lot of ugly sides and I would like a
regrown cleaner version. We've passed that.

Joe Marshall

unread,
Jan 8, 2001, 6:48:47 PM1/8/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> Joe Marshall <j...@content-integrity.com> writes:
> >
> > These differences have in the past prevented structures from being put
> > in R^nRS. Nonetheless, it is possible to write Scheme code that uses
> > DEFSTRUCT, and reasonable to expect to be able to port it (with some
> > small amount of effort) to any of the `serious' Scheme
> > implementations.
>
> Why should I have to port it when I can use a language that ensures me
> that *all* implementations will have DEFSTRUCT and that all
> implementations of it will adhere to a standard?

Er, um, you shouldn't --- you should use Common Lisp. I'm not by any
means suggesting that R^nRS gives you everything you could want in a
language! I was just saying that most serious Scheme implementations
give you a far more complete environment than barebones R^nRS. Scheme
is sort of in the state that Lisp was before Common Lisp.

> > > Also, what is the content of Scheme Lib? (This is a rethorical question).
> >
> > It's on the web, take a look. (A rhetorical answer.)
>
> I took a look. So what's in it? :) (The rethorical question stands).

I don't remember, and since you just looked, you are more informed
than I. (Rhetorical answer still stands, as well.)

cbbr...@hex.net

unread,
Jan 8, 2001, 9:52:57 PM1/8/01
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:
> Joe Marshall <j...@content-integrity.com> writes:
> > These differences have in the past prevented structures from being put
> > in R^nRS. Nonetheless, it is possible to write Scheme code that uses
> > DEFSTRUCT, and reasonable to expect to be able to port it (with some
> > small amount of effort) to any of the `serious' Scheme
> > implementations.
>
> Why should I have to port it when I can use a language that ensures
> me that *all* implementations will have DEFSTRUCT and that all
> implementations of it will adhere to a standard?

I seem to recall some discussion a while back to the effect that
"CLOS's DEFCLASS makes DEFSTRUCT redundant, so DEFSTRUCT should really
be removed." :-)

>>> Also, what is the content of Scheme Lib? (This is a rethorical
>>> question).
>
>> It's on the web, take a look. (A rhetorical answer.)
>
> I took a look. So what's in it? :) (The rethorical question
> stands).

There has been somewhat wider surrounding the "SRFI" process;
admittedly that represents a process that should have begun 15 years
ago, but it does happen to be _reasonably_ active, and is _gradually_
address the issue of "beefing up" the libraries.

I would fully agree that SRFI isn't going anywhere towards providing:
- Some equivalent to DESTRUCTURING-BIND
- A close equivalent to CL "optional arguments"
- The magic of SETF

There's some ground in between the _both_ unreasonable positions of:

"They're working on something, so obviously everything's AOK" and

"They don't have a FULL answer to ALL my objections, so obviously
their process is utterly futile and the system is utterly useless."
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
Rules of the Evil Overlord #100. "Finally, to keep my subjects
permanently locked in a mindless trance, I will provide each of them
with free unlimited Internet access. <http://www.eviloverlord.com/>

David Bakhash

unread,
Jan 11, 2001, 11:56:40 AM1/11/01
to
Eli Barzilay <e...@barzilay.org> writes:

> I really don't think that the original intent of Scheme was to have
> a language that is inherently less powerful than Lisp, just a core
> that is cleaner, that allows expansion, in a healthier way...

I would question anyone who looks at the bulk of Scheme code out there
which implements things that Common Lisp has, and would argue that
it's cleaner. Personally, having programmed and read lots of Scheme
code, to say that Scheme is in any way clean is a farce. Scheme code
is all over the place. It's mostly unreadable, overly complicated
because half of it is there just to reimplement the essentials that
Common Lisp has, where CL *also* has a superior API for that segment
of the Scheme language that gets re-implemented differently in almost
every different implementation of Scheme. The useful AND reasonably
learnable part of Scheme, to me, happens to be almost a proper subset
of Common Lisp, except where CL has superior semantics. The parts of
Scheme that are very powerful are overly complex for the average C
programmer to grasp. You take something like multiprocessing in
Common Lisp (as it is done almost identically in the different
implementations that support it), and it's got a simple interface that
most people would have no trouble with once they get functional
programming. Not so with continuations.

This newsgroup will always be frequented by Schemers, many of whom
prefer Scheme to CL. But when you consider CLOS, the MOP, CL arrays,
hashtables, vectors, structures (and DEFSTRUCT of course, among other
great macros), you want to just forget about every other language, not
just Scheme.

dave

Rainer Joswig

unread,
Jan 11, 2001, 12:12:13 PM1/11/01
to
In article <m3vgrs8...@cadet.dsl.speakeasy.net>, David Bakhash
<ca...@alum.mit.edu> wrote:

> Eli Barzilay <e...@barzilay.org> writes:
>
> > I really don't think that the original intent of Scheme was to have
> > a language that is inherently less powerful than Lisp, just a core
> > that is cleaner, that allows expansion, in a healthier way...
>
> I would question anyone who looks at the bulk of Scheme code out there
> which implements things that Common Lisp has, and would argue that
> it's cleaner.

I think one language that wanted to be a competition is EuLisp.
Reading the EuLisp spec is still worth it. Scheme as a "competition"
does not make sense to me. It lacks some basic CL
mechanisms that are hard to add later (for a several reasons),
like for example keyword arguments.

Aesthetically, some of the Common Lisp code I have seen,
is extremely pleasing (the opposite is possible, too).
Just look at the AMOP book - everything just falls beautifully
into place - masters at work.

--
Rainer Joswig, Hamburg, Germany
Email: mailto:jos...@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/

Joe Marshall

unread,
Jan 11, 2001, 3:32:25 PM1/11/01
to
David Bakhash <ca...@alum.mit.edu> writes:

> I would question anyone who looks at the bulk of Scheme code out there
> which implements things that Common Lisp has, and would argue that
> it's cleaner. Personally, having programmed and read lots of Scheme
> code, to say that Scheme is in any way clean is a farce.

You can write spaghetti code in any language, including CL.

Where Scheme is `clean' is in its formal semantics. This makes it
very useful when you are, for instance, trying to prove that a
particular compilation technique is semantically sound.

> Scheme code is all over the place. It's mostly unreadable, overly
> complicated because half of it is there just to reimplement the

> essentials that Common Lisp has...

I don't think this is a result of the language per se, but of the fact
that everyone and his brother writes a Scheme interpreter for an
undergraduate project.

> ..., where CL *also* has a superior API for that segment of the


> Scheme language that gets re-implemented differently in almost every
> different implementation of Scheme.

I wouldn't say the CL API is unconditionally superior, but I do agree
that there are too many gratuitous differences both between Scheme and
CL and each implementation of Scheme. There is a lot of utility in a
standard API, even if a `cleaner' or `better' one could be devised.

> This newsgroup will always be frequented by Schemers, many of whom
> prefer Scheme to CL. But when you consider CLOS, the MOP, CL arrays,
> hashtables, vectors, structures (and DEFSTRUCT of course, among other
> great macros), you want to just forget about every other language, not
> just Scheme.

Do you want to work or do you want to play? If you want to play
around with language design and semantics, Scheme is a good starting
point. If you want to build an `industrial strength' application, CL
is a good starting point.

Eli Barzilay

unread,
Jan 12, 2001, 1:14:36 AM1/12/01
to
David Bakhash <ca...@alum.mit.edu> writes:

> I would question anyone who looks at the bulk of Scheme code out
> there which implements things that Common Lisp has, and would argue
> that it's cleaner.

There is no connection between implementation of functionality which
is part of an implementation and the "cleanliness" of any language.


> Personally, having programmed and read lots of Scheme code, to say

> that Scheme is in any way clean is a farce. [...] The parts of


> Scheme that are very powerful are overly complex for the average C
> programmer to grasp.

Oh, tell that average C programmer I'm sorry. (Just being polite, I
couldn't care less for average-anything.)


> You take something like multiprocessing in Common Lisp (as it is
> done almost identically in the different implementations that
> support it), and it's got a simple interface that most people would
> have no trouble with once they get functional programming. Not so
> with continuations.

Of course. Using continuations for multiprocessing is a delicate
business to get right. But here's an example of code that I'd use:

(define (foo) (sleep 10) (printf "Hey!~%"))
(thread foo)

Was that hard? Unclear? Unclean?


> This newsgroup will always be frequented by Schemers, many of whom
> prefer Scheme to CL.

Yes, and Perl-ers and C-ers and maybe even VisualBasic-ers.


> But when you consider CLOS, the MOP, CL arrays, hashtables, vectors,
> structures (and DEFSTRUCT of course, among other great macros), you
> want to just forget about every other language, not just Scheme.

So, if I have all of that in my Scheme implementation, shouldn't I be
happy?

David Bakhash

unread,
Jan 12, 2001, 2:45:15 AM1/12/01
to
Joe Marshall <j...@content-integrity.com> writes:

> > This newsgroup will always be frequented by Schemers, many of whom
> > prefer Scheme to CL. But when you consider CLOS, the MOP, CL arrays,
> > hashtables, vectors, structures (and DEFSTRUCT of course, among other
> > great macros), you want to just forget about every other language, not
> > just Scheme.
>
> Do you want to work or do you want to play? If you want to play
> around with language design and semantics, Scheme is a good starting
> point. If you want to build an `industrial strength' application, CL
> is a good starting point.

Define play. Let me provide an example...

I would consider writing something like (say) a fortran-to-C translator
playing under your definition (insofar as it involves language design
and semantics). I think such a feat would be much easier to do in CL
than in Scheme.

Now consider fortran-to-cl vs. fortran-to-scheme. Which of those would
be easier? I'd still guess the former. Why? Because for all intents
and purposes, CL is a superset of Scheme, minus continuations.

Granted, scheme-to-fortran is easier than cl-to-fortran, and so you have
the following situation:

So in this example, cl is better for some uses, scheme for others. But
now suppose you wanted to write some middle-of-the-road, intermediate
turing-complete intermediate language (called `X') to describe a
program, and every translation from A->B actually goes from A->X->B.
Then Scheme would be easier, provided that it were X. However, if you
were _really_ playing, then you would be defining X yourself (i.e. it
wouldn't be Scheme), and in this case, writing code to deal with X would
probably be easier in CL than in Scheme. Writing code to translate from
A->X or from X->B (analyzers, generators) is also more likely easier in
CL than in Scheme.

So I've provided a real-world example of what the previous poster has
mentioned, and given my reasons for thinking that CL is better even for
play.

I do realize that continuations themselves are, in and of themselves,
very interesting and there's probably no single thing in CL that is as
interesting a concept as first-class Scheme continuations. Also, that
solutions using continuations are in general more interesting than other
solutions. For example, it would be nice to compare a non-deterministic
(choose/fail) sublanguage design and implementation in Scheme vs. CL.

dave

David Bakhash

unread,
Jan 12, 2001, 2:52:14 AM1/12/01
to
Eli Barzilay <e...@barzilay.org> writes:

> Of course. Using continuations for multiprocessing is a delicate
> business to get right. But here's an example of code that I'd use:
>
> (define (foo) (sleep 10) (printf "Hey!~%"))
> (thread foo)
>
> Was that hard? Unclear? Unclean?

no. good point.

> > But when you consider CLOS, the MOP, CL arrays, hashtables, vectors,
> > structures (and DEFSTRUCT of course, among other great macros), you
> > want to just forget about every other language, not just Scheme.
>
> So, if I have all of that in my Scheme implementation, shouldn't I be
> happy?

No. Because they're not standard, and not even close to being
standardized for Scheme. And if you did have them in Scheme,
implemented in Scheme, then they would likely be untollerably slow.
Also, is this even feasible?

But then again, if you *did* build these CL ideas into Scheme, you
wouldn't be the first, and that's one of my points. If you find
yourself doing so because you need these tools, then why not just use CL
instead?

dave

Marco Antoniotti

unread,
Jan 12, 2001, 10:07:25 AM1/12/01
to

Eli Barzilay <e...@barzilay.org> writes:

> Of course. Using continuations for multiprocessing is a delicate
> business to get right. But here's an example of code that I'd use:
>
> (define (foo) (sleep 10) (printf "Hey!~%"))

^^^^^ ^^^^^^
Not in R^nRS! Ditto!

> (thread foo)

I'll grant you this :)

>
> Was that hard? Unclear? Unclean?

(defun foo () (sleep 10) (format t "Hey!~%"))
^^^^^
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/fun_sleep.html

(mp:make-process #'foo)
^^^^^^^^^^^^^^^
Essentially the CLIM spec!


Was that hard? Unclear? Unclean?

...

> > But when you consider CLOS, the MOP, CL arrays, hashtables, vectors,
> > structures (and DEFSTRUCT of course, among other great macros), you
> > want to just forget about every other language, not just Scheme.
>
> So, if I have all of that in my Scheme implementation, shouldn't I be
> happy?

No you should not! Because your program won't run on another Scheme
implementation. You just don't get it, do you? :)

Joe Marshall

unread,
Jan 12, 2001, 12:37:10 PM1/12/01
to
Eli Barzilay <e...@barzilay.org> writes:

> Using continuations for multiprocessing is a delicate business to
> get right.

That is because continuations are the *wrong tool* for
multiprocessing.

Joe Marshall

unread,
Jan 12, 2001, 1:02:45 PM1/12/01
to
David Bakhash <ca...@alum.mit.edu> writes:

> > > But when you consider CLOS, the MOP, CL arrays, hashtables, vectors,
> > > structures (and DEFSTRUCT of course, among other great macros), you
> > > want to just forget about every other language, not just Scheme.

> And if you did have them in Scheme, implemented in Scheme, then they
> would likely be intolerably slow. Also, is this even feasible?

That's ridiculous.

MIT Scheme has hash tables, and defstructs. There are vectors, not
only of scheme objects, but that may be specialized to hold just
characters, small numbers, or flonums. Vector-ref is open-coded by the
compiler, so it is no slower than svref in CL.

MIT Scheme also has an object system based on ``Tiny CLOS''. Now I'm
not going to argue that Tiny CLOS is `better' or even comparable to
CLOS, but it does provide classes, slots, multiple inheritaces,
generic functions, method combination, computed methods, etc.
There is not a MOP.

CL has a very rich standard library, and you are not going to find it
duplicated in Scheme, but the reasons for that are not because it
would be impossible to implement, or too slow to be useful.

Joe Marshall

unread,
Jan 12, 2001, 1:12:45 PM1/12/01