newbie asks: why CL rather than scheme?

211 views
Skip to first unread message

Edward Piman

unread,
Dec 17, 2001, 11:58:44 AM12/17/01
to
Browsing posts to this group I frequently see real scorn for scheme. Over
on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
an outsider, I am puzzled by this bad feeling between groups who would seem
to have much in common.

I am interested in learning more about one or both languages. Scheme has
the advantage of books such as SICP and EOPL. Presumably CL has its
advantages too; anyone care to fill me in? Why (or for what purposes) is
CL better?

Christopher Stacy

unread,
Dec 17, 2001, 12:49:15 PM12/17/01
to
>>>>> On Mon, 17 Dec 2001 16:58:44 GMT, Edward Piman ("Edward") writes:

Edward> Browsing posts to this group I frequently see real scorn for scheme. Over
Edward> on comp.lang.scheme I fail to see this same scorn for CL. Why is that?

Perhaps it's because Scheme fans inhabit this newsgroup, but not vice versa.
Whatever the reason, I don't think it says anything about the technical merits
of the two languages. The seeming animosity does reflect the fact that the
constituencies of the two languages have different adgendas.

Edward> I am interested in learning more about one or both languages. Scheme has
Edward> the advantage of books such as SICP and EOPL. Presumably CL has its
Edward> advantages too; anyone care to fill me in? Why (or for what purposes) is
Edward> CL better?

Except for the fact that they both use parenthesis and have one or two
functions in common, they are very different languages. For example,
the functions that are used to define a program ("define" and "defun")
do two totally different things.

Scheme was designed to teach certain concepts in computer science classes.
Common Lisp was desiged to facilitate the maintenance and new development
of a large body of existing industrial Lisp code.

Michael Hudson

unread,
Dec 17, 2001, 1:05:10 PM12/17/01
to
Christopher Stacy <cst...@spacy.Boston.MA.US> writes:

> Scheme was designed to teach certain concepts in computer science
> classes.

Are you sure about this?

Cheers,
M.

--
Slim Shady is fed up with your shit, and he's going to kill you.
-- Eminem, "Public Service Announcement 2000"

Barry Margolin

unread,
Dec 17, 2001, 1:48:59 PM12/17/01
to
In article <uzo4hk...@python.net>, Michael Hudson <m...@python.net> wrote:
>Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>
>> Scheme was designed to teach certain concepts in computer science
>> classes.
>
>Are you sure about this?

Not just teaching, but for pedagogical purposes in general: teaching and
research. Similar to the original purpose of Algol.

--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Kent M Pitman

unread,
Dec 17, 2001, 1:53:55 PM12/17/01
to
Michael Hudson <m...@python.net> writes:

> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>
> > Scheme was designed to teach certain concepts in computer science
> > classes.
>
> Are you sure about this?

I have been in the room of the Scheme authors (check the front page of
the Revised^n Report on Scheme to see my name in the credits) and have
repeatedly seen decisions made in favor of teaching and in opposition to
proposals that would make it easier for industry. I once endured a discussion
where it was openly stated and a fair number of people present agreed that
we needed not to make Scheme too useful too fast because the committee would
take hold. I have seen them decide (that is, I have participated in votes
where my side failed) not to clarify the behavior in places that it could be
clarified and to cite the fact that it would make the spec too long (as if
the spec as in any danger of this).

No one speaks for the authors' committee as a whole except for the
spec that is its output. We have no spokesperson. We simply get together
in person or online or (as lately) not at all, and a spec either does or
does not come out.

All impressions about the actions of any committee are complex. No
one ever really knows the minds of the other people they are with,
other than that they hear stuff they say and they form impressions.
Such impressions can be wrong and such memories fade. But as a direct
participant for many years, I am as entitled to my impressions and my
memories as any whose vote was on the prevailing side of numerous
issues.

It's often hard to tell in a newsgroup whose opinion is direct and
whose is just a subjective rant based on loose information. Chris is
a good friend and a long time colleague of mine at several places
we've worked. He also knows a number of the other major participants
personally. He may even have other sources besides me, but he's
ceratinly heard me say that very statement you quote a million times
when we've been out to dinner or battling some programming bug over a
terminal somewhere. And I, in turn, allege I have every personal
reason to believe, that Scheme's primary focus has been to unify the
academic community. (That doesn't make it a "truth" because there is
no such thing in subjective/political domains. It does, though, I
think, make it a "valid belief". Capable of standing even if someone
also present has a conflicting "valid belief".)

Scheme people not present will likely rally in opposition to this
remark because they want their language for more, and their unelected
representatives on the committee may not always represent them as well
as they wish. And that's fair. Even with elected representatives, some of
us routinely deny we are getting good representation. Heck, in effect,
because my vote did not carry in some of these issues, I am for each such
vote one of those in the audience, like you, who would have aspired for
Scheme to be more or different, but who just didn't get his way.

Scheme people who were there may like to deny that they made certain
statements, or might want to diminish the importance of these things
I've seen, or might spin what they said a different way. But those
events I cite did happen. I think partly they contribute
to why the Scheme spec is now pretty much moribund and all useful work
is done by very dedicated implementors and, perhaps, through the SRFI
(Scheme Request for Implementation) process (see schemers.org).

Some people laud the Scheme spec for its minimalism. That's a valid
position. But it's not mine. I asked for tons of "unspecifies" to be
clarified. I asked for continuation semantics to be fixed so that
a unwind-protect would be reliably possible to define, but I didn't get
that. I asked forever for a condition system and worked hard with various
people to hammer out several plausible definitions, but these things
always get snagged somewhere because "clarity" and "aesthetic" and "spec
size" always dominate practical needs like "predictability" and
"portability" in my experience. (Before you get up in arms about
predictability, I don't mean the stuff Scheme does define a semantics for,
I only mean the stuff it leaves ill-specified. Just as an example,
CL has class precedence lists specified as partial orders. This leaves some
ambiguity the CL language could have left undefined. But we felt
"predictable" behavior was more important, so we defined the total order
reliably even though we didn't have to. There are numerous places CL
does this. Left-to-right order of evaluation is another thing we could have
left vague in a lot of places, but we wanted programs to predictably do
a certain thing. It's one thing to leave things vague when you worry
efficiency considerations might get in the way--it's quite another to just
leave things vague because it takes fewer words in the spec. And I am
*oh-so-tired* of hearing people on that committee talk about what would
make the spec bigger as a design criterion.)

They are entitled to their happy little world over there. I do not begrudge
them their followers, and I wish them much success. I particular am amazed
by the resilience of certain vendors, some of whom, like me, would have liked
more specificity and more featurism because they had a closer bond to
customers rather than just students. Those implementors have hung in there
and done some great things with the spec. But less "because" it was an
element of the design and more "in spite of it". IMO. (Clearly this is a
subjective opinion, so take it for what it's worth.) The reason I post this
hear rather than there is not to bash them in a place they don't respond, but
rather to defend my right to find a safe place where I can differ in opinion
and not get flamed for it. There is a reason I use CL, and that's because
it suits my personal needs and Scheme doesn't. There is a reason others
use Scheme and that's because it suits their needs and CL doesn't. These
statements don't contradict each other. They just emphasize the importance
of settling in a political constituency you're happy with.

Martin Cracauer

unread,
Dec 17, 2001, 1:30:38 PM12/17/01
to
Edward Piman <eip...@yahoo.com> writes:

>I am interested in learning more about one or both languages. Scheme has
>the advantage of books such as SICP and EOPL. Presumably CL has its
>advantages too; anyone care to fill me in? Why (or for what purposes) is
>CL better?

Existing practical CL implementations allow execution speed realistic
for non-trivial (i.e. not glue-only) applications.

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/

David Golden

unread,
Dec 17, 2001, 2:17:14 PM12/17/01
to
Edward Piman wrote:

> Browsing posts to this group I frequently see real scorn for scheme. Over
> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
> an outsider, I am puzzled by this bad feeling between groups who would
> seem to have much in common.
>

Well, Scheme stole a lot of CL's thunder, just when CL looked ready to
take on the world, a lot of the academic and open source community started
concentrating on Scheme. Scheme is "purer" than CL (e.g. differentiation
between boolean false, symbols called "nil" and the empty list), but it's
also a lot "smaller". This has good and bad points.

CL has the equivalent of much of Java's standard library, scheme is just
a "core", there's only just begun to be a semi-standard library (in the
form of the RFC-like SRFIs). There's also still no standard package system
for Scheme that's as powerful as CL's, though individual implementations of
Scheme often have similarly powerful ones, there's no standard object
system, etc. - Thus, CL is better if you want to do do "industrial" or
"real world" coding, big projects to Get Things Done, etc.

On the other hand, Scheme has become a "better" (warning: subjective!)
playground vehicle for research into _new_ features for Lisp-family
languages, thanks to its smallness and purity, sometimes for
experimentation on new + different variations of features which CL _already
has_ - lately, some scheme implementations have included the aforementioned
very fun package management, some implementations have
wierd typing and object systems, some implementations have extended
scheme's already powerful macro system, etc. These might one day lead to
improvements in CL.

And, while it's not _really_ true, people look at the relative sizes of
the Scheme and CL specifications, and decide to go for Scheme, since
it's perceived to be shorter and therefore "easier". (Not that people
should be trying to learn languages from specification documents, of course
- but it's a matter of perception).

All that said, people who _really_ understand Lisp, know that the different
lisp dialects have different strengths and weaknesses, and can be used
appropriately. I don't think you'll get real scorn for Scheme from many
CL people who really know their stuff - they're complementary - knowing
one will give you a few new insights into the other, and any innovations in
one can lead to innovations in the other... <cough>lexical scoping<cough>
And Scheme people are unlikely to criticize CL beyond, perhaps,
the occasional lighthearted accusation of "standard bloat".

There's always room for more lisp dialects - the forthcoming "arc" will
probably be worth looking out for, and "rep", which is perched somewhere
between a traditional lisp and scheme, is very popular as an extension
language for open-source projects. "Sugared" scheme and lisp (with
pythonesque indentation-sensitive syntax), is also helping increase
acceptance of Lisp among the I-hate-parentheses crowd.
Let's not even mention Emacs Lisp. ;-)

--

Don't eat yellow snow.

David Golden

unread,
Dec 17, 2001, 2:23:39 PM12/17/01
to
Christopher Stacy wrote:


> Scheme was designed to teach certain concepts in computer science classes.

I'd have to say it also serves/served as a basis for _research_ in computer
science - and a lot of that research directly benefitted the lisp community
as a whole. CL and Scheme aren't rivals, as such, they're best-suited to
somewhat different problem spaces.

Also, scheme's designed-in suitability for teaching core computer science
concepts means that there's a supply of young compscis with a firm
grounding in the "essence" of lisp, who can, and often do, become involved
in the wider lisp and common lisp community.

Christopher Stacy

unread,
Dec 17, 2001, 2:30:52 PM12/17/01
to
>>>>> On Mon, 17 Dec 2001 18:05:10 GMT, Michael Hudson ("Michael") writes:

Michael> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>> Scheme was designed to teach certain concepts in computer science classes.

Michael> Are you sure about this?

That seemed to be its primary application when SICP was being
written down the hall from me.

Marco Antoniotti

