From: Tom Lord
Subject: why Common Lisp is not a lisp
Date: 
Message-ID: <vl530j6kgdh055@corp.supernews.com>
How about, when trying to decide "what is lisp" or to apply "lispp" to
some _thing_, we just go very low level and somewhat retro and mostly
informal?

As a straw-man: a lisp is any language implementation which includes a
run time system with some recognizably lispish types (cons pairs,
numbers, symbols) having their familiar properties (latent typing,
gc-based memory management), and implemented in a recognizably
traditional way (or a brilliant new way, worthy of being added to the
design space).  In the language implemented, programs are expressed in
s-exp syntax and there are some useful senses (for which we don't need
to draw a precise line defining "useful") in which programs are
manipulatable as basic data structures (e.g., expressions as lists).
All the usual Common Lisp implementations are clearly lisps and it's
hard to imagine someone contorting themselves enough to implement a
Common Lisp that isn't a lisp (contrast with a recent "Scheme in
Javascript" that appeared on c.l.s. -- if somebody said "That may be
Scheme but it isn't a lisp" -- I'm not sure why anybody would bother
disagreeing).

We can say that there is a near-but-not-quite consensus among lisp
hackers that some things are better than other things in an
implementation.  For example, an implementation that let's you
evaluate a list as an expression is expected -- and implementations
that don't provide that or provide it poorly are, at the very least,
pretty extreme outliers.

"Common Lisp" and "Scheme" aren't lisps at all.  They are the names of
standards which a lisp may or may not implement.  Another
near-but-not-quite consensus is that Common Lisp has the far larger
commercial significance at the moment, and the greater amount of
practical experience behind it -- and that it's naive to respond to
Common Lisp by saying things like "But Scheme is so much _cleaner_ --
why don't you agree that Common Lisp sucks?".   We can acknowledge
that it has been the experience of people deeply involved with Common
Lisp that, unreasonable as it may sound, they have had to put up with
a lot of such responses over the years.

With this rather retro mostly-operational view of "what is lisp" we
can make perfect sense of statements like "Dylan is sorta-kinda-lisp
but diverges in these ways ...." or "Emacs lisp started out as a
really minimalist lisp and remains a kind of strange dialect -- but it
works _fairly_ well for it's specific applications and it's intersting
to examine why that is" or "delta(Python,lisp) keeps shrinking but
it's not clear that Python really converges on lisp".

And I can say "Hey, I'm interested in making a lisp that is a lisp-1
and _generally_ very Scheme-like; I'm not entirely sure I want (eq?
#f '()) to be false; I'm not entirely sure I really want call/cc."
And having said that, in c.l.l. no less, I might have a discussion
about why I'm leaning in those directions without having the majority
replies being a rightous forensices from Common Lisp bigwigs.

There's a heck of a lot of verbal cleverness on this list.  It seems
to be a point of pride and, indeed, personally I think it's kind of
neat.  But it's also pretty tedious after a while.  Too often it
supresses, rather than enhances, actual interesting discussion.

-t

From: Daniel Barlow
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <87ad9puxwj.fsf@noetbook.telent.net>
····@emf.emf.net (Tom Lord) writes:
> As a straw-man: a lisp is any language implementation which includes a
> run time system with some recognizably lispish types (cons pairs,
[...]

As straw men go, that one looks reasonably well built (or did before I
truncated it; please read the original before replying to this post if
you want to respond on this point).

I'd add something, though: IMO, a lisp is not _just_ a language
implementation; it's also an environment - or at least, shapes and is
shaped by the environment.  For example, supppose a language
implementation that was otherwise Lispish, but didn't allow function
redefinition, or that allowed it but without affecting old callers.
It sounds like a small divergence, but it radically affects the
environment, because it reduces the utility of interacting with the
system by about 97%.

Now, I imagine that some time in the distant past people have written
lisp implementations that run in batch mode or need input on punched
cards, or for some other similar unfriendly high-latency environment,
and I daresay they did this because they had to and we shouldn't
retrospectively deny them the "lisp" tag, but I'm also quite definite
that if anyone were to ask me about the Lispiness of some new or
proposed language, they would get points deducted for doing things
that break it for interactive use.

All hail macroexpand-1



-dan

-- 

   http://www.cliki.net/ - Link farm for free CL-on-Unix resources 
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F52A6B2.9000805@nyc.rr.com>
Daniel Barlow wrote:
> I'd add something, though: IMO, a lisp is not _just_ a language
> implementation; it's also an environment - or at least, shapes and is
> shaped by the environment. 

I actually led with this point in my second go-round presenting Lisp to 
a local Linux clan. I talked about how working in Lisp is like Fantastic 
Voyage; we're poking around inside the beast, if you will. And using the 
full power of the language to do so.


-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Larry Clapp
Subject: "The full power of Lisp"; WAS: why Common Lisp is not a lisp
Date: 
Message-ID: <slrnbl6l0s.ca7.larry@theclapp.ddts.net>
In article <················@nyc.rr.com>, Kenny Tilton wrote:
> Daniel Barlow wrote:
>> I'd add something, though: IMO, a lisp is not _just_ a language
>> implementation; it's also an environment - or at least, shapes and
>> is shaped by the environment. 
> 
> I actually led with this point in my second go-round presenting Lisp
> to a local Linux clan. I talked about how working in Lisp is like
> Fantastic Voyage; we're poking around inside the beast, if you will.
> And using the full power of the language to do so.

(begin-tangent)

I've seen this statement ("using the full power of [Lisp]") a lot.  In
my (limited) experience, it seems to show up most often in
advocacy-type discussions about the incredible usefulness of macros.
"We can write code to write code, and use the full power of Lisp to do
so."  It makes me curious -- how often has the person using the phrase
fully demonstrated Lisp's power to his audience, before showing them
macros?

As an example, if you created a new C pre-processor that did macros in
a Lispier way (i.e. manipulated C code with C), and told me "and you
can use the full power of C to do it", well, knowing a little C, this
would not in-and-of-itself impress me.  In the same way, if I knew a
lot of C but not any Lisp, and you told me about macros and talked
about "the full power of Lisp", but hadn't demonstrated said power in
other examples, I think I'd tend to discount such statements as
relatively meaningless.

Just a thought for you advocates out there ...

-- 
Larry Clapp / ·····@theclapp.org
Use Lisp from Vim: VILisp: http://vim.sourceforge.net/script.php?script_id=221
From: Kenny Tilton
Subject: Re: "The full power of Lisp"; WAS: why Common Lisp is not a lisp
Date: 
Message-ID: <3F537DB9.7040607@nyc.rr.com>
Larry Clapp wrote:
> In article <················@nyc.rr.com>, Kenny Tilton wrote:
> 
>>Daniel Barlow wrote:
>>
>>>I'd add something, though: IMO, a lisp is not _just_ a language
>>>implementation; it's also an environment - or at least, shapes and
>>>is shaped by the environment. 
>>
>>I actually led with this point in my second go-round presenting Lisp
>>to a local Linux clan. I talked about how working in Lisp is like
>>Fantastic Voyage; we're poking around inside the beast, if you will.
>>And using the full power of the language to do so.
> 
> 
> (begin-tangent)
> 
> I've seen this statement ("using the full power of [Lisp]") a lot.  In
> my (limited) experience, it seems to show up most often in
> advocacy-type discussions about the incredible usefulness of macros.
> "We can write code to write code, and use the full power of Lisp to do
> so."  It makes me curious -- how often has the person using the phrase
> fully demonstrated Lisp's power to his audience, before showing them
> macros?

Doesn't matter. The essential point in this context is that lisp macros 
are not just token replacement. Similarly, because I have done 
proof-of-concept Cells ports in Java, Python, and C++, when I talk about 
rules being expressed with "the full power of..." I finish with "..the 
host HLL".

> 
> As an example, if you created a new C pre-processor that did macros in
> a Lispier way (i.e. manipulated C code with C), and told me "and you
> can use the full power of C to do it", well, knowing a little C, this
> would not in-and-of-itself impress me.

Yeah, but a C-only programmer would fall to the ground trembling in awe. 
And don't forget Norvig saying Python did not need macros because they 
had eval and regexp. as if.

During my talk in which I reinvented half of Cells, someone watching 
closely said, "I could do those macros in C". I looked, and sure enough 
the few I had done simply used token substitution. So then I tossed off 
"defmodel Lite" a macro which expanded almost directly into defclass, 
then wrote wrapper methods and special cell macros for each slot.

Now for my point: I didn't use anything fancier than mapcar and 
destructuring-bind, but the bloke still said, Aha! OK, d-b is pretty 
cool, but to him the key thing was simply stepping above substitution 
and using the host language to write code.


-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Matthieu Villeneuve
Subject: Re: "The full power of Lisp"; WAS: why Common Lisp is not a lisp
Date: 
Message-ID: <3f536a8f$0$26380$626a54ce@news.free.fr>
"Larry Clapp" <·····@theclapp.org> wrote in message
·························@theclapp.ddts.net...
> I've seen this statement ("using the full power of [Lisp]") a lot.  In
> my (limited) experience, it seems to show up most often in
> advocacy-type discussions about the incredible usefulness of macros.
> "We can write code to write code, and use the full power of Lisp to do
> so."  It makes me curious -- how often has the person using the phrase
> fully demonstrated Lisp's power to his audience, before showing them
> macros?
>
> As an example, if you created a new C pre-processor that did macros in
> a Lispier way (i.e. manipulated C code with C), and told me "and you
> can use the full power of C to do it", well, knowing a little C, this
> would not in-and-of-itself impress me.  In the same way, if I knew a
> lot of C but not any Lisp, and you told me about macros and talked
> about "the full power of Lisp", but hadn't demonstrated said power in
> other examples, I think I'd tend to discount such statements as
> relatively meaningless.

Well, I agree with that, but I think the main reason is that Lisp is
much better at manipulating lists (a natural way to represent Lisp code)
than C is at manipulating, say, strings. So writing macros using such a
C preprocessor would likely be quite painful.

One could imagine a preprocessor that uses a more elegant syntax for
macros only, and generates plain C from them, but that would be designing
a completely different language, compiling to C...


--
Matthieu Villeneuve
From: Larry Clapp
Subject: Re: "The full power of Lisp"; WAS: why Common Lisp is not a lisp
Date: 
Message-ID: <slrnbl71tr.ca7.larry@theclapp.ddts.net>
In article <·························@news.free.fr>, Matthieu
Villeneuve wrote:
> "Larry Clapp" <·····@theclapp.org> wrote in message
> ·························@theclapp.ddts.net...
>> I've seen this statement ("using the full power of [Lisp]") a lot.
>> In my (limited) experience, it seems to show up most often in
>> advocacy-type discussions about the incredible usefulness of
>> macros.  "We can write code to write code, and use the full power
>> of Lisp to do so."  It makes me curious -- how often has the person
>> using the phrase fully demonstrated Lisp's power to his audience,
>> before showing them macros?
>>
>> As an example, if you created a new C pre-processor that did macros
>> in a Lispier way (i.e. manipulated C code with C), and told me "and
>> you can use the full power of C to do it", well, knowing a little
>> C, this would not in-and-of-itself impress me.  In the same way, if
>> I knew a lot of C but not any Lisp, and you told me about macros
>> and talked about "the full power of Lisp", but hadn't demonstrated
>> said power in other examples, I think I'd tend to discount such
>> statements as relatively meaningless.
> 
> Well, I agree with that, but I think the main reason is that Lisp is
> much better at manipulating lists (a natural way to represent Lisp
> code) than C is at manipulating, say, strings. So writing macros
> using such a C preprocessor would likely be quite painful.

Yes, exactly.  Thus my point (and my only point): if you say to a C
programmer that you can write code to write code "with the full power
of Lisp", without having demonstrated some of that power, your
statement probably won't have the desired impact.

I guess I really want to say: If you want to do Lisp advocacy, and in
particular talk about the power of macros, *show* some of the power of
Lisp instead of talking about it.  That's all.

-- L
From: Marco Gidde
Subject: Re: "The full power of Lisp"; WAS: why Common Lisp is not a lisp
Date: 
Message-ID: <m3znho4g0a.fsf@tristan.br-automation.de>
"Matthieu Villeneuve" <········@nospam.matthieu-villeneuve.net> writes:

> "Larry Clapp" <·····@theclapp.org> wrote in message
> ·························@theclapp.ddts.net...
> > I've seen this statement ("using the full power of [Lisp]") a lot.  In
> > my (limited) experience, it seems to show up most often in
> > advocacy-type discussions about the incredible usefulness of macros.
> > "We can write code to write code, and use the full power of Lisp to do
> > so."  It makes me curious -- how often has the person using the phrase
> > fully demonstrated Lisp's power to his audience, before showing them
> > macros?
> >
> > As an example, if you created a new C pre-processor that did macros in
> > a Lispier way (i.e. manipulated C code with C), and told me "and you
> > can use the full power of C to do it", well, knowing a little C, this
> > would not in-and-of-itself impress me.  In the same way, if I knew a
> > lot of C but not any Lisp, and you told me about macros and talked
> > about "the full power of Lisp", but hadn't demonstrated said power in
> > other examples, I think I'd tend to discount such statements as
> > relatively meaningless.
> 
> Well, I agree with that, but I think the main reason is that Lisp is
> much better at manipulating lists (a natural way to represent Lisp code)
> than C is at manipulating, say, strings. So writing macros using such a
> C preprocessor would likely be quite painful.
> 
> One could imagine a preprocessor that uses a more elegant syntax for
> macros only, and generates plain C from them, but that would be designing
> a completely different language, compiling to C...

I think it should be possible to write such a preprocessor, but the
syntax is not the main problem. To make these new preprocessor macros
comparable to lisp macros, it must at least be possible to call
functions from the libc at compile time! And that is very different
from even the most sophisticated kind of text substition.


Regards,

Marco Gidde
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F52AB1C.4050200@nyc.rr.com>
Tom Lord wrote:
> .. it's naive to respond to
> Common Lisp by saying things like "But Scheme is so much _cleaner_ --
> why don't you agree that Common Lisp sucks?".   We can acknowledge
> that it has been the experience of people deeply involved with Common
> Lisp that, unreasonable as it may sound, they have had to put up with
> a lot of such responses over the years.

Can anyone confirm this? Is that why some Lispniks have a cow when 
Scheme or even recursion gets mentioned?

Is Scheme seen as an insurgent language? Steele and Sussman traitors? 
This is starting to make some sense.

If so, perhaps these Lispniks should take consolation from Scheme being 
a failed experiment and just lighten up. Steele and Sussman were wrong. 
They created something small, yes, and with appeal to some who go for 
the short spec, but that is as far as it went. The CL crowd voted with 
its feet and stood on the mother ship. Game over.


-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Rayiner Hashem
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <a3995c0d.0308312100.5f38b22a@posting.google.com>
> If so, perhaps these Lispniks should take consolation from Scheme being 
> a failed experiment and just lighten up. Steele and Sussman were wrong. 
> They created something small, yes, and with appeal to some who go for 
> the short spec
And people wonder why the language wars don't stop. We have a brain
for a reason. It filters thoughts that pop up at the knee before they
get to the mouth (or fingers :)

Anyway, it would be improper to say that Steele and Sussman were
wrong. Maybe they didn't achieve what they set out to do, but as a
small, elegant academic language, scheme fits the bill quite well.
Further, in the domain of language theory, these small elegant
languages, unburdened by the baggage of utility, are critical in
driving the field continually forward.
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F535016.4030101@nyc.rr.com>
Rayiner Hashem wrote:
>>If so, perhaps these Lispniks should take consolation from Scheme being 
>>a failed experiment and just lighten up. Steele and Sussman were wrong. 
>>They created something small, yes, and with appeal to some who go for 
>>the short spec
> 
> And people wonder why the language wars don't stop. We have a brain
> for a reason. It filters thoughts that pop up at the knee before they
> get to the mouth (or fingers :)

I am sorry. Did you think I was trying to make peace? You have not been 
paying attention. It is the other folks in this thread who are trying to 
start up an ecumenical council to unite Scheme and Lisp.

Perhaps I was too subtle; I mean precisely to go on the offensive. 
Apparently a few lispniks are on their heels over this kind of bullshit 
from the comp.lang.scheme FAQ:

"Advocates of Scheme often find it amusing that the entire Scheme 
standard is shorter than the index to Guy Steele's "Common Lisp: the 
Language, 2nd Edition".

Apparently these geniuses think it matters one whit whether the spec in 
its entirety can be carved on the head of a pin. Well, jeez, what was 
wrong with the 6502 assembler instruction set?!!

In the next breath they concede:

"Scheme is often used in computer science curricula and programming
language research... Common Lisp is often used for
real world programming..."

Surprise, surprise! You want to know why your toy language does not 
scale? <sigh>

> 
> Anyway, it would be improper to say that Steele and Sussman were
> wrong. Maybe they didn't achieve what they set out to do...

That's a nice way to say "wrong". They did achieve splitting the 
community, so no one camp has critical mass. All those students learning 
scheme would be learning Common Lisp if their hubris had not impelled 
them to try to out-do Lisp. And there is no way they meant to split the 
baby in half, so clearly they wanted it for themselves. Lawdy, Steele 
tried again with his Constraints language and with Java. He shoulda 
stood on first. Or created Perl. Scheme is a failed insurrection. CL is 
prepared to declare an amnesty.

Schemers! Lay down your arms and return to your multiple namespaces. 
This amnesty expires when we prevail anyway without your numbers.

:)