unread,
Dec 17, 2001, 2:48:07 PM12/17/01
to

CL-Scheme Flame WAR!

David Golden <qnivq....@bprnaserr.arg> writes:

> Edward Piman wrote:
>
> > Browsing posts to this group I frequently see real scorn for scheme. Over
> > on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
> > an outsider, I am puzzled by this bad feeling between groups who would
> > seem to have much in common.
> >
>

....


>
> On the other hand, Scheme has become a "better" (warning: subjective!)
> playground vehicle for research into _new_ features for Lisp-family
> languages, thanks to its smallness and purity, sometimes for
> experimentation on new + different variations of features which CL _already
> has_ - lately, some scheme implementations have included the aforementioned
> very fun package management, some implementations have
> wierd typing and object systems, some implementations have extended
> scheme's already powerful macro system, etc. These might one day lead to
> improvements in CL.

And why in the world didn't all these people improve directly on CL?
(Or maybe they were enjoying re-inventing the wheel?).

Seriously, without mentioning "hygienic macros" (a dubious concept to
start with), what is going on in Scheme that is not already in CL? Or
more easily reprogrammed in CL instead of in the C/C++ guts of your
godzillionth Scheme interpreter sans compiler? I'd like to know.

...

> All that said, people who _really_ understand Lisp, know that the different
> lisp dialects have different strengths and weaknesses, and can be used
> appropriately. I don't think you'll get real scorn for Scheme from many
> CL people who really know their stuff - they're complementary - knowing
> one will give you a few new insights into the other, and any innovations in
> one can lead to innovations in the other... <cough>lexical scoping<cough>
> And Scheme people are unlikely to criticize CL beyond, perhaps,
> the occasional lighthearted accusation of "standard bloat".

My feeling is that a lot of Scheme people do not know CL enough.

> There's always room for more lisp dialects - the forthcoming "arc" will
> probably be worth looking out for, and "rep", which is perched somewhere
> between a traditional lisp and scheme, is very popular as an extension
> language for open-source projects. "Sugared" scheme and lisp (with
> pythonesque indentation-sensitive syntax), is also helping increase
> acceptance of Lisp among the I-hate-parentheses crowd.
> Let's not even mention Emacs Lisp. ;-)

I do not share this opinion. IMHO there room only for a thougtful
re-implementation of Common Lisp in a better packaged way and with a
compiler as good as the commercial ones or Python.

Good extensions should be built portably on top of CL.

All the rest is an application of Greespun's Tenth Rule.... :)
... and a lost occasion.

Cheers

--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

Kent M Pitman

unread,
Dec 17, 2001, 2:53:46 PM12/17/01
to
David Golden <qnivq....@bprnaserr.arg> writes:

> On the other hand, Scheme has become a "better" (warning: subjective!)
> playground vehicle for research into _new_ features for Lisp-family
> languages, thanks to its smallness and purity

No. Scheme has become a good testbed for Scheme features. It is a bad
testbed for CL features. (As to the middle ground of Lisp in general, I'm
less sure because I don't know that it's worth talking about an "average"
Lisp when that points to a position in the vacuum of space between the
mass gravities of the various extant implementations. It is probably
needlessly divisive to even attempt to make this statement about an abstract
like Lisp per se. But overall, I think the same reasons that it's a
bad testbed for CL make it a bad testbed for all other Lisps, except Scheme,
if you think Scheme a Lisp, which I don't. If Scheme were a Lisp, though,
I'd think the same thing. My opinion on this is based on fact-of-differentness
as a boolean matter, not degree-of-differentness as a multi-dimensional
distance matter.)

Features cannot tested in one context and assumed productworthy in another.

Testing the tiger in a jungle does not tell you that it will function well
in a desert. Languages are ecologies.

To the extent that Scheme claims to be a place where any purported
"science of design" is best tested, I allege that such is an indefensible
claim.

Further, issues of mere ecology aside, just because you can best measure
something in one context doesn't make it the place to do the measurement.
I can read my thermometer indoors better without frost and snow all over it,
but that doesn't mean it's best to position it there if I want to know the
temperature outside.

And, finally, the Scheme "science" I have seen done often presumes a very
limited and falsely-canonical notion of aesthetic. Scheme is defined around
a particular set of aesthetics, but does not by any means have a unique lock
on the notion of aesthetics. And to that extent, it misses important research
that it could and should be doing.

One might allege that one can learn all they need to know about human
language from Esperanto or Loglan, for example, and can claim such
languages are better languages for doing linguistics research because
they are small and pure. But the day we start thinking that the
science that comes out of the study of such languages is good enough
to substitute for the real science needed to understand all languages
is a sad, sad day for science.

Kaz Kylheku

unread,
Dec 17, 2001, 2:54:48 PM12/17/01
to
In article <_wrT7.3347$_3.1...@news.iol.ie>, David Golden wrote:
>Edward Piman wrote:
>
>> Browsing posts to this group I frequently see real scorn for scheme. Over
>> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
>> an outsider, I am puzzled by this bad feeling between groups who would
>> seem to have much in common.
>>
>
>Well, Scheme stole a lot of CL's thunder, just when CL looked ready to
>take on the world, a lot of the academic and open source community started
>concentrating on Scheme. Scheme is "purer" than CL (e.g. differentiation
>between boolean false, symbols called "nil" and the empty list), but it's
>also a lot "smaller". This has good and bad points.

Why is it that alleged purity invariably seems to make programs ``dirtier''?

Earlier today someone detailed in this newsgroup a few problems with
the application of the language Clean to real work.

Perhaps there is a hidden ``conservation of dirt'' law, similar to
the principle of the conservation of complexity. Cleaning the language
simply means pushing dirt into programs.

But what is dirt cannot be easily identified as complexity or simplicity;
it's rather a subjective lack of elegance. Elegance often arises from
imposing a framework of artificial constraints. Artists sometimes find
it helpful to adhere to some rigid frameworks which give their work an
identifiable form; the result can be elegant, because it makes use of
the built in elegance-generating properties of the form, which amplify
the artist's contribution. But some forms are simply not applicable to
some kinds of expression. There is a mistake of viewing those expressions
which don't fit into a given subjectively preferred form as inelegant,
giving rise to orthodoxies.

Some people view elegance in programming languages similarly; that there
is some true way of doing things, and everyone must program to that. This
works fine up to the point that programming is merely a form of artistic
self-expression. If one expression doesn't work, the artist-programmer
can self-censor and seek another. When programming is driven by actual
externally-imposed requirements, this approach is no longer adequate.

Carrying the analogy further, suppose you are a music composer, and all
you ever compose is very elegant baroque counterpoint in the style of
J. S. Bach and company. You are happy within these forms making beautiful
magic. But what if someone wants to commission you to prepare a suite of
20th century music? Well, you can say ``Bah, that stuff is cacophonic
humbug, I only write elegant music.'' So the job goes to someone else.

>Don't eat yellow snow.

Aha, Zappa! How pertinent. ;)

David Golden

unread,
Dec 17, 2001, 3:17:54 PM12/17/01
to
Marco Antoniotti wrote:

>
> And why in the world didn't all these people improve directly on CL?
> (Or maybe they were enjoying re-inventing the wheel?).
>

yes, maybe they were enjoying re-inventing the wheel. After all,
it's one thing to *use* a machine, and another to *understand it*. Wheel
reinvention can be a way for people to learn. Maybe they'll accidentaly
invent caterpillar tracks instead.

> Seriously, without mentioning "hygienic macros" (a dubious concept to
> start with), what is going on in Scheme that is not already in CL? Or
> more easily reprogrammed in CL instead of in the C/C++ guts of your
> godzillionth Scheme interpreter sans compiler?

Wel,, (a) lots of people like hygienic macros, particularly the more
powerful variants, and (b) If the feature is most easily prototyped by
adjustment of the guts of the interpreter, then perhaps it _is_ easier to
butcher a simply-written, non-optimised, interpreted scheme implementation
than a finely-tuned, multi-layered,
in-all-respects-wonderful-except-for-ease-of-comprehension-of-internals CL
implementation. People learn by doing, so even if the feature is
completely useless pants that's been discarded years ago by the
establishment, they might discover that faster by hacking on a naive
interpreter.

> My feeling is that a lot of Scheme people do not know CL enough.
>

Yes, definitely - but the majority are open to learning. After all, if
they're a "scheme person", chances are they're at the _start_ of their
computing career, and receptive to learning CL.

David Golden

unread,
Dec 17, 2001, 3:36:28 PM12/17/01
to
Kent M Pitman wrote:

> David Golden <qnivq....@bprnaserr.arg> writes:
>
>> On the other hand, Scheme has become a "better" (warning: subjective!)
>> playground vehicle for research into _new_ features for Lisp-family
>> languages, thanks to its smallness and purity
>
> No. Scheme has become a good testbed for Scheme features. It is a bad
> testbed for CL features.

I was more thnking of it as an an "invention ground" than a testbed.

> Features cannot tested in one context and assumed productworthy in
> another.

No, but they can be invented/discovered in one context, and tested
in another. Some things my be tried and found good, others unsuitable.

>
> Testing the tiger in a jungle does not tell you that it will function well
> in a desert. Languages are ecologies.

I agree completely - but would a tiger arise in a desert?
Strained analogy: Humans probably couldn't have evolved in the arctic - but
we can now live there. Now, that's due to a human's ability to adapt. and
to alter the environment - but a human can bring to the arctic features it
didn't previously have, like toasters, or big square holes in the
landscape. Yes, these features may or may not be useful to the natural
inhabitants of the arctic, but they *may* make the arctic more widely
useful to both things that were always there, and things that weren't
there before. (I suppose there's a programming-language-feature analogue of
the environmental poisoning and destruction that humans sometimes cause -
perhaps perl's automatic obfuscation by extensive use of implicit
arguments, but that serves to make perl more useful for short scripts -
just as a road may make an environment more useful for human purposes, and
cause hedgehogs and other wildlife to meet their splattery doom.)

Diversity and cross-fertilisation of ideas has played an important part in
the evolution of Common Lisp (as, you, of course, know very well :-) )

Wade Humeniuk

unread,
Dec 17, 2001, 4:12:16 PM12/17/01
to
> All that said, people who _really_ understand Lisp, know that the
different
> lisp dialects have different strengths and weaknesses, and can be used
> appropriately. I don't think you'll get real scorn for Scheme from many
> CL people who really know their stuff - they're complementary - knowing
> one will give you a few new insights into the other, and any innovations
in
> one can lead to innovations in the other... <cough>lexical scoping<cough>
> And Scheme people are unlikely to criticize CL beyond, perhaps,
> the occasional lighthearted accusation of "standard bloat".

I started using Scheme and I now use Common Lisp. From what I know there is
no strength that Scheme has that CL does not. Perhaps you can name a few?

Here I will try to name some for you:

1) Scheme is easier to learn. If one just used the subset of CL that Scheme
implements then CL would be as small and just as easy to learn. It is just
that academia has chosen Scheme as there model programming language to
teach.

2) Hygenic macros. Gag!!!!!

3) Continuations, Double Gag!!!!

4) Scheme is so small its embeddable. Yes I need a toaster that runs
Scheme.

5) Scheme is so small it can be embedded as an extension language in an app.
See 1.

6) Scheme can be used for research purposes. Got me there. I would assume a
lot of academics would like to advance computer science without actually
doing a lot of programming.

7) Scheme is easier to compile. Oh...., I forgot, what compiler?

8) Scheme has proper tail recursion. It seems to be a case of the dog
chasing its tail.

Most of the bigger Scheme implementations seem to be striving for CL
functionality (object systems, et. al.) and in fact implement CL
functionality (usually a limited subset) without giving credit where credit
is due. Scheme is progressing with piecemeal timidity, afraid to somehow
damage its "purity". With sufficient time Scheme will just become CL.

As for lexical scoping, its no longer an innovation. When was the last time
a computing innovation occured? There seems to be a view that if we can
just find the next innovation (and god knows people use the excuse all the
time) that our grundgy programming problems will go away. Most of the
necessary work is just grundge and I have found that CL has dealt with it
the best.

Wade


Aaron J Reichow

unread,
Dec 17, 2001, 5:15:03 PM12/17/01
to
On Mon, 17 Dec 2001, David Golden wrote:

> language for open-source projects. "Sugared" scheme and lisp (with
> pythonesque indentation-sensitive syntax), is also helping increase
> acceptance of Lisp among the I-hate-parentheses crowd.
> Let's not even mention Emacs Lisp. ;-)

Example of a language that uses this? I'm aware of a C syntax package for
guile, but I wouldn't say that it's used by much of anyone, and especially
not helping in making the lisps more accepted. Dylan never really took
off, either.

Regards,
Aaron

Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/
"civilization is a limitless multiplication of
unnecessary necessities." :: mark twain


Kent M Pitman

unread,
Dec 17, 2001, 5:49:06 PM12/17/01
to
David Golden <qnivq....@bprnaserr.arg> writes:

> > Features cannot tested in one context and assumed productworthy in
> > another.
>
> No, but they can be invented/discovered in one context, and tested
> in another. Some things my be tried and found good, others unsuitable.

But my point is that there exist features that can only be discovered
and tested here and not there. For example, Scheme does not believe
in declarations. CL has done very good research in declarations.
Just look at the CMU CL compiler to see how much can be done with the
declaration facility we have.

> > Testing the tiger in a jungle does not tell you that it will function well
> > in a desert. Languages are ecologies.
>
> I agree completely - but would a tiger arise in a desert?

Would desert creatures arise in a jungle? I miss your point, or you miss mine.

> Strained analogy: Humans probably couldn't have evolved in the arctic - but
> we can now live there.

Very strained analogy because you're now focusing on the life/lifelessness
aspect that was only vaguely incidental to my other example. I could just as
well have focused on rainforest vs the wheat/corn belt of central US/canada.
Things grow both places, but very different things. No buffalo in the
jungle. No anacondas in the hills of Kansas.

People often look to Scheme as somehow "better". It is not. It is simply
different.

> Diversity and cross-fertilisation of ideas has played an important part in
> the evolution of Common Lisp (as, you, of course, know very well :-) )

Mostly with us being open-minded enough to embrace Scheme ideas.
Scheme thinks it has nothing to learn from us. If there's one thing
I'd like new Scheme people never to learn, it is the all-to-prevalant
attitude that there can be a significant field of human endeavor from
which nothing can be learned. Many core Scheme people seem to want
to wish that by ignoring CL, it will become true that there was nothing
to learn from us.

I saw this effect even in work on ISO ISLISP. I remember one day
coming in with one page of the CL spec that exemplified something
useful. Some committee members, from a faction I'll subjectively
describe as "more favorable to Scheme/Eulisp than CL" refused to look
at the page of text. They said it was enough to know it came from
CL. They wanted not to be dirtied by CL. I said, taking one idea or
reading one page of text from CL will not make this a dirty language
and that it was idiotic to say otherwise, but they persisted in an
utterly emotional response, refusing to allow the matter to come to
the table for discussion. They did not want ISLISP polluted by CL thoughts.

Later, ISLISP was at risk of failure as a project because of the
non-cooperation and attitudes changed. I think by the time we
finished that spec, there was a lot more respect all around among the
participants, maybe in part because there had been some changeover in
WHO was participating, but partly also because people had mellowed.
The ISLISP spec worked out as a kind of compromise of sorts and is
small like Scheme but CL-like in other ways. I sort of wish if
someone were going to go make a new dialect they'd at least build from
something existing like this rather than from scratch.... Sigh.

Kent M Pitman

unread,
Dec 17, 2001, 5:58:12 PM12/17/01
to
k...@ashi.footprints.net (Kaz Kylheku) writes:

> Perhaps there is a hidden ``conservation of dirt'' law, similar to
> the principle of the conservation of complexity. Cleaning the language
> simply means pushing dirt into programs.

[These remarks not addressed to Kaz, just triggered by his remark here.]

I often feel that small languages make big programs. You aren't starting
with as much, and you have to spend more "building up" work.

Further, it's not clear CL is that much bigger than Scheme. A tiny bit.

Much of what is CL is library. Scheme doesn't call library part of the
language. That's just a marketing trick, like saying that a system dll
not being part of your program means your program is tiny. It doesn't
fundamentally change reality.

Of what is not library, CL has more examples, which take a lot of space.
The Scheme people have avoided the kinds of worked examples the CL spec
has. Does this make their language qualitatively better? I'm skeptical.

CL contains more discussion of portability concerns, branch cuts, handling
of error situations, etc. Does leaving this kind of verbiage out of Scheme
make it a better language? Again, I'm skeptical.

But suppose we removed the library stuff that Scheme just omits. And
suppose we remove examples and explanatory text and we change the typography
and we let someone who uses more concise language than I do write the book.
How different is Scheme from CL ultimately? At the core? Not a lot, I think.
They are issues of substance I wouldn't handwave away. But all this fuss
over size per se is just smoke and mirrors.

CL _does_ require implementors do to lots more than does Scheme.
Scheme leaves things vague, making it easier on implementors. But every
thing left easy for implementors is an increased burden on programmers.
Does making an increased burden on programmers make Scheme better? I'll even
give you that there might be some who think it might. But I hope others
on the other side of the debate will give me that it doesn't NECESSARILY
make the language better. Certainly the increased burden on me as a
programmer is a primary motivating factor for me using CL. Would I want to
IMPLEMENT a CL? No way. Too much work. But it doesn't matter to me that
there is an entry barrier AS LONG AS some are willing to cross it--enough
to give me a reasonable set of choices. And there are such choices. So
I'm happy with the trade-offs we've made.

Kent M Pitman

unread,
Dec 17, 2001, 6:05:28 PM12/17/01
to
David Golden <qnivq....@bprnaserr.arg> writes:

> > My feeling is that a lot of Scheme people do not know CL enough.
> >
> Yes, definitely - but the majority are open to learning. After all, if
> they're a "scheme person", chances are they're at the _start_ of their
> computing career, and receptive to learning CL.

Though also dangerously open to religious dogma, too.

And for all that Scheme teaches some powerful ways, its courses often
carefully omit training in alternatives. It's not uncommon to have
these "open-minded" people come out of these courses in a daze willing
to say that

(loop for i = 1 to 10
do (print i))

is an unclear program that would be more clear as

(let loop ((i 1))
(if (<= i 10)
(print i)
(loop (1+ i))))

is more clear. I have no problem with people coming out knowing that these
are equivalent programs, nor even with them having a personal preference,
but I've _too often_ been in arguments with them over where the former program
is _clear at all_ to believe they're getting a fair treatment in these
"mind-expanding" courses.

I've even seen this argument over

(do ((i 1 (1+ i)))
((> i 10))
(print i))

which doesn't even have LOOP involved and which has a straightforward
transliteration and/or trivial macroexpansion to a recursive proram for
those who worry it's hard to implement.

David Golden

unread,
Dec 17, 2001, 6:17:26 PM12/17/01
to
Aaron J Reichow wrote:

> On Mon, 17 Dec 2001, David Golden wrote:
>
> Example of a language that uses this?

Uhm... Scheme+Sugar ? "Sugar" is the name of an
_implementation_ of indentation-sensitive syntax, that hangs around
as an add-on package for most schemes... Unlike other attempts at syntax
"improvement", it doesn't try to do anything fancy like infix notation, it
just uses ordinary indentation conventions to "fill in" the parentheses.
The original source is at http://Sugar.mini.dhs.org/
it's about 100 lines.

> Dylan never really took off, either.
>

Dylan tried to do too much, I think. Sugar source is pretty much ordinary
scheme, just with the information that parantheses usually convey to the
reader conveyed by the indentation instead - since pretty much everyone
indents anyway (or the editor does it for them), and Sugar still _allows_
the normal parentheses, it's quite popular for just banging out code - one
problem you have with estimating it's usage is that people may write the
code in sugar syntax, but release the code in normal parens.

Anyway, if you think that's wierd and pointless, wait till you see cugar,
which makes C++ into an indentation-sensitive python-lookalike...

David Golden

unread,
Dec 17, 2001, 7:25:03 PM12/17/01
to
Kent M Pitman wrote:
>
> Though also dangerously open to religious dogma, too.
>

I suppose so. One must try to look on the bright side :-). Get 'em while
they're young, and all that - I still think knowing Scheme is better than
not knowing any lisp-like languages at all, and that people who know scheme
are more likely to look at Common Lisp than the frightening amounts of
programmers who know little but Java and/or C++ these days...

Kent M Pitman

unread,
Dec 17, 2001, 7:55:01 PM12/17/01
to
David Golden <qnivq....@bprnaserr.arg> writes:

Only if they are not, as I believe them to frequently be, indoctrinated
with "Lisp is evil" as part of their Scheme training.

David Golden

unread,
Dec 17, 2001, 8:01:30 PM12/17/01
to
Kent M Pitman wrote:

> Only if they are not, as I believe them to frequently be, indoctrinated
> with "Lisp is evil" as part of their Scheme training.
>

Well, if there's one way to get young people interested in finding out more
about something, it's to tell them not to do it... a certain proportion of
students, usually the better ones, will spot, and question, dogmas they're
presented with - so, you might well end up with the best scheme students...

Gareth McCaughan

unread,
Dec 17, 2001, 5:55:39 PM12/17/01
to
Edward Piman wrote:

> Browsing posts to this group I frequently see real scorn for scheme. Over
> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
> an outsider, I am puzzled by this bad feeling between groups who would seem
> to have much in common.

I have a few conjectures.

- Scheme gets, I think, rather more "mindshare" than CL does
on account of its use in university courses. So

- maybe some CLers get a little jealous;

- certainly some CLers are concerned that students
are being told "This is what Lisp is like" when the
language they're being taught is very different from
(and in the opinion of most CL users, much less
useful than) CL. So people get inoculated against
Common Lisp, and that's a shame.

- Although there isn't active scorn for CL among Schemers,
I think there is often an assumption of superiority.
(Look at our lovely elegant language and compare it
with that behemoth over there. I mean, they even let
a symbol mean different things according to whether
it's at the start of a form or not! ... etc.) That can
rankle.

> I am interested in learning more about one or both languages. Scheme has
> the advantage of books such as SICP and EOPL. Presumably CL has its
> advantages too; anyone care to fill me in? Why (or for what purposes) is
> CL better?

That may be an unnecessarily inflammatory way to ask the question :-).
However:

- CL also has some great books. My favourite is Peter Norvig's
"Paradigms of artificial intelligence programming: case
studies in Common Lisp", which in the opinion of many Lispers
is one of the finest programming books on any subject. It's
worth reading even if you have no interest in AI, and it's
worth reading even if you have very little interest in CL.

Also often recommended (but more controversial) is Paul
Graham's "On Lisp", which is mostly about macros and
higher-order functions. And "The art of the metaobject
protocol", which is all about opening up the workings
of your object system to user inspection and manipulation
without making it impossible to be efficient. Very cool
stuff.

The language itself is very different from Scheme. It will
not surprise you to learn that many of the differences are
regarded by most CLers as advantages. For instance:

- CL has a big standard library. (Scheme has a tiny standard
library and a number of different implementations each with
its own fairly big library. The SRFI process helps to
ameliorate this.)

- CL was designed with efficient implementation in mind.
Even though CL is a much bigger language than Scheme,
it's probably about as hard to make a really effective
Scheme compiler as it is to make a really effective CL
compiler. So CL is much more usable in practice for numerical
work than Scheme is, for instance. (Some features that make
it easier to write a good CL compiler: optional type
declarations, immutability of builtins, absence of call/cc.)

- CL is a big language. (This isn't quite the same thing
as having a big library, though the boundaries are blurry,
especially in a language as flexible as CL or Scheme.)
Although this makes it harder to learn all of it, it
means that you can do more, more easily, once you've
got the hang of a decent chunk of it.

- For instance, CLOS (the Common Lisp Object System)
is an amazing thing. I don't think any of the
seventeen million object systems for Scheme has
anything like the same power.

- CL's macros are strictly more powerful than Scheme's
(though I think in practice Scheme implementations
provide procedural macro facilities as well as the
"high-level" ones in the standard).

- CL's richer selection of standard data types means
you don't have to implement so much stuff from
scratch. Hash tables, multidimensional arrays,
structures.

- Some of the things that appear ugly and ad hoc to many
Schemers appear practical and friendly to many CLers.
For instance, the many-namespace-versus-single-namespace
thing: Schemers like not having to think "Is that using
the function binding or the value binding?" and not
having to write FUNCALL and #'... ; CLers like not
having to call variables LST instead of LIST or SYM
instead of SYMBOL to avoid inadvertent capture, and
find that the variety of bindings is no more troublesome
than that in any natural language.

- The community of CL users and implementors has a
rather different focus from that of Scheme users
and implementors: "industrial" rather than "academic",
I suppose. (Of course those terms are meant to be
vague and woolly; there are academic CLers and
industrial Schemers.) Some people prefer one or
the other of those communities.

--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc

David Golden

unread,
Dec 17, 2001, 8:35:50 PM12/17/01
to
Kent M Pitman wrote:

> Would desert creatures arise in a jungle? I miss your point, or you miss
> mine.

I don't think I missed your point - I'm just saying, that, sometimes,
"alien" features can arise that might take a lot longer to appear in one
language if they are not "borrowed" from the language in which they evolved

> Things grow both places, but very different things. No buffalo in the
> jungle. No anacondas in the hills of Kansas.
>

Ah... but how would an anaconda fare in the hills of Kansas, or buffalo
in the Jungle, if they suddenly were transported there? (Pretty badly,
probably, at least for the buffalo, and the anaconda come winter), but -
one can envision situations in which the alien introduction does quite
well - alien zebra mussels in european waterways, or certain non-native
seaweeds in the mediterranean, if we're going to stick with wildlife...

That was my point - features which may arise easily in one language
may be snarfed by another language, in which they haven't as yet arisen -
and the various lisp variants play off eachother in such a manner, to an
extent. Then again, maybe I've spent too much time in perl-land (perl
seems to accumulate features from any language that happens to be passing
at the time)...



> I sort of wish if
> someone were going to go make a new dialect they'd at least build from
> something existing like this rather than from scratch.... Sigh.

Well, last I heard, ISLISP was catching on a little bit in Japan...
(At least, there's a couple of implementations being actively developed in
Japan...)

Bruce Hoult

unread,
Dec 17, 2001, 8:55:06 PM12/17/01
to
In article <sfw3d29...@shell01.TheWorld.com>, Kent M Pitman
<pit...@world.std.com> wrote:

> (loop for i = 1 to 10
> do (print i))
>
> is an unclear program that would be more clear as
>
> (let loop ((i 1))
> (if (<= i 10)
> (print i)
> (loop (1+ i))))
>
> is more clear.

The first certainly looks clearer to me, except that I'm unclear what
language it is written in -- it's not CL. Or at least not the CL
implemented by CMUCL or (as far as I can make out) described in the
Hyperspec.


Scheme has macros now. Are they powerful enough to build a "loop"
macro? Dylan's macros are only template replacement, but are powerful
enough to build a CL-like "loop" macro that expands to a tail-recursive
local function, and in fact that's a standard part of the language.

-- Bruce

Daniel Barlow

unread,
Dec 17, 2001, 10:48:10 PM12/17/01
to
Kent M Pitman <pit...@world.std.com> writes:

> David Golden <qnivq....@bprnaserr.arg> writes:
> > Yes, definitely - but the majority are open to learning. After all, if
> > they're a "scheme person", chances are they're at the _start_ of their
> > computing career, and receptive to learning CL.
>
> Though also dangerously open to religious dogma, too.
>
> And for all that Scheme teaches some powerful ways, its courses often
> carefully omit training in alternatives. It's not uncommon to have
> these "open-minded" people come out of these courses in a daze willing
> to say

[ ... that loop is unclear and named let is better ]

I started out arguing against that point, but the more I edit this
post the closer I think I'm coming to agreeing with you.

My ad-hoc research (which basically consists of telling people at
Linux events that I write Common Lisp, and getting funny looks for it)
suggests that most people who learnt anything Lispish at university
were (a) told it was Lisp (or LISP, more likely), and (b) convinced
that it was perhaps kind of neat in a twisted way but too slow and
impractical to ever be of any practical use.

OK, some of the students will be keen, and, yes, probably end up as
single-namespace Scheme bigots. The majority, though, I don't think
are coming out of these courses with any kind of revolutionary fervour
against the evil LOOP, because for the most part I don't think they
even have much incentive to learn that the evil LOOP exists. The only
problem with these courses from an evangelising-CL point of view is a
namespace one. Common Lisp is LISP, right? Therefore they already
know it and know it's not actually very good at anything.

So my instinct says not to worry about it, aside from the namespace
angle. The languages on the syllabus have _never_ been the ones that
students usually want to learn - we should be talking in the places
that C, Perl, Python, Ruby etc are talking, not the places where ML,
Miranda, Scheme and Modula 2 are. There's nothing to rebel against in
learning Modula 2 ...


-dan

--

http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources

Jochen Schmidt

unread,
Dec 18, 2001, 1:40:06 AM12/18/01
to
David Golden wrote:

> Edward Piman wrote:
>
>> Browsing posts to this group I frequently see real scorn for scheme. Over
>> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
>> an outsider, I am puzzled by this bad feeling between groups who would
>> seem to have much in common.
>>
>
> Well, Scheme stole a lot of CL's thunder, just when CL looked ready to
> take on the world, a lot of the academic and open source community started
> concentrating on Scheme. Scheme is "purer" than CL (e.g. differentiation
> between boolean false, symbols called "nil" and the empty list), but it's
> also a lot "smaller". This has good and bad points.

As I hear this word very often called with some languages - what exactly do
you mean by "pure" (or "purer")? We are not talking about diamonds or gold
we talk about languages and it is not absolutely obvious to me why being
"pure" is unconditionally a good thing for a language. (many more important
things like water or air are useless if they are pure...) I don't really
think that distinguishing nil,(),false has anything to do with purity. You
may have seen an extensive discussion over this topic lately and AFAIR
there was _no_ consensus that the distinction is the unconditionally right
thing to do - so _how_ can that increase "purity" in a language?

As I already mentioned elsewhere I'm always careful if someone calls a
language "pure" as this means most of the time that the designers have
chosen to omit a vast amount of things because of more or less subjective
stylistic reasons. CL is a rather impure language in this sense and that is
what I actually think is better in CL - nobody omits some nice or important
feature from you only based on personal stylistic feelings. The default
mode in CL seems to be allowing something if it does not has an negative
effect on others.

ciao
Jochen

Kaz Kylheku

unread,
Dec 18, 2001, 1:21:00 AM12/18/01
to
In article <9vmkp3$jni$1...@rznews2.rrze.uni-erlangen.de>, Jochen Schmidt wrote:
>David Golden wrote:
>
>> Edward Piman wrote:
>>
>>> Browsing posts to this group I frequently see real scorn for scheme. Over
>>> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
>>> an outsider, I am puzzled by this bad feeling between groups who would
>>> seem to have much in common.
>>>
>>
>> Well, Scheme stole a lot of CL's thunder, just when CL looked ready to
>> take on the world, a lot of the academic and open source community started
>> concentrating on Scheme. Scheme is "purer" than CL (e.g. differentiation
>> between boolean false, symbols called "nil" and the empty list), but it's
>> also a lot "smaller". This has good and bad points.
>
>As I hear this word very often called with some languages - what exactly do
>you mean by "pure" (or "purer")? We are not talking about diamonds or gold
>we talk about languages and it is not absolutely obvious to me why being
>"pure" is unconditionally a good thing for a language.

``Pure'' means: ``Based on my experiences, I have a world view about what
is necessary in a programming language, and what is not. Those languages
which have exactly what is necessary---nothing more or less---are pure.''

How's that?

(many more important
>things like water or air are useless if they are pure...) I don't really
>think that distinguishing nil,(),false has anything to do with purity.

Unless your world view is that having distinct boolean symbols is somehow
necessary.

According to a certain kind of purist, being able to invoke CAR on an
empty list is a superfluous feature that isn't logical; after all, if
the list is empty, it has no first element, so the function appears to
be lying if it produces NIL; it's covering up for what should be
signaled as a programmer error. You get the effect that