-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Anton van Straaten
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <ipL4b.17542$Om1.8451@newsread2.news.atl.earthlink.net>
Kenny Tilton wrote:
> All those students learning Scheme would be learning
> Common Lisp if their hubris had not impelled them to
> try to out-do [Common] Lisp.

Doubtful.  Students would probably be taught using ML or Haskell - in fact,
those languages are already commonly used for the purpose, for many of the
same kinds of reasons.

Understandably, academic language research and teaching has moved in the
direction of languages whose formal descriptions are suitably tractable -
which, as you may have noticed I enjoy pointing out, is what McCarthy was
originally trying to create with Lisp.

Imagining that somehow, if Scheme simply went away or hadn't existed in the
first place, that academia would focus instead on Common Lisp, is wishful
thinking at best.  CL and Scheme address different domains, even if there's
an area of overlap (of arguable size).  Their similarities could be a
strength, though, if you allow it.

Anton

P.S. Nice troll!
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F5386EC.9010201@nyc.rr.com>
Anton van Straaten wrote:
> Kenny Tilton wrote:
> 
>>All those students learning Scheme would be learning
>>Common Lisp if their hubris had not impelled them to
>>try to out-do [Common] Lisp.
> 
> 
> Doubtful.  Students would probably be taught using ML or Haskell - in fact,
> those languages are already commonly used for the purpose, for many of the
> same kinds of reasons.

Lawdy, all I hear are about are schools where students riot if you try 
to teach them anything but java.

> 
> Understandably, academic language research and teaching has moved in the
> direction of languages whose formal descriptions are suitably tractable -
> which, as you may have noticed I enjoy pointing out, is what McCarthy was
> originally trying to create with Lisp.

Yes, and then the language got used. And when it got used people 
naturally started adding in real-world stuff. And then they all got 
together and standardized on all the real world stuff. Without losing 
the groovy formal stuff.

Scheme never got used enough for steps two and three to happen, and what 
would be the point? CL is scheme plus steps two and three. So Schemers 
dig in their heels forever marginalized, consoling themselves with their 
tiny little specs.*

> 
> Imagining that somehow, if Scheme simply went away or hadn't existed in the
> first place, that academia would focus instead on Common Lisp, is wishful
> thinking at best.

We'll get them when Java collapses under its own weight. The problem may 
be that Java and XML may start an Ice Age in IT development that will 
take a decade for Lisp to thaw. What will not help is a language that 
makes you write your own object system.

> P.S. Nice troll!

This is war. No fraternizing.

:)


-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
* "Isn't that cute an extra belly button
You need to put your pants back on honey "
                                  -- Salt N Pepa
From: Rayiner Hashem
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <a3995c0d.0309011409.525f78fc@posting.google.com>
> Lawdy, all I hear are about are schools where students riot if you try 
> to teach them anything but java.
There are some schools like that, yes, but the ones on the cutting
edge of language design are not like that. I remember that in my
*high-school* you could take C++, Prolog, and Lisp before you
graduated. In our University's CS program, they teach you Scheme,
Java, C, Smalltalk, and Python by the time you get halfway through
your second year.

> Yes, and then the language got used. And when it got used people 
> naturally started adding in real-world stuff. And then they all got 
> together and standardized on all the real world stuff. Without losing 
> the groovy formal stuff.
Less is more. People teaching language theory (where Scheme is largely
taught) aren't interested in direct practical usage. They're
interested in something that's good as a teaching and a research
platform. Something that you can easily remember the entire spec to
fits that bill much better than something with a 1000 page spec. Plus,
CL doesn't have a lot of the "groovy formal stuff" that has come out
in the last few years. Its type system isn't (as far as I can see)
based on any rigorous mathematical theory (like the type systems in
ML, Haskell, etc) and it has lots of features (exceptions) that are
useful, but don't map to any central flow-control paradigms.

> We'll get them when Java collapses under its own weight. The problem may 
> be that Java and XML may start an Ice Age in IT development that will 
> take a decade for Lisp to thaw. What will not help is a language that 
> makes you write your own object system.
If you want to research object systems, you'd write your own anyway.
If you don't, you'd use something off the shelf. Many of the major
Schemes come with pre-canned object systems. Also, I'm curious --- how
integral do you really think Scheme *is* to academics? Its usually a
first year teaching language, designed to teach the basic theories of
computation. When you go further along the line, they teach you all
sorts of other languages to introduce you to different computing
paradigms. Finally, once you get heavily into language theory, you're
usually working with something like ML, Haskell, or one of the
professor's pet languages.

> This is war. No fraternizing.
Only in your head.
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F542E66.10309@nyc.rr.com>
Rayiner Hashem wrote:
>>Lawdy, all I hear are about are schools where students riot if you try 
>>to teach them anything but java.
> 
> There are some schools like that, yes, but the ones on the cutting
> edge of language design are not like that.

To both you and Anton, sorry, but give me some credit. I would not bring 
this up if we were discussing Bubba's Drive-Thru Institute of 
Technology. Look it up on Google if you don't have the last three years 
of c.l.l. memorized like I do. It was a top school, I forget which. 
Search on both "riot" and "Java".

> ...In our University's CS program, they teach you Scheme,
> Java, C, Smalltalk, and Python by the time you get halfway through
> your second year.

Sounds like a trade school to me. Or are you going to give us some 
different-laguages-for-different-purposes moral relativistic crap?

> Less is more. People teaching language theory (where Scheme is largely
> taught) aren't interested in direct practical usage.

<sigh> What exactly do you think languages are for? I can just see these 
same people working on abstract farm machinery. You can learn so much 
more about tilling if you don't get all bogged down in dirt!

yes, that's the thing. let's have a language whose spec fits on the head 
of a pin. no, you wouldn't want to do anything with it, that would 
totally ruin the pretty little spec. hang on, do we really need that 
"if" statement? where are those scissors...

> ...  Something that you can easily remember the entire spec to

Now there's a language design principle. Another good one is that you 
can sing it to the tune of Camptown Races.

> fits that bill much better than something with a 1000 page spec.

Oh yes, I much prefer reinventing all the code documented by those 1000 
pages. God forbid my soccer client should ever take a shot on goal, I'm 
busy coding up my own trig functions so i could do the math to calculate 
the angle of my shot if I ever got done reinventing those 1000 pages, 
which I won't, so why the hell am I reinventing these trig functions?!

aflac!!!!!!

> ...Its type system isn't (as far as I can see)
> based on any rigorous mathematical theory

Well tsk frickin tsk.

> ML, Haskell, etc) and it has lots of features (exceptions) that are
> useful, but don't map to any central flow-control paradigms.

I have all this astonishing CL-code functionality over here and the type 
system i am using doesn't even rigorously mathematically map to any 
central flow-control paradigm?! I must be even better than I tell people 
I am! Gotta update that resume...

> If you want to research object systems, you'd write your own anyway.

Using CLOS and an implementation that supports the MOP? <sigh> Hell, 
Cells extend OO to deliver on the grail of object re-use with nothing 
more than unhygienic macros.

Oh, well, i guess this "gee, it's good for research" consolation prize 
to the Scheme insurrectionists is tantamount to an admission of defeat. 
We accept.

>>This is war. No fraternizing.
> 
> Only in your head.

That's more like it.

:)

-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Paolo Amoroso
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <87k78rwq85.fsf@plato.moon.paoloamoroso.it>
Kenny Tilton writes:

> yes, that's the thing. let's have a language whose spec fits on the
> head of a pin. no, you wouldn't want to do anything with it, that

Given the advances in the field of microelectronics, I guess it may be
already possible to put the Common Lisp spec on the head of a pin.


Paolo
-- 
Paolo Amoroso <·······@mclink.it>
From: Rayiner Hashem
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <a3995c0d.0309021200.355e581@posting.google.com>
> Sounds like a trade school to me. Or are you going to give us some 
> different-laguages-for-different-purposes moral relativistic crap?
Right. Because we all know how popular Scheme and Smalltalk are in the
commercial world... These languages are used because they are simple
to learn, simple to teach, and have a wide body of literature and
learning materials already available. Further, they each demonstrate
different computing paradigms in a relatively pure manner:

1) Scheme: First year language (freshman undergraduate) used to teach
basic computing paradigms. Has very little cruft to get in the way.
Also useful for shock value. Its different from languages that people
may know already (like BASIC) so its useful for teaching ideas without
past experience getting in the way.

2) Java: Its a very useful teaching language. Its has lots of
libraries available and good documentation. Because of the easily
accessible libraries, students can get started on some "interesting"
programs (read: games) that provide something similar to the software
they see normally used on computers. CL might be a good fit here, as a
powerful language with a wide range of capabilities, but hey, you
gotta throw a bone to the commercial market somewhere, right?

3) Smalltalk: Useful for teaching OOP because its pure OOP, without
anything else to get in the way.

4) C: Everybody should know C. It gives a very good understanding of
how machines work at the lowest levels. The first C assignment in our
particular course has students wade through SPARC assembly trying to
figure out what each statement does.

I don't really know what else they use at our school, but I know that
even MIT and Caltech push languages as varied as Ocaml, Scheme, and
Eiffel, depending on a professor's particular bent.

> <sigh> What exactly do you think languages are for?
It really depends on what you want to do. For some people, a language
is a way to reach a goal. For others, it is the goal. Your statement
is like asking, "what is English for?"

> same people working on abstract farm machinery. You can learn so much 
> more about tilling if you don't get all bogged down in dirt!
Nice imagery, but unfortunately, it works better for my point than
yours. If you just want to know the theoretics of tilling, there is no
need for you to move dirt around. Similarly, if you just want the
theory, there is no need for all the functionality of CL.

> Now there's a language design principle. Another good one is that you 
> can sing it to the tune of Camptown Races.
That smaller (and simpler) is better is a well established design
philosophy. If you have a problem with that, then your opposition is a
whole lot bigger than the Scheme community.

> Oh yes, I much prefer reinventing all the code documented by those 1000 
> pages.
That's a really dumb argument that just keeps popping up. Nobody is
reinventing the code in those 1000 pages of specs, because they don't
need it. Have you ever been through a CS course? The concentration in
the first few years (where Scheme is mainly taught) is not creating
useful programs. Its teaching theory. Students in that phase are
learning about data structures and algorithms --- they don't need any
library support beyond a simple function to print strings and numbers!

> Well tsk frickin tsk.
You might not care, but if you're studying type theory you do! 

> 
> > ML, Haskell, etc) and it has lots of features (exceptions) that are
> > useful, but don't map to any central flow-control paradigms.
> 
> I have all this astonishing CL-code functionality over here and the type 
> system i am using doesn't even rigorously mathematically map to any 
> central flow-control paradigm?! I must be even better than I tell people 
> I am! Gotta update that resume...
It's not about functionality or your resume or anything of the sort.
The goal isn't to pop out efficient little code monkeys as fast as
possible. Its to create computer *scientists*. You sound like a
practitioner who can't see the usefulness of those "stupid academics."
We all know where thinking like that gets you.

Look, if all you want to do is pound your little hammer all day and
generate "real-world" programs, than go ahead. If you believe that CL
is the be-all end-all of computer languages, and that there is nowhere
else to go, and that the only useful thing left is to sit down and
code web portable back-ends, then fine. But thankfully, nobody is
going to stop trying to push the field of computer science forward
just because little Kenny thinks that he has no use for a better
hammer.
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F55157E.2050006@nyc.rr.com>
Please stop trying to elevate the tone of this food fight with 
well-reasoned arguments.

>>same people working on abstract farm machinery. You can learn so much 
>>more about tilling if you don't get all bogged down in dirt!
> 
> Nice imagery, but unfortunately, it works better for my point than
> yours. If you just want to know the theoretics of tilling, there is no
> need for you to move dirt around. 

What do I do instead, right a program to simulate dirt?!

>>Now there's a language design principle. Another good one is that you 
>>can sing it to the tune of Camptown Races.
> 
> That smaller (and simpler) is better is a well established design
> philosophy.

I should have said "design goal".

>>Oh yes, I much prefer reinventing all the code documented by those 1000 
>>pages.
> 
> That's a really dumb argument that just keeps popping up. Nobody is
> reinventing the code in those 1000 pages of specs, because they don't
> need it. Have you ever been through a CS course? 

Does "Fortran for Economists" count?


> The concentration in
> the first few years (where Scheme is mainly taught) is not creating
> useful programs. Its teaching theory.

Those who can't do, teach. Badly. I am reminded of the New Math, which 
made Principia Mathematica (?) a first-grade textbook. Biiggggg mistake. 
The logical does not determine the pedagogical.

> 
> It's not about functionality or your resume or anything of the sort.
> The goal isn't to pop out efficient little code monkeys as fast as
> possible. 

Eeeep! I resent that. I demand a banana.

>.. You sound like a
> practitioner who can't see the usefulness of those "stupid academics."

Anton won't let me get away with that. He keeps pointing out something I 
myself get a huge kick out of, the theoretical stuff tapped by McCarthy 
to create Lisp. But then McCarthy ended up having to create his own 
language because he could not sell some committee on COND. Interesting. 
Almost on day one McCarthey was growing the spec in favor of 
practicality. Hmmm, I hear Python will get a case statement over GvR's 
dead body. How did r5rs end up with that code bloat?

> ...  nobody is
> going to stop trying to push the field of computer science forward
> just because little Kenny thinks that he has no use for a better
> hammer.

Yeah, well little Kenny has made constraints work where Steele and an 
ivory tower full of academics went flat on their faces, because they 
lost sight of getting useful things done. They sniffed at one-way, 
linear, dataflow constraints as trivial and went off in quest of 
multi-way constraints. Last seen wandering hallways late at night 
muttering about walkabout strengths. Never heard from again, though 
rumor has it Steele found work as a tech writer for Sun.

:)

-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Anton van Straaten
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <gPa5b.23117$Om1.22892@newsread2.news.atl.earthlink.net>
Kenny Tilton wrote:
> >.. You sound like a
> > practitioner who can't see the usefulness of those "stupid academics."
>
> Anton won't let me get away with that. He keeps pointing out something I
> myself get a huge kick out of, the theoretical stuff tapped by McCarthy
> to create Lisp.

Heh.  I see a crack in the armor here.  Can I come to the next LispNYC
meeting and give a presentation on elementary lambda calculus and its
historical & technical connection to Lisp?  ;)

> But then McCarthy ended up having to create his own
> language because he could not sell some committee on COND.
> Interesting. Almost on day one McCarthey was growing the
> spec in favor of practicality.

Was it McCarthy, or the brand-new Lisp community, already feisty and ready
to ignore a fuddy-duddy theoretician?  There's some nice historical summary
here:
http://www8.informatik.uni-erlangen.de/html/lisp-enter.html , and in
particular on this page:
http://www8.informatik.uni-erlangen.de/html/lisp/mcc91.html .

Here's a quote from the last link, from shortly after the heading
"Theoretical Interpreters":

"During this research, McCarthy felt uneasy with the machine dependent names
of the selector functions (additionally, 'cons' was not regarded as good
enough) and he tried to change that [to] 'first' instead of 'car', 'rest'
instead of 'cdr', 'combine' instead of 'cons'.  Programmers and students
were surprised by McCarthy's new language, but nobody took up his proposal
and after some days [!] he dropped it. The LISP community was already more
powerful [than] the designer."

> Hmmm, I hear Python will get a case statement over GvR's
> dead body. How did r5rs end up with that code bloat?

You're talking about the bit written in "English", which is a really poor
language for talking about computer languages, and often involves excessive
padding.  The R5RS formal semantics only defines 'if'!

> Yeah, well little Kenny has made constraints work where Steele
> and an ivory tower full of academics went flat on their faces,
> because they lost sight of getting useful things done. They
> sniffed at one-way, linear, dataflow constraints as trivial and
> went off in quest of multi-way constraints.

Sorry to be all serious in the midst of a food fight (a personality flaw),
but good academics tend not to study things that they don't consider
challenging (since "good" academics are by definition looking for something
more than the "least publishable increment").  If something isn't
challenging enough, it implies we don't need the good academics working on
them - good practitioners can probably deal with it.  That's not to imply a
hierarchy between academia and practice, but rather that the academics study
things that often have a longer term payoff (if any!), which practitioners
may not be able to afford or have an incentive to spend time on.

There are successes and failures and missed opportunities on both sides.  As
a practitioner myself, I want to learn from all of that, on both sides.
Call me greedy.