(CAR '())

and
(CAR '(() 1 2 3))

produce the same result. This rubs a purist the wrong way. One must
test the list for emptiness to obtain a boolean value (and by golly,
a boolean true and false must exist for this purpose); then only if
that value is true can one access the first element of that list.
If the result of that is (), we then know that the first element is an
empty list.

The problem is that this makes common programming tasks inconvenient.
Being able to CAR an empty list is convenient, yet you can still
explicitly test for an empty list if you need to. So by having a little
superfluous robustness in the standard function, you eliminate annoying
tests from the vast amount of code written to use it.

There is another kind of view which clashes with the above one and
that is: make the language do the gruntwork whenever possible, and put
frequently-needed idioms into the implementation. This view can equally
be the basis of purism, centered on the purity of work, rather than
the purity of the language.

What is more precious, the programming language or every programmer's
time? Which should serve the other? Language purists hold the language
to be important, and programmers to be unimportant.

Friedrich Dominicus

unread,
Dec 18, 2001, 1:36:37 AM12/18/01
to
Kent M Pitman <pit...@world.std.com> writes:

> David Golden <qnivq....@bprnaserr.arg> writes:
>
> > On the other hand, Scheme has become a "better" (warning: subjective!)
> > playground vehicle for research into _new_ features for Lisp-family
> > languages, thanks to its smallness and purity
>
> No. Scheme has become a good testbed for Scheme features. It is a bad
> testbed for CL features. (As to the middle ground of Lisp in general, I'm
> less sure because

Well I obviously disagree here (otherwise I hardly would answer
;-). Schemes are very diverse and have incorporated extensions which I
do not have seen for Common Lisp. Well at first SCSH comes to my
mind. Than Kawa or Silk. Maybe STk and probably a bunch of others if I
think about it for a while.

Well I do not know of anythink done for Common Lisp which could
compare with the Shell-Scripting facilities of SCSH. I can't see why
that would be worse for Common Lisp. I know of no Common Lisp which is
to tighlty integrated with Java. (Not that I'm a fan of it, just I see
it as an experiment.

Teh regex stuff form SCSH was done in Scheme not in Common Lisp!. Why?
Well I'm sure if one digs a bit deeper into different Schemes one will
find other examples which suggest (at least for me) that Scheme is not
just a good testbed for Scheme features but for very different
"things".

Well I do think that the Common Lispers have put much more effort in
the "programming language" Common Lisp as you pointed out. In that
area I would think that Schemes are very much behind.

Regards
Friedrich


Christopher Stacy

unread,
Dec 18, 2001, 1:36:55 AM12/18/01
to
>>>>> On Mon, 17 Dec 2001 14:12:16 -0700, Wade Humeniuk ("Wade") writes:
Wade> As for lexical scoping, its no longer an innovation.

That particular innovation adopted by Scheme actually came from
(at least) an earlier Lisp language called MDL, by the way.

Thomas F. Burdick

unread,
Dec 18, 2001, 1:45:56 AM12/18/01
to
David Golden <qnivq....@bprnaserr.arg> writes:

Yes, people will certainly question a lot of the dogma typically
associated with learning Scheme. And they'll express it by rejecting
Lisp, because this is what they think Lisp is about, and they want no
part of it. GCC optimizes tail calls? Great, who needs Lisp!

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

Thomas F. Burdick

unread,
Dec 18, 2001, 2:04:38 AM12/18/01
to
Gareth.M...@pobox.com (Gareth McCaughan) writes:

> - CL also has some great books. My favourite is Peter Norvig's
> "Paradigms of artificial intelligence programming: case
> studies in Common Lisp", which in the opinion of many Lispers
> is one of the finest programming books on any subject. It's
> worth reading even if you have no interest in AI, and it's
> worth reading even if you have very little interest in CL.
>
> Also often recommended (but more controversial) is Paul
> Graham's "On Lisp", which is mostly about macros and
> higher-order functions. And "The art of the metaobject
> protocol", which is all about opening up the workings
> of your object system to user inspection and manipulation
> without making it impossible to be efficient. Very cool
> stuff.

I'd say that AMOP is as much about implementing the innards of an
object system as PAIP is about AI. It _is_ about that subject, yes,
but is also a wonderful example of OO design for a non-trivial system.
Most pedantic texts on OO design use uselessly small examples. Most
working OO systems, like most working systems, "should" (in a world
with an infinite number of man-hours) be torn down, and redesigned and
re-implemented. I'd say it's useful reading for anyone who is
interested in learning about designing object-oriented systems in
general.

Michael Hudson

unread,
Dec 18, 2001, 10:03:21 AM12/18/01
to
Kent M Pitman <pit...@world.std.com> writes:

> Michael Hudson <m...@python.net> writes:
>
> > Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
> >
> > > Scheme was designed to teach certain concepts in computer science
> > > classes.
> >

> > Are you sure about this?
>

> I have been in the room of the Scheme authors (check the front page
> of the Revised^n Report on Scheme to see my name in the credits) and
> have repeatedly seen decisions made in favor of teaching and in
> opposition to proposals that would make it easier for industry.

Hmm. I think I sort-of misread Christopher's remark, and asked the
wrong question. I was more-or-less aware of scheme's development (and
knew your name was on the front of R^5RS) -- though thanks for the
long and as-ever informative post.

What I meant to ask was more about the purpose of scheme's creation
way back when. Was scheme actually *created* for the purpose of
teaching? I was under the impression that it was not, though I can't
for the life of me remember where I get that impression from, and am
now suspecting that it was erroneous.

Cheers,
M.
(Hmm, good sigmonster)

--
Famous remarks are very seldom quoted correctly.
-- Simeon Strunsky

Kent M Pitman

unread,
Dec 18, 2001, 10:25:16 AM12/18/01
to
Jochen Schmidt <j...@dataheaven.de> writes:

> David Golden wrote:
>
> > Edward Piman wrote:
> >
> >> Browsing posts to this group I frequently see real scorn for scheme. Over
> >> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
> >> an outsider, I am puzzled by this bad feeling between groups who would
> >> seem to have much in common.
> >>
> >
> > Well, Scheme stole a lot of CL's thunder, just when CL looked ready to
> > take on the world, a lot of the academic and open source community started
> > concentrating on Scheme. Scheme is "purer" than CL (e.g. differentiation
> > between boolean false, symbols called "nil" and the empty list), but it's
> > also a lot "smaller". This has good and bad points.
>
> As I hear this word very often called with some languages - what exactly do
> you mean by "pure" (or "purer")? We are not talking about diamonds or gold
> we talk about languages and it is not absolutely obvious to me why being
> "pure" is unconditionally a good thing for a language. (many more important
> things like water or air are useless if they are pure...) I don't really
> think that distinguishing nil,(),false has anything to do with purity. You
> may have seen an extensive discussion over this topic lately and AFAIR
> there was _no_ consensus that the distinction is the unconditionally right
> thing to do - so _how_ can that increase "purity" in a language?

I'm guessing he means purity as in "failing to deviate from a social
goal" and the bug is not per se with the sense of "purity" but with
his failure to identify and defend explicitly the social goal. Often
people assume that social goals are "obvious", "uniquely determined",
and "universally accepted". Such is rarely the case, but often the
more passionate someone believes in the the goal, the more surprised
and confused they are that it's possible for others not to.

For example, Scheme has an implicit assumption in it that fewer
"cases" in a language is undesirable. And they observe that a
statement of the general form "if x is in a functional position, then
... else if x is in a variable position, then ..." is notationally
more complex than "if x is in an evaluable position then ...".
They're right. Two namespaces are more complex than one. But then
they promote this to a social goal: complexity is to be always
avoided. This is the point they usually overlook--that others might
say "some complexity is ok and even desirable". If they fail to see
this, they miss the point. They look at "some" as being an operator
on domain data that introduces impurity. But I don't agree. The onl
kind of impurity that's interesting to me is the kind that happens
after the initial goals are laid down. If my goal is to use my
brain's ability to accomodate limited complexity, then my goal is not
achieved by dumbing down a problem down to where part of my brain that
could be active is left idle by an attempt to apply some sort of
meta-purity that wishes my brain were not constructed as it is.

Within the context of the problem as I want to state it, purity
addresses the question of how to most straightforwardly I can keep my
whole "somewhat complex" brain from either confronting problems that
are either too complex OR too simpleminded. I don't like the verb purity
because it judges at a funny level that seems irrelevant, like trying to
judge a straight line drawn by a person without a straight-edge with a crayon
against a mathematical line. You can do that judgment, but it won't tell
you much about whether the line was of suitable engineering quality since
the result will always be "it's impure" and will miss the point that some lines
will be "just what was needed" while others not. Moreover, there are times
that a mathematically straight line, however elegant, will be the wrong thing.
It might be too thin, too rigid, too lacking in "character", or whatever.
Consider how much art in a museum would be judged impure by gauging its
lines this way, and how much less pretty a museum's art would be if that
kind of purity were the canonical metric of goodness.

> As I already mentioned elsewhere I'm always careful if someone calls a
> language "pure" as this means most of the time that the designers have
> chosen to omit a vast amount of things because of more or less subjective
> stylistic reasons. CL is a rather impure language in this sense and that is
> what I actually think is better in CL - nobody omits some nice or important
> feature from you only based on personal stylistic feelings. The default
> mode in CL seems to be allowing something if it does not has an negative
> effect on others.

Nearly all things that are not uniquely determined are outside the reach of
the Scheme designers to offer to their users since their consensus process
couldn't allow them to choose. Like the donkey left to starve to death
when put at midpoint between two carrots at opposite ends of the room, and
no hint as to which would be the better way to go, sometimes Scheme's design
criteria has overlooked the value of the simply arbitrary.

It also overlooks the value of the blunt. I have often summed up that
virtue in this way:

You are to be locked in a closet. You may choose to be locked in the
one marked Scheme or the one marked Lisp. In the Scheme closet is a
drawer filled with thousands of tiny keys, each of which neatly fits
just one lock. One will get you out, but the others are irrelevant
to your task. Whoever put them there didn't like master keys--too
impure. So you'll have to find the one you need. In the Lisp
closet, you will find a hammer, a screwdriver, and an adjustable
wrench, but no key. (Neither is Lisp this blunt, nor Scheme this
unforgiving, but indulge me some exaggeration to make a simple point
here.) Dinner is not the table while you're locked in there--will you
get out before it's stone cold?

Kent M Pitman

unread,
Dec 18, 2001, 10:33:35 AM12/18/01
to
Christopher Stacy <cst...@spacy.Boston.MA.US> writes:

Actually, it came from Algol.

If you study the original Algol 60 report and the Scheme report
(especially versions before R5RS, which has started to drift slightly
IMO), you'll see a HUGE amount of work was done to match the "book
design" (text layout, typography, formatting, chapter organization,
and even certain key phrases) from the Algol 60 report. This was VERY
deliberate, since Algol 60 is what inspired Scheme. The Algol 60
report had, under its list of authors, a dedication to someone who had
died; one of the Scheme reports at least has a similar remark about the
passing of one that had been cared about, but it was Algol itself...

For people who think Algol means Algol 68, this detail probably went right
past them, since I'd imagine the Algol 68 spec is laid out differently, and
since maybe people don't even learn Algol from the spec.

I probably have a copy of the Algol 60 report somewhere in my files
laying around and could maybe could try to scan in the cover for
people to see the similarity if there are those out there who don't
have access... But it may already be online somewhere. I would hope so.

Kent M Pitman

unread,
Dec 18, 2001, 11:05:48 AM12/18/01
to
Michael Hudson <m...@python.net> writes:

> What I meant to ask was more about the purpose of scheme's creation
> way back when. Was scheme actually *created* for the purpose of
> teaching?

Probably not per se, but I'll check. I _think_ it was created by
Steele/Sussman as a paper as part of some research but I'm not sure it
was intended really to be used at all at that point except for fun.

Sussman was teaching Lisp then, though. (Not sure if Abelson was back
then. My memory says he came onboard slightly later, but I might be
misremembering...) Sussman was using a really ad hoc silly lisp for
the class, probably not of his chosing. I first saw that lisp on the
pdp-11/45 we were using under the Delphi operating system and later
they moved to Unix. (It had some very odd features, like you could
invoke it with a -t or -s option from the command line to tell it to
use a "tree interpreter" or "stack interpreter", which I think
affected whether you got sphaghetti stacks or not...) But the system
it ran on was way too loaded and they wanted to use it on other
machines besides the delphi computer (which was called that even after
it didn't run the delphi operating system). I wrote, in Maclisp on
the pdp10, a simulator of the lisp, which people I know all called
delphi lisp (though I'm not sure that was its name) so my friends
could do homework on another machine. Then I played around with the
simulator and wrote something I liked better called "ulisp" (I believe
the "u" had to so with its origin on the unix). Anyway, ulisp was
used in sussman's class for one semester. It was pretty in some ways
but it didn't have tail call elimination and I for the life of me
didn't know what Sussman was ranting about when he said he wanted
that. (I don't know if he wasn't explaining himself well or if I
wasn't listening.) But he ended up taking original-Scheme (which I
*think* he'd already done as a kind of research project with Steele)
and revised it heavily for his class. I'm not sure if this was going
on already or if it was catalyzed by his frustration with my lisp and
the lisp mine had replaced.

[I still have the ulisp spec at least in hardcopy and will try to put
it online, btw. It had some curious properties that were not what
sussman wanted to be teaching, but it was quite elegant and cute in
its own very different way... it would make a good scripting
language. it was hard to compile, i realized later, becuase of some
oddball decisions i'd made. (The TeX macros I worked out for Ulisp's
manual, though, turned out to be usable for documenting Maclisp and
probably had a coincidental effect on my willingness to start
accumulating maclisp trivia, ultimately resulting in the maclisp
manual, and my interest in documenting lisps. So the weird potential
side effects of stray projects one happens into even just by chance
are not to be understated.)]

> I was under the impression that it was not, though I can't
> for the life of me remember where I get that impression from, and am
> now suspecting that it was erroneous.

I think originally not, but I think Sussman had these ideas rolling around
in his head and was frustrated that he didn't have a language for his class
that allowed him to use them. So I think he co-opted Scheme's design and
development for the purposes of the class for a while, and I think it's
probably at least fair to characterize it as having been productized for
teaching, if not designed for it. Also, original-Scheme is different in
a lot of ways than the Revised Report scheme was. It has changed over time.

I'll see if I can get someone to fill in some gaps here. I was an
undergrad at the time, and though I shared an office at the lab with
Steele during that general timeframe, and I hung out a lot downstairs
with Sussman, I didn't really have a total understanding of what
"drove" the lab's activity at that point. I'm not even sure I then
knew the right questions to ask. I just kind of pushed my way into
things blindly/bluntly and learned by the seat of my pants... not that
most others around me didn't seem to be doing the same, but it doesn't
lead to the most objective retellings. It won't surprise me if Steele
and/or Sussman tells an utterly different version of this. I'll see
what I can coax out of them and post any results I get here.

Aaron J Reichow

unread,
Dec 18, 2001, 11:03:27 AM12/18/01
to
On Mon, 17 Dec 2001, David Golden wrote:

> The original source is at http://Sugar.mini.dhs.org/
> it's about 100 lines.

Thanks for the pointer.

> > Dylan never really took off, either.
> >
> Dylan tried to do too much, I think. Sugar source is pretty much ordinary
> scheme, just with the information that parantheses usually convey to the
> reader conveyed by the indentation instead - since pretty much everyone
> indents anyway (or the editor does it for them), and Sugar still _allows_
> the normal parentheses, it's quite popular for just banging out code - one
> problem you have with estimating it's usage is that people may write the
> code in sugar syntax, but release the code in normal parens.

Do a fair amount of people actually use this in your estimation? What
kinds of people? Algol-head CS students forced to use Scheme in school?

> Anyway, if you think that's wierd and pointless, wait till you see cugar,
> which makes C++ into an indentation-sensitive python-lookalike...

Actually, I've used that before on CS assignments. Didn't last through the
semester unfortunately- evenually we were paired for later assignments,
and cugar couldn't change my partner's source back in to cugar. :)

Regards,
Aaron

Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/

"life, probably the biggest word i've ever said, that says a lot,
because there's a whole lot of words inside my head.." :: atmosphere


David Golden

unread,
Dec 18, 2001, 12:49:12 PM12/18/01
to
Aaron J Reichow wrote:

> Do a fair amount of people actually use this in your estimation?

I'd say only a minority of schemers, and it seems to be more popular/known
in france/germany than in america, but the facility tends to be there for
programmers who like it - actually, a similar package for common lisp might
be nice, if it doesn't already exist...

> What kinds of people?

Lazy people, and people who think all the parens in lisp are as ugly as
all the $ signs in Perl. :-)

Actually, as all lisp people know, the current XML fad is rather silly,
given that XML IS basically a tree structure, like one might compose in
lisp with conventional () sexps, but with really annoying syntax -
one of the fun things you can do in theory is munge Sugar and the SSAX
functional xml parser[1] together, so you can write xml/xhtml thusly:

html
head
title
"My Document"
body
h1
"this is my document"
p
"And this is a paragraph. Woop-de-do"

Personally, in conjunction with an autoindenting editor, I think I'd find
this a lot less annoying than the myriad <> of XML...

[1] See http://ssax.sourceforge.net - no doubt, a CL port or
reimplementation of this framework would be relatively painless... it'd
be nice if it still used the same SXML data format...

Janos Blazi

unread,
Dec 18, 2001, 2:13:01 PM12/18/01
to

"Edward Piman" <eip...@yahoo.com> schrieb im Newsbeitrag
news:Xns917A7B05D1EF...@65.82.44.7...

> Browsing posts to this group I frequently see real scorn for scheme. Over
> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
> an outsider, I am puzzled by this bad feeling between groups who would
seem
> to have much in common.
>
> I am interested in learning more about one or both languages. Scheme has
> the advantage of books such as SICP and EOPL. Presumably CL has its
> advantages too; anyone care to fill me in? Why (or for what purposes) is
> CL better?

Scheme has no Erik Naggum.
J.B.


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
Check out our new Unlimited Server. No Download or Time Limits!
-----== Over 80,000 Newsgroups - 19 Different Servers! ==-----

Ray Blaak

unread,
Dec 18, 2001, 3:10:17 PM12/18/01
to
Kent M Pitman <pit...@world.std.com> writes:
> They said it was enough to know it came from CL. They wanted not to be
> dirtied by CL. I said, taking one idea or reading one page of text from CL
> will not make this a dirty language and that it was idiotic to say
> otherwise, but they persisted in an utterly emotional response, refusing to
> allow the matter to come to the table for discussion. They did not want
> ISLISP polluted by CL thoughts.

This "heads in the sand" mentality is the scourge of organizations.

My trick for dealing with this kind of thing is to present the technical idea
one its own, without indicating the controversial origins.

--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@telus.net The Rhythm has my soul.

Wade Humeniuk

unread,
Dec 18, 2001, 3:44:07 PM12/18/01
to
> As I hear this word very often called with some languages - what exactly
do
> you mean by "pure" (or "purer")? We are not talking about diamonds or gold
> we talk about languages and it is not absolutely obvious to me why being
> "pure" is unconditionally a good thing for a language. (many more
important
> things like water or air are useless if they are pure...) I don't really
> think that distinguishing nil,(),false has anything to do with purity. You
> may have seen an extensive discussion over this topic lately and AFAIR
> there was _no_ consensus that the distinction is the unconditionally right
> thing to do - so _how_ can that increase "purity" in a language?

When people are talking about a pure language I think they are really
referring personally to themselves. That "they" are "pure". That their
thoughts are not contaminated by complexity. They have fresh ideas, new
approaches, innovative constructs and uncluttered vision. For these people
they confuse the programming languages they use with who they are.

The idea that advances are made by naive (but gifted) youth, is a mythology
deeply ingrained into modern thought. Unencumbered by the past and all its
untidiness (pureness) they have the pliability to see new things. It is
half true. Having a limited number of paints (the three primary, white and
black) with which to paint a picture is not a virtue even though one can
theoretically mix all possible colours (in practice this is impossible).

The advancements of computer science (and programming) in the 60's and 70's
was done largely by the young though the groundwork was laid people with
great experience and insight. There were lots of new ideas and approaches to
come out then. The point however is that these have come out, the work has
been done and its time to move ahead. The work with Scheme, Dylan and Java
is just re-implementing the wheel. Maybe it is because programming can
create the illusion that you are accomplishing something when you are really
not.

Wade


Christopher Stacy

unread,
Dec 18, 2001, 4:07:19 PM12/18/01
to
>>>>> On Tue, 18 Dec 2001 15:33:35 GMT, Kent M Pitman ("Kent") writes:

Kent> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>> >>>>> On Mon, 17 Dec 2001 14:12:16 -0700, Wade Humeniuk ("Wade") writes:
Wade> As for lexical scoping, its no longer an innovation.
>>
>> That particular innovation adopted by Scheme actually came from
>> (at least) an earlier Lisp language called MDL, by the way.

Kent> Actually, it came from Algol.

I also thought that it originally came from Algol (which is why I said
"at least"), but I think MDL was the first Lisp to have lexical scoping.

Actually, in MDL, symbols were self-evaluating (like keywords in CL),
and for a symbol value you had to specify whether you wanted the
"global" or "local" value. The reader macros "," and "." called
the symbol-value functions GVAL and LVAL, respectively.

MDL was the preferred Lisp programming language of the Project MAC people
on the 2d floor of the lab (people on most other floors liked MACLISP).

Christopher Stacy

unread,
Dec 18, 2001, 4:10:03 PM12/18/01
to
>>>>> On Tue, 18 Dec 2001 20:13:01 +0100, Janos Blazi ("Janos") writes:

Janos> "Edward Piman" <eip...@yahoo.com> schrieb im Newsbeitrag
Janos> news:Xns917A7B05D1EF...@65.82.44.7...


>> Browsing posts to this group I frequently see real scorn for scheme. Over
>> on comp.lang.scheme I fail to see this same scorn for CL. Why is that? As
>> an outsider, I am puzzled by this bad feeling between groups who would

Janos> seem


>> to have much in common.
>>
>> I am interested in learning more about one or both languages. Scheme has
>> the advantage of books such as SICP and EOPL. Presumably CL has its
>> advantages too; anyone care to fill me in? Why (or for what purposes) is
>> CL better?

Janos> Scheme has no Erik Naggum.
Janos> J.B.

That's a bug, not a feature.

Kent M Pitman

unread,
Dec 18, 2001, 4:31:10 PM12/18/01
to
Christopher Stacy <cst...@spacy.Boston.MA.US> writes:

> >>>>> On Tue, 18 Dec 2001 15:33:35 GMT, Kent M Pitman ("Kent") writes:
>
> Kent> Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
> >> >>>>> On Mon, 17 Dec 2001 14:12:16 -0700, Wade Humeniuk ("Wade") writes:
> Wade> As for lexical scoping, its no longer an innovation.
> >>
> >> That particular innovation adopted by Scheme actually came from
> >> (at least) an earlier Lisp language called MDL, by the way.
>
> Kent> Actually, it came from Algol.
>
> I also thought that it originally came from Algol (which is why I said
> "at least"), but I think MDL was the first Lisp to have lexical scoping.

That may well be (never thought to check) but, being a statement about
timelines rather than influence, is not in contradiction with my
stated belief. (I sent my post to Sussman and Steele to see if they
have any comments to make. We'll see.) Of course, the influence could
have followed in lockstep with timeline, but it's a mistake in general
to assume that everyone at point X in time was either cognizant of all
things before point X or willing to open their mind to the implications
of such things even if cognizant.

> MDL was the preferred Lisp programming language of the Project MAC people
> on the 2d floor of the lab (people on most other floors liked MACLISP).

You speak about the lab like a unified thing. I always felt the AI Lab
and the Lab for Computer Science were worlds apart. ESPECIALLY the
dynamic modeling (DM) people, who didn't share much of any software with
the other three computers in the building...

Kent M Pitman

unread,
Dec 18, 2001, 4:37:59 PM12/18/01
to
"Wade Humeniuk" <hume...@cadvision.com> writes:

> The idea that advances are made by naive (but gifted) youth, is a mythology
> deeply ingrained into modern thought. Unencumbered by the past and all its
> untidiness (pureness) they have the pliability to see new things.

From the "AI Koans" (perplexing little fables used for "teaching"
occasional lessons at MIT's AI Lab, I think generally attributed
to Danny Hillis as author):

+--------------------
|
| In the days when Sussman was a novice, Minsky once came to him as he
| sat hacking at the PDP-6.
|
| "What are you doing?", asked Minsky.
|
| "I am training a randomly wired neural net to play Tic-Tac-Toe"
| Sussman replied.
|
| "Why is the net wired randomly?", asked Minsky.
|
| "I do not want it to have any preconceptions of how to play", Sussman said.
|
| Minsky then shut his eyes.
|
| "Why do you close your eyes?", Sussman asked his teacher.
|
| "So that the room will be empty."
|
| At that moment, Sussman was enlightened.
|
+--------------------

Barry Margolin

unread,
Dec 18, 2001, 5:08:20 PM12/18/01
to
In article <ur8psq...@telus.net>, Ray Blaak <bl...@telus.net> wrote:
>This "heads in the sand" mentality is the scourge of organizations.
>
>My trick for dealing with this kind of thing is to present the technical idea
>one its own, without indicating the controversial origins.

If their priorities are political issues over technical one, they're bound
to ask or find out. The whole reason ISLISP was created was because
several influential members of the ISO Lisp committee were extremely biased
against CL, and that bias influenced the process.

--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

Kent M Pitman

unread,
Dec 18, 2001, 5:30:11 PM12/18/01
to
Barry Margolin <bar...@genuity.net> writes:

> In article <ur8psq...@telus.net>, Ray Blaak <bl...@telus.net> wrote:
>
> >This "heads in the sand" mentality is the scourge of organizations.
> >
> >My trick for dealing with this kind of thing is to present the
> >technical idea one its own, without indicating the controversial
> >origins.
>
> If their priorities are political issues over technical one, they're
> bound to ask or find out. The whole reason ISLISP was created was
> because several influential members of the ISO Lisp committee were
> extremely biased against CL, and that bias influenced the process.

I wouldn't say this was the WHOLE reason. It was probably a strong
influence in the start and perhaps an influence all along. If this had
been the only driving force, I don't think it would have been completed
because completing it required considerable accomodation to CL's needs.
It is not a CL subset, but I think we (the US, and by implication the
global CL community) got all of the important concessions we needed in
order to assure that an ISLISP compatibility package can be constructed
within a conforming CL without a conflict with the CL type system, the
CL package system, etc.

Another reason, though, that ISLISP was there and continued to be
important was that there were specific Lisp projects afoot
internationally in various countries and regions that for various
reasons needed some thing that CL wasn't. (I vaguely recall touching
on this in my paper about Lambda, the ultimate political party.
http://world.std.com/~pitman/PS/Lambda.html ) Either smaller text size
or an international stamp of approval or the mere fact of still being
an ongoing design and not a finished project. As someone (not sure
who) once rightly said about standards: The nice thing about standards
is that there are so many of them.

Btw, I have made some very negative remarks about the Scheme
community's disdain for bloat not because I don't think the size issue
is ever real, just because the passion there was extreme. I remember
once they were concerned about the fact that their community was so
size-obsessed that, like an anorexic, they were both too small to be
printed in a bound edition (and had to include another related paper
with the spec to give it more bulk) and yet at the same time didn't
want to grow the spec for "fear" it would change over to where it
needed a different kind of binding that they couldn't brag about in
the same way. When we're talking "keeping Scheme small", we're
talking really obsessively extreme here. HOWEVER, by contrast, the
international concern about size was much more reasaoned. Japan, for
example, cited a specific desire of 100 pages or less, because it was
expensive to do a translation and because they feared various
universities would not use it bigger than a certain size. Yet they
still did not make irrational requests that we not fix bugs or clarify
issues and when the ultimate document was something like 130 pages or
so (can't quite recall, but I recall it as an order of magnitude
smaller than ANSI CL), they voted yes. This kind of concern about
size I have no problem with.

Lieven Marchand

unread,
Dec 18, 2001, 12:31:21 PM12/18/01
to
Kent M Pitman <pit...@world.std.com> writes:

> You are to be locked in a closet. You may choose to be locked in the
> one marked Scheme or the one marked Lisp. In the Scheme closet is a
> drawer filled with thousands of tiny keys, each of which neatly fits
> just one lock. One will get you out, but the others are irrelevant
> to your task. Whoever put them there didn't like master keys--too
> impure. So you'll have to find the one you need. In the Lisp
> closet, you will find a hammer, a screwdriver, and an adjustable
> wrench, but no key. (Neither is Lisp this blunt, nor Scheme this
> unforgiving, but indulge me some exaggeration to make a simple point
> here.) Dinner is not the table while you're locked in there--will you
> get out before it's stone cold?

A nice contrapunt to Guy Steele's woodworking toolshop metaphor in his
foreword to Scheme and the Art of Programming.

I'm beginning to detect a theme ;-)

--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words

Aaron J Reichow

unread,
Dec 18, 2001, 5:38:42 PM12/18/01
to
On Tue, 18 Dec 2001, David Golden wrote:

> Personally, in conjunction with an autoindenting editor, I think I'd find
> this a lot less annoying than the myriad <> of XML...
>
> [1] See http://ssax.sourceforge.net - no doubt, a CL port or
> reimplementation of this framework would be relatively painless... it'd
> be nice if it still used the same SXML data format...

I do the same thing, but using the parens, with le-sursis and clisp. A
collapsing-tree editor would make this even better.

Regards,
Aaron

Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/

"the question is no longer between violence and non-violence; It is
between non-violence and non-existence." :: martin luther king junior


Christopher Stacy

unread,
Dec 18, 2001, 5:42:24 PM12/18/01
to
>>>>> On Tue, 18 Dec 2001 15:03:21 GMT, Michael Hudson ("Michael") writes:

Michael> Kent M Pitman <pit...@world.std.com> writes:
>> Michael Hudson <m...@python.net> writes:
>>
>> > Christopher Stacy <cst...@spacy.Boston.MA.US> writes:
>> >
>> > > Scheme was designed to teach certain concepts in computer science
>> > > classes.
>> >
>> > Are you sure about this?
>>
>> I have been in the room of the Scheme authors (check the front page
>> of the Revised^n Report on Scheme to see my name in the credits) and
>> have repeatedly seen decisions made in favor of teaching and in
>> opposition to proposals that would make it easier for industry.

Michael> Hmm. I think I sort-of misread Christopher's remark, and asked the
Michael> wrong question. I was more-or-less aware of scheme's development (and
Michael> knew your name was on the front of R^5RS) -- though thanks for the
Michael> long and as-ever informative post.

Michael> What I meant to ask was more about the purpose of scheme's creation
Michael> way back when. Was scheme actually *created* for the purpose of
Michael> teaching? I was under the impression that it was not, though I can't
Michael> for the life of me remember where I get that impression from, and am
Michael> now suspecting that it was erroneous.

Michael,

At least by R^3, Scheme was described by the authors thus:
"As might be expected of a language used primarily
for education and research..."

That certainly doesn't mean that Scheme is entirely unsuitable for
industrial applications! However, it does hint at the constituency,
and the underlying goals of the language.

Originally, SCHEME was created as research into programming, especially
recursion techniques: to "have a simple and concrete experimental domain
for certain issues of programming semantics and style". It grew out
experience with Hewitt's ACTORS language, and Micro-PLANNER and CONNIVER.
The original SCHEME Report does not mention ALGOL at all, but does go out
of its way to mention those other languages; there is no cite of ALGOL,
but there is of MDL (which Sussman was also peripherally involved in),
and a couple of CACM cites (Dijkstra; Knuth; Lamport) on "Dijkstra's
Concurrent Programming Problem". Certainly the authors knew ALGOL, though.

As to whether they originally thought they were making a Lisp: they did and
they didn't. That is, it's in the Lisp family, but significantly different.
"SCHEME is essentially a full-funarg LISP...
All LISP functions are primitive operators in SCHEME,
and have the same meaning as they have in LISP."
Later, in the first Revised Report, SCHEME is described as "a dialect
of LISP" and "a LISP-like language".

At that time, people were busy figuring out "the funarg problem" and
related issues; evaluation, quoting, and call-by-name vs. call-by-value,
and basic Lisp implementation techniques were also still research areas.

The were creating a language to *study* *certain* programming issues,
not trying to create a language for application programming. One of
the very first things mentioned was the elimination of features that
were useful for applications such as database manipulation and pattern
matching (which were present in those other research languages that
they were involved with). Over and over, the whole point and emphasis
is on simplicity, lambda calculus (Sussman was teaching 6.031 at the
time), and the cool idea of continuation passing recursion.

That was all back before 1975.

I think ALGOL is first mentioned about 3 years later in the first
Revised Report on SCHEME, which is when the BNF was introduced.
At that point, however, the description was still: "SCHEME programs
are represented by LISP s-expressions. The evaluator interprets
S-expressions in a specified way. This specification constitutes
the definition of the language..."

By that time, they had also gotten rid of some of the Lisp terminology.
(Originally, what CL calls "special forms" and MACLISP called "FEXPRs"
were called "AINTs" in SCHEME.)

I personally didn't encounter SCHEME until 1981 (when I was mostly
programming in MACLISP, MDL, and Lisp Machine Lisp, and of course,
PDP-10 assembler). At that time, SICP was being written from the
course notes for 6.001, and the primary application of Scheme was
for teaching that course. Scheme was also the target of a set of
new Lisp processor chips (the ASSQ chip, etc.).
(Not related to the Lisp Machine project, incidentally.)

Those courses (taught now in many more schools) remain the primary
application of Scheme. The language is still useful for exploring ideas
in programming, except to the extent that its clientele perceive that
this takes it away from being Scheme. Some object systems, and hygenic
macros, are examples of more recent (ca 1983) language research in Scheme.
Common Lisp, of course, includes significant lessons learned from Scheme.

Of course Scheme *can* also be used for writing "real" applications,
but that was not its intended purpose. (Contrast this with Common Lisp,
which eschewed anything smacking of experimental, maybe overly so, and
was designed explicitly for writing and porting industrial applications.)
For some applications, for example tiny machines running small embedded
programs, Scheme might be a much better choice than Common Lisp.
In recent years, Sussman has promoted using Scheme in several
science and engineering domains, and as a vehicle of calculus for
teaching formal concepts in various domains.

When some people get all excited about Scheme being "pure" (by which I
suppose they mean "regularized to the point of simplicity, simple to
trivially implement, underspecified, and lacking many features"),
that just doesn't really enthuse Common Lisp programmers, who are
interested in a different set of aesthetics and features, and who
seem to resent an implication that Common Lisp is "dirty".

But if the real world is not pure, and Lisp is happily a ball of mud,
why should we be offended that Common Lisp is not "pure", anyway?

Chris

cbbr...@acm.org

unread,
Dec 18, 2001, 5:57:10 PM12/18/01
to
Aaron J Reichow <reic...@d.umn.edu> writes:
> On Tue, 18 Dec 2001, David Golden wrote:
>
> > Personally, in conjunction with an autoindenting editor, I think I'd find
> > this a lot less annoying than the myriad <> of XML...
> >
> > [1] See http://ssax.sourceforge.net - no doubt, a CL port or
> > reimplementation of this framework would be relatively painless... it'd
> > be nice if it still used the same SXML data format...
>
> I do the same thing, but using the parens, with le-sursis and clisp. A
> collapsing-tree editor would make this even better.

I'd love to see a port of something like this.

There are getting to be quite enough different sorts of documents out
there that use XML that would be _really_ nice to walk through using
CL.

I'm _slightly_ undecided as to whether I'd rather see:
a) Something like SSAX, where you have to write code to parse bits of
the document, so that essentially the parser walks across the
document, running your code as it goes, or

b) Something that transforms the whole document into a tree,
basically like the Franz "xmlutils," but a bit more portable :-).