Anton
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F55A566.3020808@nyc.rr.com>
Anton van Straaten wrote:
> Kenny Tilton wrote:
> 
>>>.. You sound like a
>>>practitioner who can't see the usefulness of those "stupid academics."
>>
>>Anton won't let me get away with that. He keeps pointing out something I
>>myself get a huge kick out of, the theoretical stuff tapped by McCarthy
>>to create Lisp.
> 
> 
> Heh.  I see a crack in the armor here.

i think you misunderstand something. I have known for a quite a long 
time about the theoretical origins of Lisp. And I have long maintained 
that lisp has survived and now is prevailing precisely becuase of the 
theoreticla origins! Striking out with such a friendly audience is very 
bad news for your toy language.

>  Can I come to the next LispNYC
> meeting and give a presentation on elementary lambda calculus and its
> historical & technical connection to Lisp?  ;)

Sounds good.

> Was it McCarthy, or the brand-new Lisp community, already feisty and ready
> to ignore a fuddy-duddy theoretician?  There's some nice historical summary
> here:

Do me a favor, read the stuff you are referencing, OK?:

"McCarthy became unhappy with the language elements for conditional 
actions. The "arithmetical IF", with its narrow restriction to 
comparison with 0 and the constraint to do conditional function IF with 
three arguments. It delivered the value of the second or third argument 
if the first resulted in the value 1 or 0, respectively. This enabled a 
clean function-oriented programming, but was neither very efficient nor 
as nice as it should have been."

Does that sound purist-theoretical to you? Give it up, you can't go 
upside my head anymore with McCarthey as Mr Abstraction. The dude was 
all about practicality. i would bet you dollars to donuts that we went 
with the theoretical foundation purely as a practical matter; if you are 
  a mathematician, hopefully you think good math makes good engineering. 
One thing for sure is this was not theory for theory's sake, and that is 
exactly how scheme trivialized itself the day it was conceived.

> "During this research, McCarthy felt uneasy with the machine dependent names
> of the selector functions (additionally, 'cons' was not regarded as good
> enough) and he tried to change that [to] 'first' instead of 'car', 'rest'
> instead of 'cdr', 'combine' instead of 'cons'.  Programmers and students
> were surprised by McCarthy's new language, but nobody took up his proposal
> and after some days [!] he dropped it. The LISP community was already more
> powerful [than] the designer."

if mccarthy was as abstract as schemers, he would not give a rat's ass 
what a function was called. He was so pragmatic that he was years ahead 
of his time, decades even: clear names are vital to software development.

> You're talking about the bit written in "English", which is a really poor
> language for talking about computer languages, and often involves excessive
> padding.  The R5RS formal semantics only defines 'if'!

I'll take your word for it. But I tried. I followed the link to RSR5 
from scheme.org and found "cond". Are you saying the formal semantics 
are a subset of rsr5 and I had strayed into -- what? the bit where they 
tried to fix as fast as possible the consequence of a scrimshaw language 
design goal?

> 
> 
>>Yeah, well little Kenny has made constraints work where Steele
>>and an ivory tower full of academics went flat on their faces,
>>because they lost sight of getting useful things done. They
>>sniffed at one-way, linear, dataflow constraints as trivial and
>>went off in quest of multi-way constraints.
> 
> 
> Sorry to be all serious in the midst of a food fight (a personality flaw),
> but good academics tend not to study things that they don't consider
> challenging ...

Nice spin. Can you get my cold fusion project a few million with some of 
that puffery? That seems damn challenging. Hot fusion not being far 
behinf. The only thing academics care about is government grants. The 
whole neural net research programme got quashed for twenty years by a 
superficial paper denouncing perceptrons, by a couple of guys trying to 
protect the funding stream of their doomed attempts to compute 
consciousness.

If the multiway crowd had had a clue they would have worked out in a 
month or two that they had lost their way and retreated to simple 
one-way constraints, where they would have discovered extraordinary 
productivity gains. Instead they just got fancier and fancier -- 
walkabout strength! that's the ticket!! Not. But the longer they dragged 
it out the more financing they got, so they did not notice they had 
missed a silver bullet. And now they have moved on and abandoned 
constraints, leaving a lowly monkey to bang it all out. I am sure they 
have moved onto something more challenging.


-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Anton van Straaten
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <gxm5b.17969$EW1.17678@newsread1.news.atl.earthlink.net>
"Kenny Tilton" wrote:
> i think you misunderstand something. I have known for a quite a long
> time about the theoretical origins of Lisp. And I have long maintained
> that lisp has survived and now is prevailing precisely becuase of the
> theoreticla origins! Striking out with such a friendly audience is very
> bad news for your toy language.

Afaict, the striking out, such as it is, is primarily because of people with
grudges, which in turn has led to deliberate avoidance of communication and
ultimately to propaganda and disinformation (on both sides) worthy of the
Cold War.  We're busy re-enacting a Usenet version of the Cold War,
Israel/Palestine, and/or Old vs. New Iraq, all while watching these same
events on TV and thinking how much more civilized we are.  No doubt, the
grudgers will pass their grudges onto their children, so the battles can
continue to the umpteenth generation.

> > Was it McCarthy, or the brand-new Lisp community, already feisty and
ready
> > to ignore a fuddy-duddy theoretician?  There's some nice historical
summary
> > here:
>
> Do me a favor, read the stuff you are referencing, OK?:
>
> "McCarthy became unhappy with the language elements for conditional
> actions. The "arithmetical IF", with its narrow restriction to
> comparison with 0 and the constraint to do conditional function IF with
> three arguments. It delivered the value of the second or third argument
> if the first resulted in the value 1 or 0, respectively. This enabled a
> clean function-oriented programming, but was neither very efficient nor
> as nice as it should have been."
>
> Does that sound purist-theoretical to you?

Why did you stop the quote there?  Let's complete it:

  "Because of the call-by-reference parameter passing mechanism of FORTRAN
all arguments are evaluated, wheras only two are actually needed. This
unused computation puzzled McCarthy and he explored the problem thoroughly.
In the end, he developed the idea of conditional expressions.  The special
feature of this invention is the possibility of composing conditional
expressions and restricting the computation to those really needed to get
the value of the whole expression. In contrast to an IF-statement and an
IF-function, one obtains an increase in expressive power and efficiency -
which leads to completely new applications."

This was a major theoretical advance!  The fact that it was combined with a
practical advance doesn't detract from its theoretical importance.

> Give it up, you can't go upside my head anymore
> with McCarthey as Mr Abstraction. The dude was
> all about practicality.

My examples about McCarthy have been connected to the point that academic
concerns drove the development of the language - including concerns about
referential transparency and developing a theoretical language for the
expression of computations, more elegant than Turing machines.  Your example
isn't a counter-example - in fact, I'll claim it as an example of how
McCarthy applied his theoretical insight to a practical problem and solved
it.

> One thing for sure is this was not theory for theory's sake

In some cases.

> and that is exactly how scheme trivialized itself the day it was
conceived.

The gospel according to Kenny?

> > "During this research, McCarthy felt uneasy with the machine dependent
names
> > of the selector functions (additionally, 'cons' was not regarded as good
> > enough) and he tried to change that [to] 'first' instead of 'car',
'rest'
> > instead of 'cdr', 'combine' instead of 'cons'.  Programmers and students
> > were surprised by McCarthy's new language, but nobody took up his
proposal
> > and after some days [!] he dropped it. The LISP community was already
more
> > powerful [than] the designer."
>
> if mccarthy was as abstract as schemers, he would not give a rat's ass
> what a function was called.  He was so pragmatic that he was years ahead
> of his time, decades even: clear names are vital to software development.

He didn't want names that had to do with machines, contaminating his math.
Scheme and CL, like all languages, face a similar issue - you don't want
external-facing names to reflect implementation concerns that should be
hidden.  IOW, abstraction.  I'm afraid your examples are not illustrating
the points you think they are.

> > You're talking about the bit written in "English", which is a really
poor
> > language for talking about computer languages, and often involves
excessive
> > padding.  The R5RS formal semantics only defines 'if'!
>
> I'll take your word for it. But I tried. I followed the link to RSR5
> from scheme.org and found "cond". Are you saying the formal semantics
> are a subset of rsr5 and I had strayed into -- what? the bit where they
> tried to fix as fast as possible the consequence of a scrimshaw language
> design goal?

Sorry, I presumed some familiarity with R5RS.  You need a PS, DVI, or PDF
version to see the formal semantics, they don't display well on the web.
You can get them here:
http://www.schemers.org/Documents/Standards/R5RS/

R5RS provides a formal semantics for "the primitive expressions of Scheme
and selected built-in procedures", essentially, a core language.  The
features defined are variable references, procedure application, lambda
abstraction, conditionals (if), assignment (set!), and sequences of
expressions or 'commands'.  This core language is very much like the core
languages used in many interpreters and the intermediate languages used in
advanced compilers.

In fact, the work related to compiling by program transformation, which
involves similar small core languages as intermediate representations, seems
to have begun in Scheme (at least, Appel credits Scheme in his book about
compiling with continuations).  This has influenced compilation strategies
for functional languages and beyond.  For one of the earlier references on
the subject, which is fairly accessible, see Kelsey & Hudak's "Realistic
Compilation by Program Transformation":
http://citeseer.nj.nec.com/kelsey89realistic.html

I was kidding about the "English" bit, obviously - a specification that was
only presented in terms of formal semantics wouldn't be quite as useful.
The real point is that things like 'case' and 'cond' can be defined in terms
of 'if', and the formal semantics only defines core forms.  (I should
mention that some functional languages consider something more case-like to
be a core form, and define 'if' in terms of that - either works.)

> Nice spin. Can you get my cold fusion project a few million with some of
> that puffery?

If you had a theoretical justification that could pass a grant committee,
sure.  Although I wouldn't think a few million would get you very far -
think bigger.

> That seems damn challenging. Hot fusion not being far behind.

Yeah, afaik they're working on it.

> The only thing academics care about is government grants. The
> whole neural net research programme got quashed for twenty years by a
> superficial paper denouncing perceptrons, by a couple of guys trying to
> protect the funding stream of their doomed attempts to compute
> consciousness.

And one of these days I'm going to hear about how one of these guys stole
your girlfriend?

> If the multiway crowd had had a clue they would have worked out in a
> month or two that they had lost their way and retreated to simple
> one-way constraints, where they would have discovered extraordinary
> productivity gains. Instead they just got fancier and fancier --
> walkabout strength! that's the ticket!! Not. But the longer they dragged
> it out the more financing they got, so they did not notice they had
> missed a silver bullet. And now they have moved on and abandoned
> constraints, leaving a lowly monkey to bang it all out. I am sure they
> have moved onto something more challenging.

That's the way it works sometimes, whether or not your characterization in
this case is accurate.

Anton
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F561526.5040508@nyc.rr.com>
Anton van Straaten wrote:
> Why did you stop the quote there?  Let's complete it:

Actually, I think the bit I did quote, on re-reading it this AM, 
supports your case better than this next bit. It mentions a goal of a 
more functional style.

> 
>   "....   The special
> feature of this invention is the possibility of composing conditional
> expressions and restricting the computation to those really needed to get
> the value of the whole expression...."
> 
> This was a major theoretical advance!  

i think this is the difference between engineers and theorists. McCarthy 
did not make a theoretical advance, he fixed a bug.

I am reminded of being disappointed by Norvig's PAIP (or was it the 
other one?). In a very early chapter he lays out some AI algorithm. I am 
puzzled, because it clearly won't work. Then in the next section he 
presents a case that breaks the algorithm, because of the flaw I had 
noticed. We are supposed to go, Wow! He tells us this problem has been 
given a name, I forget what, let's call it the Walkabout Problem. Ah, 
yes. Now I can write a paper on the Walkabout Problem!

McCarthy or any good programmer is sitting there trying to figure out 
some misbehavior in his program, probably arising from a side effect in 
a branch not to be taken. Or maybe he just saw a ton of trace output 
from the branch not to be taken and was aghast at all the work being 
done for nought. If it was the first case he might have said, Oh, gotta 
remember, side-effects BAD! But side effects only bother purists, and at 
any rate one would still be wasting cpu cycles, so he fixes the bug.

He goes down the hall to share his bug fix with someone also writing a 
Lisp compiler and that person says, Yeah, I saw that one coming, I 
avoided that in the first place. Then in charges the department chairman 
waving his paper on "The Road Taken-Not Taken Problem".


Well, right now my scheme to resume play after one drill without 
bouncing the soccer server is not working, gotta go work on the Socket 
Identification Mismatch Problem.

:)


-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Anton van Straaten
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <yGo5b.26663$Om1.17595@newsread2.news.atl.earthlink.net>
Kenny Tilton wrote:
> Anton van Straaten wrote:
> > Why did you stop the quote there?  Let's complete it:
>
> Actually, I think the bit I did quote, on re-reading it this AM,
> supports your case better than this next bit. It mentions a goal of a
> more functional style.

Ooh, gotta remember that one!  :)

> >   "....   The special
> > feature of this invention is the possibility of composing conditional
> > expressions and restricting the computation to those really needed to
get
> > the value of the whole expression...."
> >
> > This was a major theoretical advance!
>
> i think this is the difference between engineers and theorists. McCarthy
> did not make a theoretical advance, he fixed a bug.

It's a bug that no-one else seemed to have recognized.  The line between
theory and practice can be fuzzy.  It can be said that FORTRAN implemented a
weak theory.  McCarthy's fix improved both theory and practice.

Practitioners often do things that impact theory, too.  That's why I have
difficulty getting my head around this antipathy towards theory.  Formal and
theoretical tools are just that - tools that can help us do things,
sometimes amazing things.

> McCarthy or any good programmer is sitting there trying to figure out
> some misbehavior in his program, probably arising from a side effect in
> a branch not to be taken. Or maybe he just saw a ton of trace output
> from the branch not to be taken and was aghast at all the work being
> done for nought. If it was the first case he might have said, Oh, gotta
> remember, side-effects BAD! But side effects only bother purists, and at
> any rate one would still be wasting cpu cycles, so he fixes the bug.
>
> He goes down the hall to share his bug fix with someone also writing a
> Lisp compiler and that person says, Yeah, I saw that one coming, I
> avoided that in the first place. Then in charges the department chairman
> waving his paper on "The Road Taken-Not Taken Problem".

In this case, no-one else *had* seen it coming, afaik (I'd be interested in
references to the contrary).  There was a bug or weakness in both theory and
practice, it was natural that they were fixed together.

> Well, right now my scheme to resume play after one drill without
> bouncing the soccer server is not working, gotta go work on the Socket
> Identification Mismatch Problem.
>
> :)

Write a paper, get a grant, and soon your head will be as pointy as the rest
of them!!

Anton
From: Marc Spitzer
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <86ad9ltitw.fsf@bogomips.optonline.net>
Kenny Tilton <·······@nyc.rr.com> writes:

> Anton van Straaten wrote:
> > Kenny Tilton wrote:
> >
> >>>.. You sound like a
> >>>practitioner who can't see the usefulness of those "stupid academics."
> >>
> >>Anton won't let me get away with that. He keeps pointing out something I
> >>myself get a huge kick out of, the theoretical stuff tapped by McCarthy
> >>to create Lisp.
> > Heh.  I see a crack in the armor here.
> 
> i think you misunderstand something. I have known for a quite a long
> time about the theoretical origins of Lisp. And I have long maintained
> that lisp has survived and now is prevailing precisely becuase of the
> theoreticla origins! Striking out with such a friendly audience is
> very bad news for your toy language.
> 
> >  Can I come to the next LispNYC
> > meeting and give a presentation on elementary lambda calculus and its
> > historical & technical connection to Lisp?  ;)
> 
> Sounds good.

it on the 9th of september btw, see ya there.

marc
From: Anton van Straaten
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <Nmx5b.28029$Om1.4217@newsread2.news.atl.earthlink.net>
Marc Spitzer wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Anton van Straaten wrote:
> > >  Can I come to the next LispNYC
> > > meeting and give a presentation on elementary lambda calculus and its
> > > historical & technical connection to Lisp?  ;)
> >
> > Sounds good.
>
> it on the 9th of september btw, see ya there.

Hmm - how polished a presentation do you expect (short notice), and is it
going to be in that same bar where I played Bruce Lee?  I'm seriously
interested in talking about the topic, but I'm not sure a bar/restaurant is
the place to do it.  At the very least, something like a whiteboard would be
helpful.

BTW, as I've mentioned to Kenny, I would attend more meetings but it's quite
a trip for me from Connecticut, it tends to end up at about a 4-hour
round-trip commuting time, including getting to & from Grand Central etc...

Anton
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F56ABC8.7010502@nyc.rr.com>
Anton van Straaten wrote:
> Marc Spitzer wrote:
> 
>>Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>
>>>Anton van Straaten wrote:
>>>
>>>> Can I come to the next LispNYC
>>>>meeting and give a presentation on elementary lambda calculus and its
>>>>historical & technical connection to Lisp?  ;)
>>>
>>>Sounds good.
>>
>>it on the 9th of september btw, see ya there.
> 
> 
> Hmm - how polished a presentation do you expect (short notice), and is it
> going to be in that same bar where I played Bruce Lee?  I'm seriously
> interested in talking about the topic, but I'm not sure a bar/restaurant is
> the place to do it.  At the very least, something like a whiteboard would be
> helpful.