I _think_ I'd generally prefer the latter; the fact that you get no
results before reading the whole document arguably means that it's
less efficient, and (arguably) "less elegant." On the other hand,
brute force can work quite well, and if the document fits nicely into
memory, I think that's what I'd rather have.

There are a bunch of XML libraries out there; none are quite
completely working...
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.ntlug.org/~cbbrowne/xml.html
Rules of the Evil Overlord #15. "I will never employ any device with a
digital countdown. If I find that such a device is absolutely
unavoidable, I will set it to activate when the counter reaches 117
and the hero is just putting his plan into operation."
<http://www.eviloverlord.com/>

David Golden

unread,
Dec 18, 2001, 7:24:44 PM12/18/01
to
cbbr...@acm.org wrote:

> I _think_ I'd generally prefer the latter; the fact that you get no
> results before reading the whole document arguably means that it's
> less efficient, and (arguably) "less elegant." On the other hand,
> brute force can work quite well, and if the document fits nicely into
> memory, I think that's what I'd rather have.
>

I dunno about that - a lot of XML (or pseudo-XML) usage, particularly
coming out of the microsoft camp, involves streaming it to clients over
sockets - then it's a definite advantage to have interim access to the
parts, particularly for "progressive display" of partial data (users like
to see the web pages or whatever building, and like to "click ahead" on a
part-rendered page, particularly if the network's slow.) and it's not as if
with SSAX (as opposed to the evil, evil SAX) you can't subsequently end up
with a complete DOM-style tree...


cbbr...@acm.org

unread,
Dec 18, 2001, 7:46:04 PM12/18/01
to

In that I'm not presently looking at streamed usage, interim access
falls into the "don't care" category...
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/oses.html
Zaphod's just zis guy, you know?

David Golden

unread,
Dec 18, 2001, 8:09:27 PM12/18/01
to
cbbr...@acm.org wrote:

> There are a bunch of XML libraries out there; none are quite
> completely working...

how's the xml.lisp one in the clocc?
http://clocc.sourceforge.net/dist/cllib.html
(I've never used it, just asking.)

Harald Hanche-Olsen

unread,
Dec 19, 2001, 6:48:37 AM12/19/01
to
+ Kent M Pitman <pit...@world.std.com>:

| As someone (not sure who) once rightly said about standards: The
| nice thing about standards is that there are so many of them.

That was Tannenbaum, I think. He may not have been the first, though.

--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?

Bijan Parsia

unread,
Dec 19, 2001, 2:39:23 PM12/19/01
to
On Tue, 18 Dec 2001, Wade Humeniuk wrote:
[snip]

> When people are talking about a pure language I think they are really
> referring personally to themselves.

I don't think that's a wise thought to hold uncritically. When I encouter
"pure" it's usually "pure with respect to something" and the contrary is
"hybrid". So, Java isn't a pure object oriented language because of
primitive types. Purity of OOness isn't a virtue on its own, or, at least,
it's perfectly possible to have a completely wretched pure OO language (or
"more or less" pure :)).

This is only one, primary use. It's perhaps unfortuneate that the word
"pure" tends to get read *uncritically* as "better", or, at least, more
valuable. But purity even of gold isn't an uniform virtue (as pure gold is
very very soft, too soft for many purposes). Hybridity can bring about
more vigor, disease resistence, or interesting colors (I tend to think of
Common Lisp as a hybrid langauge in this sense; it *unites* various
paradigms/styles in a way that produces strengths beyond merely having the
array of styles available; in this way, "multi-paradigm" doesn't seem
right to me).

[snip]


> The advancements of computer science (and programming) in the 60's and 70's
> was done largely by the young though the groundwork was laid people with
> great experience and insight. There were lots of new ideas and approaches to
> come out then. The point however is that these have come out, the work has
> been done and its time to move ahead. The work with Scheme, Dylan and Java
> is just re-implementing the wheel.

[snip]

Java and Dylan are both explicilty derivative projects, indeed, projects
motivated in part by the goal of making certain things "palatable" to
"mainstream" programmers. That is, they both more or less explicitly
sought to move the state of the general *practice* more in line with the
state of the *art*.

(I tend to think of Common Lisp as an attempt to *codify* the minimum
level of the state of the art and general practice. That is, to settle
*some* stuff as settled so as to focus energy on new things. CL would fail
in one way if it was a base to restrictive to support new things. Clearly,
it's not *yet* failed in that respect.)

Scheme, OTOH, has a rather different history. It may have *ended up* as a
place where wheels are reinvented, but I don't think it started there (as
subsequent posts in this forum have documented).