I think my apartment just three blocks down from Time Out could be made 
to serve, and there has been talk already of snagging an easel with a 
2x3 paper pad. Polish? nah, just wing it.


-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Marc Spitzer
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <86znhkt3qr.fsf@bogomips.optonline.net>
"Anton van Straaten" <·····@appsolutions.com> writes:

> Marc Spitzer wrote:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> >
> > > Anton van Straaten wrote:
> > > >  Can I come to the next LispNYC
> > > > meeting and give a presentation on elementary lambda calculus and its
> > > > historical & technical connection to Lisp?  ;)
> > >
> > > Sounds good.
> >
> > it on the 9th of september btw, see ya there.
> 
> Hmm - how polished a presentation do you expect (short notice), and is it
> going to be in that same bar where I played Bruce Lee?  I'm seriously
> interested in talking about the topic, but I'm not sure a bar/restaurant is
> the place to do it.  At the very least, something like a whiteboard would be
> helpful.
> 
> BTW, as I've mentioned to Kenny, I would attend more meetings but it's quite
> a trip for me from Connecticut, it tends to end up at about a 4-hour
> round-trip commuting time, including getting to & from Grand Central etc...

I know what you mean, mine is 3-4 also, LI.

marc

> 
> Anton
From: Anton van Straaten
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3YM4b.17681$Om1.5060@newsread2.news.atl.earthlink.net>
Kenny Tilton wrote:
> > Doubtful.  Students would probably be taught using ML or Haskell - in
fact,
> > those languages are already commonly used for the purpose, for many of
the
> > same kinds of reasons.
>
> Lawdy, all I hear are about are schools where students riot if you try
> to teach them anything but java.

There's a wide range of schools.  A school that teaches only Java would be a
technical college or trade/vocational school, regardless of what it calls
itself.  There's a place for those, and there's a place for schools which
teach programming language concepts grounded in a formal understanding of
languages.  I was referring to the latter.  The former will always teach the
current popular languages, and some of the ones in between may have to argue
with their students about what they teach.

> Yes, and then the language got used. And when it got used people
> naturally started adding in real-world stuff. And then they all got
> together and standardized on all the real world stuff. Without losing
> the groovy formal stuff.

One groovy formal thing CL seems to be missing is a formal description of
the language semantics.  A seemingly entirely irrelevant thing in the Real
World, but something that's useful and important in academia.

Another item missing from CL are continuations, which regardless of their
direct Real World utility, have a great deal of importance for language
implementations, as evidenced by influential books like Appel's "Compiling
with Continuations".  The applicability of these sorts of compilation
strategies extend way beyond academia.

Although you don't need first-class continuation capture in a language to
implement these sorts of strategies, it certainly helps in teaching and
learning about such things, not to mention simplifying development of
non-standard language control constructs.

Scheme is a Lisp dialect|variant which has these features, and others.
Consider this a way of keeping Lisp competitive in the academic world, and
preventing Lisp from being completely shut out of academia, or relegated to
the occasional AI department.

> Scheme never got used enough for steps two and three to happen,
> and what would be the point? CL is scheme plus steps two and three.

If that last sentence were really true, there'd be no issue.

> > Imagining that somehow, if Scheme simply went away or hadn't existed in
the
> > first place, that academia would focus instead on Common Lisp, is
wishful
> > thinking at best.
>
> We'll get them when Java collapses under its own weight.

Are you sure *you'll* get them, as opposed to say the future mutant
stepchild of OCaml?

> The problem may be that Java and XML may start an Ice Age in
> IT development that will take a decade for Lisp to thaw. What will
> not help is a language that makes you write your own object system.

This seems to be a common misunderstanding of the purpose of the Scheme
standard.  It has a different goal from the CL standard - it constrains the
family of languages that qualify as Scheme, it doesn't define a single
standard language.  Actually, the CL standard does the same thing, but it
just leaves a lot fewer things unspecified.

All fully-fledged Scheme implementations have an object system.  Some of
them even integrate with Java's object system pretty neatly, so what you
consider a disadvantage may actually be a strong point.

> > P.S. Nice troll!
>
> This is war. No fraternizing.
>
> :)

Oh, war is it?  Don't mind me, I'm just sitting here in the lotus position
with a beatific smile on my face.  If you look carefully, you may even
notice that I'm hovering a few fractions of an inch above the ground.  When
you embrace the full diversity of expression that is Lisp, anything becomes
possible...

Anton
From: lin8080
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F53C22E.33DDDAD8@freenet.de>
Hei :)

you should go one doing the 6502 vs 8088(tm), oh sorry, scheme vs lisp.
This gives me more time to discuss whether the ISS should better run
with windowsxx or with xy-linux ... hm?

hint: the hardware there is made in Germany 

stefan
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F55A622.8040202@nyc.rr.com>
lin8080 wrote:
> Hei :)
> 
> you should go one doing the 6502 vs 8088(tm), 

we 6502 programmers often find it amusing that entire 6502 programs 
could fit inside the eight registers of the 8088.

:)

-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Thomas F. Burdick
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <xcvu17w2pn1.fsf@famine.OCF.Berkeley.EDU>
Kenny Tilton <·······@nyc.rr.com> writes:

> Tom Lord wrote:
> > .. it's naive to respond to
> > Common Lisp by saying things like "But Scheme is so much _cleaner_ --
> > why don't you agree that Common Lisp sucks?".   We can acknowledge
> > that it has been the experience of people deeply involved with Common
> > Lisp that, unreasonable as it may sound, they have had to put up with
> > a lot of such responses over the years.
> 
> Can anyone confirm this? Is that why some Lispniks have a cow when
> Scheme or even recursion gets mentioned?

In my Lisp advocacy, I run constantly into the wall of Scheme.  I've
taken recently to telling people that CL is all the power that you'd
hoped C++ would have, with most of the elegance of Scheme, but almost
none of the puzzles.  That, and I tell them that Scheme was a pedantic
tool, and CL is an engineering tool.  Before I came up with good
answers, though, it drove me nuts trying to convince people that
car/cdr/cons/lambda/cond doesn't mean Scheme.

> If so, perhaps these Lispniks should take consolation from Scheme
> being a failed experiment and just lighten up. Steele and Sussman were
> wrong.

Oh my goodness, no, it was a resounding success.  We reaped the
benefits (well defined lexical scope).  It's the various latter-day
Schemes that are the failures.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F53BCC4.1080405@nyc.rr.com>
Thomas F. Burdick wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>>If so, perhaps these Lispniks should take consolation from Scheme
>>being a failed experiment and just lighten up. Steele and Sussman were
>>wrong.
> 
> 
> Oh my goodness, no, it was a resounding success. 

No, to succeed they had to supplant Lisp, not just irritate Lispniks.

>... We reaped the
> benefits (well defined lexical scope).

They had to invent a language to come up with lexical scope? You know, 
Steele made the same mistake with constraints; he made a whole new 
language. Variable assignment was done by a constraint. I am not making 
this up. Turned out to be a little slow. :)

We need a bumper sticker: "Make (new) datatypes, not languages." Cells 
don't make you adopt anything other than Cells. Steele always makes you 
take up a new language.

>..  It's the various latter-day
> Schemes that are the failures.

Oh. What happened? Is the spec a page and a half now?

:)

-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Anton van Straaten
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <DWP4b.19118$Om1.12780@newsread2.news.atl.earthlink.net>
Kenny Tilton wrote:
> They had to invent a language to come up with lexical scope? You know,
> Steele made the same mistake with constraints; he made a whole new
> language. Variable assignment was done by a constraint. I am not making
> this up. Turned out to be a little slow. :)

Some kinds of changes do require either a new language, or at least
fundamental changes to an existing language.  Lexical variables and
continuations are two such features.  When making such changes, it's often
useful, and even important, to start from scratch, so as not to be misled by
inherited design assumptions that may not make sense in the context of the
new feature.  Inventing useful new features is not easily done from a
perspective in which the current status quo is accepted as an axiom.

What Sussman & Steele did was to improve on some choices that were made
early in Lisp's history, when the lambda notation was first borrowed from
Alonzo Church.  McCarthy says at:
http://www-formal.stanford.edu/jmc/history/lisp/node2.html that "it seemed
natural to use the [lambda]-notation of Church (1941). I didn't understand
the rest of his book, so I wasn't tempted to try to implement his more
general mechanism for defining functions."

It turned out that that Church's "more general mechanism for defining
functions" was a lot more important than might have been imagined.  Lisp's
original lambda was a little broken, and Sussman & Steele showed how to fix
it.  Such a fundamental fix creates a new language, whether it's made to an
existing variety of Lisp or implemented in a brand-new variety.  See below.

> We need a bumper sticker: "Make (new) datatypes, not languages." Cells
> don't make you adopt anything other than Cells. Steele always makes you
> take up a new language.

This view comes from a somewhat narrow perspective of what a language is.
CL+Cells is a new language - you can't write code with Cells and run it on a
CL without Cells being present.  The line between language and library may
not seem very blurry in this case, but that's not always the case.

Once a useful new feature has been identified, the question then becomes
whether that feature belongs in existing languages.  CL and some other Lisps
answered "yes" for lexical variables, but "no" for continuations, for
example.  Such choices are a central reason why different languages exist -
if you could just throw all imaginable features in a bucket, and call it a
language, we'd all be using that language - which would truly be a ball of
mud.  But the reality is that once you throw certain features in the bucket,
some other features will no longer fit well, if at all.  That's why we have
lots of different languages.

Many of those different languages aren't, by any stretch of the imagination,
Lisp.  But Lisp has demonstrated the potential to cover a larger part of the
possible design space than many languages.  But it can't do that by picking
a single set of features.  If it does that, then any language without that
exact set of features won't be Lisp, and Lisp loses by that - loses
flexibility, loses potential, and loses mindshare, not to mention
encouraging the proliferation of non-Lisps.

For Lisp to reach its true potential, it has to have more than one variant,
some of which will have features incompatible with other variants - whether
it's the number of namespaces, the presence of absence of some features, the
way in which they treat program source, or something else.  The fact of
these incompatibilities says nothing other than that different tradeoffs
were made in a larger design space - known, to some, as Lisp.

Anton
From: William D Clinger
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <fb74251e.0309021134.6fdbf6a6@posting.google.com>
Kenny Tilton quoting Thomas F. Burdick:
> > Oh my goodness, no, it was a resounding success. 
> 
> No, to succeed they had to supplant Lisp, not just irritate Lispniks.

Scheme is older than Common Lisp, and ANSI Scheme is older than
ANSI Common Lisp.  If a language succeeds only by supplanting
all previous languages in its family, then Common Lisp is a
near-success: it supplanted all previous languages in the Lisp
family except for Scheme.

Thus people who hold to Tilton's definition of success cannot
proclaim Common Lisp a success except by denying that Scheme is
a Lisp.

Will
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfwad9nrn3c.fsf@shell01.TheWorld.com>
··········@verizon.net (William D Clinger) writes:

> Kenny Tilton quoting Thomas F. Burdick:
> > > Oh my goodness, no, it was a resounding success. 
> > 
> > No, to succeed they had to supplant Lisp, not just irritate Lispniks.
> 
> Scheme is older than Common Lisp, and ANSI Scheme is older than
> ANSI Common Lisp.  If a language succeeds only by supplanting
> all previous languages in its family, then Common Lisp is a
> near-success: it supplanted all previous languages in the Lisp
> family except for Scheme.
> 
> Thus people who hold to Tilton's definition of success cannot
> proclaim Common Lisp a success except by denying that Scheme is
> a Lisp.

A curious analysis.

Incidentally, another way of looking at it is to say that ANSI would
likely not, as a procedural matter, have allowed two co-existing
standards for the same language.  So, one might conclude, that ANSI,
at least, must believe that Scheme and Common Lisp are not the same
language.

Not that I (nor anyone) is empowered to speak for ANSI.  Just 
speculating using the same power of pseudo-logic (or actual logic
applied to pseudo-facts) that Will was using.

And not that anything ANSI (an entity with no stake in the outcome)
thinks necessarily really matters... ;)
From: William D Clinger
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <fb74251e.0309021924.3acfcfd8@posting.google.com>
Kent M Pitman wrote:
> Incidentally, another way of looking at it is to say that ANSI would
> likely not, as a procedural matter, have allowed two co-existing
> standards for the same language.  So, one might conclude, that ANSI,
> at least, must believe that Scheme and Common Lisp are not the same
> language.

I'm sure ANSI just followed the official position of the X3J13 committee,
which was that Lisp is a family of languages, and Scheme and Common Lisp
are two distinct languages in that family.

> Not that I (nor anyone) is empowered to speak for ANSI.  Just 
> speculating using the same power of pseudo-logic (or actual logic
> applied to pseudo-facts) that Will was using.

Have you forgotten the facts?  Or did all this happen before you became
involved with X3J13?

Will
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfwad9lvkve.fsf@shell01.TheWorld.com>
··········@verizon.net (William D Clinger) writes:

> Kent M Pitman wrote:
> > Incidentally, another way of looking at it is to say that ANSI would
> > likely not, as a procedural matter, have allowed two co-existing
> > standards for the same language.  So, one might conclude, that ANSI,
> > at least, must believe that Scheme and Common Lisp are not the same
> > language.
> 
> I'm sure ANSI just followed the official position of the X3J13 committee,
> which was that Lisp is a family of languages, and Scheme and Common Lisp
> are two distinct languages in that family.

Note, FWIW, that I personally do not subscribe to the terminology that
X3J13 chose.  I think the interactions are not effectively shown in that
regard.  I prefer to see the tree as having substantially more layers than
the words "language" and "language family" can do.  I refer to dialects
and sometimes subdialects in order to emphasize a tree of rich influences,
and in my model the word "lisp" occurs at multiple levels.


                    +----------------------+
                    | lisp language family |
                    +----------------------+
                            /          |
     +--------------------------+   +----------------------------------+
     | lisp language            |   |      scheme language             |
     +--------------------------+   +----------------------------------+
      |  |          |                    |     :    |        |       :
      | Elisp    ISLISP  Eulisp        T(EA)   :  RnRS    IEEE/ANSI  :
      | dialects                               :  Scheme    Scheme   :
      |                                        :  dialects         (influence)
      |  +- - - (influence)- - - - - - - - - - +  | | | |            :
      |                                                              :
      |  |                                                +----------------+
      |                                                   | dylan language |
  CL dialects                                             +----------------+
    |    |    \
 CLTL  CLTL2  ANSI CL

In support of my claim that it's reasonable to both include and exclude
scheme as a lisp in this way, I have to recite (via paraphrase--it's been
a long time) a cute thing that the late Bill Martin of MIT taught us in
his computational linguistics class...

 - The world is divided into animals, vegetables and minerals.
 - Among animals, there are microbes, insects, bugs, etc. and 
   there are animals.
 - Among animals, there are people and there are animals.
 - Among people, there are nice people and then there are animals.

I think the bottom line was that words don't always mean the same thing.
And in any discussion like this, I think you have to assume that even
a single person cannot be held to using the same term in all cases.

Does Scheme have history with Lisp and a number of common traits? Sure.
Does that make it a Lisp? Kind of.

Does Scheme do things very differently than other Lispy languages, such
that it's worth saying it has earned a first-class culture of its own?
I think yes.  Surely you can't say it's "just another lisp".

I'm not putting Scheme down by saying it's not a Lisp.  I'm saying
that sometimes people just use the local dialect of Lisp.  My bet is
that most CL programmers would be happy programming in Zetalisp, for
example.  And many are happy programming in Emacs lisp, or vice versa
(i.e., many Elisp programmers are happy in CL).  But the transition back
and forth between Scheme and CL is larger.  The syntax hides the difference,
but to program with a CL mindset in Scheme will fight Scheme's power,
and vice versa.  Hence I prefer to model them as different.  Without
attempting to deny their history.

In the same regard, I think dylan is a lisp (historically) but has a 
culture uniquely its own now, and is not easily interchangeable with
Lisp.

Indeed, CL and ISLISP, because of their lexical characteristics, almost
deserve a classification-grouping tier in the class hierarchy in itself
distinct from dynamic-only languages that precede.

I think mostly that discussions like this are useless if they are just
vehicles to alienate one another.  The constructive goal I seek by
commenting at all is to say that there are both structural relationships
and structural differences between certain languages and dialects, and
that those borders explain why programmers and programs pass easily 
across some boundaries and not across others.  Saying "we're all one
big happy family" may be chummy, but it merely destroys the opporunity
to explain real, observed effects in a way that enlightens.
From: Duane Rettig
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <4ekyxlm52.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:

 [ ... ]

I really like your diagram:

>                     +----------------------+
>                     | lisp language family |
>                     +----------------------+
>                             /          |
>      +--------------------------+   +----------------------------------+
>      | lisp language            |   |      scheme language             |
>      +--------------------------+   +----------------------------------+
>       |  |          |                    |     :    |        |       :
>       | Elisp    ISLISP  Eulisp        T(EA)   :  RnRS    IEEE/ANSI  :
>       | dialects                               :  Scheme    Scheme   :
>       |                                        :  dialects         (influence)
>       |  +- - - (influence)- - - - - - - - - - +  | | | |            :
>       |                                                              :
>       |  |                                                +----------------+
>       |                                                   | dylan language |
>   CL dialects                                             +----------------+
>     |    |    \
>  CLTL  CLTL2  ANSI CL

However, I wouldn't consider Dylan a Scheme.  It has a somewhat different
philosophy than either Scheme or Lisp, although it drew heavily from both
Scheme and Common Lisp for its functionality (and other C-like languages for
its syntax). It would probably be better placed at the same level as your
second-level "lisp language" and "scheme language" boxes, with influence
lines between it and both Scheme and CL.  There are also several dialects
of Dylan.

... although I don't really much _care_; if you disagree with my
suggestion, I would not argue with you leaving your diagram the
way it is...

> In support of my claim that it's reasonable to both include and exclude
> scheme as a lisp in this way, I have to recite (via paraphrase--it's been
> a long time) a cute thing that the late Bill Martin of MIT taught us in
> his computational linguistics class...
> 
>  - The world is divided into animals, vegetables and minerals.
>  - Among animals, there are microbes, insects, bugs, etc. and 
>    there are animals.
>  - Among animals, there are people and there are animals.
>  - Among people, there are nice people and then there are animals.

So are you saying that Scheme is an animal?

:-)

Actually, taking your analogy, it would be CL that is the animal...

> I think mostly that discussions like this are useless if they are just
> vehicles to alienate one another.  The constructive goal I seek by
> commenting at all is to say that there are both structural relationships
> and structural differences between certain languages and dialects, and
> that those borders explain why programmers and programs pass easily 
> across some boundaries and not across others.  Saying "we're all one
> big happy family" may be chummy, but it merely destroys the opporunity
> to explain real, observed effects in a way that enlightens.

I agree completely.  I'd _even_ rather see discussion on call/cc (because
that is real discussion on a technical issue) than to continue seeing
pointless discussion about whether or not Scheme is a Lisp, or whether
or not Common Lisp is a Lisp, where no minds are changed and the argument
remains just that - an argument.

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfwr82xhd5e.fsf@shell01.TheWorld.com>
Duane Rettig <·····@franz.com> writes:

> I really like your diagram: [...]
> However, I wouldn't consider Dylan a Scheme.

Nor CL a Scheme.  But they each had strong influence, so I used dotted lines.

> It would probably be better placed at the same level as your
> second-level "lisp language" and "scheme language" boxes, with influence
> lines between it and both Scheme and CL.

Because of the CLOS influence.  Yeah, I guess I'd buy that.

> There are also several dialects
> of Dylan.

(Yes, I didn't expand below that point.)

> ... although I don't really much _care_; if you disagree with my
> suggestion, I would not argue with you leaving your diagram the
> way it is...

No, but your point of view was worth noting, I think.  And I'm not in 
substantial disagreement with it.  It reinforces my point that depending
on context, some languages (e.g., Dylan) might be properly considered a
Lisp or a Scheme, but not always.  And that they have enough culture of
their own to be seen as first-class.

> > In support of my claim that it's reasonable to both include and exclude
> > scheme as a lisp in this way, I have to recite (via paraphrase--it's been
> > a long time) a cute thing that the late Bill Martin of MIT taught us in
> > his computational linguistics class...
> > 
> >  - The world is divided into animals, vegetables and minerals.
> >  - Among animals, there are microbes, insects, bugs, etc. and 
> >    there are animals.
> >  - Among animals, there are people and there are animals.
> >  - Among people, there are nice people and then there are animals.
> 
> So are you saying that Scheme is an animal?
> :-)
>
> Actually, taking your analogy, it would be CL that is the animal...

I'd intended "Lisp" to be in the analogous place, since it is the
recurrent name in these discussions, implicitly placed by conversational
context at different points in the tree.

As to whether CL is animalistic in its own right, well, I personally
don't think so, but I don't deny others do.  Then again, it's common
for people from country X to think the manners and customs of country
Y are animalistic merely because they diverge from convention in
country X, for various values of X and Y, including many symmetric
rearrangements.  Divergence from expectation often equates to
unmannerly in a given viewer, even when there is no objectively
canonical notion of what is to be expected.
From: Duane Rettig
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <4ad9llgpi.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:

> Duane Rettig <·····@franz.com> writes:


> > It would probably be better placed at the same level as your
> > second-level "lisp language" and "scheme language" boxes, with influence
> > lines between it and both Scheme and CL.
> 
> Because of the CLOS influence.  Yeah, I guess I'd buy that.

Yes, and also collections (influenced by CL sequences).

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfwr82x3753.fsf@shell01.TheWorld.com>
Duane Rettig <·····@franz.com> writes:

> Kent M Pitman <······@world.std.com> writes:
> 
> > Duane Rettig <·····@franz.com> writes:
> 
> 
> > > It would probably be better placed at the same level as your
> > > second-level "lisp language" and "scheme language" boxes, with influence
> > > lines between it and both Scheme and CL.
> > 
> > Because of the CLOS influence.  Yeah, I guess I'd buy that.
> 
> Yes, and also collections (influenced by CL sequences).

Right.   Though CL could (even without violating/changing ANSI CL, through
vendor experimentation - hint, hint) learn a lot from the additional
functionality Dylan added here.  
From: Duane Rettig
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <4znhljzop.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:

> Duane Rettig <·····@franz.com> writes:
> 
> > Kent M Pitman <······@world.std.com> writes:
> > 
> > > Duane Rettig <·····@franz.com> writes:
> > 
> > 
> > > > It would probably be better placed at the same level as your
> > > > second-level "lisp language" and "scheme language" boxes, with influence
> > > > lines between it and both Scheme and CL.
> > > 
> > > Because of the CLOS influence.  Yeah, I guess I'd buy that.
> > 
> > Yes, and also collections (influenced by CL sequences).
> 
> Right.   Though CL could (even without violating/changing ANSI CL, through
> vendor experimentation - hint, hint) learn a lot from the additional
> functionality Dylan added here.  

The major language feature missing from CL is sealing.  I would love
to be able to create "breakable" seals in CL, where optimizations
due to sealing can be undone when the criteria for the seal cease to
be met.  CLOS and especially the MOP (and its implementation, in
practice) would be well-suited for such a task.

Yes, we have an rfe (request for enhancement) logged in the books for
sealing;  all it needs to raise its priority, like many other such
rfes, is funding (hint, hint).

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Bruce Hoult
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <bruce-8C2804.14031604092003@copper.ipg.tsnz.net>
In article <·············@beta.franz.com>,
 Duane Rettig <·····@franz.com> wrote:

> Kent M Pitman <······@world.std.com> writes:
> 
> > Duane Rettig <·····@franz.com> writes:
> 
> 
> > > It would probably be better placed at the same level as your
> > > second-level "lisp language" and "scheme language" boxes, with influence
> > > lines between it and both Scheme and CL.
> > 
> > Because of the CLOS influence.  Yeah, I guess I'd buy that.
> 
> Yes, and also collections (influenced by CL sequences).

And conditions (exceptions & restarts).
And keyword and rest arguments.
And places ( := is essentially setf in disguise)

"But other than that, what have the Romans ever done for us?"

-- Bruce
From: Erann Gat
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <gat-0309032028370001@192.168.1.52>
In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
<·····@hoult.org> wrote:

> "But other than that, what have the Romans ever done for us?"

Hey, I got that one! :-)

E.
From: Bruce Hoult
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <bruce-CDE067.23001304092003@copper.ipg.tsnz.net>
In article <····················@192.168.1.52>,
 ···@jpl.nasa.gov (Erann Gat) wrote:

> In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
> <·····@hoult.org> wrote:
> 
> > "But other than that, what have the Romans ever done for us?"
> 
> Hey, I got that one! :-)

Romanes eunt domus
From: Doug Tolton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <gpbslvgrg0hamgsfvplibbum7h99oahico@4ax.com>
On Thu, 04 Sep 2003 23:00:13 +1200, Bruce Hoult <·····@hoult.org>
wrote:

>In article <····················@192.168.1.52>,
> ···@jpl.nasa.gov (Erann Gat) wrote:
>
>> In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
>> <·····@hoult.org> wrote:
>> 
>> > "But other than that, what have the Romans ever done for us?"
>> 
>> Hey, I got that one! :-)
>
>Romanes eunt domus

Hmm, I didn't get it.  Care to illuminate?


Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
From: Erann Gat
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <gat-0909031259150001@k-137-79-50-101.jpl.nasa.gov>
In article <··································@4ax.com>, ·······@yahoo.com
wrote:

> On Thu, 04 Sep 2003 23:00:13 +1200, Bruce Hoult <·····@hoult.org>
> wrote:
> 
> >In article <····················@192.168.1.52>,
> > ···@jpl.nasa.gov (Erann Gat) wrote:
> >
> >> In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
> >> <·····@hoult.org> wrote:
> >> 
> >> > "But other than that, what have the Romans ever done for us?"
> >> 
> >> Hey, I got that one! :-)
> >
> >Romanes eunt domus
> 
> Hmm, I didn't get it.  Care to illuminate?

STFW.

E.
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F5E41C7.1060202@nyc.rr.com>
Doug Tolton wrote:
> On Thu, 04 Sep 2003 23:00:13 +1200, Bruce Hoult <·····@hoult.org>
> wrote:
> 
> 
>>In article <····················@192.168.1.52>,
>>···@jpl.nasa.gov (Erann Gat) wrote:
>>
>>
>>>In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
>>><·····@hoult.org> wrote:
>>>
>>>
>>>>"But other than that, what have the Romans ever done for us?"
>>>
>>>Hey, I got that one! :-)
>>
>>Romanes eunt domus
> 
> 
> Hmm, I didn't get it.  Care to illuminate?

they are trading Monty Python lines, specifically the Life of Brian. Run 
don't walk to the nearest video rental joint.

-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"This is my simple religion.
There is no need for temples;
no need for complicated philosophy.
Our own brain, our own heart is our temple;
the philosophy is kindness."
            --  Tenzin Gyatso, the Dalai Lama
From: Bruce Hoult
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <bruce-7AC529.11545110092003@copper.ipg.tsnz.net>
In article <··································@4ax.com>,
 Doug Tolton <·······@yahoo.com> wrote:

> On Thu, 04 Sep 2003 23:00:13 +1200, Bruce Hoult <·····@hoult.org>
> wrote:
> 
> >In article <····················@192.168.1.52>,
> > ···@jpl.nasa.gov (Erann Gat) wrote:
> >
> >> In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
> >> <·····@hoult.org> wrote:
> >> 
> >> > "But other than that, what have the Romans ever done for us?"
> >> 
> >> Hey, I got that one! :-)
> >
> >Romanes eunt domus
> 
> Hmm, I didn't get it.  Care to illuminate?

Google knows:

   http://members.chello.se/hansdotter/romanes.html

-- Bruce
From: Erann Gat
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <gat-0909031958240001@192.168.1.52>
In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
<·····@hoult.org> wrote:

> In article <··································@4ax.com>,
>  Doug Tolton <·······@yahoo.com> wrote:
> 
> > On Thu, 04 Sep 2003 23:00:13 +1200, Bruce Hoult <·····@hoult.org>
> > wrote:
> > 
> > >In article <····················@192.168.1.52>,
> > > ···@jpl.nasa.gov (Erann Gat) wrote:
> > >
> > >> In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
> > >> <·····@hoult.org> wrote:
> > >> 
> > >> > "But other than that, what have the Romans ever done for us?"
> > >> 
> > >> Hey, I got that one! :-)
> > >
> > >Romanes eunt domus
> > 
> > Hmm, I didn't get it.  Care to illuminate?
> 
> Google knows:

Google knows all (including what STFW means ;-)

E.
From: Doug Tolton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <ammulvc1ib388b58mlf4p5fu3ncd8nlpmt@4ax.com>
On Tue, 09 Sep 2003 19:58:24 -0700, ···@jpl.nasa.gov (Erann Gat)
wrote:

>In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
><·····@hoult.org> wrote:
>
>> In article <··································@4ax.com>,
>>  Doug Tolton <·······@yahoo.com> wrote:
>> 
>> > On Thu, 04 Sep 2003 23:00:13 +1200, Bruce Hoult <·····@hoult.org>
>> > wrote:
>> > 
>> > >In article <····················@192.168.1.52>,
>> > > ···@jpl.nasa.gov (Erann Gat) wrote:
>> > >
>> > >> In article <···························@copper.ipg.tsnz.net>, Bruce Hoult
>> > >> <·····@hoult.org> wrote:
>> > >> 
>> > >> > "But other than that, what have the Romans ever done for us?"
>> > >> 
>> > >> Hey, I got that one! :-)
>> > >
>> > >Romanes eunt domus
>> > 
>> > Hmm, I didn't get it.  Care to illuminate?
>> 
>> Google knows:
>
>Google knows all (including what STFW means ;-)
>
>E.

Ok, I looked it up on <childish drawl>Goooooogle</childish drawl>.

Now I get it, I wasn't sure if the "But other than that, what have the
Romans ever done for us?" was a quote from a different thread, thus I
didn't immediately STFW.  However, in the future, I will STFW before I
ask. :-p


Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
From: Christopher C. Stacy
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <ufzjdd53i.fsf@dtpq.com>
>>>>> On 03 Sep 2003 12:14:49 -0700, Duane Rettig ("Duane") writes:
 Duane> 
 Duane>  [ ... ]



 >> Kent M Pitman <······@world.std.com> writes:
 >>
 >> +----------------------+
 >> | lisp language family |
 >> +----------------------+
 >> /          |
 >> +--------------------------+   +----------------------------------+
 >> | lisp language            |   |      scheme language             |
 >> +--------------------------+   +----------------------------------+
 >> |  |          |                    |     :    |        |       :
 >> | Elisp    ISLISP  Eulisp        T(EA)   :  RnRS    IEEE/ANSI  :
 >> | dialects                               :  Scheme    Scheme   :
 >> |                                        :  dialects         (influence)
 >> |  +- - - (influence)- - - - - - - - - - +  | | | |            :
 >> |                                                              :
 >> |  |                                                +----------------+
 >> |                                                   | dylan language |
 >> CL dialects                                             +----------------+
 >> |    |    \
 >> CLTL  CLTL2  ANSI CL

 Duane> I really like your diagram:

 Duane> However, I wouldn't consider Dylan a Scheme.  It has a somewhat different
 Duane> philosophy than either Scheme or Lisp, although it drew heavily from both
 Duane> Scheme and Common Lisp for its functionality (and other C-like languages for
 Duane> its syntax).


I mnight place Dylan with Scheme because of its lack of symbol objects
and its approach to macros, but was going to suggest that there should
be an (influence) arrow from CL dialects over to Dylan, because of its
CLOS-like approach to OOP and because of some things like with-open-file.

 >> In support of my claim that it's reasonable to both include and exclude
 >> scheme as a lisp in this way, I have to recite (via paraphrase--it's been
 >> a long time) a cute thing that the late Bill Martin of MIT taught us in
 >> his computational linguistics class...
 >>
 >> - The world is divided into animals, vegetables and minerals.
 >> - Among animals, there are microbes, insects, bugs, etc. and 
 >> there are animals.
 >> - Among animals, there are people and there are animals.
 >> - Among people, there are nice people and then there are animals.

 Duane> So are you saying that Scheme is an animal?
 Duane> :-)
 Duane> Actually, taking your analogy, it would be CL that is the animal...

WHAT YES/NO QUESTION COULD I ASK TO DISTINGUISH A SCHEME FROM A LISP?
From: Erann Gat
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <gat-0309031439110001@k-137-79-50-101.jpl.nasa.gov>
In article <·············@dtpq.com>, ······@dtpq.com (Christopher C.
Stacy) wrote:

> WHAT YES/NO QUESTION COULD I ASK TO DISTINGUISH A SCHEME FROM A LISP?

Here's one possibility:

Are the semantics of the langauge defined on forms, or on the text of the
source code?  If the former, then it's a (non-Scheme) Lisp.  If the latter
then it's a Scheme.

E.
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfw1xuxld6v.fsf@shell01.TheWorld.com>
···@jpl.nasa.gov (Erann Gat) writes:

> In article <·············@dtpq.com>, ······@dtpq.com (Christopher C.
> Stacy) wrote:
> 
> > WHAT YES/NO QUESTION COULD I ASK TO DISTINGUISH A SCHEME FROM A LISP?
> 
> Here's one possibility:
> 
> Are the semantics of the langauge defined on forms, or on the text of the
> source code?  If the former, then it's a (non-Scheme) Lisp.  If the latter
> then it's a Scheme.

Not that it's wholly unreasonable to go ahead and answer his question
(except that it might just reiterate the whole thread), but Chris's remark
was surely intended a joke.  See my response to Duane.
From: Erann Gat
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <gat-0309031540360001@k-137-79-50-101.jpl.nasa.gov>
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:

> ···@jpl.nasa.gov (Erann Gat) writes:
> 
> > In article <·············@dtpq.com>, ······@dtpq.com (Christopher C.
> > Stacy) wrote:
> > 
> > > WHAT YES/NO QUESTION COULD I ASK TO DISTINGUISH A SCHEME FROM A LISP?
> > 
> > Here's one possibility:
> > 
> > Are the semantics of the langauge defined on forms, or on the text of the
> > source code?  If the former, then it's a (non-Scheme) Lisp.  If the latter
> > then it's a Scheme.
> 
> Not that it's wholly unreasonable to go ahead and answer his question
> (except that it might just reiterate the whole thread), but Chris's remark
> was surely intended a joke.  See my response to Duane.

Yes, I saw that.  Sorry.  The allusion was just a little too obscure for
me (a little before my time perhaps).

E.
From: ·············@comcast.net
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <u17tv342.fsf@comcast.net>
···@jpl.nasa.gov (Erann Gat) writes:

> Are the semantics of the langauge defined on forms, or on the text of the
> source code?  If the former, then it's a (non-Scheme) Lisp.  If the latter
> then it's a Scheme.

To be pedantic, the semantics of both are defined over domains....
From: Duane Rettig
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <44qztley1.fsf@beta.franz.com>
······@dtpq.com (Christopher C. Stacy) writes:

> >>>>> On 03 Sep 2003 12:14:49 -0700, Duane Rettig ("Duane") writes:
>  Duane> 
>  Duane>  [ ... ]
> 
> 
> 
>  >> Kent M Pitman <······@world.std.com> writes:
>  >>
>  >> +----------------------+
>  >> | lisp language family |
>  >> +----------------------+
>  >> /          |
>  >> +--------------------------+   +----------------------------------+
>  >> | lisp language            |   |      scheme language             |
>  >> +--------------------------+   +----------------------------------+
>  >> |  |          |                    |     :    |        |       :
>  >> | Elisp    ISLISP  Eulisp        T(EA)   :  RnRS    IEEE/ANSI  :
>  >> | dialects                               :  Scheme    Scheme   :
>  >> |                                        :  dialects         (influence)
>  >> |  +- - - (influence)- - - - - - - - - - +  | | | |            :
>  >> |                                                              :
>  >> |  |                                                +----------------+
>  >> |                                                   | dylan language |
>  >> CL dialects                                             +----------------+
>  >> |    |    \
>  >> CLTL  CLTL2  ANSI CL
> 
>  Duane> I really like your diagram:
> 
>  Duane> However, I wouldn't consider Dylan a Scheme.  It has a somewhat different
>  Duane> philosophy than either Scheme or Lisp, although it drew heavily from both
>  Duane> Scheme and Common Lisp for its functionality (and other C-like languages for
>  Duane> its syntax).
> 
> 
> I mnight place Dylan with Scheme because of its lack of symbol objects
> and its approach to macros, but was going to suggest that there should
> be an (influence) arrow from CL dialects over to Dylan, because of its
> CLOS-like approach to OOP and because of some things like with-open-file.

This is certainly a reasonable position.

>  >> In support of my claim that it's reasonable to both include and exclude
>  >> scheme as a lisp in this way, I have to recite (via paraphrase--it's been
>  >> a long time) a cute thing that the late Bill Martin of MIT taught us in
>  >> his computational linguistics class...
>  >>
>  >> - The world is divided into animals, vegetables and minerals.
>  >> - Among animals, there are microbes, insects, bugs, etc. and 
>  >> there are animals.
>  >> - Among animals, there are people and there are animals.
>  >> - Among people, there are nice people and then there are animals.
> 
>  Duane> So are you saying that Scheme is an animal?
>  Duane> :-)
>  Duane> Actually, taking your analogy, it would be CL that is the animal...
> 
> WHAT YES/NO QUESTION COULD I ASK TO DISTINGUISH A SCHEME FROM A LISP?

I'm a little confused by this question, and especially its delivery.
There is some context I'm missing about why this question is asked here,
at this point during disscussions about animals, and why it is all in
caps.  Either:

 - You are incredibly angry at my lame jokes

 - You're keyboard got locked-up into caps mode accidentally

 - You intended to ask this on the tail of some other part of this thread

 - you want my opinion on language botany

 - [something else]

Perhaps you can re-ask the question, but give me a little more
context to work with?

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfw65k9ld8s.fsf@shell01.TheWorld.com>
Duane Rettig <·····@franz.com> writes:

> > WHAT YES/NO QUESTION COULD I ASK TO DISTINGUISH A SCHEME FROM A LISP?
> 
> I'm a little confused by this question, and especially its delivery.
> There is some context I'm missing about why this question is asked here,
> at this point during disscussions about animals, and why it is all in
> caps.  Either:
> 
>  - You are incredibly angry at my lame jokes
> 
>  - You're keyboard got locked-up into caps mode accidentally
> 
>  - You intended to ask this on the tail of some other part of this thread
> 
>  - you want my opinion on language botany
> 
>  - [something else]
> 
> Perhaps you can re-ask the question, but give me a little more
> context to work with?

You're missing a variety of in jokes collapsed into that short but 
seemingly out of contet statement.

He's quoting from early versions of a program called "ANIMAL" which played
a "guess an animal" game.  It went like:

 DOES YOUR ANIMAL HAVE 2 LEGS? YES
 IS YOUR ANIMAL A PERSON? NO
 I GIVE UP. WHAT WERE YOU THINKING OF? A DUCK.
 WHAT YES/NO QUESTION COULD I ASK TO DISTINGUISH A PERSON FROM A DUCK?
 DOES IT QUACK LIKE A DUCK?
 THANKS. I'LL REMEMBER THAT.
 ANOTHER GAME? YES
 DOES YOUR ANIMAL HAVE 2 LEGS? YES
 DOES IT QUICK LIKE A DUCK? YES
 IS IT A DUCK? YES
 I WIN! ANOTHER GAME?

There are some other details I'm not mentioning that make what Chris said
funny, but I don't have time to go into them all.

Anyway, I don't think he's suddenly lost either his temper or his sanity.
From: Duane Rettig
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <4k78pjwky.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:

> Duane Rettig <·····@franz.com> writes:
> 
> > > WHAT YES/NO QUESTION COULD I ASK TO DISTINGUISH A SCHEME FROM A LISP?
> > 
> > I'm a little confused by this question, and especially its delivery.
> > There is some context I'm missing about why this question is asked here,
> > at this point during disscussions about animals, and why it is all in
> > caps.  Either:
> > 
> >  - You are incredibly angry at my lame jokes
> > 
> >  - You're keyboard got locked-up into caps mode accidentally
> > 
> >  - You intended to ask this on the tail of some other part of this thread
> > 
> >  - you want my opinion on language botany
> > 
> >  - [something else]
> > 
> > Perhaps you can re-ask the question, but give me a little more
> > context to work with?
> 
> You're missing a variety of in jokes collapsed into that short but 
> seemingly out of contet statement.
> 
> He's quoting from early versions of a program called "ANIMAL" which played
> a "guess an animal" game.  It went like:
> 
>  DOES YOUR ANIMAL HAVE 2 LEGS? YES
>  IS YOUR ANIMAL A PERSON? NO
>  I GIVE UP. WHAT WERE YOU THINKING OF? A DUCK.
>  WHAT YES/NO QUESTION COULD I ASK TO DISTINGUISH A PERSON FROM A DUCK?
>  DOES IT QUACK LIKE A DUCK?
>  THANKS. I'LL REMEMBER THAT.
>  ANOTHER GAME? YES
>  DOES YOUR ANIMAL HAVE 2 LEGS? YES
>  DOES IT QUICK LIKE A DUCK? YES
>  IS IT A DUCK? YES
>  I WIN! ANOTHER GAME?
> 
> There are some other details I'm not mentioning that make what Chris said
> funny, but I don't have time to go into them all.
> 
> Anyway, I don't think he's suddenly lost either his temper or his sanity.

Ahh, I completely missed that.

Good one, Chris!

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Christopher C. Stacy
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <uptihp2w4.fsf@dtpq.com>
>>>>> On 03 Sep 2003 18:26:59 -0400, Kent M Pitman ("Kent") writes:

 Kent> Anyway, I don't think he's suddenly lost either his temper or his sanity.

No, the latter happened gradually over many years...
From: Eduardo Muñoz
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <ur82x8q0q.fsf@terra.es>
* Duane Rettig <·····@franz.com>
| ······@dtpq.com (Christopher C. Stacy) writes:
| > 
| > WHAT YES/NO QUESTION COULD I ASK TO DISTINGUISH A SCHEME FROM A LISP?
| 
| I'm a little confused by this question, and especially its delivery.
| There is some context I'm missing about why this question is asked here,
| at this point during disscussions about animals, and why it is all in
| caps.  Either:
| 
        [...]
| 
|  - [something else]
| 
| Perhaps you can re-ask the question, but give me a little more
| context to work with?

I think that some AI-Bot took command of his computer and
wants to play "guess the animal" :)


-- 
Eduardo Mu�oz          | (prog () 10 (print "Hello world!")
http://213.97.131.125/ |          20 (go 10))
From: Rainer Joswig
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <joswig-CC3C1E.20014703092003@news.fu-berlin.de>
In article <···············@shell01.TheWorld.com>,
 Kent M Pitman <······@world.std.com> wrote:

> I'm not putting Scheme down by saying it's not a Lisp.  I'm saying
> that sometimes people just use the local dialect of Lisp.  My bet is
> that most CL programmers would be happy programming in Zetalisp, for
> example.  And many are happy programming in Emacs lisp, or vice versa
> (i.e., many Elisp programmers are happy in CL).  But the transition back
> and forth between Scheme and CL is larger.  The syntax hides the difference,
> but to program with a CL mindset in Scheme will fight Scheme's power,
> and vice versa.  Hence I prefer to model them as different.  Without
> attempting to deny their history.

I would more likely switch for application development from
CL to Scheme. Not to Elisp and certainly not Zetalisp. Lack
of lexical binding -> no fun.

> In the same regard, I think dylan is a lisp (historically) but has a 
> culture uniquely its own now, and is not easily interchangeable with
> Lisp.

Lack of Lisp syntax -> no switch to Dylan.
 
> Indeed, CL and ISLISP, because of their lexical characteristics, almost
> deserve a classification-grouping tier in the class hierarchy in itself
> distinct from dynamic-only languages that precede.

A few things that are IMHO desirable for Lisps:

- easy syntax -> CL not, Scheme yes
- lexical binding -> CL yes but with baggage, Scheme yes
- easy language model -> CL not, Scheme yes
- FP support -> CL yes + minus some stuff, Scheme yes
- defined semantics -> CL no, Scheme somewhat

Actually in my view CL is relatively unlispy.

(large, complicated, messy, external representation is problematic
  (Common Lisp source programs are usually only readable by
   a full Lisp implementation -> program analyzing tools
   at source level are problematic),
typical IDEs often work on text instead of data structures ...).


-> "A critique of Common Lisp" Brooks/Gabriel
-> The death of creativity: is Common LISP a LISP-like language?',
   John R Allen, AI Expert, 1987


Besides all that I'm using CL until something better appears,
for which I'm not holding my breath.
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfwd6ehy9c3.fsf@shell01.TheWorld.com>
Rainer Joswig <······@lispmachine.de> writes:

> I would more likely switch for application development from
> CL to Scheme. Not to Elisp and certainly not Zetalisp. Lack
> of lexical binding -> no fun.
> [...]
> Lack of Lisp syntax -> no switch to Dylan.
> [...]
> A few things that are IMHO desirable for Lisps:
> 
> - easy syntax -> CL not, Scheme yes
> - lexical binding -> CL yes but with baggage, Scheme yes
> - easy language model -> CL not, Scheme yes
> - FP support -> CL yes + minus some stuff, Scheme yes
> - defined semantics -> CL no, Scheme somewhat
 
My first thought about the above was "mercenary".  But in spite of the
connotation of that word, probably most users are.  I guess the real
observation worth making is that a scholarly analysis of language
families (by studying history, feature influence, etc.) might not cut
along the same line as a man-on-the-street/mercenary analysis of
"usage preference".  Users are allowed to like whatever subset of
features they like, whether or not it appears organized to the
designer.  [I have this problem with Amazon.com: It thinks that
audiobooks are just another kind of books, but I _only_ read
audiobooks and I detest its mentioning of paper books because to me
they are just bad data.  Similar effects are probably visible to
people with only VHS players or only DVD, since some people want to
shop "movies" and the format is merely a detail, while others want to
shop "something I can play" and one or the other formats is
non-product.]  Considerable margin for error is created by the fact
that consumers and creators are not in necessary agreement on what the
thing is that is being transacted, and have only crude information of
"they seemed to buy it. there must be something about it they wanted."
It's common for US presidents to get elected because people didn't like
the alternative, yet to immediately spout rhetoric saying "The people
have indicated a preference [or "mandate"] for all of my programs." which
is leaning just a bit too heavy on the information content expressed
by the election.

> Actually in my view CL is relatively unlispy.

Ah.  Finally a scholarly analysis.  Heh.  That is to say, an analysis
which does not relate to CL's usability and is just the kind of random
useless blathering about abstract feature sets that I thought the
rest of us were engaged in.  Welcome back to the discussion.

> (large, complicated, messy, external representation is problematic
>   (Common Lisp source programs are usually only readable by
>    a full Lisp implementation -> program analyzing tools
>    at source level are problematic),
> typical IDEs often work on text instead of data structures ...).

Typical IDE's not written in Lisp, I assume you mean, which is to ask
the question "what is typical?"  Do you mean Emacs?  Does it get to 
be referred to in plural because it has a lot of seats?  LispWorks seems
to use parsed structure.  So does the Lisp Machine.  I bet MCL's environment
does, too. These are, admittedly, based on the full Lisp.  But your parens
are oddly placed here, suggesting that it's problematic to have tools based
on the full Lisp, yet I had thought most IDE tools for Lisp were, in fact, 
based on a full Lisp... Emacs might have the most users, and might be text
based, but I bet there are more other implementations even if they have
fewer users.  Well, at least you see my confusion.  Could you say the
same thing again without the confusing parentheses? ;)

> -> "A critique of Common Lisp" Brooks/Gabriel
> -> The death of creativity: is Common LISP a LISP-like language?',
>    John R Allen, AI Expert, 1987
> 
> Besides all that I'm using CL until something better appears,
> for which I'm not holding my breath.

We're in agreement here.
From: Doug Tolton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfbslv48kcjrl0i31323ej1245962pa54i@4ax.com>
On 03 Sep 2003 15:13:00 -0400, Kent M Pitman <······@world.std.com>
wrote:

>Users are allowed to like whatever subset of
>features they like, whether or not it appears organized to the
>designer.  [I have this problem with Amazon.com: It thinks that
>audiobooks are just another kind of books, but I _only_ read
>audiobooks and I detest its mentioning of paper books because to me
>they are just bad data.  Similar effects are probably visible to
>people with only VHS

Just to clarify, you only "read" audiobooks and you think paper books
are a bad idea?  I'm thinking you must mean the reverse, that you in
fact detest audio books and only read paper books.  If so, that's my
feeling also.  If not, I'm perplexed.


Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfw3cf5xrcz.fsf@shell01.TheWorld.com>
Doug Tolton <·······@yahoo.com> writes:

> On 03 Sep 2003 15:13:00 -0400, Kent M Pitman <······@world.std.com>
> wrote:
> 
> >Users are allowed to like whatever subset of
> >features they like, whether or not it appears organized to the
> >designer.  [I have this problem with Amazon.com: It thinks that
> >audiobooks are just another kind of books, but I _only_ read
> >audiobooks and I detest its mentioning of paper books because to me
> >they are just bad data.  Similar effects are probably visible to
> >people with only VHS
> 
> Just to clarify, you only "read" audiobooks and you think paper books
> are a bad idea?  I'm thinking you must mean the reverse, that you in
> fact detest audio books and only read paper books.  If so, that's my
> feeling also.  If not, I'm perplexed.

Drifting a little off topic, but since you ask: I wrote it right the
first time.  I read for many hours a day online.  When I'm away from
the console, I prefer to take a break from reading, but I still like
to keep up on fiction stories, so I listen to them on audiobook...
From: Anton van Straaten
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <k5H5b.29028$Om1.11659@newsread2.news.atl.earthlink.net>
Kent M Pitman wrote:
> I think mostly that discussions like this are useless
> if they are just vehicles to alienate one another.

Agreed.

> The constructive goal I seek by commenting at all is
> to say that there are both structural relationships and
> structural differences between certain languages and
> dialects, and that those borders explain why programmers
> and programs pass easily across some boundaries
> and not across others.

Sure.  It just sometimes seems as though some of those boundaries are
surrounded by more baggage than can rationally be justified.  (Of course,
now we can argue about what constitutes a rational response to decades of
feuding.)

When boundaries are used as a way to say "keep out", in some situations at
least, they become controversial, and may be worthy of a redesign.  The
Berlin Wall might be a good example here: it came down, which was indicative
of an improved situation.  In Israel/Palestine, fences have been going up
lately, which seems indicative of a deteriorating situation (and an attempt
to control it).

> Saying "we're all one big happy family" may be chummy,
> but it merely destroys the opporunity to explain real,
> observed effects in a way that enlightens.

My own interest would not be to try to say "we're all one big happy family",
nor to try to paper over differences or lose opportunities to understand
things (I can't imagine many people have the latter as a goal).  I'm more
interested in having discussions that are *not* "vehicles to alienate one
another" - but doing that requires a certain amount of mutual respect for,
and understand of, different language preferences we each have, and choices
we've made.  Learning about and understanding those different preferences
ought to involve exchanging information about "real, observed effects in a
way that enlightens".  Treating each other's different preferences as the
sign of an enemy combatant certainly isn't going to lead to such
enlightment.

Anton
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfw8yp4fhdp.fsf@shell01.TheWorld.com>
"Anton van Straaten" <·····@appsolutions.com> writes:

> Kent M Pitman wrote:
> > I think mostly that discussions like this are useless
> > if they are just vehicles to alienate one another.
> 
> Agreed.

This may be all we agree on, but I guess it's something.
 
> > The constructive goal I seek by commenting at all is
> > to say that there are both structural relationships and
> > structural differences between certain languages and
> > dialects, and that those borders explain why programmers
> > and programs pass easily across some boundaries
> > and not across others.
> 
> Sure.  It just sometimes seems as though some of those boundaries are
> surrounded by more baggage than can rationally be justified.  (Of course,
> now we can argue about what constitutes a rational response to decades of
> feuding.)
> 
> When boundaries are used as a way to say "keep out", in some situations at
> least, they become controversial, and may be worthy of a redesign.  The
> Berlin Wall might be a good example here: it came down, which was indicative
> of an improved situation.  In Israel/Palestine, fences have been going up
> lately, which seems indicative of a deteriorating situation (and an attempt
> to control it).

This is something I think I disagree with very much and is probably a
fundamental difference beyond which we cannot go.  Though it depends
on whether your use of terminology is just pessimally chosen or whether
this is the only way you are willing to frame the wording.

I didn't say "keep out" and quite resent being re-quoted that way.

What I do think, though, is that there are reasons for people to
voluntarily keep out.  If you see a room full of nudists and you're
not a nudist, the thing to do is not to enter and then whine about how
people don't do what you like.  Nor is it to tell people that they're
making you keep out by their lifetstyle.  The choice is yours, not
theirs.  But your joining requires some acceptance of premise in order
to be even remotely constructive.

Anyone can join the CL community, but they should do so by accepting
the framework of goals that CL has.  They should not come here
surreptitiously thinking they will teach us to have different goals.
There are other places to go if you have different goals.  This applies
not just to CL but to a variety of situations.  It is embodied in the
commonly used phrase "Let's agree to disagree."

Likewise anyone can join the Scheme community, but they should do so by
accepting the framework of goals that Scheme has.  They should not go there
surreptitiously thinking they will teach the Scheme community to have
different goals.  There are others places to go if you have different goals
than the Scheme community.  (I say this somewhat redundantly in order to
textually underscore the fact that nothing I said in the previous paragraph
is militantly "anti-Scheme" or "keep out"-ish in some way that I myself
cannot tolerate applied to me.)

The phrase "strong fences make good neighbors" also comes to mind.
People don't feel nearly as bothered by other people's differing beliefs
and practices when they don't think those things apply to them.

So when we talk about whether one or another language is or is not a Lisp,
all I'm saying is that if you insist on it being a Lisp, what could be your
motive? Simply to wave the banner? Fine, call yourself part of the 
"Greater Lisp Morass" and I guess that's fine.  But the place it's come up
in my career is with employers asking the question "you said you're a lisp
programmer, can't you just use Scheme" or with a prospective hire saying
"I program in Scheme, why doesn't that qualify me?"  And the answer I'm
trying to say in those cases is that the term Lisp really is not specific
enough to say what language I'd rather be using, nor what language you ought
to know to feel qualified as a CL programmer.  (Likewise, I rush to emphasize,
it is rash for a CL programmer to assume they are qualified to just sit down
and program in Scheme.  It's quite a culture shock.  And there may well be
things Scheme does for which CL would not be a suitable replacement.  

I am not arguing for one being "better" than the other.  I am arguing for
proper labeling.  Proper labeling leans, in my experience, toward the 
specific.  Less specific loses information.

Moreover, I am arguing that two separated communities, each working according
to their own beliefs, may be able to yield a better combined outcome than
the same communities pushed together and asked to pick a single unified
culture.  It seems to me a necessary implication of this that it's important
for each person to pick the right community, or else you get the same effect
as one big merged community without any of the connectivity benefits... so
I am arguing for voluntary separation,  and you are not.

> > Saying "we're all one big happy family" may be chummy,
> > but it merely destroys the opporunity to explain real,
> > observed effects in a way that enlightens.
> 
> My own interest would not be to try to say "we're all one big happy family",
> nor to try to paper over differences or lose opportunities to understand
> things (I can't imagine many people have the latter as a goal).  I'm more
> interested in having discussions that are *not* "vehicles to alienate one
> another" - but doing that requires a certain amount of mutual respect for,
> and understand of, different language preferences we each have, and choices
> we've made.  Learning about and understanding those different preferences
> ought to involve exchanging information about "real, observed effects in a
> way that enlightens".  Treating each other's different preferences as the
> sign of an enemy combatant certainly isn't going to lead to such
> enlightment.

You're the one using terms like "enemy" and "combatant" and "Berlin".

I did use the word force, but there are many kinds of force short of this.

To my mind, what isn't going to lead to more enlightenment is
metaphorical escalation.  I use metaphors/analogies myself, a lot, but
almost never for the sake of the imagery it evokes.  Rather to show a
specific structural relationship from a worked situation in another
context that the reader might be familiar with to a situation that the
reader might not be familiar with and might be unable to speculate
about.  By tying the situation to the analogy, one can see likely outcomes.

You seem to be using the analogy mechanism to belittle me by
suggesting I am writing "scary stories".  There is a difference
between scary stories and saying that some things scare me.
Self-control is not a kind of "controlling behavior", although it's
often re-painted by the passive aggressive to appear so.

I'm not sure if I'll have more to say on this subthread.  Don't take
any silence on my part as sudden agreement. ;)
From: Anton van Straaten
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <L%R5b.33414$Om1.18721@newsread2.news.atl.earthlink.net>
Kent M Pitman wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > Kent M Pitman wrote:
> > > I think mostly that discussions like this are useless
> > > if they are just vehicles to alienate one another.
> >
> > Agreed.
>
> This may be all we agree on, but I guess it's something.

Gotta start somewhere.

> > > The constructive goal I seek by commenting at all is
> > > to say that there are both structural relationships and
> > > structural differences between certain languages and
> > > dialects, and that those borders explain why programmers
> > > and programs pass easily across some boundaries
> > > and not across others.
> >
> > Sure.  It just sometimes seems as though some of those boundaries are
> > surrounded by more baggage than can rationally be justified.  (Of
course,
> > now we can argue about what constitutes a rational response to decades
of
> > feuding.)
> >
> > When boundaries are used as a way to say "keep out", in some situations
at
> > least, they become controversial, and may be worthy of a redesign.  The
> > Berlin Wall might be a good example here: it came down, which was
indicative
> > of an improved situation.  In Israel/Palestine, fences have been going
up
> > lately, which seems indicative of a deteriorating situation (and an
attempt
> > to control it).
>
> This is something I think I disagree with very much and is probably a
> fundamental difference beyond which we cannot go.  Though it depends
> on whether your use of terminology is just pessimally chosen or whether
> this is the only way you are willing to frame the wording.
>
> I didn't say "keep out" and quite resent being re-quoted that way.

Oops, that wasn't directed at you at all, sorry.

You raised the issue of boundaries.  My experience and observation, recently
updated, is that the Scheme/CL boundary in general (at least on usenet) is
of the sort I was describing.  If my comparions seem extreme, consider that
the Berlin Wall did eventually come down, whereas I'm not sure about
Scheme/CL...  ;)

> What I do think, though, is that there are reasons for people to
> voluntarily keep out.  If you see a room full of nudists and you're
> not a nudist, the thing to do is not to enter and then whine about how
> people don't do what you like.  Nor is it to tell people that they're
> making you keep out by their lifetstyle.  The choice is yours, not
> theirs.  But your joining requires some acceptance of premise in order
> to be even remotely constructive.
>
> Anyone can join the CL community

What about the c.l.l. community?  The isomorphism between CL and c.l.l. is
incomplete and ambiguous.

> but they should do so by accepting
> the framework of goals that CL has.

I certainly accept those, as I've said.  I'd agree it's unfortunate when
others don't.

> They should not come here
> surreptitiously thinking they will teach us to have different goals.

Again, that would be unfortunate.  But there's a fine line between "teaching
to have different goals" and "learning to better understand the unfamiliar".
Ideally, the latter could take place, in both directions, without it
devolving into the former.

> There are other places to go if you have different goals.

Such as discussing "Lisp" in general?

> Likewise anyone can join the Scheme community, but they should do so by
> accepting the framework of goals that Scheme has.  They should not go
there
> surreptitiously thinking they will teach the Scheme community to have
> different goals.  There are others places to go if you have different
goals
> than the Scheme community.  (I say this somewhat redundantly in order to
> textually underscore the fact that nothing I said in the previous
paragraph
> is militantly "anti-Scheme" or "keep out"-ish in some way that I myself
> cannot tolerate applied to me.)

Yes, but there's still the asymmetry that c.l.l. nominally attempts to
encompass a little more than just CL, but practically may not really be able
to do a good job of that.  There's no real corresponding issue for c.l.s.

> The phrase "strong fences make good neighbors" also comes to mind.
> People don't feel nearly as bothered by other people's differing beliefs
> and practices when they don't think those things apply to them.

Good point.

> So when we talk about whether one or another language is or is not a Lisp,
> all I'm saying is that if you insist on it being a Lisp, what could be
your
> motive?

Speaking for myself as opposed to any others who might have done this, my
"motive", such as it is, is that's what I believe in this case.  It's a
conclusion that arises from what I (and others) perceive as a reasonable
definition of what qualifies as Lisp - it doesn't have a "motive" in the
sense I think you're suggesting, i.e. if you think it furthers some hidden
(or open) pro-Scheme agenda, for example, I think that would say more about
your perspective, than about my motives.

> Simply to wave the banner? Fine, call yourself part of the
> "Greater Lisp Morass" and I guess that's fine.

Oh neat, thanks, that completely settles it!  I feel proud to be a part of
the Greater Lisp Morass!  Please join me in a chant: Greater Lisp Mor-ass,
Mor-ass, Mor-ass...   hmm...

> But the place it's come up
> in my career is with employers asking the question "you said you're a lisp
> programmer, can't you just use Scheme" or with a prospective hire saying
> "I program in Scheme, why doesn't that qualify me?"  And the answer I'm
> trying to say in those cases is that the term Lisp really is not specific
> enough to say what language I'd rather be using, nor what language you
> ought to know to feel qualified as a CL programmer.

I agree the term "Lisp" is not specific enough in these cases.  If you want
a CL programmer, hire someone with CL experience, or recognize that they'll
have to learn CL.  If a hirer asks you to use a language you're not
comfortable with, explain the issues.  Lisp is an unusual language family,
and some education may be needed about that.

> I am not arguing for one being "better" than the other.  I am arguing for
> proper labeling.  Proper labeling leans, in my experience, toward the
> specific.  Less specific loses information.

One uses less specific labels when you are talking about less specific
things - such as, the class of all languages that can be called "Lisp".

> Moreover, I am arguing that two separated communities, each working
according
> to their own beliefs, may be able to yield a better combined outcome than
> the same communities pushed together and asked to pick a single unified
> culture.

I definitely have never suggested "picking a single unified culture", and
I'm not sure anyone else has.  But I think that better relations would be
possible, and beneficial.

> It seems to me a necessary implication of this that it's important
> for each person to pick the right community, or else you get the same
effect
> as one big merged community without any of the connectivity benefits... so
> I am arguing for voluntary separation,  and you are not.

No, I think there *should* be voluntary separation.  But there's also
overlap in certain areas, both technical and non-technical.  There doesn't
seem to be anywhere conducive to discussion of matters covered by that
overlap.

> > > Saying "we're all one big happy family" may be chummy,
> > > but it merely destroys the opporunity to explain real,
> > > observed effects in a way that enlightens.
> >
> > My own interest would not be to try to say "we're all one big happy
family",
> > nor to try to paper over differences or lose opportunities to understand
> > things (I can't imagine many people have the latter as a goal).  I'm
more
> > interested in having discussions that are *not* "vehicles to alienate
one
> > another" - but doing that requires a certain amount of mutual respect
for,
> > and understand of, different language preferences we each have, and
choices
> > we've made.  Learning about and understanding those different
preferences
> > ought to involve exchanging information about "real, observed effects in
a
> > way that enlightens".  Treating each other's different preferences as
the
> > sign of an enemy combatant certainly isn't going to lead to such
> > enlightment.
>
> You're the one using terms like "enemy" and "combatant" and "Berlin".

Again, just to be clear, this choice of words wasn't directed at you
specifically.  However, the words were chosen as a characterization of what
can happen if someone blinks funny in this group (and I'm not just talking
about myself).

> To my mind, what isn't going to lead to more enlightenment is
> metaphorical escalation.  I use metaphors/analogies myself, a lot, but
> almost never for the sake of the imagery it evokes.

The imagery of the Berlin Wall coming down is positive.  But I take your
point.

> You seem to be using the analogy mechanism to belittle me by
> suggesting I am writing "scary stories".

I don't even know which scary stories that would refer to, unless you're
talking about my earlier Heston analogy, which I stand by as being
appropriate and relevant.  I'll put this down to another case where you took
something personally that wasn't intended as such.

In this case, you wrote, in general terms, about being "one big happy
family".  One reason I responded to your post is that I felt that this
characterization is a trivialization of the ideas that have been put
forward.  Once so trivialized, it's easy to dismiss it as simply "chummy".
I should have responded more directly to that point.

Anton
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfw7k4ox9oo.fsf@shell01.TheWorld.com>
"Anton van Straaten" <·····@appsolutions.com> writes:

> ... just to be clear, this choice of words wasn't directed at you ...

Thanks for clarifying.

> In this case, you wrote, in general terms, about being "one big happy
> family".  One reason I responded to your post is that I felt that this
> characterization is a trivialization of the ideas that have been put
> forward.  Once so trivialized, it's easy to dismiss it as simply "chummy".
> I should have responded more directly to that point.

Well, I didn't mean to trivialize but rather to react to a perceived
trivialization by someone (or -"ones") along the way, in the sense 
that it's very easy to accidentally assume that "working together"
is productive and "working separately" is unproductive.  There are a
variety of ways that this "obviousness" breaks down, and I wanted to
highlight some.  I wasn't trying to say this was a small matter at all;
rather, I was trying to say that it wasn't a simple matter to simply
say "because people are not all aligned, there is something amiss".
People will, of course, get together for a "family reunion" and all drink
wine and celebrate their bloodlines, but the next day they'll be back to
their more routine relationships at home, not all of which are so 
celebratory.  

I've sometimes summarized such issues more or less thus: By moving in
modern society from wars of sticks and stones to wars of words to
express our personal passions, we didn't extinguish the passions, we
just made it less likely we'd get physically injured in the crossfire.
The passions are still there and I certainly do not mean to ever
trivialize them...

I almost disbelieve, these days, in the actual concept of the trivial,
and especially so when all parties in a discussion don't agree that a
matter is trivial.  Put another way, I claim that it more or less
suffices in polite debate to rebutt the claim by one party that some
issue is trivial to merely say "I disagree."  That is, the fact that
someone does not feel an issue is trivial is, I think, sufficient evidence
that it is not.  Once in a while, one won't want to debate such issues
with that person.  But it doesn't serve anyone well to insist that the
party that doesn't devalue the issue must yield to the person who does.
We are each, in the modern connected world, caretakers of special truths
known only to ourselves.  That we don't all make everything a priority is
a necessity.  But we ought not trivialize the fact that others have 
different priorities.  The fact of different priorities is what makes us
each individually valuable to the whole.
From: Nils Goesche
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <ly7k4nnvvw.fsf@cartan.de>
"Anton van Straaten" <·····@appsolutions.com> writes:

> When boundaries are used as a way to say "keep out", in some
> situations at least, they become controversial, and may be worthy of
> a redesign.  The Berlin Wall might be a good example here: it came
> down, which was indicative of an improved situation.  In
> Israel/Palestine, fences have been going up lately, which seems
> indicative of a deteriorating situation (and an attempt to control
> it).

Your historical analogies tend to be rather crude.  The Berlin Wall
wouldn't have been the Monument of Shame it was if it had actually
been built to ``keep out�� people.  The communists built it to keep
people /inside/ their Evil Empire.

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

PGP key ID 0x0655CFA0
From: Anton van Straaten
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <lK16b.422$BG6.27@newsread1.news.atl.earthlink.net>
Nils Goesche wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > When boundaries are used as a way to say "keep out", in some
> > situations at least, they become controversial, and may be worthy of
> > a redesign.  The Berlin Wall might be a good example here: it came
> > down, which was indicative of an improved situation.  In
> > Israel/Palestine, fences have been going up lately, which seems
> > indicative of a deteriorating situation (and an attempt to control
> > it).
>
> Your historical analogies tend to be rather crude.  The Berlin Wall
> wouldn't have been the Monument of Shame it was if it had actually
> been built to ``keep out�� people.  The communists built it to keep
> people /inside/ their Evil Empire.

Thanks for pointing that out - it serves as a reminder of the
literal-mindedness of some readers.

Anton
From: Kenny Tilton
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <3F5503D9.1040901@nyc.rr.com>
William D Clinger wrote:
> Kenny Tilton quoting Thomas F. Burdick:
> 
>>>Oh my goodness, no, it was a resounding success. 
>>
>>No, to succeed they had to supplant Lisp, not just irritate Lispniks.
> 
> 
> Scheme is older than Common Lisp,..

Good one!

-- 

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Career highlights? I had two. I got an intentional walk from
Sandy Koufax and I got out of a rundown against the Mets."
                                                  -- Bob Uecker
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfwr82zxa46.fsf@shell01.TheWorld.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> We need a bumper sticker: "Make (new) datatypes, not languages."

More than a decade ago, I began saying that if I could do it all over,
I'd rather see standards for datatypes (and their accessors, and only
a few control mechanisms, for the sake of error handling) rather than
standards for languages.  If datatypes (and these few other matters)
were more standard, languages would not matter.  (That is, they could
be a private programmer choice that didn't interfere with later
linking.)  That's a bit of a pipe dream because sometimes languages
derive their power from the choice of datatype, and so the two are not
always separable.

The fact that CL and C do not agree on what an integer is, and that
even a language (such as Java) that acknoledges the need for a (pardon
the bad pun) "real" Integer does not agree with CL on where it goes in
the type tree makes it very hard for data to be shared among these
languages without expensive (un)marshalling, which was (I was once
told) the effective downfall of CORBA.  Likewise for NUL-terminated 
strings vs length-counted strings.  And so on.  That we don't have names
for each others' "valuable goods" makes it very hard to serve each other.
From: Alain Picard
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <87brtupfsd.fsf@optushome.com.au>
Kent M Pitman <······@world.std.com> writes:

> [snip] ... makes it very hard for data to be shared among these
> languages without expensive (un)marshalling, which was (I was once
> told) the effective downfall of CORBA.  

Yeah, right.  So now, they send XMS in ASCII down the pipes
and everyone has their favorite translators.  Much faster
than CORBA, I'm sure.   :-(
From: Brian Palmer
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <0whk78iowp3.fsf@rescomp.Stanford.EDU>
Alain Picard <·······················@optushome.com.au> writes:
 
> Yeah, right.  So now, they send XMS in ASCII down the pipes
> and everyone has their favorite translators.  Much faster
> than CORBA, I'm sure.   :-(

XML, I assume you mean? One of XML's selling points is that it's not
an ASCII only medium; XML processors are required to support both
UTF-8 and UTF-16, and many support others. 
-- 
I'm awfully glad I'm a Beta, because I don't work so hard.
From: Jon S. Anthony
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <m34qzkmtx2.fsf@rigel.goldenthreadtech.com>
Brian Palmer <·······@rescomp.Stanford.EDU> writes:

> Alain Picard <·······················@optushome.com.au> writes:
>  
> > Yeah, right.  So now, they send XMS in ASCII down the pipes
> > and everyone has their favorite translators.  Much faster
> > than CORBA, I'm sure.   :-(
> 
> XML, I assume you mean? One of XML's selling points is that it's not
> an ASCII only medium; XML processors are required to support both
> UTF-8 and UTF-16, and many support others. 

This somehow makes it better????  That probably makes it even _worse_
in this context.

/Jon
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfwu17mrqnn.fsf@shell01.TheWorld.com>
Alain Picard <·······················@optushome.com.au> writes:

> Kent M Pitman <······@world.std.com> writes:
> 
> > [snip] ... makes it very hard for data to be shared among these
> > languages without expensive (un)marshalling, which was (I was once
> > told) the effective downfall of CORBA.  
> 
> Yeah, right.  So now, they send XMS in ASCII down the pipes
> and everyone has their favorite translators.  Much faster
> than CORBA, I'm sure.   :-(

Probably funded by the CORBA guys as a long-range pre-marketing tool
for a CORBA revival.
From: Raymond Wiker
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <86n0detkyt.fsf@raw.grenland.fast.no>
Alain Picard <·······················@optushome.com.au> writes:

> Kent M Pitman <······@world.std.com> writes:
>
>> [snip] ... makes it very hard for data to be shared among these
>> languages without expensive (un)marshalling, which was (I was once
>> told) the effective downfall of CORBA.  
>
> Yeah, right.  So now, they send XMS in ASCII down the pipes
> and everyone has their favorite translators.  Much faster
> than CORBA, I'm sure.   :-(

        I did some CORBA stuff in C++ a few years back, and I would
say that the major problem with CORBA under C++ is that the C++
binding is *much* too complex to use. It seems that the emphasis was
wholly on performance, with very little priority given to useability. 

        XMLRPC is of course the opposite, and has more or less swept
CORBA away.

-- 
Raymond Wiker                        Mail:  ·············@fast.no
Senior Software Engineer             Web:   http://www.fast.no/
Fast Search & Transfer ASA           Phone: +47 23 01 11 60
P.O. Box 1677 Vika                   Fax:   +47 35 54 87 99
NO-0120 Oslo, NORWAY                 Mob:   +47 48 01 11 60

Try FAST Search: http://alltheweb.com/
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfwptiarqlg.fsf@shell01.TheWorld.com>
Raymond Wiker <·············@fast.no> writes:

>         I did some CORBA stuff in C++ a few years back, and I would
> say that the major problem with CORBA under C++ is that the C++
> binding is *much* too complex to use. It seems that the emphasis was
> wholly on performance, with very little priority given to useability. 

Have you compared it to the CL binding for CORBA?
From: Raymond Wiker
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <86ad9et1e3.fsf@raw.grenland.fast.no>
Kent M Pitman <······@world.std.com> writes:

> Raymond Wiker <·············@fast.no> writes:
>
>>         I did some CORBA stuff in C++ a few years back, and I would
>> say that the major problem with CORBA under C++ is that the C++
>> binding is *much* too complex to use. It seems that the emphasis was
>> wholly on performance, with very little priority given to useability. 
>
> Have you compared it to the CL binding for CORBA?

        I looked at the CL binding when it was first shown by the
people who created it. I had the distinct feeling that it would be
much simpler to use, but I never actually tried it.

-- 
Raymond Wiker                        Mail:  ·············@fast.no
Senior Software Engineer             Web:   http://www.fast.no/
Fast Search & Transfer ASA           Phone: +47 23 01 11 60
P.O. Box 1677 Vika                   Fax:   +47 35 54 87 99
NO-0120 Oslo, NORWAY                 Mob:   +47 48 01 11 60

Try FAST Search: http://alltheweb.com/
From: David Lichteblau
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <oelekypvoz3.fsf@vanilla.rz.fhtw-berlin.de>
Raymond Wiker <·············@fast.no> writes:
[C++/IDL Mapping]
>> Have you compared it to the CL binding for CORBA?
>         I looked at the CL binding when it was first shown by the
> people who created it. I had the distinct feeling that it would be
> much simpler to use, but I never actually tried it.

Can you give a brief summary of the differences you saw?  The basic
tasks seem to be the same to me, at least if you are using the POA.
(Though I have not actually _used_ CORBA with C++ so far, only seen code
which uses it, so my impression might be wrong.)

With any mapping to an object-oriented language, I see two scenarios:
  1. You have ordinary objects implementing IDL-conforming functions
     that you want to expose via CORBA.
  2. Although CORBA deals with objects, your implementation behind the
     IDL interface is not object-oriented.

In the second case, you have to deal with CORBA issues a lot.  And what
is worse, you cannot even use the API without going through (most of?)
the CORBA overhead.

In the first case, you can avoid touching the ORB at all if the objects
happen to live in the same process and the client, and their
implementation need not be aware of CORBA.  But between the ORB's
servants and the actual data objects you need to translate between the
objects references and your data.  Tedious to write, since the mapping
is trivial, but a lot of code needs to be written if you have many IDL
operations.  In fact, the wrapper code is so trivial that I can
auto-genarate it by running over the IDL (or the interface repository).
Given this wrapper code generator, the remaining hand-written Lisp code
is very simple indeed, but a C++ server could use the same technique, I
believe.
From: Raymond Wiker
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <8665k1t5u9.fsf@raw.grenland.fast.no>
David Lichteblau <···········@lichteblau.com> writes:

> Raymond Wiker <·············@fast.no> writes:
> [C++/IDL Mapping]
>>> Have you compared it to the CL binding for CORBA?
>>         I looked at the CL binding when it was first shown by the
>> people who created it. I had the distinct feeling that it would be
>> much simpler to use, but I never actually tried it.
>
> Can you give a brief summary of the differences you saw?  The basic
> tasks seem to be the same to me, at least if you are using the POA.
> (Though I have not actually _used_ CORBA with C++ so far, only seen code
> which uses it, so my impression might be wrong.)

        The main difference is that the C++ bindings for CORBA is
cumbersome to use - it does not use C++'s string type, for example,
and I think there are 4 different types of pointers (references) used
for various CORBA entities (I haven't touched CORBA for more than
three years, so I'm hazy on the details).

        A quick summary would be that:

        1) The C++ bindings were done before some of the C++
constructs that we take for granted (templates, namespaces, the
standard template library were in place)

        2) the C++ bindings were done with "highest possible
performance" as a design goal, which (in this case, at least) is in
direct conflict with ease-of-use.


-- 
Raymond Wiker                        Mail:  ·············@fast.no
Senior Software Engineer             Web:   http://www.fast.no/
Fast Search & Transfer ASA           Phone: +47 23 01 11 60
P.O. Box 1677 Vika                   Fax:   +47 35 54 87 99
NO-0120 Oslo, NORWAY                 Mob:   +47 48 01 11 60

Try FAST Search: http://alltheweb.com/
From: Christian Lynbech
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <87pti8675t.fsf@dhcp229.ted.dk.eu.ericsson.se>
We did some prototyping with CORBA in different settinggs this spring
and allthough I have not been doing any C++/CORBA programming myself,
we got extensive feedback from the guy doing that part and from that I
concluded: CORBA in C++ is next to a nightmare due to the complicated
memory management issues you are facing. 

My colleague ended up concluding that CORBA in C++ was actually easier
than he expected, but there is (I believe he would agree) a
considerable lead time until you have mastered the relationships
between your code and the CORBA system, and it is much harder than
working in a language with automatic memory management (such as java
or lisp).


------------------------+-----------------------------------------------------
Christian Lynbech       | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - ·······@hal.com (Michael A. Petonic)
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfwvfsbxah6.fsf@shell01.TheWorld.com>
Kenny Tilton <·······@nyc.rr.com> writes:

> Tom Lord wrote:
> > .. it's naive to respond to
> > Common Lisp by saying things like "But Scheme is so much _cleaner_ --
> > why don't you agree that Common Lisp sucks?".   We can acknowledge
> > that it has been the experience of people deeply involved with Common
> > Lisp that, unreasonable as it may sound, they have had to put up with
> > a lot of such responses over the years.
> 
> Can anyone confirm this? Is that why some Lispniks have a cow when
> Scheme or even recursion gets mentioned?
> 
> Is Scheme seen as an insurgent language? Steele and Sussman traitors?
> This is starting to make some sense.
> 
> If so, perhaps these Lispniks should take consolation from Scheme
> being a failed experiment and just lighten up. Steele and Sussman were
> wrong. They created something small, yes, and with appeal to some who
> go for the short spec, but that is as far as it went. The CL crowd
> voted with its feet and stood on the mother ship. Game over.

Certainly Steele and Sussman are not traitors.

For one thing, the only sense in which Steele abandoned anything is that he
left both communities.  ;)

However, there is an underlying problem that there is NOT a canonical notion
of "simple".  (For an elaboration, read my paper on equality. The same issues
are in play.)  In brief, you have to say "simple in what way?"

I claim that "simplicity of implementation" necessarily sacrifices
"simplicity of programming", and vice versa.  Scheme often uses the
unadorned term "simple" as if it were "obvious" that "less to learn"
was better.  ("simple to learn" is probably some third axis, actually.)

While one can draw a three dimensional space with ease of programming
on one axis, ease of learning on another, and ease of implementation
on a third, this is deceptive because it suggests that it's easy to
locate an object anywhere in that space. These axes are somewhat 
interdependent, and so making it easier on the implementors usually
makes things harder on the users, and vice versa.  Some counterexamples
are possible, but there are reasons, I think, that most human languages
are not like esperanto and loglan, and that even after the development
of these so-called "simpler" languages, humans didn't flock to their use.
Humans are equipped in hardware to spend a longer learning and to hold
a large amount of information in exchange for easier programming.  So the
claim that CL is "less simple" addresses the language, not the programs.

I personally find CL programs simpler to read than Scheme programs in
most cases exactly for the same reason that I would expect to find a 
copy of Gone with the Wind harder to read in Esperanto than in English.
The fewer words you have to work with, the more heaps of modifiers and
early little definitinos you need to "catch up" with a larger language.

There is some tiny fussing about the "size of the core" but that's all
red herring because the actual difference between the CL core (not normally
separately articulated) and the Scheme core is tiny, and is not by any
means the bulk of what you spend your time learning about when programming
either language.

I don't care to characterize Scheme as failed, though I have heard this
characterization.  If there are extant happy users, that's fine with me.
I have no deathwish for Scheme.  Just not a desire to be forced to use it.

And, moreover, in the context of this message, I have a desire not to be
forced to use their metric of "simple".

I regard "making an implementation" as a "loop invariant" to be done once
early,  and as such it's ok for it to take a little longer than the iterative
part (the part that will execute many times), that is, "programming".  
Scheme people are taught how to make an implementation virtually overnight.
I don't care if it takes months to make an implementation.  I care whether
there are _enough_ implementations (and CL has "enough"--sometimes is even
accused of having too many).  What I really want is that when I sit down to
write programs, I can do that.  And with reasonable brevity.
From: Anton van Straaten
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <0d75b.16590$EW1.7393@newsread1.news.atl.earthlink.net>
Kent M Pitman wrote:
> I have no deathwish for Scheme.  Just not a desire to be forced to use it.

Just curious, who's trying to force you to use it?  Or perhaps this is just
an attempt to portray CL the way Charlton Heston did for guns: "from my
cold, dead hands!"

> Scheme people are taught how to make an implementation virtually
overnight.
> I don't care if it takes months to make an implementation.

I think that's a red herring: serious Scheme implementations are not made
overnight.  The fully-fledged implementations all have many years of
development behind them.

> There is some tiny fussing about the "size of the core" but that's all
> red herring because the actual difference between the CL core
> (not normally separately articulated) and the Scheme core is tiny,
> and is not by any means the bulk of what you spend your time
> learning about when programming either language.

I'm curious about whether there's some reason that the CL core is not
separately articulated - after all, layering of functionality is a pretty
well-accepted technique for dealing with complexity.  Are there any
references which provide such a separate articulation?

Anton
From: Kent M Pitman
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <sfwd6eij335.fsf@shell01.TheWorld.com>
"Anton van Straaten" <·····@appsolutions.com> writes:

> Kent M Pitman wrote:
> > I have no deathwish for Scheme.  Just not a desire to be forced to use it.
> 
> Just curious, who's trying to force you to use it?  Or perhaps this is just
> an attempt to portray CL the way Charlton Heston did for guns: "from my
> cold, dead hands!"

declaring the two to be the same language is the same as declaring that
one can be substituted for the other. 
From: Anton van Straaten
Subject: Re: why Common Lisp is not a lisp
Date: 
Message-ID: <f%95b.23000$Om1.7282@newsread2.news.atl.earthlink.net>
Kent M Pitman wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > Kent M Pitman wrote:
> > > I have no deathwish for Scheme.  Just not a desire to be forced to use
it.
> >
> > Just curious, who's trying to force you to use it?  Or perhaps this is
just
> > an attempt to portray CL the way Charlton Heston did for guns: "from my
> > cold, dead hands!"
>
> declaring the two to be the same language is the same as declaring that
> one can be substituted for the other.

Let me translate that, to be clear: "declaring CL and Scheme to both be
'Lisps' is the same as declaring that
one can be substituted for the other."

This claim makes no sense to me.  I guess we're back to disagreeing on the
meaning of "Lisp" - if not the meaning of "the same as".

In any case, even if your perspective were accepted, "can be substituted" is
not the same thing as "forced to use it".  Your Heston act isn't justified.

Anton