Cheers,
Bijan Parsia.

Seth Gordon

unread,
Dec 19, 2001, 3:26:35 PM12/19/01
to
You should keep in mind that while the Scheme *standard* is deliberately
sparse, almost every Scheme *implementation* worth using has features
not included in the standard. There are a lot of free Scheme
implementations floating around out there, with various feature sets.

So rather than simply ask "what are the advantages of CL over Scheme or
vice versa?", it might be better to start with some goal, find out
*which* Scheme implementations are best for achieving that goal, and
then find out whether there are CL implementations that do better for
that purpose than their Scheme competitors.

--
"Any fool can write code that a computer can understand.
Good programmers write code that humans can understand."
--Martin Fowler
// seth gordon // wi/mit ctr for genome research //
// se...@genome.wi.mit.edu // standard disclaimer //

Nils Goesche

unread,
Dec 19, 2001, 4:21:18 PM12/19/01
to
k...@ashi.footprints.net (Kaz Kylheku) writes:

> Elegance often arises from imposing a framework of artificial
> constraints. Artists sometimes find it helpful to adhere to some
> rigid frameworks which give their work an identifiable form; the
> result can be elegant, because it makes use of the built in
> elegance-generating properties of the form, which amplify the
> artist's contribution. But some forms are simply not applicable to
> some kinds of expression. There is a mistake of viewing those
> expressions which don't fit into a given subjectively preferred form
> as inelegant, giving rise to orthodoxies.

> Some people view elegance in programming languages similarly; that
> there is some true way of doing things, and everyone must program to
> that. This works fine up to the point that programming is merely a
> form of artistic self-expression. If one expression doesn't work,
> the artist-programmer can self-censor and seek another. When
> programming is driven by actual externally-imposed requirements,
> this approach is no longer adequate.

Hear, hear. I wish somebody would take the time and explain this to
the folks over in comp.lang.functional ;-)

> Carrying the analogy further, suppose you are a music composer, and all
> you ever compose is very elegant baroque counterpoint in the style of
> J. S. Bach and company. You are happy within these forms making beautiful
> magic. But what if someone wants to commission you to prepare a suite of
> 20th century music? Well, you can say ``Bah, that stuff is cacophonic
> humbug, I only write elegant music.'' So the job goes to someone else.

Interesting analogy. I wonder if it fails if taken very far. For,
there is no music whatsoever without ``form'', that is, rules of any
kind. Bach had certain rules and forms, sometimes very strict like
the ``contrapunkt'' rules, but in other fields was more free than the
people who came after him, like with harmonics. People who don't
understand 20th century composers often think that those compose
without any rules, but that isn't true. Schoenberg /hated/ the term
``atonal music'', and he never wrote a single piece of music that
wasn't ruled by a very rigid framework (that changed over time,
though; sometimes from piece to piece). Similarly, those people who
can tell good free jazz from bad free jazz know that the Godfather
himself, John Coltrane, never played a single note that didn't fit
into the particular framework he was working in (at the time he played
it). In fact, the very reason people don't play any ``free jazz''
anymore is rather that its somewhat hidden frameworks proved to be
rather too restrictive, so the name ``free jazz'' is actually a
misnomer.

There has never been any kind of music that didn't work within some
kind of a ``rigid framework'', nor could there be any. The possible
frameworks differ very much, though. Now, is there some other
framework Lisp people work in? I think there is no Lisp analogy for
stuff like

(*(int *) p)++;

so maybe there is...

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x42B32FC9

Kent M Pitman

unread,
Dec 19, 2001, 6:11:55 PM12/19/01
to
Seth Gordon <se...@genome.wi.mit.edu> writes:

> You should keep in mind that while the Scheme *standard* is deliberately
> sparse, almost every Scheme *implementation* worth using has features
> not included in the standard. There are a lot of free Scheme
> implementations floating around out there, with various feature sets.
>
> So rather than simply ask "what are the advantages of CL over Scheme or
> vice versa?", it might be better to start with some goal, find out
> *which* Scheme implementations are best for achieving that goal, and
> then find out whether there are CL implementations that do better for
> that purpose than their Scheme competitors.

But then what meaning does it have to say "Scheme" has any particular
property if every Scheme is different.

If you criticize CL, you have said something because there is a lot of
commonality there. But criticizing Scheme is as slippery as criticizing
Lisp.

Why don't we just say when people say Lisp is too big, "no, it's small"
because of ISLISP. Or when they say it has no users we'll say "Emacs has
lots of users". I have no problem saying there are useful Scheme
implementations but what makes them useful is, to a large degree, the
part invested by the vendors. Had those same vendors invested the same
amount in CL or some Lisp dialect, I don't think they'd be any worse off.

When we do comparison, let me know if we're talking implementations to
implementations or languages to languages. Because if we compare
implementations, I may pick something like Symbolics Genera as my
implementation to compare to. Or I may pick Allegro. Or I may pick
LispWorks. It just depends on what I think you're going to debate me
about, as I'm sure it does in reverse when people pick a particular
Scheme implementation to debate about... I'm jus tnot sure I see the
point.

Raffael Cavallaro

unread,
Dec 20, 2001, 12:26:55 AM12/20/01