Why is Scheme not a Lisp?

Showing 1-572 of 572 messages
Why is Scheme not a Lisp? Erann Gat 3/12/02 12:00 PM

I hesitate to ask this question because I really don't want to start a
flame war.  To me it seems clear that Scheme is a dialect of Lisp.  The
Scheme standard says it's a dialect of Lisp.  Many textbooks say it's a
dialect of Lisp (e.g. Norvig's book, which has a chapter called "Scheme -
an uncommon Lisp".  Quiennec I believe also includes Scheme as a dialect
of Lisp.)

So my question is directed to those of you who say that Scheme is not a
Lisp, notably Erik, but I gather that there are many out there who agree
with him.  Why is Scheme not a Lisp?  Does Scheme lack some necessary
feature that is required to be considered a Lisp in your book?  Was Lisp
1.5 a Lisp?

Please note that I don't want to get into the argument about whether or
not Scheme is or is not a Lisp.  I'm just interested in hearing from those
people who already believe that it isn't what their rationale is.

Thanks,
Erann
g...@jpl.nasa.gov

Why is Scheme not a Lisp? Rahul Jain 3/12/02 1:06 PM
g...@jpl.nasa.gov (Erann Gat) writes:

> I'm just interested in hearing from those people who already believe
> that it isn't what their rationale is.

Here's my rationale: If Scheme were a lisp, it would call itself a
Lisp. Does Java call itself a C? No, because it's not a C.

Moreover, if scheme were a lisp, then ML would be a lisp. As would
dylan, logo, perl, ruby, and lots of other languages which have
closures and recusive functions. ML and scheme are far more similar to
each other than either is to Common Lisp.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Barry Margolin 3/12/02 1:16 PM
In article <gat-120302...@eglaptop.jpl.nasa.gov>,

Erann Gat <g...@jpl.nasa.gov> wrote:
>
>I hesitate to ask this question because I really don't want to start a
>flame war.  To me it seems clear that Scheme is a dialect of Lisp.  The
>Scheme standard says it's a dialect of Lisp.  Many textbooks say it's a
>dialect of Lisp (e.g. Norvig's book, which has a chapter called "Scheme -
>an uncommon Lisp".  Quiennec I believe also includes Scheme as a dialect
>of Lisp.)
>
>So my question is directed to those of you who say that Scheme is not a
>Lisp, notably Erik, but I gather that there are many out there who agree
>with him.  Why is Scheme not a Lisp?  Does Scheme lack some necessary
>feature that is required to be considered a Lisp in your book?  Was Lisp
>1.5 a Lisp?

The decision of whether to call something a dialect or a separate language
is generally arbitrary and subjective, and frequently based more on
political issues rather than technical ones.  Scheme users have chosen to
separate themselves philosophically from Lisp users, so despite the many
similarities, they consider them distinct languages.

I've been reading a very interesting book called "The Power of Babel",
about the evolution of human languages.  He gives numerous examples of
pairs of languages that are easily intelligible between their respective
speakers, but are considered separate languages mostly due to nationalistic
attitudes; e.g. the Scandinavian languages and Spanish vs. Portugese.
Conversely, there are dialects that are spoken within the same country, but
speakers of each dialect have a hard time understanding each other; Germany
has examples of these.

These same issues occur with computer languages.  Visual BASIC is a far cry
from the original Dartmouth BASIC, and the PDP-8 BASIC I used 25 years ago
was crippled in comparison to Dartmouth BASIC, but they're all considered
dialects of BASIC.  C and C++ are about as similar as Lisp and Scheme, but
they're also generally considered separate languages, although with very
close ties (the C++ standard is expected to adopt changes in the C standard
that don't directly conflict with its goals).

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

Why is Scheme not a Lisp? Carl Shapiro 3/12/02 1:16 PM
g...@jpl.nasa.gov (Erann Gat) writes:

> So my question is directed to those of you who say that Scheme is not a
> Lisp, notably Erik, but I gather that there are many out there who agree
> with him.  Why is Scheme not a Lisp?  Does Scheme lack some necessary
> feature that is required to be considered a Lisp in your book?  Was Lisp
> 1.5 a Lisp?

If you would like instant gratification, Google Groups has a complete
record of discussions dealing with this very question.

Why is Scheme not a Lisp? Kent M Pitman 3/12/02 1:44 PM
g...@jpl.nasa.gov (Erann Gat) writes:

> I hesitate to ask this question because I really don't want to start a
> flame war.  To me it seems clear that Scheme is a dialect of Lisp.  The
> Scheme standard says it's a dialect of Lisp.  Many textbooks say it's a
> dialect of Lisp (e.g. Norvig's book, which has a chapter called "Scheme -
> an uncommon Lisp".  Quiennec I believe also includes Scheme as a dialect
> of Lisp.)

This isn't quite fair.  You can find writing of mine that calls it a Lisp,
too, but this is because it is sometimes easier to use another's terminology
than to make a political statement every time you want to have a simple
discussion.

In ANSI CL, I was forced by the fact of committee vote to refer to things
as I did, so count that merely as a majority wish, not the view of the
neutral editor (me, at least  I tried to be neutral with my "Editor" hat
on ... sometimes tricky to keep the hats separated, but I think I did ok).

> So my question is directed to those of you who say that Scheme is not a
> Lisp, notably Erik, but I gather that there are many out there who agree
> with him.

Count me in with Erik.  Even if I don't get to be notable. ;)

> Why is Scheme not a Lisp?  Does Scheme lack some necessary feature
> that is required to be considered a Lisp in your book?  Was Lisp 1.5
> a Lisp?

First, it doesn't call itself Lisp.  It calls itself Scheme.

Second, at the Lisp & Functional Programming conference, there was
serious difficulty getting Lisp papers accepted.  Lisp papers were
about engineering, and Scheme papers were about mathy and theoretical
issues.  And, to be utterly crude about it, what I think gets papers
accepted to such conferences is heavy use of greek letters (and
spelling out the word LAMBDA does not appear seem to count).  Merely
talking about satisfying users doesn't tend to float anyone's boat
there.  Even before L&FP broke up, it got to the point that when there
was a Lisp paper, all the Scheme folks left the room and when there as
a Scheme paper all the Lisp folks left the room.  That's an empirical
observation that I'm not the only one to have made.  People were on
divergent paths.

Third, the priorities of the language design of the two languages are
different.  That means that if the two communities are viewed as
merged, they appear to have no coherent theory of what they do or
don't want.  But if you separate them into two groups, you see they
are massively more likely to converge on two fairly coherent theories
of the universe.  That, in turn, suggests they are happier separated.

I think the question of what makes a Lisp is taken historically by
examining the torch passing.  Lisp 1.5 was of course a Lisp because it
was passed the torch by other Lisps.  Emacs Lisp and Common Lisp are
both Lisps because they both ascended from Maclisp with a substantial
(even if divergent) desire to be true to the original Maclisp concepts
and user base.  But at design meetings of Scheme I have repeatedly
seen the designers say that compatibility was not relevant.  That, to
me, says there is no allegiance to existing codebases and userbases
and there is more desire to build a new community.  That, to me, is
the very essence of the launch of a new language--the breaking of
essential links with the past.  They did it voluntarily, the people
outside their community did not do it to them.

Moreover, it was the right thing to do, both for them and for us.
They were hampered by the tradition in what they wanted to do and
sought to build a new life.  Your question is very much like
questioning why the United States is a different country than England,
and questioning whether it was true even in the time when Jamestown
was founded.  Of course it wasn't.  But there came a point where
breaking free was administratively appropriate because of divergent
goals.  It doesn't mean we can't be pals in our cultural stance
against "those evildoers" who seek sanctuary in C and Java, but it
does mean neither our systems of laws nor our cultural priorities are
the same.

> Please note that I don't want to get into the argument about whether or
> not Scheme is or is not a Lisp.  I'm just interested in hearing from those
> people who already believe that it isn't what their rationale is.

I don't think it's got to be totally one way or the other.  Sometimes
it's useful to blur the distinction, e.g., for outreach, as I did when
discussing Lisp and Scheme on Slashdot.  It wasn't worth portraying us
as separate communities there, where people are standing at such a
distance.  But as one gets closer, I think the differences very much
matter.  And proper placement in the right political party is better
than trying to bang your head against the wall in the wrong one.

And it doesn't mean you can't use both languages either.  It just means
one is more likely to care about the needs of certain people, and one is
more likely to care about others.

McCarthy has asked that no single language take the name Lisp.  That
it be kept a language family.  That's fine.  But it also makes the
name close to meaningless.  The only common operator which has the
same meaning in all Lisp dialects I know of is CONS.  I don't think
that's much to go on.  I find it more useful to think of a tighter
space than this, and leaving out Scheme makes it easier to cluster
than leaving out any other thing and keeping Scheme.  Sure, we can
be like the datatype ATOM, defined by what we are not (that is, as
a non-cons).  We're not C.  We're not Javascript.  We're not Teco.
Yeah, that must be us.  Those guys with the parentheses.  I don't want
to be defined by that.  At some point I think you have to drive in the
stake and say difference is useful.

Let me turn the question around:  Make a list of the value you get from
insisting there is not a division.  Then make a list of the confusions,
irritations, frustrations, and deadlocks that occur by merging them.
Then ask--which list has the most weight?  For me, the answer is plainly
one where the grief to be avoided by separation is bigger than the value
to be gained by globbing things together.  Don't you agree?  What is
your agenda/purpose in wanting the answer to come out that we're all
indistinguishable under a then-completely-useless predicate of Lispness?
I feel as if I'm missing something because it sounds like you're somehow
injured by this, and I just don't see how.  I think everyone is enriched
by the current division.

Why is Scheme not a Lisp? Dorai Sitaram 3/12/02 1:57 PM
In article <xeuj8.16$on4...@paloalto-snr2.gtei.net>,

Barry Margolin  <bar...@genuity.net> wrote:
>Scheme users have chosen to
>separate themselves philosophically from Lisp users, so despite the many
>similarities, they consider them distinct languages.

If Scheme users themselves consider Scheme to be a
non-Lisp as you say, I can't see where the conflict
of views is coming from.   Who are the two groups
holding opposing views here?

--d

Why is Scheme not a Lisp? Lieven Marchand 3/12/02 12:35 PM
Barry Margolin <bar...@genuity.net> writes:

> I've been reading a very interesting book called "The Power of Babel",
> about the evolution of human languages.  He gives numerous examples of
> pairs of languages that are easily intelligible between their respective
> speakers, but are considered separate languages mostly due to nationalistic
> attitudes; e.g. the Scandinavian languages and Spanish vs. Portugese.
> Conversely, there are dialects that are spoken within the same country, but
> speakers of each dialect have a hard time understanding each other; Germany
> has examples of these.

Defining what a language is in linguistics has about the same problems
as defining a species in biology. The mutual intelligibility criterium
shows the analogue of ring species, it isn't transitive and so you
can't use it as an equivalence relation on "languages". Starting from
the west coast of Flanders, you can go through Flanders towards
Germany and so onto Austria and Swiss along a path of mutually
understandable dialects but the end points are very different
languages.

In the end, it is indeed political. Serbo-Croatian was once one
language, written in two alphabets (Latin and Cyrillic) but will
probably grow apart under political pressure. Contrariwise, Flemish
and Dutch were fairly apart in the 19th century and have grown more
alike under political pressure.

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

Why is Scheme not a Lisp? Lieven Marchand 3/12/02 12:44 PM
g...@jpl.nasa.gov (Erann Gat) writes:

> So my question is directed to those of you who say that Scheme is not a
> Lisp, notably Erik, but I gather that there are many out there who agree
> with him.  Why is Scheme not a Lisp?  Does Scheme lack some necessary
> feature that is required to be considered a Lisp in your book?  Was Lisp
> 1.5 a Lisp?

Scheme is not a Lisp IMO because of two types of reasons: first,
technical, which have been argued on this group ad nauseam (the
deepest difference there to me is that a scheme program is defined as
a string of characters whereas a CL program is defined as a sequence
of lists of Lisp objects. This may seem pedantic or trivial but a lot
of different design decisions follow from this. It makes Scheme an
infix member of the Algol language family.); but more important,
philosophically. The Scheme community has evolved a set of values at
odds with the spirit of Lisp: the goal for simplicity at the expense
of convenience (compare the concept of CL's $item designators with the
design of convert stuff explicitly like Scheme's exact->inexact), the
goal of only giving basic blocks and letting you assemble stuff
yourself (call/cc isn't a replacement for a worked out exception
system).

To sum it up with a Ritchie quote: "Some languages were meant to get
work done, some were meant to prove a point." I put Lisp in the first
category and Scheme and ML in the second. (See also the reliance on
tail call elimination to be able to prove the point that a looping
construct isn't necessary.)

I don't know enough about Lisp 1.5 to answer your last question.

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

Why is Scheme not a Lisp? Dorai Sitaram 3/12/02 2:16 PM
>
>First, it doesn't call itself Lisp.  It calls itself Scheme.

Actually it does too calls itself a Lisp.  Vide
the standard.  But if one means that it doesn't have
the substring "Lisp" in its name, then taxonomy isn't
determined by name substrings.  An elephant is a
mammal, a hammer is a tool, a car is a vehicle, and a
German is a European.

--d

Why is Scheme not a Lisp? Craig Brozefsky 3/12/02 2:19 PM
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

Since the issue of making the distinction depends on the context
(political and technical) it is not surprising that in various heated
discussions the participants come to different conclusions about
wether to uphold the distinction or not, often depending upon how it
suits their argument.  

Internally to c.l.l it seems the consensus is leaning towards a
distinction, at least amongst the more active posters who have been
here awhile.  I think this is a good thing, since with the influx of
CL programmers coming in the last year or two it allows the community
to focus its commonly held interests and "philosophies" when
discussing issues facing the language at the level of specificity
required to coordinate different projects while maintaining
cohesiveness.


--
Craig Brozefsky                           <cr...@red-bean.com>
                                http://www.red-bean.com/~craig
Ask me about Common Lisp Enterprise Eggplants at Red Bean!

Why is Scheme not a Lisp? Rahul Jain 3/12/02 2:26 PM
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> If Scheme users themselves consider Scheme to be a non-Lisp as you
> say, I can't see where the conflict of views is coming from.  Who
> are the two groups holding opposing views here?

I think it's a small group of insecure Scheme users who think that
they should be considered "A Lisp" so that they get all the
"publicity" that Lisp does along with the publicity that Scheme does.

Additionally, they get to defame the name of Lisp by making people
think that it's as limited at Scheme. That's what I had thought from
my prior education, before being informed by Sriram Krishnamurthi and
c.l.l that Lisp really is very different from Scheme. Turned out that
the language I had been building and semi-specifying was a subset of
CL, and I effectively replaced the copy of that language's spec with
the Hyperspec and never looked back. :)

What those Schemers get from defaming Lisp beats me. Probaby some sort
of jealous envy. If they really like Scheme, I don't see why they
should need to dupe others out of wanting to learn Lisp.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Dorai Sitaram 3/12/02 3:06 PM
In article <87g0352...@photino.sid.rice.edu>,

Rahul Jain  <rj...@sid-1129.sid.rice.edu> wrote:
>
>I think it's a small group of insecure Scheme users who think that
>they should be considered "A Lisp" so that they get all the
>"publicity" that Lisp does along with the publicity that Scheme does.
>
>Additionally, they get to defame the name of Lisp by making people
>think that it's as limited at Scheme. That's what I had thought from
>my prior education, before being informed by Sriram Krishnamurthi and
>c.l.l that Lisp really is very different from Scheme. Turned out that
>the language I had been building and semi-specifying was a subset of
>CL, and I effectively replaced the copy of that language's spec with
>the Hyperspec and never looked back. :)
>
>What those Schemers get from defaming Lisp beats me. Probaby some sort
>of jealous envy. If they really like Scheme, I don't see why they
>should need to dupe others out of wanting to learn Lisp.

I'll admit I don't want those epithets any more than
the next guy, Rahul, but I find I cannot honestly alter
my opinion that Scheme is a Lisp.  Perhaps
Erann's call will unearth some new technical insight
that will change my mind.

I thank you for your vigorous response.

--d

Why is Scheme not a Lisp? Barry Margolin 3/12/02 2:25 PM

Many Lisp programmers consider Scheme to be a dialect of Lisp.  In my
opinion, Scheme, Interlisp, Maclisp, Common Lisp, Lisp 1.5, and even Dylan
are all dialects within the Lisp family of languages.  (Dylan's surface
syntax is no longer Lisp-like, although it originally was, but its
underlying operation is very much like most other Lisps.)

Also, it's unlikely that all Scheme users are of like mind in this regard.
I'm sure there are plenty who consider it to be a dialect of Lisp, such as
the ones who wrote the second sentence of the specification, where they say
"Scheme is a ... dialect of the Lisp programming language ..."

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

Why is Scheme not a Lisp? Barry Margolin 3/12/02 2:35 PM
In article <87g035i...@piracy.red-bean.com>,

Craig Brozefsky  <cr...@red-bean.com> wrote:
>Since the issue of making the distinction depends on the context
>(political and technical) it is not surprising that in various heated
>discussions the participants come to different conclusions about
>wether to uphold the distinction or not, often depending upon how it
>suits their argument.  
>
>Internally to c.l.l it seems the consensus is leaning towards a
>distinction, at least amongst the more active posters who have been
>here awhile.

Although it often depends on the specific subject matter.

There was a recent thread about garbage collection (about writing it in the
language being collected).  There's not much about GC that's dependent on
the particular dialect, so this question seemed appropriate to c.l.l,
IMHO.  I think he actually posted it to both groups.

And even though Emacs Lisp is considered a Lisp, most questions about it
are more appropriate to comp.emacs or gnu.emacs.help rather than
comp.lang.lisp.  When there's a forum oriented towards any specific
dialect, the experts are more likely to be found there than in the more
general group like this one.

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

Why is Scheme not a Lisp? Rahul Jain 3/12/02 3:14 PM
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> I find I cannot honestly alter my opinion that Scheme is a Lisp.

It all depends on how you define "Lisp". Remember that meanings
change, communities change over time. At one time, scheme was a
lisp. Now Lisp has moved on, as has Scheme. Scheme people like where
Scheme has gone. Lisp people like where Lisp has gone. There's usually
not much overlap.

Also, read Kent's and Lieven's posts carefully, I think they really
show just how different the two communities are and how that can be
seen in natural language evolution as well. And what are languages
other than a way for communities to express themselves?

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Erik Naggum 3/12/02 3:20 PM
* Erann Gat

| I hesitate to ask this question because I really don't want to start a
| flame war.  To me it seems clear that Scheme is a dialect of Lisp.  The
| Scheme standard says it's a dialect of Lisp.  Many textbooks say it's a
| dialect of Lisp (e.g. Norvig's book, which has a chapter called "Scheme -
| an uncommon Lisp".  Quiennec I believe also includes Scheme as a dialect
| of Lisp.)

  The "Lisp" Scheme is a dialect of is no longer the current meaning of
  "Lisp".  It is somewhat like calling English a dialect of German because
  of ancient history that has since between invalidated by each of their
  separate evolution, Fahrvergnügen, Weltanschauung, Kindergarten, and
  Pennsylvania to the contrary notwithstanding.  There is also a very
  limited value in talking about "Germanic languages" in terms of your
  actual ability to use any of the Germanic languags.  You do not order the
  "vertebrate" in a restaurant, but generally choose between fish or bird
  or meat.  In other words, there is a time when an abstraction and a
  commonality has completely ceased to be valuable.

  Because of this accident a long time ago, people who hear that "Scheme is
  a Lisp" tend to think that what they have learned is valid for some other
  Lisps they meet, too.  Today, this is flat out wrong.  It used to be
  somewhat true _before_ Common Lisp, because "Lisp" had no particular
  direction on is own, so Scheme was not much different from the rest,
  which had many serious internal differences, which would pale the Scheme
  differences in comparison.  After Common Lisp, this is no longer true,
  because the whole point was to consolidate and compromise away those
  differences.  Therefore, there is no _present_ value to make Scheme look
  like or pretend be a Lisp.  The direction that Scheme took was _not_ part
  of this consolidation and compromise process, no matter how much this
  lexical scoping thing may be credited to Scheme (history has a way of
  showing that cross-pollination happens when the time is right), and
  Scheme is therefore the odd language out -- it left the Lisp family
  before the important shift.  Scheme is what the Lisp community did _not_
  agree upon.  That Scheme predates Common Lisp by several years strongly
  supports this view.  Those who were not enamored by Scheme, went on to
  work with the Lisp that remained.

  The Scheme that was a dialect of "Lisp" is no longer the same Scheme,
  either -- it has evolved quite a bit and in a very different direction
  than the _supposed_ other "dialects of Lisp".  By choosing a new name,
  the budding community also made it clear that it was departing from the
  rest of the Lisp fold to go independent.  When they got what they wanted,
  some mysteriously want back in the fold, and that is incomprehensible
  from an evolutionary stand-point, unless they intend to be predators on
  their heritage and want "Lisp" for themselves -- which is also what many
  object to when they hear "Scheme is a Lisp", because it no longer is in
  any meaningful sense that people immediately understand unless they are
  purposefully obtuse.

  Both of these clearly imply that it is counterproductive for both
  languages to claim to be dialects of each other, because the _evolution_
  and "growing apart" that Common Lisp and Scheme have done from whatever
  the ancient "Lisp" they could have been dialects of, is effectively
  _denied_ to have taken place when Scheme and Common Lisp are portrayed as
  just as closely related as they were, what, 25 years ago.  The message
  that is therefore actually being sent by "Scheme is a Lisp" is "neither
  Lisp nor Scheme have evolved in 25 years", and that is wrong and very,
  very counterproductive.

| Why is Scheme not a Lisp?  Does Scheme lack some necessary feature that
| is required to be considered a Lisp in your book?  Was Lisp 1.5 a Lisp?

  You _should_ be asking what "being a Lisp" means that would make "Scheme
  is a Lisp" and "Common Lisp is a Lisp" true.  The two languages and their
  attendant communities have drifted so far apart that there is nothing of
  value in their intersection.  Add D*lan to the fray, and I think there is
  actually _nothing_ left, and that "being a Lisp" is diluted beyond any
  possibly useful and informative meaning.

  So by saying "Scheme is not a Lisp" I do not deny the historical and the
  evolutionary commonality up to a particular point, I am just saying it in
  the same sense as "Homo sapiens is not a simian", although some would
  probably spend all day arguing that any evidence of evolution has yet to
  show up in, say, the Middle East.
 
///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Kent M Pitman 3/12/02 3:23 PM
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> ... I find I cannot honestly alter my opinion that Scheme is a Lisp.


> Perhaps Erann's call will unearth some new technical insight that
> will change my mind.

Are you wedded to the idea that the insight to be sought should be
technical?  Most human language divisions are not drawn on technical
lines, or, if they are, it's only among researchers and not among the
general public.  Ultimately, aren't the real issues things like "who
has the right to speak for it?" and "who has the right to change it?"
and things like that?  Whatever you think of who that might be, surely
you don't think that's decided by some sort of technical criterion...?
Why is the choice of a name, something that has no material technical
implication on any program's execution, a technical matter?

Why is Scheme not a Lisp? Erik Naggum 3/12/02 3:33 PM
* Dorai Sitaram

| I'll admit I don't want those epithets any more than the next guy, Rahul,
| but I find I cannot honestly alter my opinion that Scheme is a Lisp.

  But what is this "Lisp" that Scheme is?  I maintain that it is a concept
  evacuated by evolllution.  What is left in this concept for you?  Please
  remember that you have to accomodate D*lan users who argue the same way
  Scheme users do about the supposed Lisp nature of their pet language.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Thomas F. Burdick 3/12/02 3:43 PM
Erik Naggum <er...@naggum.net> writes:

>   So by saying "Scheme is not a Lisp" I do not deny the historical and the
>   evolutionary commonality up to a particular point, I am just saying it in
                                                       ^^^^^^^^^^^^^^^^^^^^^^

>   the same sense as "Homo sapiens is not a simian", although some would
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>   probably spend all day arguing that any evidence of evolution has yet to
>   show up in, say, the Middle East.

Terrible, terrible example, and I'm jumping on it hoping to beat
others to the punch.  The rest of your post was quite good, I just
hope the ending example doesn't color your conclusion for others[*].

[*] Totally OT: _Homo sapiens_ is an African Ape, certainly a simian.
We're far closer evolutionarily to chimpanzees and gorillas than
either of those are to orangutans, not to mention New World monkeys.
There's really no debate here (if you want debate, ask if chimpanzees
and bonobos should be genus Pan or Homo...)

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

Why is Scheme not a Lisp? Joe Marshall 3/12/02 3:44 PM

"Lieven Marchand" <m...@wyrd.be> wrote in message
news:m3pu29o6r9.fsf@localhost.localdomain...

> Scheme is not a Lisp IMO because of two types of reasons: first,
> technical, which have been argued on this group ad nauseam (the
> deepest difference there to me is that a scheme program is defined as
> a string of characters whereas a CL program is defined as a sequence
> of lists of Lisp objects.

For those insufficiently nauseated, here is something I posted
to comp.lang.lisp some time ago that argues that the notion
that ``a scheme program is defined as a string of characters''
is not supportable.

I don't offer this as an argument for or against
`Scheme is/is not a Lisp', I'm just trying to clear up a common
misconception.

------------ old post follows ------------

Near the end of R5RS, there is a section that gives a BNF grammar for
Scheme.  There are two relevant sections, the one on `Programs and
Definitions' and the one on `Expressions'.

There are two ways to interpret the right-hand-side of these grammars:
a purely textual way, or as printed representation.
For example, the rule for a conditional:

<conditional> --> (if <test> <consequent> <alternate>)

If you adopt a `purely textual' interpretation, you would say that a
conditional expression is defined the token sequence:

<(> <optional whitespace> <if> <whitespace> [expression] <whitespace>
[expression] <whitespace> [expression] <optional whitespace> <)>


Suppose instead, that the right-hand-side was interpreted as the
printed representation of the grammar.  Then,

<conditional> --> (if <test> <consequent> <alternative>)

would mean that a conditional is formed from a list of four elements,
the first being the symbol if, the second, third, and fourth being
whatever subexpressions are in the list.

If you attempt to apply the `purely textual' interpretation, you run
into numerous difficulties:

  1.  Eval takes `expressions represented as data'.  But expressions
      are defined solely as token sequences, and there is no mapping
      between expressions and data.

  2.  Many places in the text point out how useful it is to be able
      to use read to read programs.

  3.  Quasiquote (backquote) is an operation defined on lists,
      therefore it could not be used in a program.

  4.  Macros, too, would be disallowed.

  5.  The interpretation of a subform as <expression> or <datum> is
      context sensitive. For example, the second element in
      "(foo (+ a b c))" may or may not be an <expression> depending
      upon whether foo is a macro that expands into QUOTE.  If
      the external representation of expressions cannot include dotted
      lists, the reader would be required to discriminate between
      "(foo (+ a b . (c)))" and "(foo (+ a b c))" in precisely those
      contexts where foo has a macro binding -- information that is
      not available at read time!

  6.  Derived expressions are defined as macro expansions.  Macros
      accept <datum> as an argument, not <expression>.  Therefore, the
      BNF grammar for derived expressions is inconsistent with the
      recommended macro expansions.

If you instead accept that the right-hand-side of the BNF grammar is
to be interpreted as the printed representation of the list structure
by which programs are representable, *all* of the above problems
disappear.   Note that I said `representable'.  The spec does not
*require* that programs be `read' by the procedure `read', nor that
the entire program be turned into list structure before compiling, but it
*does* require that program fragments be representable and manipulable
as list structure for the purposes of eval and macro expansion, and
that the fragments behave as if they were read by read.

Why is Scheme not a Lisp? Erann Gat 3/12/02 3:42 PM
In article <sfwy9gx...@shell01.TheWorld.com>, Kent M Pitman
<pit...@world.std.com> wrote:

> First, it doesn't call itself Lisp.  It calls itself Scheme.

The introduction to R5RS says, "Scheme was the first major dialect of Lisp
to [have certain distinguishing features]".  So it does call itself a
"dialect of Lisp."

[much snippage]

> Let me turn the question around:  Make a list of the value you get from
> insisting there is not a division.

I'm not insisting on anything.  I'm just asking a question.

> Then make a list of the confusions,
> irritations, frustrations, and deadlocks that occur by merging them.
> Then ask--which list has the most weight?  For me, the answer is plainly
> one where the grief to be avoided by separation is bigger than the value
> to be gained by globbing things together.  Don't you agree?

No, but my experience has obviously been different from yours.

>  What is
> your agenda/purpose in wanting the answer to come out that we're all
> indistinguishable under a then-completely-useless predicate of Lispness?

I don't have an agenda.  I was just curious.

> I feel as if I'm missing something because it sounds like you're somehow
> injured by this, and I just don't see how.

Injured?  No.  Whatever gave you that impression?

E.

Why is Scheme not a Lisp? Erik Naggum 3/12/02 4:18 PM
* Erik Naggum

> So by saying "Scheme is not a Lisp" I do not deny the historical and the
> evolutionary commonality up to a particular point, I am just saying it in
                                                     ^^^^^^^^^^^^^^^^^^^^^^
> the same sense as "Homo sapiens is not a simian", although some would
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> probably spend all day arguing that any evidence of evolution has yet to
> show up in, say, the Middle East.

* Thomas F. Burdick


| Terrible, terrible example, and I'm jumping on it hoping to beat others
| to the punch.  The rest of your post was quite good, I just hope the
| ending example doesn't color your conclusion for others[*].
|
| [*] Totally OT: _Homo sapiens_ is an African Ape, certainly a simian.
| We're far closer evolutionarily to chimpanzees and gorillas than either
| of those are to orangutans, not to mention New World monkeys.  There's
| really no debate here (if you want debate, ask if chimpanzees and bonobos
| should be genus Pan or Homo...)

  But that is the whole point.  There are so many things that are true only
  of homo sapiens but not of other simians that talking about people as
  "simians" is completely worthless.  So it certainly seems you missed my
  point entirely and got hung up the exact same taxonomic snag that has
  caught the Scheme freaks who want it to be a Lisp.  In particular, my
  stab at the warring idiots in the Middle East was intended to communicate
  what it would mean to call somebody a "simian" today.

  Put another way: arguing that Scheme is "a Lisp" is like arguing that it
  is "a programming language".  On the one hand, of course it is.  On the
  other hand, of _course_ saying this does something in a discussion where
  people already know what a programming language is and that Scheme is one
  of them.  Take this scenario: You discuss the merits of several
  programming languages with a group of friends, and then you make a huge
  point out of Scheme being a programming language.  There are basically
  two ways to react to this: either (1) you are an annoying idiot who has
  failed to grasp what people have been talking about -- and gets whatever
  beer is left poured over your head, or (2) you are an arrogant bastard
  who denigrates every other programming language by effectively arguing
  that Scheme is the only one that _really_ merits that name -- and gets
  whatever beer is left poured over your head.  People assume that when you
  say something, it has greater value to you than to shut up, so if you
  something that is either blindingly obvious and irrelevant, it does in
  fact communicate hostility to any _thinking_ audience.  (I do not care
  much about unthinking audiences, who sometimes react very differently to
  redundant idiocy and empty, meaningless statements -- some even vote for
  the guy.)

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Erik Naggum 3/12/02 4:23 PM
* Erann Gat

| The introduction to R5RS says, "Scheme was the first major dialect of
| Lisp to [have certain distinguishing features]".  So it does call itself
| a "dialect of Lisp."

  When was this written?

| Injured?  No.  Whatever gave you that impression?

  If not you, some people sure act terribly injured if you say "Scheme is
  not a Lisp" to them or tell them to stop saying "Scheme is a Lisp".

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Daniel Barlow 3/12/02 4:08 PM
Lieven Marchand <m...@wyrd.be> writes:

> Defining what a language is in linguistics has about the same problems
> as defining a species in biology.
[...]

> In the end, it is indeed political. Serbo-Croatian was once one
> language, written in two alphabets (Latin and Cyrillic) but will
> probably grow apart under political pressure. Contrariwise, Flemish
> and Dutch were fairly apart in the 19th century and have grown more
> alike under political pressure.


"A language is a dialect with an army and a navy"

(variously attributed to Uriel Weinreich, Max Reinreich, Noam Chomsky,
Joshua Fishman ...)


-dan

--

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

Why is Scheme not a Lisp? Erann Gat 3/12/02 5:05 PM
In article <32249678...@naggum.net>, Erik Naggum <er...@naggum.net> wrote:

> * Erann Gat
> | The introduction to R5RS says, "Scheme was the first major dialect of
> | Lisp to [have certain distinguishing features]".  So it does call itself
> | a "dialect of Lisp."
>
>   When was this written?

R5RS is dated 20 February 1998.  It's the most recent Scheme standard.

> The two languages and their
>   attendant communities have drifted so far apart that there is nothing of
>   value in their intersection.

What about the use of S-expressions to represent both code and data?

E.

Why is Scheme not a Lisp? Larry Clapp 3/12/02 6:12 PM
In article <gat-120302...@eglaptop.jpl.nasa.gov>, Erann Gat wrote:
> So my question is directed to those of you who say that Scheme is not a
> Lisp, notably Erik, but I gather that there are many out there who agree
> with him.  Why is Scheme not a Lisp?  Does Scheme lack some necessary
> feature that is required to be considered a Lisp in your book?  Was Lisp 1.5
> a Lisp?

If you ask me (and you sort of did :), the problem arises in part from the use
of "is".  See www.generalsemantics.org and in particular
http://www.generalsemantics.org/eprime/contents.htm and other articles on
E-prime, which describe speaking and writing English without the use of the
verb "to be".

Kent, I think, dealt with this issue very clearly and yet subtly.  Omitting
much excellent and thoughtful writing, I might make free to summarize Kent's
article: "Scheme has these characteristics and this community, and Common Lisp
has these other characteristics and this other community.  While these
characteristics and communities overlap in some places, they diverge in many
much more important places."[1]

I don't think one can say that a) Common Lisp comes from a subset of Scheme,
b) Scheme comes from a subset of Common Lisp, c) Common Lisp and Scheme form
different subsets of some larger language, or d) Common Lisp and Scheme form
different supersets of some smaller language.[2]

You can (maybe) say that Common Lisp and Scheme diverged from a common
ancestor (should I give a link to the talk.origins FAQ?  ;), but not much
else.

My US$0.02.

-- Larry


[1] Any errors in this summary come from me, of course.

[2] Note: I don't accuse you or anyone of making any of these claims.

Why is Scheme not a Lisp? Geoffrey Summerhayes 3/12/02 7:57 PM

"Erann Gat" <g...@jpl.nasa.gov> wrote in message
news:gat-1203021705570001@eglaptop.jpl.nasa.gov...
> In article <32249678...@naggum.net>, Erik Naggum <er...@naggum.net>
wrote:
>
> > * Erann Gat
> > | The introduction to R5RS says, "Scheme was the first major dialect of
> > | Lisp to [have certain distinguishing features]".  So it does call
itself
> > | a "dialect of Lisp."
> >
> >   When was this written?
>
> R5RS is dated 20 February 1998.  It's the most recent Scheme standard.
>

LOL Good comeback.

I have a published copy of Hamlet with the date 1994. What does
say about when, "I am but mad north-north-west. When the wind is
southerly, I know a hawk from a handsaw." was penned?

Take a look at the introduction to R4RS and think recursively. :-)

-------------

Geoff

Why is Scheme not a Lisp? Christopher C. Stacy 3/12/02 9:20 PM
The "Is Scheme a Lisp" debate implies that there is an answer to
the following question: "What is Lisp?".   Good luck.

Anyway, as KMP will no doubt write, these are political questions
about different camps and self-identities.  When the ensuing flame
war dies down to a smolder, there will still be no definitive answer.

Why is Scheme not a Lisp? Christopher C. Stacy 3/12/02 9:33 PM
>>>>> On Tue, 12 Mar 2002 23:20:41 GMT, Erik Naggum ("Erik") writes:
 Erik>   people who hear that "Scheme is a Lisp" tend to think that
 Erik>   what they have learned is valid for some other Lisps they
 Erik>   meet, too.

This goes to the reason why I make the distinction, and is
exactly the same as when around 1982 I used to have to explain
that "Lisp" does not mean: "Lisp 1.5, as badly explained to you".
The technicalities are different in those two examples, but the
problem is the same: a bunch of incorrect assumptions and
misunderstandings that will make a useful discussion difficult.

Why is Scheme not a Lisp? Rahul Jain 3/12/02 9:30 PM
cst...@theworld.com (Christopher C. Stacy) writes:

> Anyway, as KMP will no doubt write, these are political questions
> about different camps and self-identities.

This just made me think of the Republican and Democratic parties in
the US. They were originally the same party, which split some time in
the mid 19th century or so, IIRC.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/12/02 10:26 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> This just made me think of the Republican and Democratic parties in
> the US. They were originally the same party, which split some time in
> the mid 19th century or so, IIRC.

No, you recall incorrectly.

The Democratic party dates back to a previous party named the
"Democratic Republican Party", which was an opponent of the Federalist
Party.  The Democratic Republicans wanted the US to be a "democratic
republic", you see; the Federalists stressed the federal system.

The Democratic Republicans morphed their name into the Democrats, for
the obvious reason--a shorter name is better; that happened when
Andrew Jackson was president.  (He was elected in 1824 as a Democratic
Republican, and in 1828 as a Democrat.)  

The Democratic Republicans trounced the Federalists very quickly, in
1800.  There was a "National Republican" party of some brief note, and
some coalition opponents as well, but from 1801 to 1840,with the sole
exception of the 1824 election, the Democratic Republicans ruled the
White House.  The Whig party was formed to offer credible opposition
to the Democrats, and did win the White House in 1840, and things went
back and forth until the Republican Party was formed.

The Republicans were brand spankin new; they first contended in 1856,
and then won the White House in 1860 under Abraham Lincoln.

Since that time, it's mostly been the Republicans and the Democrats,
though some Democratic Presidential candidates ran under double
affiliations, linking up with the Progressives or the Liberal
Republicans.  Teddy Roosevelt ran in 1912 as a Progressive (and lost
to Woodrow Wilson).

Thomas

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/12/02 10:29 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Here's my rationale: If Scheme were a lisp, it would call itself a
> Lisp. Does Java call itself a C? No, because it's not a C.

But Scheme does call itself a Lisp!

The very beginning of the R5RS reads:

"The report gives a defining description of the programming language
Scheme. Scheme is a statically scoped and properly tail-recursive
dialect of the Lisp programming language invented by Guy Lewis Steele
Jr. and Gerald Jay Sussman."

Thomas

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/12/02 10:32 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> I think it's a small group of insecure Scheme users who think that
> they should be considered "A Lisp" so that they get all the
> "publicity" that Lisp does along with the publicity that Scheme does.

People like that indeed have a problem.  Scheme doesn't want to be "a
Lisp" so that it gets some publicity or caché.  Or at least, sensible
people shouldn't be caring about such things.

> What those Schemers get from defaming Lisp beats me. Probaby some sort
> of jealous envy. If they really like Scheme, I don't see why they
> should need to dupe others out of wanting to learn Lisp.

Maybe you've misunderstood them.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/12/02 10:33 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> It all depends on how you define "Lisp". Remember that meanings
> change, communities change over time. At one time, scheme was a
> lisp. Now Lisp has moved on, as has Scheme. Scheme people like where
> Scheme has gone. Lisp people like where Lisp has gone. There's usually
> not much overlap.

I'm a Scheme person.  And I like where Scheme has gone.

I also like where Common Lisp has gone.

Why should I pick?  Both are cool languages.

Thomas

Why is Scheme not a Lisp? Thaddeus L Olczyk 3/13/02 12:38 AM
On 12 Mar 2002 23:30:23 -0600, Rahul Jain
<rj...@sid-1129.sid.rice.edu> wrote:

>cst...@theworld.com (Christopher C. Stacy) writes:
>
>> Anyway, as KMP will no doubt write, these are political questions
>> about different camps and self-identities.
>
>This just made me think of the Republican and Democratic parties in
>the US. They were originally the same party, which split some time in
>the mid 19th century or so, IIRC.
>
>--
>-> -/                        - Rahul Jain -  
aka A person stupid enough to advertise his ignorance of American
history by making false statements about it.

Why is Scheme not a Lisp? Thaddeus L Olczyk 3/13/02 12:44 AM
On Tue, 12 Mar 2002 12:00:23 -0800, g...@jpl.nasa.gov (Erann Gat)
wrote:

Use the simple and most basic test of whether or not Scheme is a Lisp.

Assume you take a standard text book ( say one of the following
ACL by Paul Graham, Dr. Touretsky's book, Successful Lisp
or David Coopers book ). Assuming you have no previous experience
in Lisp ( or Scheme). Instal a Scheme compiler and start writing for
it. How much do you have to thumb through a Scheme reference.
If it's significantly less than the amount a C programmer thumbs
through a Pascal reference when writing a Pascal program, then
Scheme is a Lisp. If not then Scheme is not a Lisp. ( BTW no
C programmer or Pascal programmer would claim C is a dialect of Pacal.
)

Why is Scheme not a Lisp? Kent M Pitman 3/13/02 1:52 AM

I'm worried that the same test, done in reverse, with a Scheme text and
a Lisp compiler would conclude that Lisp is a Scheme.  That seems a bad
property of the test.  It tests distance, not containment.

Also, when I first learned to program, it was with FORTRAN on punch cards on
an IBM 1130.  Then our school bought a WANG 2200S minicomputer that
ran BASIC and I thumbed through a manual.  I had no sense then of the
space of computer languages.  I had seen only FORTRAN.  My initial
assumption was that BASIC was just a FORTRAN variant.  Had I used
your test, I might well have concluded that it confirmed my suspicions.

And also, I think both C and Pascal are members of the Algol family.
But your test seems to presuppose they are unrelated languages.  Then
again, my purpose in relating these languages, when I do, is mostly to
make broad classifications of languages.  This has almost no
operational meaning other than "they share the notion of block
stucture and infix notation".  That's pretty weak and useless in most
cases.  It's often useful to divide the world along certain axes for
momentary purposes of conversation; that's not the same as saying that
it's the right way to describe them.

Historically, as part of the civil rights struggles, people of various
races, and even women of any race, have fought not to be viewed as "objects".
Are they objects?  Are you and I objects?  Well, we're not abstracts.  
If we were coding us up, we'd probably do
 (defclass person (animal) ...)
 (defclass animal (live-object) ...)
 (defclass live-object (object) ...)
But that doesn't mean this is our best view.  Referring to a person as an
object is to say "you can get away without understanding any of the more
specialized purposes that have come since" or "there are no new insights to
be had by considering a more specific type".

Sometimes it is good to ignore more specific types.  For example, when we
refer to floats, we often ignore double-float vs single-float because most
of the time dealing in the abstract is less confusing.  Sometimes when we
refer to error conditions, it suffices just to know an error has happened,
and the fact of the error kind is very much "in the noise".

The most often reason language families come up in conversation is to say
"are there legitimate new ideas between X and Y such that if I know X it's
still worth learning Y."  I think Scheme has ideas Common Lisp doesn't.
I think Common Lisp has ideas Scheme doesn't.  Both of these facts argue for
separation.  (Even back to my C example, the same can be said for C and
Pascal, which is why I say they are part of the Algol family, which is more
just a statement of historical pedigree than a statement of now-truth.)

I'm comfortable with the analogy raised earlier by Erik about
Germanic.  You can say English is a Germanic language.  I don't know
what good it does, but you can say it.  And yes, you can say Scheme is
part of the Lisp family of languages.  But English is its own
language, not a dialect of German.  To view English as a Germanic language
is to say "those changes that have happened since are minor" (which might be
true and useful to some linguists in a highly technical conversation on a
narrow and obscure technical point, but is not true of most people in most
practical situations).

Scheme is its own language, not a dialect of Lisp.  There is a strong
separation of culture, direction, and practice. To assert it is not
its own language is to deny the importance of those differences and to
call into question all that Scheme has sought to build.  It is, in simple
terms, an insult to Scheme.  

Scheme and Lisp are fundamentally different way than British and American
are different.  British and American are different in pronunciation and in
this and that choice of random word, but most of those differences are mere
nuissance more than an attempt to prove a point.

The separations of ISLISP, Emacs Lisp, and Common Lisp are more like English
and British, where the mere fact of differing points of authority makes for
some drift, but where the fundamental underlying theses of the language are
not really majorly different.  These dialects are not intentionally different,
they are merely different because they had different target needs and because
their creators didn't want the administrative overhead of coordinating every
little change with each other's communities.  But they didn't go out of their
way to cut ties with the past, they just wanted administrative streamlining.

Even Dylan can be called part of the Lisp language family, if you mean
it in the historical sense of Erik's "Germanic" analogy, though I
certainly again would not call it a dialect of Lisp.  And, moreover,
in the case of German, the Dylan marketeers of the past not only chose
a new direction, but some of them actively worked to get a "divorce"
from the Lisp language family because they didn't like the baggage it
carried with it and didn't even want to claim access to their
pedigree.  But Dylan is its own language because it sought to really
do something different than what came before.  And it would be an
insult again to Dylan to suggest it is a mere dialect of Lisp.

- - - -

I started to tell a story the other day, and I don't recall sending the post,
so I'll risk repeating myself because it was a keen observation:

I took a course at MIT from the late Prof. Bill Martin, who made the following
observation about terminological overloading in type trees (paraphrased from
memory):

 The world is divided into inert things and animals.  Among animals, of course,
 there are animals, vegetables, and minerals.  Of those animals, though, there
 are things like insects and then there are "real" animals.  Among animals,
 there are people and then there are animals.  Among people, there are
 civilized people, and then there are animals.

Maybe we should take a page from Bill's book and before we go much farther
in this conversation, acknowledge that linguistic overloading permitting us
to talk at crossed purposes uselessly, without even being sure we're all
talking about the same thing.  We're more likely sparring over the relatively
useless question of "who gets to decide what 'language' means".  Chris


Stacy was 100% right in a recent post when he wrote:

 Anyway, as KMP will no doubt write, these are political questions
 about different camps and self-identities.  When the ensuing flame
 war dies down to a smolder, there will still be no definitive answer.

The only way in which Chris failed in his prediction is that he should
have said "as KMP will no doubt write (in more detail than should be
really necessary)".  I like his summary and should have just gone with it.

Unless I see something new of substance here, I'm going to stop posting
on this thread because, interesting/fun as sparring over this useless topic
is, Chris is right.  It's got no hope of going anywhere, and so ultimately
we'll just have to decide we've said what is to be said and then stop.
For now, I've said what I have to say.

Why is Scheme not a Lisp? Juanma Barranquero 3/13/02 6:39 AM
On Tue, 12 Mar 2002 21:16:13 GMT, Barry Margolin <bar...@genuity.net>
wrote:

>He gives numerous examples of
>pairs of languages that are easily intelligible between their respective
>speakers, but are considered separate languages mostly due to nationalistic
>attitudes; e.g. the Scandinavian languages and Spanish vs. Portugese.

Hmm. No.

There are certainly lots of "languages" considered separate due to
nationalistic attitudes. Just here, in Spain, there are people who
consider as distinct languages català (catalonian), valencià and
mallorquí even if it is easy to prove that speakers are mutually
intelligible. Something similar happens with portuguese and gallego
(galician). But as a Spaniard who's lived in Brazil and visited
Portugal, and whose wife is Brazilian, I can assure you Portuguese and
Spanish are very different. Usually the Portuguese can understand
Spanish with a little effort, even if they aren't able to speak it;
but most Spaniards do *not* understand Portuguese, and even less yet
Brazilian Portuguese.

I'm not being nationalistic here. I like languages a lot and would
cause me no distress to accept Spanish and Portuguese as the same
language; but the fact is that after a full year on Brazil I
understood Portuguese reasonably well but was utterly unable to speak
more than a few stock idioms :)

It is obvious that all latin languages do share some vocabulary and
grammar; but we're talking of more than 1,000 years of separate
development. Just consider how different is Chaucer's English from the
modern language :)

/L/e/k/t/u

Why is Scheme not a Lisp? Dorai Sitaram 3/13/02 6:43 AM
In article <sfw7koh...@shell01.TheWorld.com>,
Kent M Pitman  <pit...@world.std.com> wrote:
>ds...@goldshoe.gte.com (Dorai Sitaram) writes:
>
>> ... I find I cannot honestly alter my opinion that Scheme is a Lisp.
>> Perhaps Erann's call will unearth some new technical insight that
>> will change my mind.
>
>Are you wedded to the idea that the insight to be sought should be
>technical?  Most human language divisions are not drawn on technical
>lines, or, if they are, it's only among researchers and not among the
>general public.  Ultimately, aren't the real issues things like "who
>has the right to speak for it?" and "who has the right to change it?"
>and things like that?  Whatever you think of who that might be, surely
>you don't think that's decided by some sort of technical criterion...?
>Why is the choice of a name, something that has no material technical
>implication on any program's execution, a technical matter?

Sure, whatever flavor of insight is fine.  It's just
that "political reality"-type arguments wouldn't need
explicit belaboring, as everyone would feel it in their
bones already.  The reason I specified "technical" was
because it would be much easier both to offer and to
accept.  If you could just toss in some convincing
insight amid the "politically plausible"
analogizing, I would have no problem being an
early convert to your view, well before it became
political reality.

--d

Why is Scheme not a Lisp? Wade Humeniuk 3/13/02 8:08 AM
"Erann Gat" <g...@jpl.nasa.gov> wrote in message
news:gat-1203021200230001@eglaptop.jpl.nasa.gov...
>
> I hesitate to ask this question because I really don't want to start a
> flame war.  To me it seems clear that Scheme is a dialect of Lisp.  The
> Scheme standard says it's a dialect of Lisp.  Many textbooks say it's a
> dialect of Lisp (e.g. Norvig's book, which has a chapter called "Scheme -
> an uncommon Lisp".  Quiennec I believe also includes Scheme as a dialect
> of Lisp.)

>
> So my question is directed to those of you who say that Scheme is not a
> Lisp, notably Erik, but I gather that there are many out there who agree
> with him.  Why is Scheme not a Lisp?  Does Scheme lack some necessary
> feature that is required to be considered a Lisp in your book?  Was Lisp
> 1.5 a Lisp?

Both Scheme and CL have concrete specifications, they are specific languages
and by inspection you can tell one from the other.  From your question there
seems to be an implication there is a "Lisp" which is independent of
specific implementations.  A kind of abstract Lisp much like the idea of
thought-form of a tree as opposed to  a specific tree (say a pine).  This
Thought-Form-Lisp (TFL) has never existed but seems to be exerting a force
on the development of languages like Scheme and now maybe Arc.  It may arise
because of intrinsic insights that the Lisps have into programming in
general (evidenced by how other programming languages start out small and
then start to implement Lisp features because they are necessary).  I know
that I am certainly attracted to Lisp for some deeper reason.  Maybe people
have been caught by the aesthetics of their TFL.  It could explain why
people can be so attached to the language which expresses their TFL best and
some people's frustrations (because of reality constraints) of not being
able to manifest their TFL.  This also may explain some people's anger at CL
because of its the gall it shows by "specifying" Lisp.

Wade


Why is Scheme not a Lisp? Will Hartung 3/13/02 8:37 AM
"Thaddeus L Olczyk" <olc...@interaccess.com> wrote in message
news:3c91101b.50489765@nntp.interaccess.com...

Ok, I'll bite...put my tounge firmly in cheek here, and preface this with
"Be careful what you wish for ...".

I grabbed this off of Grahams site, it's his POV Ray Trace program from ACL.
Used without permission.

(defun sq (x) (* x x))

(defun mag (x y z)
  (sqrt (+ (sq x) (sq y) (sq z))))

(defun unit-vector (x y z)
  (let ((d (mag x y z)))
    (values (/ x d) (/ y d) (/ z d))))

(defstruct (point (:conc-name nil))
  x y z)

(defun distance (p1 p2)
  (mag (- (x p1) (x p2))
       (- (y p1) (y p2))
       (- (z p1) (z p2))))

(defun minroot (a b c)
  (if (zerop a)
      (/ (- c) b)
      (let ((disc (- (sq b) (* 4 a c))))
        (unless (minusp disc)
          (let ((discrt (sqrt disc)))
            (min (/ (+ (- b) discrt) (* 2 a))
                 (/ (- (- b) discrt) (* 2 a))))))))


(defstruct surface  color)

(defparameter *world* nil)
(defconstant eye (make-point :x 0 :y 0 :z 200))

(defun tracer (pathname &optional (res 1))
  (with-open-file (p pathname :direction :output)
    (format p "P2 ~A ~A 255" (* res 100) (* res 100))
    (let ((inc (/ res)))
      (do ((y -50 (+ y inc)))
          ((< (- 50 y) inc))
        (do ((x -50 (+ x inc)))
            ((< (- 50 x) inc))
          (print (color-at x y) p))))))

(defun color-at (x y)
  (multiple-value-bind (xr yr zr)
                       (unit-vector (- x (x eye))
                                    (- y (y eye))
                                    (- 0 (z eye)))
    (round (* (sendray eye xr yr zr) 255))))

(defun sendray (pt xr yr zr)
  (multiple-value-bind (s int) (first-hit pt xr yr zr)
    (if s
        (* (lambert s int xr yr zr) (surface-color s))
        0)))

(defun first-hit (pt xr yr zr)
  (let (surface hit dist)
    (dolist (s *world*)
      (let ((h (intersect s pt xr yr zr)))
        (when h
          (let ((d (distance h pt)))
            (when (or (null dist) (< d dist))
              (setf surface s hit h dist d))))))
    (values surface hit)))

(defun lambert (s int xr yr zr)
  (multiple-value-bind (xn yn zn) (normal s int)
    (max 0 (+ (* xr xn) (* yr yn) (* zr zn)))))


(defstruct (sphere (:include surface))
  radius center)

(defun defsphere (x y z r c)
  (let ((s (make-sphere
             :radius r
             :center (make-point :x x :y y :z z)
             :color  c)))
    (push s *world*)
    s))

(defun intersect (s pt xr yr zr)
  (funcall (typecase s (sphere #'sphere-intersect))
           s pt xr yr zr))

(defun sphere-intersect (s pt xr yr zr)
  (let* ((c (sphere-center s))
         (n (minroot (+ (sq xr) (sq yr) (sq zr))
                     (* 2 (+ (* (- (x pt) (x c)) xr)
                             (* (- (y pt) (y c)) yr)
                             (* (- (z pt) (z c)) zr)))
                     (+ (sq (- (x pt) (x c)))
                        (sq (- (y pt) (y c)))
                        (sq (- (z pt) (z c)))
                        (- (sq (sphere-radius s)))))))
    (if n
        (make-point :x  (+ (x pt) (* n xr))
                    :y  (+ (y pt) (* n yr))
                    :z  (+ (z pt) (* n zr))))))

(defun normal (s pt)
  (funcall (typecase s (sphere #'sphere-normal))
           s pt))

(defun sphere-normal (s pt)
  (let ((c (sphere-center s)))
    (unit-vector (- (x c) (x pt))
                 (- (y c) (y pt))
                 (- (z c) (z pt)))))

(defun ray-test (&optional (res 1))
  (setf *world* nil)
  (defsphere 0 -300 -1200 200 .8)
  (defsphere -80 -150 -1200 200 .7)
  (defsphere 70 -100 -1200 200 .9)
  (do ((x -2 (1+ x)))
      ((> x 2))
    (do ((z 2 (1+ z)))
        ((> z 7))
      (defsphere (* x 200) 300 (* z -400) 40 .75)))
  (tracer (make-pathname :name "spheres.pgm") res))

To get this to work in Scheme I had to:

o Change all of the (defun ...) to (define). Same with (defconstant ...) and
(defparameter ...)

That mostly worked, except for tracer. Scheme didn't have any idea what to
make of that, and didn't seem to have a facility to handle the optional,
defaulted parameter. I guess I have to do it myself.

o Implement all of the defstructs

Scheme doesn't have defstruct, so I had to do all of that from scratch, I
happened to choose lists to do it. Also, I hade to manually perform the
:include in the (defstruct sphere).

o replace all of the (when...), (unless...) forms with appropriate if
statements. I'm sure I could have written (define-syntax ...) structures,
but using the ifs was much easier as I'm unfamiliar with (define-syntax
...).

o needed to define (zerop ..) and (minusp ...)

o I couldn't find an equivalent to (dolist ...), so I used (for-each ...)
and (lambda ...) instead, though the other (do...) forms seem to work.

o I had to write (1+ ...)

o I eleminated the (funcall ...) completely, as they're not necessary.

o I converted the (typecase ...) to a (case...), but I also had to go back
and "type" my lists-that-are-structures so I could test on something, but
since I already had to implement that, what's a little bit more at this
point. Of course, I had to remove the #' reader macros as well.

o The (with-open-file ...) to (with-output-to-file ...).
o No (format ...), so I had to make do with (write ...)
o Apparently Scheme doesn't know about (make-pathname ...) either, so I just
used a string.

Finally, all of the multi-value-bind stuff had to be converted to lists that
were constructed and deconstructed by hand. That was fun.

I think that's about it. Other than that, you're right, it was easy. Any
inexperienced Lisp/Scheme programmer would have had no problem.

Mind you, I used the R5RS reference as a guide for Scheme, not any
particular implementation. It was a thought exercise, and I may have missed
some things. I know there are more capable Schemes out there that would have
made this task easier (if not trivial).

For extra credit, I dumped the code into EMACS and hit M-x eval-buffer. It
complained about (defparameter ...) and (defconstant ...), other than that
it seemed to compile straight away, though I did not run it. Also, I don't
know if my EMACS has the "Common Lisp" package installed. It's a
pre-compiled binary for windoze that I downloaded, and I've never checked.

Now, going the other way around, from Scheme to Lisp would have probably
been MUCH easier (call/cc not withstanding). So, perhaps CL is a Scheme?

:-) ^ 100

Best Regards,

Will Hartung
(vft...@cox.net)


Why is Scheme not a Lisp? Matthias Blume 3/13/02 7:48 AM
On Tue, 12 Mar 2002 15:00:23 -0500, Erann Gat wrote:


> I hesitate to ask this question because I really don't want to start a
> flame war.  To me it seems clear that Scheme is a dialect of Lisp.  The
> Scheme standard says it's a dialect of Lisp.  Many textbooks say it's a
> dialect of Lisp (e.g. Norvig's book, which has a chapter called "Scheme
> - an uncommon Lisp".  Quiennec I believe also includes Scheme as a
> dialect of Lisp.)
>
> So my question is directed to those of you who say that Scheme is not a
> Lisp, notably Erik, but I gather that there are many out there who agree
> with him.  Why is Scheme not a Lisp?  Does Scheme lack some necessary
> feature that is required to be considered a Lisp in your book?  Was Lisp
> 1.5 a Lisp?
>
> Please note that I don't want to get into the argument about whether or
> not Scheme is or is not a Lisp.  I'm just interested in hearing from
> those people who already believe that it isn't what their rationale is.

The following question is somewhat related:

Would the Lisp as McCarthy originally envisioned it be considered a Lisp?
Back then?  Today?

IIRC, the S-expression form of Lisp was created (contrary to what
has been said here numerous items) "to prove a point".  It was a
strictly-for-paper-and-eyeballs-only implementation of EVAL that someone
else (a student or coworker of McCarthy? -- I forget the details) then
took and implemented (to the initial disgust of McCarthy).  McCarthy devised EVAL
as a proof-of-concept, showing how the Lisp he envisioned (with a rather
different, more Algolish-looking syntax) has its very own universal
function.

What McCarthy wanted Lisp to look like was called the "meta language" aka
M-expressions.  (Is it pure coincidence that today there is another computer
language whose name is the acronym for "Meta Language"?)

Matthias

PS: To the person who said that ML was created to "prove a point":  You
are absolutely right, literally.  :-)

Why is Scheme not a Lisp? Doug Quale 3/13/02 9:45 AM
Kent M Pitman <pit...@world.std.com> writes:

> I'm worried that the same test, done in reverse, with a Scheme text and
> a Lisp compiler would conclude that Lisp is a Scheme.  That seems a bad
> property of the test.  It tests distance, not containment.

The essential problem with all these sorts of arguments is that you
repeatedly assume your own conclusion.  What is a lisp compiler or a
lisp text?  You always equate Lisp with Common Lisp.  This is very
sly, but it doesn't make a sound argument.  (Technically speaking,
this is begging the question.)  The Lisp family is a family of
languages, not a single language.

Although you've banged hard on the community angle, an objective view
of language families needs to consider at least these factors:

- history
- community
- syntax
- semantics

The question has been raised repeatedly, what does it mean to say "X
is a Lisp", or what advantage does it give?  "Scheme is a Lisp", or
more fully "Scheme is a member of the lisp language family" emphasizes
the substantial common ground in those four important areas with other
members of the lisp family.  I think this is useful.  Obviously some
Common Lisp fans do not.

An interesting comparison can be made with the Algol family of
languages.  This family includes Algol 60 as the founding member and
has many members including Algol-W, PL/1, Pascal, C and Ada.  The
Algol family includes members that are far more different that Common
Lisp and Scheme.  No one would ever confuse Algol 60 and Ada, but they
are members of the Algol family all the same.

Kent has argued rationally that Scheme is not a Lisp, but most people
arguing in favor of that view have not been so dispassionate.  The
interesting thing is that for some Common Lisp users, the question of
whether Scheme is a Lisp is a religious one rather than a technical
one.  I can't even imagine that level of emotion in a discussion
between Pascal and C partisans about the common cultural and
historical origins of their languages, although they can disagree very
heatedly about the relative merits of their chosen languages.  (By way
of contrast, I think from a Scheme or Common Lisp point of view, many
might say the differences between Pascal and C aren't very important.)

Despite what some Scheme haters in c.l.l say, I think very few Scheme
users have any strong intellectual or emotional investment in this
question.  I think the initial inquiry was prompted more by a desire
to understand the venom displayed towards Scheme in c.l.l than a need
to prove anything.  "Why do they hate us?" has gained a lot of
attention recently in areas much more important than computer
programming languages.

As a final thought, it's quite funny that someone can say that Common
Lisp is a lisp-2 and Scheme is a lisp-1, and then in the next breath
say Scheme is not a Lisp.


--
Doug Quale

Why is Scheme not a Lisp? Erik Naggum 3/13/02 10:15 AM
* tb+u...@becket.net (Thomas Bushnell, BSG)

| But Scheme does call itself a Lisp!
|
| The very beginning of the R5RS reads:
|
| "The report gives a defining description of the programming language
| Scheme. Scheme is a statically scoped and properly tail-recursive dialect
| of the Lisp programming language invented by Guy Lewis Steele Jr. and
| Gerald Jay Sussman."

  But how can you trust a specification that says the Lisp programming
  language was invented by Guy Lewis Steele, Jr., and Gerald Jay Sussman?

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Nils Goesche 3/13/02 10:29 AM
In article <32250321...@naggum.net>, Erik Naggum wrote:
> * tb+u...@becket.net (Thomas Bushnell, BSG)
>| But Scheme does call itself a Lisp!
>|
>| The very beginning of the R5RS reads:
>|
>| "The report gives a defining description of the programming language
>| Scheme. Scheme is a statically scoped and properly tail-recursive dialect
>| of the Lisp programming language invented by Guy Lewis Steele Jr. and
>| Gerald Jay Sussman."
>
>   But how can you trust a specification that says the Lisp programming
>   language was invented by Guy Lewis Steele, Jr., and Gerald Jay Sussman?

Hehehe - one should submit a bug report asking them to put claims
like that in denotational semantics in the future :-)

Regards,
--
Nils Goesche                          PGP key ID 0x42B32FC9

"The sooner all the animals are dead, the sooner we'll find
 their money."                              -- Ed Bluestone

Why is Scheme not a Lisp? Dorai Sitaram 3/13/02 10:35 AM
In article <a6noi8$gk6$1...@news.gte.com>, Dorai Sitaram <ds...@gte.com> wrote:
>In article <sfw7koh...@shell01.TheWorld.com>,
>Kent M Pitman  <pit...@world.std.com> wrote:
>>
>>Are you wedded to the idea that the insight to be sought should be
>>technical?  Most human language divisions are not drawn on technical
>>lines, or, if they are, it's only among researchers and not among the
>>general public.  Ultimately, aren't the real issues things like "who
>>has the right to speak for it?" and "who has the right to change it?"
>>and things like that?  Whatever you think of who that might be, surely
>>you don't think that's decided by some sort of technical criterion...?
>>Why is the choice of a name, something that has no material technical
>>implication on any program's execution, a technical matter?
>
>[my reply snipped]

Kent, I replied in good faith because I thought your
extensive set of questions specifically addressed
to me were in expectation of an answer.  

I learned too late from another article of yours (to
someone else) that you had publicly announced
your withdrawal from the dicussion.  

I am not a big fan of these staged withdrawals --
however it's your privilege.  How about a little
email heads-up next time you adopt this approach?

Cheers,

--d

Why is Scheme not a Lisp? Erik Naggum 3/13/02 10:55 AM
* Erann Gat
| The introduction to R5RS says, "Scheme was the first major dialect of
| Lisp to [have certain distinguishing features]".  So it does call itself
| a "dialect of Lisp."

* Erik Naggum
> When was this written?

* Erann Gat


| R5RS is dated 20 February 1998.  It's the most recent Scheme standard.

  OK, I see I have to be extremely explicit here.  That bores the hell out
  of me, so I am not going to repeat the effort.

  When people write something, they do so in a particular context, even
  though they are not necessarily consciously aware of this context.  In
  particular, the meaning of a word is contextual and the external
  references refer to other things as they both exist and are understood by
  the particular person at that particular time.  In particular, a sentence
  like the above might have been true once, but the common referent for
  "Lisp" may change, so it has to be understood in its historical context.
  The Bible works that way, and people have to assume (or "temporarily
  adopt", since you have demonstrated problems understanding this word,
  too) a special context to understand it properly.  The same is true of
  most non-fiction, actually, and the more specialized some area is, the
  more context becomes explicit.  In fact, the bibliographic references of
  a scientific paper works to establish the context in which the paper is
  written as well as its soundness.  In particular, a scientific paper
  makes its position in time very explicit through its bibliographic
  references, and thus establish the time-dependent meaning of any term,
  the time-dependent status of any theory, and the time-dependent referents
  of a concept.  The ability to understand that something changes in time,
  that it is indeed a "fourth dimension" that we travel through, seems to
  take some time for many people to develop, and the ability to understand
  that some words (like "gay", "negro") may change dramatically in meaning
  over a few years is usually resisted by some people who "liked" the old
  meaning (like "hacker").  So, too, is the case with the meaning of "Lisp"
  that Scheme freaks want to enforce, but they are dishonest, sloppy people
  with little or no experience in writing scientific papers (or this is a
  sloppiness done on purpose, which may be worse), because they have _not_
  provided the particular time-dependent reference of "Lisp" as they have
  used it.

  Also note that I did not ask when the line was "published".  I asked when
  it was _written_, specifically in order to request the time-dependent
  context of the particular sentence, since the sloppy writers somehow
  managed to omit that information in the otherwise anal-retentively
  detail-driven accuracy in that document.  There is often a remarkable
  difference between the time of writing and the time of publication that I
  hope you will understand some day so I do not have to be extremely
  explicit about that difference, too.

  Sometimes I wonder if you are intentionally obtuse or if you cannot help
  it.  I keep hoping that you can do better, which is probably why it is so
  annoying that you do not.  Let me know if I should stop hoping.

> The two languages and their attendant communities have drifted so far
> apart that there is nothing of value in their intersection.

| What about the use of S-expressions to represent both code and data?

  How about using characters to represent source code?

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erann Gat 3/13/02 10:36 AM

Thanks to all who responded to "Why is Scheme not a Lisp."

My own view, FWIW, is that the essence of Lisp is the use of S-expressions
to represent both code and data.  On that view, both Common Lisp and
Scheme are Lisps, and Python and Dylan are not.  (I realize that this view
is at odds with McCarthy's original idea, but this would not be the first
time that the person who came up with a great idea didn't immediately
recognize it for what it was.)

This is a view shared by many of my colleagues who are not computer
scientists or software engineers.  In their mind, Lisp == S expressions.
If a function call is written (f x y z) instead of f(x,y,z) then it's
Lisp.  (This view has been the source of a great deal of frustration for
me, because S-expressions are useful in contexts other than programming
languages, but the prejudice against Lisp extends to the use of
S-expressions in non-programming contexts.  But that's another story.)

So I have another question directed to those who say Scheme is not a Lisp:
is the concept of "programming language with S-expression-based syntax"
not important enough to deserve its own less verbose term?  If it is, what
should that term be if not "Lisp"?  And if it isn't, what is it about Lisp
that you think is more important?

Remember, if you think Scheme is a Lisp then there's no need to respond.
I'm not interested in starting a debate.  I just want to understand the
Scheme != Lisp pont of view.

Thanks,
E.

Why is Scheme not a Lisp? Julian Stecklina 3/13/02 11:37 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> g...@jpl.nasa.gov (Erann Gat) writes:
>
> > I'm just interested in hearing from those people who already believe
> > that it isn't what their rationale is.
>
> Here's my rationale: If Scheme were a lisp, it would call itself a
> Lisp. Does Java call itself a C? No, because it's not a C.


This is a strange argument. E.g. Delphi is a PASCAL. Judging the name
is not really constructive.

Regards,
Julian
--
Meine Hompage: http://julian.re6.de

Um meinen oeffentlichen Schluessel zu erhalten:
To get my public key:
http://math-www.uni-paderborn.de/pgp/

Why is Scheme not a Lisp? Kent M Pitman 3/13/02 11:41 AM
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> In article <a6noi8$gk6$1...@news.gte.com>, Dorai Sitaram <ds...@gte.com> wrote:
> >In article <sfw7koh...@shell01.TheWorld.com>,
> >Kent M Pitman  <pit...@world.std.com> wrote:
> >>
> >>Are you wedded to the idea that the insight to be sought should be
> >>technical?  Most human language divisions are not drawn on technical
> >>lines, or, if they are, it's only among researchers and not among the
> >>general public.  Ultimately, aren't the real issues things like "who
> >>has the right to speak for it?" and "who has the right to change it?"
> >>and things like that?  Whatever you think of who that might be, surely
> >>you don't think that's decided by some sort of technical criterion...?
> >>Why is the choice of a name, something that has no material technical
> >>implication on any program's execution, a technical matter?
> >
> >[my reply snipped]
>
> Kent, I replied in good faith because I thought your
> extensive set of questions specifically addressed
> to me were in expectation of an answer.  
>
> I learned too late from another article of yours (to
> someone else) that you had publicly announced
> your withdrawal from the dicussion.  

Well I hadn't stopped reading.  I just feel like people must be getting
bored with me just repeating the same old stuff over and over.  So I
thought I'd step back awhile and see what people have to say.

> I am not a big fan of these staged withdrawals --
> however it's your privilege.

I do it mostly so that people feel more easy about ragging on me to shut
up if I persist after I said I was going to stop.

> How about a little email heads-up next time you adopt this approach?

It wasn't on any point of principle I withdrew, and I don't mind continuing
the discussion if there is something legitimately new to be said.
I didn't mean to create a problem for you here.  I _did_ read your reply
where you said:

 | Sure, whatever flavor of insight is fine.  It's just that
 | "political reality"-type arguments wouldn't need explicit
 | belaboring, as everyone would feel it in their bones already.  The
 | reason I specified "technical" was because it would be much easier
 | both to offer and to accept.  If you could just toss in some
 | convincing insight amid the "politically plausible" analogizing, I
 | would have no problem being an early convert to your view, well
 | before it became political reality.

but it wasn't clear to me that it had a question in it.  Is it really
the case that I have not made myself clear (to the pont of sounding like
a broken record.

I think this question doesn't have much relevance except at one point:
when a new dialect comes along.  Because then those loyal to the Lisp name
ask whether they should go on.  I recall a conversation with Pat Winston
about his Lisp book back when Common Lisp came along, where he was asking
me whether he should upgrade to Common Lisp, because it wasn't clear at that
time that CL was the "heir apparent" to the Lisp name, or whether Maclisp
would continue to be the right target.  We were in "wait and see" mode.
My recommendation to him at that time was that it was something of a
self-fulfilling prophecy and that if he, Pat Winston, head of the AI Lab at
MIT, said "this is what Lisp is", then this is what Lisp would be.  But if
he looked at Common Lisp and chose not to use it in his book, that in a sense
that would vote against Lisp.  Of course, he is not the only guy people look
to.  But certain people are leaders, and certain people are followers, and
the followers are just looking at the name and saying "I want to program in
Lisp. What does Lisp mean today?"  And as new dialects present themselves,
they ask, "Is this The Way?"  They did this when Dylan came along, and there
was a time when Dylan still had Lispy syntax and had the marketing  backing
of Apple where I think there was some chance that Dylan could have fragmented
or diverted the community.  But when the syntax was revamped and Apple lost
interest, Dylan in that moment became something other than a next generation
Lisp but still showed the will to become a "new experiment".  

Put another way, I think that you understand what Lisp is by going back in time
and following the community and asking "where did it go next"?

It is like the ship of Theseus (I think it is), where a worn out plank is
replaced, and then another, and so on until none of the original ship remains.
The question becomes (and you can check Google to see this issue comes up
in numerous other contexts periodically): is it still the same ship?
(And is your answer changed if I tell you I've been saving the old planks
and have reassembled the original ship elsewhere?)  My answer is that it
depends on your purpose.  For insurance purposes, the "maintained ship" is
probably the ship that is insured; for historical purposes, I'm sure the
"original (now reassembled) ship" is the real one.  And the Lisp community
is a bit like this.  We lose ourselves piece by piece from one community to
the next, but the real question is, "where is our mass".  We could totally
split, but often we don't.  In the case of CL, the Maclisp coalesced from
previously disparate encampments.  That was a pretty strong statement.  
Moreover, the Interlisp community, which was detached, has in some cases
reattached to us.  That, too, is a strong statement of sorts.  It's all
subjective abstracts and subjective aggregations, so I don't know that there
are definitive answers, but that's how I arrive at my thinking on this.

That's my answer to you.  But it looks to me just like the answers I've
already given.  That's why, to the extent possible, I'm still going to try
to stay out of this.  But if there's something that really seems to call
for me to reply, I will.  Please try to phrase your question in the form
of a question, though.  That will help me know I am really being specifically
addressed and you are awaiting an answer.

Why is Scheme not a Lisp? Doug Quale 3/13/02 11:47 AM
At the 1980 Lisp Conference at Stanford, John McCarthy published an
article, "LISP---NOTES ON ITS PAST AND FUTURE---1980".  In 1999 he
wrote that it almost entirely corresponds to his present opinions
(http://www-formal.stanford.edu/jmc/lisp20th.html).

McCarthy gave 15 characteristics of the LISP programming language
which I reproduce below.  Examining the list, R5RS Scheme has all of
the listed characteristics except number 9.  (RnRS for n < 5 also do
not meet number 12 since EVAL was not a standard part of Scheme at
that time.)

Are there any programming languages other than Scheme that have 13 or
14 of these 15 characteristics but are not a Lisp?  (A yes answer is
evidence that Scheme is not a Lisp, a no answer is evidence that
Scheme is a Lisp.)

Are there any Lisps that do not have all 15 of these characteristics?
(A yes answer weakens the argument that Scheme is not a Lisp, a no
answer strengthens it.)

(One could argue that Common Lisp itself does not support number 7
very well since CL does not guarantee tail recursion optimization.)

John McCarthy wrote in "LISP---NOTES ON ITS PAST AND FUTURE---1980":

> As a programming language, LISP is characterized by the following ideas:
>
> 1. Computing with symbolic expressions rather than numbers.
>
> 2. Representation of symbolic expressions and other information by
>    list structure in computer memory.
>
> 3. Representation of information on paper, from keyboards and in other
>    external media mostly by multi-level lists and sometimes by
>    S-expressions. It has been important that any kind of data can be
>    represented by a single general type.
>
> 4. A small set of selector and constructor operations expressed as
>    functions, i.e. car, cdr and cons.
>
> 5. Composition of functions as a tool for forming more complex functions.
>
> 6. The use of conditional expressions for getting branching into
>    function definitions.
>
> 7. The recursive use of conditional expressions as a sufficient tool
>    for building computable functions.
>
> 8. The use of lambda-expressions for naming functions.
>
> 9. The storage of information on the property lists of atoms.
>
> 10. The representation of LISP programs as LISP data that can be
>     manipulated by object programs. This has prevented the separation
>     between system programmers and application programmers. Everyone
>     can ``improve'' his LISP, and many of these ``improvements'' have
>     developed into improvements to the language.
>
> 11. The conditional expression interpretation of Boolean connectives.
>
> 12. The LISP function eval that serves both as a formal definition of
>     the language and as an interpreter.
>
> 13. Garbage collection as the means of erasure.
>
> 14. Minimal requirements for declarations so that LISP statements can
>     be executed in an on-line environment without preliminaries.
>
> 15. LISP statements as a command language in an on-line environment.
>
> Of course, the above doesn't mention features that LISP has in common
> with most programming languages in its ``program feature''.

Why is Scheme not a Lisp? Doug Quale 3/13/02 12:01 PM
Kent M Pitman <pit...@world.std.com> writes:

> Moreover, the Interlisp community, which was detached, has in some cases
> reattached to us.  That, too, is a strong statement of sorts.  It's all
> subjective abstracts and subjective aggregations, so I don't know that there
> are definitive answers, but that's how I arrive at my thinking on this.

This confuses me.  Is Interlisp a Lisp?  Despite your emphasis on
community over other issues like history, syntax and semantics, the
Scheme and Common Lisp communities have had and continue to have a
greater overlap with each other than the Interlisp community had with
Common Lisp before Interlisp became extinct.

Does the fact that the Interlisp community has today reattached itself
to the Common Lisp community somehow retroactively make Interlisp a
Lisp?


--
Doug Quale

Why is Scheme not a Lisp? Christopher Browne 3/13/02 12:14 PM
In the last exciting episode, Erik Naggum <er...@naggum.net> wrote::

> * tb+u...@becket.net (Thomas Bushnell, BSG)
> | But Scheme does call itself a Lisp!
> |
> | The very beginning of the R5RS reads:
> |
> | "The report gives a defining description of the programming language
> | Scheme. Scheme is a statically scoped and properly tail-recursive dialect
> | of the Lisp programming language invented by Guy Lewis Steele Jr. and
> | Gerald Jay Sussman."

> But how can you trust a specification that says the Lisp programming
> language was invented by Guy Lewis Steele, Jr., and Gerald Jay
> Sussman?

<flame on>
It doesn't say that except when you do a misleading, out-of-context
reading of the text.

The reading that seems more natural is that it indicates that Scheme
is a dialect of Lisp, and that this dialect was invented by a
particular group of people.

The notion that this _could_ be a claim that GLS/GJS "invented Lisp"
flies in the face of blatant obviousness.  All of these people spent
"quality time" at MIT, where it's completely obvious who the initial
inventor was, namely John McCarthy.

Indeed, for you to claim your reading requires that Kent Pitman be
accused of complicity in the dishonesty you suggest, as he has been on
the review committee since at least 1991, and probably much earlier.
<flame off>

Go ahead and attack Scheme on technical grounds, but dredging up this
kind of nonsense does nobody any favors.
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www3.sympatico.ca/cbbrowne/sgml.html

Why is Scheme not a Lisp? Rahul Jain 3/13/02 12:14 PM
Doug Quale <qua...@charter.net> writes:

Seems like this list is misleading and/or inaccurate. Probably because
it was published in 1980 and we're applying it to 2000's context.

> John McCarthy wrote in "LISP---NOTES ON ITS PAST AND FUTURE---1980":
>
> > As a programming language, LISP is characterized by the following ideas:
> >
> > 1. Computing with symbolic expressions rather than numbers.

"Rather than"? CL has an excellent numeric type system and set of
operators, as does scheme (but they are subtly different in ways I
don't quite understand).

> > 2. Representation of symbolic expressions and other information by
> >    list structure in computer memory.

Fair enough.

> > 3. Representation of information on paper, from keyboards and in other
> >    external media mostly by multi-level lists and sometimes by
> >    S-expressions. It has been important that any kind of data can be
> >    represented by a single general type.

That was added to scheme later, I though.

> > 4. A small set of selector and constructor operations expressed as
> >    functions, i.e. car, cdr and cons.

That's true of scheme, not of CL.

> > 5. Composition of functions as a tool for forming more complex functions.

That's true of any language with functions as first-class objects.

> > 6. The use of conditional expressions for getting branching into
> >    function definitions.

Same as 5 and for most other languages.

> > 7. The recursive use of conditional expressions as a sufficient tool
> >    for building computable functions.

Same as 6.

> > 8. The use of lambda-expressions for naming functions.

Well, that's just the ability to have anonymous functions. Same as 5.

> > 9. The storage of information on the property lists of atoms.

That's more of a style issue these days in CL, and of course, doesn't
happen in Scheme at all.

> > 10. The representation of LISP programs as LISP data that can be
> >     manipulated by object programs. This has prevented the separation
> >     between system programmers and application programmers. Everyone
> >     can ``improve'' his LISP, and many of these ``improvements'' have
> >     developed into improvements to the language.

Again, I think (read) was a recent addition to Scheme, but it has it
now, so no point clinging onto the past.

> > 11. The conditional expression interpretation of Boolean connectives.

This is common to nearly all languages in use today.

> > 12. The LISP function eval that serves both as a formal definition of
> >     the language and as an interpreter.

New to scheme, ok.

> > 13. Garbage collection as the means of erasure.

Well, this is not required in CL, but let's call this "non-explicit
memory management". C++ has it, too, if you use libgc.

> > 14. Minimal requirements for declarations so that LISP statements can
> >     be executed in an on-line environment without preliminaries.

Scheme doesn't even have declarations, but I guess this is referring
to defaulting to dynamic typing? Lots of languages have this.

> > 15. LISP statements as a command language in an on-line environment.

I don't know if Scheme requires a REPL. Lots of other languages have
them, too, however.

> > Of course, the above doesn't mention features that LISP has in common
> > with most programming languages in its ``program feature''.

Which is why I consider this list to be useless to this discussion.

7 of the 15 critera are basically useless to comparing Lisp and
Scheme, specifically, because they are common to large classes of
languages.

Personally, I think the thing that defines Lisp is the symbol. Note
that I consider packages to be essential to symbols, and the previous
symbol types were incomplete. Therefore, I consider pre-CL Lisps to be
proto-Lisps, and that's where Scheme came from. Not that it matters.

Scheme doesn't have the same symbolic manipulation capabilities as
Common Lisp, and since that's one of the most unique features of CL,
and one that explains how it can be so flexible, I don't consider
Scheme to be close enough to CL to consider them to be dialects of the
same language. In a sense, it wasn't Scheme that broke from Lisp, it
was CL that broke from it and made it a mature language.

Oh well, this is a pretty useless post.

--

-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Dorai Sitaram 3/13/02 12:27 PM
In article <sfwlmcw...@shell01.TheWorld.com>,

Kent M Pitman  <pit...@world.std.com> wrote:
>
>but it wasn't clear to me that it had a question in it.  Is it really
>the case that I have not made myself clear (to the pont of sounding like
>a broken record.
>
> [...]

>
>That's my answer to you.  But it looks to me just like the answers I've
>already given.  That's why, to the extent possible, I'm still going to try
>to stay out of this.  But if there's something that really seems to call
>for me to reply, I will.  Please try to phrase your question in the form
>of a question, though.  That will help me know I am really being specifically
>addressed and you are awaiting an answer.

Oh no, I didn't ask a question -- I was answering yours
with some diligence.  I just felt I could have avoided
that effort if the questions you posed were to be
considered de facto withdrawn.  

It does not serve a person well to be induced to drone
on unilaterally when the other has magisterially left
the scene.  :-)  

Thanks.

--d

Why is Scheme not a Lisp? Christopher Browne 3/13/02 12:30 PM
The world rejoiced as Lieven Marchand <m...@wyrd.be> wrote:

> g...@jpl.nasa.gov (Erann Gat) writes:
>
> > So my question is directed to those of you who say that Scheme is not a
> > Lisp, notably Erik, but I gather that there are many out there who agree
> > with him.  Why is Scheme not a Lisp?  Does Scheme lack some necessary
> > feature that is required to be considered a Lisp in your book?  Was Lisp
> > 1.5 a Lisp?
>
> Scheme is not a Lisp IMO because of two types of reasons: first,
> technical, which have been argued on this group ad nauseam (the
> deepest difference there to me is that a scheme program is defined as
> a string of characters whereas a CL program is defined as a sequence
> of lists of Lisp objects. This may seem pedantic or trivial but a lot
> of different design decisions follow from this. It makes Scheme an
> infix member of the Algol language family.); but more important,
> philosophically. The Scheme community has evolved a set of values at
> odds with the spirit of Lisp: the goal for simplicity at the expense
> of convenience (compare the concept of CL's $item designators with the
> design of convert stuff explicitly like Scheme's exact->inexact), the
> goal of only giving basic blocks and letting you assemble stuff
> yourself (call/cc isn't a replacement for a worked out exception
> system).
>
> To sum it up with a Ritchie quote: "Some languages were meant to get
> work done, some were meant to prove a point." I put Lisp in the first
> category and Scheme and ML in the second. (See also the reliance on
> tail call elimination to be able to prove the point that a looping
> construct isn't necessary.)
>
> I don't know enough about Lisp 1.5 to answer your last question.

This also begs the question:

If these criteria for "Lispness" were applied to Emacs Lisp and ILisp,
what result falls out?

- I would think that an evaluation criteria that would indicate that
  they _weren't_ Lisps would be severely flawed.

- I would expect Dylan to be considered "not Lisp;" while it bears
  some resemblances, I don't think it's anywhere near enough.  (It's
  near enough that there may be some meaning discussions to have about
  the similarities and differences; calling it Lisp would seem to be
  going too far...)

- I would find it surprising for a set of evaluation criteria that
  would exclude Scheme from being considered "a Lisp" to NOT similarly
  exclude ELisp/ILisp.

I would be _fascinated_ to see a set of "Lispness criteria" that would
be inclusive of ELisp/ILisp and simultanously exclude Scheme.  

My expectations are that such a set of criteria would more likely than
not be designed in a manner that was politically motivated with a
conscious view to exclude Scheme, which doesn't strike me as "fair
cricket."  

It seems a shabby thing to make up a definition with the conscious
_political_ goal of excluding something.


--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www3.sympatico.ca/cbbrowne/lisp.html

Why is Scheme not a Lisp? Kent M Pitman 3/13/02 12:32 PM
Doug Quale <qua...@charter.net> writes:

> Kent M Pitman <pit...@world.std.com> writes:
>
> > Moreover, the Interlisp community, which was detached, has in some
> > cases reattached to us.  That, too, is a strong statement of
> > sorts.  It's all subjective abstracts and subjective aggregations,
> > so I don't know that there are definitive answers, but that's how
> > I arrive at my thinking on this.
>
> This confuses me.  Is Interlisp a Lisp?  Despite your emphasis on
> community over other issues like history, syntax and semantics, the
> Scheme and Common Lisp communities have had and continue to have a
> greater overlap with each other than the Interlisp community had with
> Common Lisp before Interlisp became extinct.

I certainly think Interlisp is a lisp.  I think so because it descends
from the same cultural parentage as does Maclisp.  That a split
occurred doesn't mean one or the other half has to lose its identity.
Emacs Lisp is a Lisp, too, and is split off.  Zetalisp also split.
But none of these splits were made over ideology, as far as I can
tell, but rather were made over simple administrative need to
gradually control evolution in a way that suited a local user base.

I don't see that as what Sussman did.  Sussman had a locally
administered Lisp but wasn't satisfied with it.  He specifically took
control and designed something else because it didn't suit his way of
thinking.  He had some concepts he wanted to teach, and he needed a
different vehicle for that teaching.  That's a great thing to do, but
it's not torchbearing to me.  It's being a revolutionary.  And
revolutionaries build new things, they do not maintain a status quo.

Incidentally, I think Stallman thought CL was being revolutionary, not
evolutionary, because of its choice of lexical scope (and perhaps for
other reasons).  I think he thought he was keeping Lisp on the straight
and narrow.  If I were examining only the outcome, I might agree with him.
But because it was a "community consensus process" that led to CL, and
not just an individual striking out for change, I take CL's changes as
evolutionary even though some of them, at a technical level, might be
argued not to be.

> Does the fact that the Interlisp community has today reattached itself
> to the Common Lisp community somehow retroactively make Interlisp a
> Lisp?

No.  At least, I don't think so.  Interlisp was always a Lisp.

Why is Scheme not a Lisp? Christopher Browne 3/13/02 12:42 PM
Erik Naggum <er...@naggum.net> wrote:
> * Erann Gat
> | The introduction to R5RS says, "Scheme was the first major dialect of
> | Lisp to [have certain distinguishing features]".  So it does call itself
> | a "dialect of Lisp."
>
>   When was this written?

At least as far back as 1991, which is the earliest R*RS that I can
easily locate online.  

I suspect that it may have been adopted from MIT AI Memo 452 or 848,
which were earlier definitions of Scheme.  I can't verify that,
unfortunately.

R0RS is available at <http://www.sonic.net/~bear/scheme/R0RS.ps>; I
currently can't view PS, so others will have to verify whether the
intro changed significantly between R0RS and R3RS.  I'd guess not.


--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www3.sympatico.ca/cbbrowne/sgml.html

Why is Scheme not a Lisp? Erik Naggum 3/13/02 1:03 PM
* Doug Quale <qua...@charter.net>

| The Lisp family is a family of languages, not a single language.

  So _say_ "The language Scheme is a member of the Lisp language family"
  instead of saying "Scheme is a dialect of Lisp".  Emphasize language, not
  dialect.  Emphasize language family.  A standards-like document that is
  so lacking in precision does both its audience and its subject matter a
  disservice.

| "Scheme is a Lisp", or more fully "Scheme is a member of the lisp
| language family" emphasizes the substantial common ground in those four
| important areas with other members of the lisp family.

  It does not mean that because Common Lisp is most likely the only "Lisp"
  they will see, and your interpretation of "is a lisp" as "member of the
  Lisp language family" assumes facts not in evidence, namely that "Lisp"
  is a language family, as seen by those who read it.  Scheme is not a
  "dialect" of Common Lisp, and there are no other large _families_ of
  programming languages around that people talk about.  Pascal is not a
  member of the Algol family, although Delphi might be a dialect of Pascal,
  but there is no Pascal family of languages, of which Ada is a member.  So
  the notion of a language family cannot be assumed to exist in the readers
  and certainly not in students who go into the world and would like to
  study Common Lisp.

  Had you schmucks actually been able to achieve clarity of expression and
  thought and communicate your intent, which you have rewritten "Scheme is
  a Lisp" to mean, just _imagine_ how much less hostility would have
  ensued.  I repeat my suggestion: say "the language Scheme is a member of
  the Lisp language family" if that is what you mean, do not weasel out of
  your responsibility for the weak expression.

| An interesting comparison can be made with the Algol family of languages.
| This family includes Algol 60 as the founding member and has many members
| including Algol-W, PL/1, Pascal, C and Ada.  The Algol family includes
| members that are far more different that Common Lisp and Scheme.  No one
| would ever confuse Algol 60 and Ada, but they are members of the Algol
| family all the same.

  But who talks about the Algol family?  None.  Would a C programmer be
  anywhere close to comfortable with this classification?  No.

| Kent has argued rationally that Scheme is not a Lisp, but most people
| arguing in favor of that view have not been so dispassionate.  The
| interesting thing is that for some Common Lisp users, the question of
| whether Scheme is a Lisp is a religious one rather than a technical one.

  It is a feeble-minded, stupid, inflammatory way to say "Scheme is a
  member of the Lisp family" if that is what you read it to mean "more
  fully".

| I can't even imagine that level of emotion in a discussion between Pascal
| and C partisans about the common cultural and historical origins of their
| languages, although they can disagree very heatedly about the relative
| merits of their chosen languages.

  But nobody says "C is an Algol".

| (By way of contrast, I think from a Scheme or Common Lisp point of view,
| many might say the differences between Pascal and C aren't very
| important.)

  Then try answering a C question with a Pascal answer in comp.lang.c.
  Suggest that somebody who wants to learn C "begin with Pascal", or offer
  people who do not like feature X of C or just have a problem using it, to
  use Pascal, instead.  This is what the annoying Scheme freaks do in
  comp.lang.lisp.  Also, people do not discuss Ada in comp.lang.algol.

| Despite what some Scheme haters in c.l.l say, I think very few Scheme
| users have any strong intellectual or emotional investment in this
| question.

  Every single person who has ever answered a Common Lisp question with a
  Scheme answer has at least at that time had serious emotional investment
  in a competition between Scheme and Common Lisp.

| I think the initial inquiry was prompted more by a desire to understand
| the venom displayed towards Scheme in c.l.l than a need to prove
| anything.

  There is no venom towards Scheme per se.  There is venom towards all the
  obnoxious, persistent Scheme crap in comp.lang.lisp.  If you spend your
  time on a date talking about computers, chances are you will bore your
  date to death and not score.  Computer science did not get dissed, but
  your choice of topic to talk about in that setting did.  So, too, with
  all the irrelevant Scheme crap in comp.lang.lisp.

| "Why do they hate us?" has gained a lot of attention recently in areas
| much more important than computer programming languages.

  Reasonbly intelligent people manage to figure out the difference between
  "why do they hate what we do" and "why do they hate us".  If Scheme
  freaks could please figure out that when somebody has a problem in Common
  Lisp, answering with a Scheme solution is bad form, and simply refrain
  from being such obnoxious retards, there would be no "hatred" at all.
  People who are told to shut up and go away, but do neither are not hated
  for their _person_, they are hated for their obnoxious behavior.

  When you accuse people of hating you because of your behavior, you have
  actually attacked him in an inexcusable way.  Some people never figure
  out that false accusation trip people and can seriously piss them off,
  but feel free to accuse others of things they do not like simply because
  _they_ do not like the person.  I consider such behavior to be clear
  evidence of a very serious coping problem.

| As a final thought, it's quite funny that someone can say that Common
| Lisp is a lisp-2 and Scheme is a lisp-1, and then in the next breath say
| Scheme is not a Lisp.

  Context, dude.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Erann Gat 3/13/02 12:51 PM
In article <32250345...@naggum.net>, Erik Naggum <er...@naggum.net> wrote:

> * Erann Gat
> | The introduction to R5RS says, "Scheme was the first major dialect of
> | Lisp to [have certain distinguishing features]".  So it does call itself
> | a "dialect of Lisp."
>
> * Erik Naggum
> > When was this written?
>
> * Erann Gat
> | R5RS is dated 20 February 1998.  It's the most recent Scheme standard.

[Snip]

>   Also note that I did not ask when the line was "published".

Yes.  Note that I didn't actually answer when the passage was written.  I
don't know when it was actually written, I just know the date given in the
document.

>   Sometimes I wonder if you are intentionally obtuse or if you cannot help
>   it.  I keep hoping that you can do better, which is probably why it is so
>   annoying that you do not.  Let me know if I should stop hoping.

Sometimes I wonder if you are intentionally obnoxious or if you cannot


help it.  I keep hoping that you can do better, which is probably why it
is so annoying that you do not.  Let me know if I should stop hoping.

> > The two languages and their attendant communities have drifted so far
> > apart that there is nothing of value in their intersection.
>
> | What about the use of S-expressions to represent both code and data?
>
>   How about using characters to represent source code?

Yes, how about that?  We take it for granted nowadays that characters are
used to represent source code, but it wasn't always that way.  Time was,
programs were represented by the positions of toggle switches, or the
physical layout of wires on plugboards.  The idea that programs could be
represented using characters was considered revolutionary a mere 50 years
ago.  (Grace Hopper told a story about trying to convince people to use
the A-0 "compiler", which today we would call an assembler.  She says: "I
had a running compiler and nobody would touch it because, they carefully
told me, computers could only do arithmetic; they could not do programs."
This was 1952.)

There actually *are* programming "languages" that don't use characters.
My favorite example is LabView, which if you haven't seen it is actually
very cool.  It's a graphical programming language with very Lispy
semantics.  Some of these graphical programming systems even call
themselves "languages", like UML.  

<tangent>
Personally, I don't think UML is a language.  I think an essential
characteristic of a language is that it have fundamentally a
one-dimensional structure, whereas the fundamental structure of UML is
two-dimensional.  But that's just my opinion.
</tangent>

Programming systems that use characters to represent source code seem to
me to fall into two major categories: those that use S-expressions and
those that do not.  The reason I think that this is a useful division is
that S-expressions are a universal syntax that can represent both code and
data.  Non-S-expression syntaxes can represent only code.  (Note: this is
not inherently true.  There's no reason why you couldn't design some
syntax other than S-expressions that could represent both code and data.
It's just that no one has.)

This has important practical consequences.  For example, people who
program in non-S-expression syntaxes spend a lot of time and effort
designing and writing parsers for syntaxes for representing data.  People
who use S-expressions spend very little time writing parsers because they
just use the built-in parser provided by their programming language
(a.k.a. READ).  People who use S-expression-based languages tend to
embrace the idea of *extending* a programming langauge as a useful
programming technique because extending an S-expression-based language is
easy.  People who use non-S-expression-based languages tend not to even
consider extending the language because doing so is all but impossible
(with Dylan perhaps being a notable exception).

So: you said that there is nothing of value in the intersection of Common
Lisp and Scheme.  So do you think that S-expressions are not in the
intersection, or that they have no value?

E.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erik Naggum 3/13/02 1:06 PM
* Erann Gat

| So I have another question directed to those who say Scheme is not a
| Lisp: is the concept of "programming language with S-expression-based
| syntax" not important enough to deserve its own less verbose term?  If it
| is, what should that term be if not "Lisp"?

  How hard is it to say "Lisp family"?

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Geoff Summerhayes 3/13/02 1:14 PM

"Christopher Browne" <cbbr...@acm.org> wrote in message
news:m3sn74tec1.fsf@salesman.cbbrowne.com...

> In the last exciting episode, Erik Naggum <er...@naggum.net> wrote::
> > * tb+u...@becket.net (Thomas Bushnell, BSG)
> > | But Scheme does call itself a Lisp!
> > |
> > | The very beginning of the R5RS reads:
> > |
> > | "The report gives a defining description of the programming language
> > | Scheme. Scheme is a statically scoped and properly tail-recursive dialect
> > | of the Lisp programming language invented by Guy Lewis Steele Jr. and
> > | Gerald Jay Sussman."
>
> > But how can you trust a specification that says the Lisp programming
> > language was invented by Guy Lewis Steele, Jr., and Gerald Jay
> > Sussman?
>
> <flame on>
> It doesn't say that except when you do a misleading, out-of-context
> reading of the text.

*snip*

>
> Go ahead and attack Scheme on technical grounds, but dredging up this
> kind of nonsense does nobody any favors.
> --

I don't know, personally I enjoy seeing the occasional bit of
levity in this NG. To borrow from Steele, I doubt that very
many users have complained to him that a misreading of that
sentence has cramped their programming style.

-----------------

Geoff

Why is Scheme not a Lisp? Erik Naggum 3/13/02 1:27 PM
* Christopher Browne <cbbr...@acm.org>

| Go ahead and attack Scheme on technical grounds, but dredging up this
| kind of nonsense does nobody any favors.

  Anyone wonder why I get pissed off at the fucking morons who find faults
  with every goddamn thing I do?  TRY LIGHTENING UP, DICKWEED!  It was an
  attempt at light-hearted humor, although it was certainly at the expense
  of some of the most anal-retentive bunch of stuck-ups I know, who quote
  chapter and verse at people who argue about their inflammatory, useless
  desire to included in the Lisp family ever after they left, voluntarily,
  and who cannot even write well enough to communicate what they mean in
  simple, unambiguous English.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Doug Quale 3/13/02 1:33 PM
Kent M Pitman <pit...@world.std.com> writes:

> I certainly think Interlisp is a lisp.  I think so because it descends
> from the same cultural parentage as does Maclisp.  That a split
> occurred doesn't mean one or the other half has to lose its identity.

You have explained this very carefully and clearly, but I am surprised
to see you emphasize at times the separateness of the Interlisp and
Maclisp communities, and at other times (especially when the question
of Scheme comes up) say that they are close enough to make Interlisp a
Lisp.  Isn't it true that the Interlisp and Maclisp communities had no
significant mixing (when Interlisp was still alive)?  My impression is
that the communities were almost totally separate, and that many in
the Maclisp community had the same kind of disdain for Interlisp then
that some in the Common Lisp community show for Scheme now.

> Incidentally, I think Stallman thought CL was being revolutionary, not
> evolutionary, because of its choice of lexical scope (and perhaps for
> other reasons).  I think he thought he was keeping Lisp on the straight
> and narrow.  If I were examining only the outcome, I might agree with him.
> But because it was a "community consensus process" that led to CL, and
> not just an individual striking out for change, I take CL's changes as
> evolutionary even though some of them, at a technical level, might be
> argued not to be.

Well, the "community consensus process" essentially included only the
Maclisp community (and its immediate offspring).  History is written
by the victors.  That answers a question, but I'm not certain if it's
the question that was asked.  Basically we've arrived at "Scheme is
not a Lisp because Common Lisp people say it isn't."  There is a nice
finality to this, if Common Lisp users have the ability to decree what
is and isn't a Lisp.

> > Does the fact that the Interlisp community has today reattached itself
> > to the Common Lisp community somehow retroactively make Interlisp a
> > Lisp?
>
> No.  At least, I don't think so.  Interlisp was always a Lisp.

I agree, but the community argument seems to be becoming more
tortured.  The Maclisp and Interlisp communities were more isolated
from each other than the Common Lisp and Scheme communities were in
the past or are today, but apparently you argue that Interlisp is a
Lisp and Scheme is not because the Interlisp community division was
not ideologically motivated and the Scheme community division was.

The great thing about this argument is that it doesn't require any
comparison between Scheme and any other Lisp.  Only the intent of
Sussman and Steele matters; their background, the process they used
and the result they obtained is irrelevant.

In thinking about this some more, the community argument is starting
to feel more and more like tracing royal bloodlines.  I don't think
this is a very effective way to classify computer programming
languages, but maybe it gives some in the Common Lisp community a
feeling of Divine Right.


--
Doug Quale

Why is Scheme not a Lisp? Erik Naggum 3/13/02 1:35 PM
* Doug Quale <qua...@charter.net>

  You read "Scheme is a (dialect of) Lisp" to mean "Scheme is a member of
  the Lisp family", and argue as if someone has denied that Scheme is a
  member of the Lisp family.  You have completely missed the point.  If the
  meaning you have inferred from the statement that has caused so much
  hostility could have been stated plainly, nothing would have happened,
  because the way it is written is so often _misunderstood_ (relative to
  your understanding, at least), and it is the possible, even reasonable,
  interpretation of that stupidly phrased relationshpi that is under attack.

  You are barking up the wrong tree.  Even eloquent barking does not change
  the tree.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/13/02 1:40 PM
g...@jpl.nasa.gov (Erann Gat) writes:

> (Grace Hopper told a story about trying to convince people to use
> the A-0 "compiler", which today we would call an assembler.  She says: "I
> had a running compiler and nobody would touch it because, they carefully
> told me, computers could only do arithmetic; they could not do programs."
> This was 1952.)

You know, she is just stunningly amazing.  I never hear a Grace
Hopper story that doesn't make me nearly swoon in admiration.  

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/13/02 1:35 PM
Kent M Pitman <pit...@world.std.com> writes:

> Incidentally, I think Stallman thought CL was being revolutionary, not
> evolutionary, because of its choice of lexical scope (and perhaps for
> other reasons).  

Do you mean "Sussman" here?

Why is Scheme not a Lisp? Bruce Hoult 3/13/02 2:00 PM
In article <Z6Aj8.26363$hb6.1...@news20.bellglobal.com>,
 "Geoffrey Summerhayes" <sumNOS...@hotmail.com> wrote:

> "Erann Gat" <g...@jpl.nasa.gov> wrote in message
> news:gat-1203021705570001@eglaptop.jpl.nasa.gov...
> > In article <32249678...@naggum.net>, Erik Naggum <er...@naggum.net>


> wrote:
> >
> > > * Erann Gat
> > > | The introduction to R5RS says, "Scheme was the first major dialect of
> > > | Lisp to [have certain distinguishing features]".  So it does call
> itself
> > > | a "dialect of Lisp."
> > >
> > >   When was this written?

> >
> > R5RS is dated 20 February 1998.  It's the most recent Scheme standard.
> >
>
> LOL Good comeback.
>
> I have a published copy of Hamlet with the date 1994. What does
> say about when, "I am but mad north-north-west. When the wind is
> southerly, I know a hawk from a handsaw." was penned?

I don't know Shakespear from Rushdie, but that seems a perfectly clear
reference to a Foehn wind and the effect of its hot, dry, electrically
charged air on some people.

-- Bruce

Why is Scheme not a Lisp? Bruce Hoult 3/13/02 2:05 PM
In article <32249648...@naggum.net>, Erik Naggum <er...@naggum.net>
wrote:

> * Dorai Sitaram
> | I'll admit I don't want those epithets any more than the next guy, Rahul,
> | but I find I cannot honestly alter my opinion that Scheme is a Lisp.
>
>   But what is this "Lisp" that Scheme is?  I maintain that it is a concept
>   evacuated by evolllution.  What is left in this concept for you?  Please
>   remember that you have to accomodate D*lan users who argue the same way
>   Scheme users do about the supposed Lisp nature of their pet language.

Dylan and Common Lisp have *far* more in common with each other than
either has with Scheme!

-- Bruce

Why is Scheme not a Lisp? Doug Quale 3/13/02 2:09 PM
Erik Naggum <er...@naggum.net> writes:

> * Doug Quale <qua...@charter.net>
> | The Lisp family is a family of languages, not a single language.
>
>   So _say_ "The language Scheme is a member of the Lisp language family"
>   instead of saying "Scheme is a dialect of Lisp".  Emphasize language, not
>   dialect.  Emphasize language family.  A standards-like document that is
>   so lacking in precision does both its audience and its subject matter a
>   disservice.

Take any complaints about R5RS to Kent M Pitman.  His name is on it,
not mine.

> | "Scheme is a Lisp", or more fully "Scheme is a member of the lisp
> | language family" emphasizes the substantial common ground in those four
> | important areas with other members of the lisp family.
>
>   It does not mean that because Common Lisp is most likely the only "Lisp"
>   they will see, and your interpretation of "is a lisp" as "member of the
>   Lisp language family" assumes facts not in evidence, namely that "Lisp"
>   is a language family, as seen by those who read it.  Scheme is not a
>   "dialect" of Common Lisp, and there are no other large _families_ of
>   programming languages around that people talk about.  Pascal is not a
>   member of the Algol family, although Delphi might be a dialect of Pascal,
>   but there is no Pascal family of languages, of which Ada is a member.  So
>   the notion of a language family cannot be assumed to exist in the readers
>   and certainly not in students who go into the world and would like to
>   study Common Lisp.

Common Lisp is likely to be the only "Lisp" they see, only if "Lisp"
does not include Scheme.  This is begging the question.  Actually I
think it might be a false statement anyway, since a significant number
of Lisp users may see Emacs lisp.

About the rest, Pascal and Ada are members of the Algol family of
languages, and people who study computer programming languages do talk
about it that way.

> | An interesting comparison can be made with the Algol family of languages.
> | This family includes Algol 60 as the founding member and has many members
> | including Algol-W, PL/1, Pascal, C and Ada.  The Algol family includes
> | members that are far more different that Common Lisp and Scheme.  No one
> | would ever confuse Algol 60 and Ada, but they are members of the Algol
> | family all the same.
>
>   But who talks about the Algol family?  None.  Would a C programmer be
>   anywhere close to comfortable with this classification?  No.

People who study programming languages talk about the Algol family,
and a C programmer who knew Algol would be comfortable with this
classification.  Anyway, there's no reason to classify programming
languages if your only goal is to make programmers comfortable.

> | I can't even imagine that level of emotion in a discussion between Pascal
> | and C partisans about the common cultural and historical origins of their
> | languages, although they can disagree very heatedly about the relative
> | merits of their chosen languages.
>
>   But nobody says "C is an Algol".

True.  "Is an Algol" doesn't parse, so it wouldn't make any sense.


--
Doug Quale

Why is Scheme not a Lisp? Rahul Jain 3/13/02 2:04 PM
Doug Quale <qua...@charter.net> writes:

> You have explained this very carefully and clearly, but I am
> surprised to see you emphasize at times the separateness of the
> Interlisp and Maclisp communities, and at other times (especially
> when the question of Scheme comes up) say that they are close enough
> to make Interlisp a Lisp.

Then you have missed the whole point of the bulk of the discussion in
this thread.

Please go back and read the posts by Erik and Kent and others more
carefully. The English/German/Germanic analogy is very apropos to
this idea.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Rahul Jain 3/13/02 2:24 PM
Doug Quale <qua...@charter.net> writes:

> True.  "Is an Algol" doesn't parse, so it wouldn't make any sense.

And yet "is a Lisp" does?

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Carl Shapiro 3/13/02 2:36 PM
Doug Quale <qua...@charter.net> writes:

         Isn't it true that the Interlisp and Maclisp communities had no
> significant mixing (when Interlisp was still alive)?  
                                                       
This is most certainly not true.  There are a number of significant
ideas that were shared between Maclisp and the BBN-Lisp, SDS Lisp,
(and later) Interlisp, family.  For example, the Interlisp NLAMBDA is
extremely similar to the Maclisp FEXPR.

Why is Scheme not a Lisp? Doug Quale 3/13/02 2:38 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Doug Quale <qua...@charter.net> writes:
>
> > True.  "Is an Algol" doesn't parse, so it wouldn't make any sense.
>
> And yet "is a Lisp" does?

You must think it does.

If it doesn't, would you explain to me again what your complaint is?

--
Doug Quale

Why is Scheme not a Lisp? Kent M Pitman 3/13/02 2:40 PM
Doug Quale <qua...@charter.net> writes:

> ... Isn't it true that the Interlisp and Maclisp communities had no


> significant mixing (when Interlisp was still alive)?  My impression is
> that the communities were almost totally separate, and that many in
> the Maclisp community had the same kind of disdain for Interlisp then
> that some in the Common Lisp community show for Scheme now.

You mean like British and American?

> Well, the "community consensus process" essentially included only the
> Maclisp community (and its immediate offspring).

Yes, that's probably fair.  But the point is that it didn't seek to shun
that community.  It wanted to court that community, and for that community
to become its community.  Scheme, by contrast, had no such aspirations
that I could detect.

But remember, I'm not saying Scheme is not part of the Lisp language family.
And there are days on which I'll describe Scheme as a Lisp.  But they are
just massively outnumbered by the days when I won't.  It's not an absolute.
There are days recently where people have pronounced that there is no
difference between Democrats and Republicans here in the US, too, and that
we are all just Americans.  But those days are not as many as the days in
which they usefully separate themselves from each other to keep from scraping
each others' eyes out over issues that simply don't require addressing if
everyone stays in their respective right living rooms...

And I should also note that McCarthy has asked that no member of the Lisp
family claim the unadorned name "Lisp".  That is, that it be reserved to
the family.  It almost caused a huge problem when we submitted the
international standard for ISLISP to ISO and they "helpfully" renamed it to
the international standard for LISP (I guess figuring "IS" stood for
International Standard).  By informal agreement among the members, "IS"
doesn't stand for that, nor does it stand for "is LISP".  Though those things
were no doubt on someone's mind when they pushed the name originally.  We just
need a gensym prefix so it wouldn't be just "LISP", and that was as good as
any.  But ISO almost undid it.  We got them to fix the problem with the cover
as a typo, fortunately, and the standards work proceeded.

But I mention this because we sometimes refer to "dialect of Lisp" yet the
term "dialect of xxx" usually refers to a language, and there really is no
language that is Lisp, so we're really saying "dialectal variants of
languages in the Lisp family", and then that makes the the question more
vague: what is in the question.

I have said many times that a major cause of strife in the world is that
people tend to assume that being fluent in a language implies total  
understanding of it.  I think often people don't take into account the full
breadth of vaguery that languages really carry with them, and they act as
if their speaking precisely means others will understand them precisely.
This is sometimes helpful when you want to get agreement on certain words
because it allows people to stretch to agree with things they might not agree
with if better specified.  And it is very unhelpful when the word that is able
to stretch has negative connotation and one is trying to create a degree of
separation.  I think the latter is what's happening here.  We're using fuzzy
language.  We wish we were doing otherwise.  But tough.  We have no way of
legislating how language is used.  We have to endure that others will use
the words differently than we.  The best we can do is just to explain our
own points of views and tolerate those of others.

> History is written
> by the victors.  That answers a question, but I'm not certain if it's
> the question that was asked.  Basically we've arrived at "Scheme is
> not a Lisp because Common Lisp people say it isn't."  There is a nice
> finality to this, if Common Lisp users have the ability to decree what
> is and isn't a Lisp.

For myself, the issue isn't to "define away" or "marginalize" another
language.  It is merely to restrict the meaning of an otherwise
useless word to a point where it can have meaning.  In the US, in some
schools, we practically define everyone to have a passing grade in
school because somewhere along the way we have decided it's a
subjective judgment to fail someone, and no one should really be
singled out.  Teachers get sued for failing students, and back down.
But in our attempt to embrace such "tolerance" of those who are
slower, we have made mockery of what it means to have "graduated".  It
is not an attempt to exclude someone to make the term "pass" have
meaning.  It is an attempt to say that there is no point to saying
someone passed if everyone passes.  Narrowing the term does have the
effect of failing some students, but the _intent_ of narrowing the
term is not to fail some students, it is to say something specific
about those who did not fail.  I have the same problem with the animal
rights movement babbling away with statements like "Animals are
people, too."  Sigh.

Certainly McCarthy is entitled to say what he thinks is criterial to Lisp,
but I would make a different list.  And I don't know how I feel about him
retaining the right to say what Lisp is.  I don't generally accord to the
author of a book or director of a movie the right to dictate what the
significance of that book or movie is.  Sometimes I'm not sure they even
know.  I'm not saying McCarthy is an idiot by any means, nor even that he's
not entitled to his opinion.  But I think we who have invested in the
community have a right to determine it too.

This issue came up in the design of CLTL and was a learning experience
for me.  We who had been involved in the production of Steele's 1984
specification showed up in 1986 in a meeting in Monterrey, pre-ANSI,
to talk about what changes were needed.  About twice the number of
people we expected showed up.  Those new people said "we want a vote".
I was inclined at the time to say "you aren't entitled. if you like
it, fine.  but if you don't, go make your own standard.  we invested
in this standard and its ours to define."  But their position was "No,
we have invested in this language, too, by having implemented and used
it.  We are as much a part of the community as those who created the
community."  I didn't like that position, but it seemed to be the
consensus of others older and wiser than myself at that meeting that
this was a reasonable position.  And it's why we went to ANSI--because
we didn't have a good way of defining how to resolve who should have
how much power any more, but ANSI came with prefab rules on such
issues.  And in retrospect, while I sometimes doubt the wisdom of
going with as sluggish an organization as ANSI, I think "we" (meaning
the people around me who were smarter and more politically powerful
than I, and has the wisdom to see better what to do) were right to
have included those newcomers as equals.

So now, having learned this lesson, I invoke the same claim that I once
eschewed--that I've settled in the Lisp community and have as much right
as anyone to claim an opinion as to what Lisp is.  And no, we don't all
agree.  That's ok. I addressed that above.

> The great thing about [the political] argument is that it doesn't


> require any comparison between Scheme and any other Lisp.  Only the
> intent of Sussman and Steele matters; their background, the process
> they used and the result they obtained is irrelevant.

Well, I defend this position as one would a "thesis".  I find it an
interesting point of view and I think it is both internally consistent
and conversationally useful.  But I don't mean to suggest it's the only
possible view.

> In thinking about this some more, the community argument is starting
> to feel more and more like tracing royal bloodlines.  I don't think
> this is a very effective way to classify computer programming
> languages, but maybe it gives some in the Common Lisp community a
> feeling of Divine Right.

I can see how it would seem that way if what you seek is to come up with
an answer to this question "what's a lisp?" in a context-independent way.
I don't think it has a single answer that transcends context, and so
the more you try to make it be wholly general, the more it requires weird
patching and I suppose Divine Right is as good a patch as any.

I usually use the political argument in particular contexts that seem
already political.  People pop up here and say "Should I use Lisp or
Scheme?" and my immediate thought is "this is a political question"
because what I really hear is "I'm going to want certain things, and
when they are not there, I'm going to want to be in the community most
sympathetic to my needs and most likely to cater to me".  Like it or not,
you don't get to an understanding of why a community is what it is, or
why it caters to one or another person or idea, without looking at
history.

But if you look at the set of partitions

In my Slashdot interview, I created a lot of divisions among languages
that are "technically" rather than "politically" derived.  But those
are just overlays.  They are no more Right than any other view.
They just suited the context, which was to suggest some different kinds
of languages that people should know in order to broaden their horizons.

 - A block-structured language, such as Algol or Pascal or Scheme.
 - A line-oriented language, such as Fortran or BASIC.
 - A rule-based logic language, such as Prolog or EMYCIN.
 - An Englishy language such as HyperTalk or Cobol.
 - A "stack" language such as PostScript.
 - A "line noise" language (heavy emphasis on one-letter operators)
   like APL or Teco.
 - A dynamic object-oriented language, such as Common Lisp or Smalltalk.
 - A strongly-typed, statically analyzed language such as ML or Haskell.
 - A dynamically-typed functional programming language, such as Scheme.
 - A string or macro processing language, such as Perl or m4 or TeX or Teco.
 - A database access language, such as SQL.
 - An abstract high-level, assembly language, such as Java.
 - A concrete high-level, assembly language, such as C.
 - A low-level, traditional assembly language.
 - A scripting language, such as Javascript.
 - An interface-definition language such as Visual Basic, HyperTalk,
   or Javascript.
 - A document-structuring language such as XSL or TeX.
 - A language with a modern error system, such as Common Lisp or Dylan.
 - A reflective/introspective language such as Common Lisp or Java.
 - A symbolic programming language, such as Common Lisp or Scheme.
 - A security-oriented language, such as Java or MOO.
 - A language where both programs and data are fully persistent,
   such as MOO or HyperTalk.

You'll note that none of these categories was called Lisp.  You'll also
note that there are categories that only include Scheme or only include
Common Lisp.  And there is a category (which I called here "symbolic
programming languages") that includes both.  This was a fairly ad hoc
list, so don't read too much into my choice of categories.

Some of the category names are deliberately provocative, in order to
encourage people to reconsider some of their assumptions.  I guess
that's the thing that bugs me most about considering Scheme and Common
Lisp to both be Lisps.  It just seems too easy to just say "hey,
they've got parens. they must be the same".  It doesn't require much
thought, and I don't think it yields much conceptual leverage.  I
think it makes the world think harder and learn more to say these are
not the same, and to force people to examine the differences.  So if
you see me being stubborn on this, it's probably more about that and less
any intent to be gratuitously exclusionary.

(If I'm repeating myself uselessly, I'm relying on someone to hold me to
my promise to just shut up.)

Why is Scheme not a Lisp? Erik Naggum 3/13/02 2:42 PM
* Doug Quale <qua...@charter.net>

| Take any complaints about R5RS to Kent M Pitman.  His name is on it, not
| mine.

  Please divert your energy to _thinking_, away from moronic hostilties.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Kent M Pitman 3/13/02 2:45 PM

No, I meant Stallman.  I was talking about how the split with Emacs
Lisp happened, since at the time Stallman set out to make it, we
pestered him to make it CL-compatible.  But I recall at least one of
his major objections being the scoping.  He insisted that dynamic
binding was essential to easy customization he sought in his work, but
in any case was the way Lisp was supposed to be.  I think this was a
principled position, even if I didn't agree with it.  I can't remember
if he had other objections as well.  I felt he was abandoning Common Lisp,
but I think he felt the reverse, that it was abandoning him.

Maybe you were confused because you see the term "revolutionary" as a
term of admiration.  I meant it only literally, and not as a term of
either good or bad; that is, "going against the inertial flow".

Why is Scheme not a Lisp? Kent M Pitman 3/13/02 2:47 PM
Doug Quale <qua...@charter.net> writes:

> Erik Naggum <er...@naggum.net> writes:
>
> >   But nobody says "C is an Algol".
>
> True.  "Is an Algol" doesn't parse, so it wouldn't make any sense.

Besides, Scheme aspires to be an Algol.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/13/02 3:02 PM
Kent M Pitman <pit...@world.std.com> writes:

> tb+u...@becket.net (Thomas Bushnell, BSG) writes:
>
> > Kent M Pitman <pit...@world.std.com> writes:
> >
> > > Incidentally, I think Stallman thought CL was being revolutionary, not
> > > evolutionary, because of its choice of lexical scope (and perhaps for
> > > other reasons).  
> >
> > Do you mean "Sussman" here?
>
> No, I meant Stallman.  I was talking about how the split with Emacs
> Lisp happened, since at the time Stallman set out to make it, we
> pestered him to make it CL-compatible.  

Ah, ok, that's why I was asking.  I was unsure of the history, and it
seemed to me it could make sense both ways.  :)  I mean, Stallman and
Sussman are *still* only paces away from eachother most of the time. :)

> But I recall at least one of his major objections being the scoping.
> He insisted that dynamic binding was essential to easy customization
> he sought in his work, but in any case was the way Lisp was supposed
> to be.  

Hrm, curious.  

One irony is that the thrust of GNU Emacs development in this regard
today is to ultimately transition the extension language to
Guile--lexically scoped as all bingo!  It will have dynamic variables
too, of course; emacs really does seem to need them.

I think one difference in retrospect is that Common Lisp is very, um,
non-lightweight.  Even the 1984 spec is *very* rich.  While that
richness is one of the great strengths of Common Lisp, and one of the
things that accounts for its popularity, it is also a detriment to
using it as an extension language for something like Emacs.

People already complain about Emacs being too huge; adding in the
entire library of Common Lisp would be, um, painful.

Thomas

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/13/02 2:52 PM
Kent M Pitman <pit...@world.std.com> writes:

> We have to endure that others will use the words differently than
> we.  The best we can do is just to explain our own points of views
> and tolerate those of others.

I think this is surely right.  It seems to me that a necessary
corollary is that we ought not insist that the thing named
"comp.lang.lisp" is only for Common Lisp, and nothing else.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erann Gat 3/13/02 2:35 PM
In article <32250424...@naggum.net>, Erik Naggum <er...@naggum.net> wrote:

> * Erann Gat
> | So I have another question directed to those who say Scheme is not a
> | Lisp: is the concept of "programming language with S-expression-based
> | syntax" not important enough to deserve its own less verbose term?  If it
> | is, what should that term be if not "Lisp"?
>
>   How hard is it to say "Lisp family"?

That's fine, but given the vehemence with which "Scheme is a Lisp" is
opposed it is not self-evident that "Scheme is a member of the Lisp family
of languages" would be any less objectionable.  In fact, to me both
sentences seem to mean precisely the same thing.

E.

Why is Scheme not a Lisp? Doug Quale 3/13/02 3:23 PM
Carl Shapiro <cshapi...@panix.com> writes:

Are you sure about this?  NLAMBDA is extremely similar to FEXPR, but
Wasn't FEXPR in Lisp 1.5, a common ancestor to both Maclisp and
Interlisp?  MIT AI Memo 57 mentions FEXPR in 1963, the year I was
born.  (Timothy P. Hart, "Macro Definitions for LISP", AI Memo 57,
October 1963.)

Steele and Gabriel talk about the Maclisp and Interlisp communities in
"The Evolution of Lisp" (Guy L. Steele, Jr. and Richard P. Gabriel,
ACM SIGPLAN Notices, 28(3), p231-270, 1993).  They say this about a
1974 meeting between Maclisp and Interlisp implementors:

"In 1974 about a dozen persons attended a meeting at MIT between the
MacLisp and Interlisp implementors, including Warren Teitelman, Alice
Hartley, Jon L White, Jeff Golden, and Steele.  There was some hope of
finding substantial common ground, but the meeting actually served to
illustrate the great chasm separating the two groups, in everything
from implementation details to overall design philosophy....  In the
end only a trivial exchange of features resulted from "the great
MacLisp/Interlisp summit": MacLisp adapted from Interlisp the behavior
(CAR NIL) -> NIL and (CDR NIL) -> NIL, and Interlisp adopted the
concept of a read table."


--
Doug Quale

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Paul Wallich 3/13/02 3:24 PM
In article <gat-130302...@eglaptop.jpl.nasa.gov>, g...@jpl.nasa.gov
(Erann Gat) wrote:

Nah. It's a matter both of precedence and of the fact that "A Lisp"
has pretty much come to mean Common Lisp, at least in this
newsgroup. (All of the remnants and descendants of older-style
lisps and little lisps seem pretty strongly deprecated -- not that
that's necessarily a bad approach).

But whoever was trying to use the analogy to saying that English
is a dialect of German vs saying that English is a member of the
germanic family of languages had it about right, I think. One
fomulation makes it clear that the family name is just a name,
the other implies which language the speaker considers first-class.

paul

Why is Scheme not a Lisp? Christopher Browne 3/13/02 3:22 PM
In an attempt to throw the authorities off his trail, tb+u...@becket.net (Thomas Bushnell, BSG) transmitted:

> People already complain about Emacs being too huge; adding in the
> entire library of Common Lisp would be, um, painful.

I really can't imagine why this should be considered so "painful."

The source code for CLISP, a CL in C, represents a download of about
10.8MB of code.

The equivalent download for Guile and Goops is 7.3MB.  There's a
difference in size, but not a particularly immense difference.  Add in
a bytecompiler for Guile, which _isn't_ there now, and I'd be
completely unsurprised to see the source tree for Guile get downright
bigger than that.

Similar is true for DrScheme/MzScheme, which has a footprint of about
12MB of sources.  That probably includes the GUI, but it's hardly
"tiny."
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/internet.html
Rules of the Evil Overlord #46. If an advisor says to me "My liege, he
is but one man. What can one man possibly do?", I will reply "This."
and kill the advisor. <http://www.eviloverlord.com/>

Why is Scheme not a Lisp? Erik Naggum 3/13/02 3:31 PM
* Thomas Bushnell, BSG

| I think this is surely right.  It seems to me that a necessary corollary
| is that we ought not insist that the thing named "comp.lang.lisp" is only
| for Common Lisp, and nothing else.

  But nobody "insist" on that at all -- nobody even thinks so.  All I
  insist is that you take your Scheme stuff to comp.lang.scheme and your
  Dylan stuff to comp.lang.dylan and your Ada stuff to comp.lang.ada,
  because so little information come out of polluting discussions with
  these other languages.  This is both because these languages have their
  own fan clubs/newsgroups and because that only the differences between
  Common Lisp and these other languages are discussed here.  People do in
  fact not discuss their commonality here.  It is that simple and easy.

  I actually completely fail to understand what you Scheme freaks and Dylan
  users want to take over comp.lang.lisp for.  Why are you posting here?
  Better audience, smarter people, fewer anal-retentive readers, _what_?
  Why _do_ you want to post comp.lang.lisp when it annoys people so much?
  I conclude that you do it in _order_ to annoy people and that you have
  _no_ constructive element to your obnoxiousness.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Erik Naggum 3/13/02 3:40 PM
* Thomas Bushnell, BSG

| I think one difference in retrospect is that Common Lisp is very, um,
| non-lightweight.  Even the 1984 spec is *very* rich.  While that richness
| is one of the great strengths of Common Lisp, and one of the things that
| accounts for its popularity, it is also a detriment to using it as an
| extension language for something like Emacs.

  I disagree.  Emacs Lisp would have been a lot simpler if it were based on
  Common Lisp.  A lot.  Object-orientation Common Lisp style would have
  made Emacs a lot more customizable and much friendlier to Emacs hackers
  (old sense).

| People already complain about Emacs being too huge; adding in the entire
| library of Common Lisp would be, um, painful.

  Not so.  Trust me on this, I spent a year or so working on a design for
  CLEMACS, until it became clear to me that I would have to maintain
  _continued_ source-level compatibility with Emacs Lisp, and that caused
  me to rethink the whole idea and its desirability, because I had worked
  too long on Emacs Lisp to regard this as a simple, solvable problem.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Erik Naggum 3/13/02 3:42 PM
* Doug Quale

> True.  "Is an Algol" doesn't parse, so it wouldn't make any sense.

* Rahul Jain


> And yet "is a Lisp" does?

* Doug Quale <qua...@charter.net>


| You must think it does.
|
| If it doesn't, would you explain to me again what your complaint is?

  So we have yet another stupid troll on our hands.  Go away, OK?

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erik Naggum 3/13/02 3:44 PM
* Erann Gat

| That's fine, but given the vehemence with which "Scheme is a Lisp" is
| opposed it is not self-evident that "Scheme is a member of the Lisp
| family of languages" would be any less objectionable.  In fact, to me
| both sentences seem to mean precisely the same thing.

  That is because you do not listen to other people, Erann.  If they mean
  the same thing to you, say the latter, and see how people react.  If you
  only _think_ they would react the same because you think the two are the
  same, which they are not, you make the age-old mistake of prejudice.  Not
  that this surprises me, but it is still something you can do better than.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Rahul Jain 3/13/02 4:20 PM
Doug Quale <qua...@charter.net> writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
> > Doug Quale <qua...@charter.net> writes:
> > > True.  "Is an Algol" doesn't parse, so it wouldn't make any sense.
> > And yet "is a Lisp" does?
> You must think it does.

Why must I think it does?

> If it doesn't, would you explain to me again what your complaint is?

That you are claiming that a statement that doesn't exist is true, I
guess.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Pierre R. Mai 3/13/02 3:44 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

I don't think so.

Regs, Pierre.

--
Pierre R. Mai <pm...@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein

Why is Scheme not a Lisp? Kent M Pitman 3/13/02 4:40 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Kent M Pitman <pit...@world.std.com> writes:

> > But I recall at least one of [RMS'] major objections being the scoping.


> > He insisted that dynamic binding was essential to easy customization
> > he sought in his work, but in any case was the way Lisp was supposed
> > to be.  
>
> Hrm, curious.  
>
> One irony is that the thrust of GNU Emacs development in this regard
> today is to ultimately transition the extension language to
> Guile--lexically scoped as all bingo!  It will have dynamic variables
> too, of course; emacs really does seem to need them.

Yes, I've noticed this, too.  But I find I'm wrong sometimes, or that I
change.  And so I like not to rub it in.  I remember when I was in grade
school having my mom say that one day some food she was trying to foist
upon me that day would be something I would like.  But I had the presence
of mind to came back with: Yes, but right now I'm a child, and I haven't
made that transition yet, and I don't like it.  (Which is not to say that
RMS was then a child.  Just that people take things at their own pace.)

> I think one difference in retrospect is that Common Lisp is very, um,
> non-lightweight.

Sure.  But all I wanted him to do was to be CL-compatible on the obvious
syntactic stuff, to avoid _gratuitous_ divergence.  Purposeful divergence
is another matter.

> Even the 1984 spec is *very* rich.  While that
> richness is one of the great strengths of Common Lisp, and one of the
> things that accounts for its popularity, it is also a detriment to
> using it as an extension language for something like Emacs.

I disagree, only since I didn't ever suggest this.  Subsetting would have
been adequate.  I'm quite sure he wasn't confused about my desire on
this point.

> People already complain about Emacs being too huge; adding in the
> entire library of Common Lisp would be, um, painful.

And needless.  I certainly would never have suggested it.

Why is Scheme not a Lisp? Kent M Pitman 3/13/02 4:45 PM
Doug Quale <qua...@charter.net> writes:

> Carl Shapiro <cshapi...@panix.com> writes:
>
> > Doug Quale <qua...@charter.net> writes:
> >
> >          Isn't it true that the Interlisp and Maclisp communities had no
> > > significant mixing (when Interlisp was still alive)?  
> >                                                        
> > This is most certainly not true.  There are a number of significant
> > ideas that were shared between Maclisp and the BBN-Lisp, SDS Lisp,
> > (and later) Interlisp, family.  For example, the Interlisp NLAMBDA is
> > extremely similar to the Maclisp FEXPR.
>
> Are you sure about this?  NLAMBDA is extremely similar to FEXPR, but
> Wasn't FEXPR in Lisp 1.5, a common ancestor to both Maclisp and
> Interlisp?  MIT AI Memo 57 mentions FEXPR in 1963, the year I was
> born.  (Timothy P. Hart, "Macro Definitions for LISP", AI Memo 57,
> October 1963.)

The difference was that NLAMBDA had an anonymous form.

 ((NLAMBDA (A B) (LIST B A)) X Y) => (Y X)

A FEXPR was a property upon which you put an ordinary LAMBDA and it caused
the symbol having that property to have special meaning.

 (DEFPROP FOO (LAMBDA (ARGS) (LIST (CADR ARGS) (CAR ARGS))) FEXPR)

 (FOO X Y) => (Y X)

Note, though, that when such a DEFPROP was compiled, it secretly put
a compiled function on the FSUBR property instead of putting a list
on the FEXPR property.  Maclisp was full of strangeness like that.

NLAMBDA was more akin to the Zetalisp &QUOTE.

 (NLAMBDA (X Y) (LIST X Y)) == (LAMBDA (&QUOTE X Y) (LIST X Y))

NLAMBDA had no way to express &EVAL, which would undo the &QUOTE effect.

These ideas were important to bootstrapping systems, but were bad in users'
hands and went away when macros came into big popularity.  See my Special
Forms paper at
 http://world.std.com/~pitman/Papers/Special-Forms.html

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Kent M Pitman 3/13/02 4:48 PM
g...@jpl.nasa.gov (Erann Gat) writes:

It doesn't have to be a member of the Lisp family to use Lisp notation.
I'd just say it uses Lisp-like notation, just as I'd say Java uses C-like
notation.

No need to pull in the full baggage of language families, which implies
a lot more than syntax, if all you're talking about is notation.

Why is Scheme not a Lisp? Bruce Hoult 3/13/02 4:51 PM
In article <jlbm6a...@rabbit.ddts.net>,
 Larry Clapp <la...@theclapp.org> wrote:

> I don't think one can say that a) Common Lisp comes from a subset of Scheme,
> b) Scheme comes from a subset of Common Lisp, c) Common Lisp and Scheme form
> different subsets of some larger language, or d) Common Lisp and Scheme form
> different supersets of some smaller language.[2]

Your a) and b) are just special cases of d).

I don't think any of these need to be true in a precise, character for
character way, in order for both to be "Lisps".

I'd look for things more like ability to translate typical textbook
programs from one language to another without excessive blowout in
program size.  I'd allow non-task specific libraries to be added without
counting towards the program size e.g. hash tables or OO libraries for
Scheme.

What proportion of code from SICP can be easily translated to Common
Lisp or Dylan?  Just about anything that doesn't use call/cc (and much
that does).

What proportion of "On Lisp" can be easily translated into Dylan or
Scheme?  Well, I'm in the process of finding out but the answer, at
least in the case of Dylan, is "more than you might think".

-- Bruce

Why is Scheme not a Lisp? Daniel Barlow 3/13/02 4:13 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> People already complain about Emacs being too huge; adding in the
> entire library of Common Lisp would be, um, painful.

In 1984, maybe.  Today, I doubt anyone would notice.  The emacs I'm
writing this in is 50Mb or so in RSS: adding gnu clisp to this would
make for another 2Mb, at a guess.  Maybe the extra stuff in the Common
Lisp library would even bring this size down through code reuse.
Greenspun's Rule, etc.

The emacs I'm writing this in is not usually even the biggest process
on this machine either: that position is reserved for some kind of
glorified help file viewer with a socket interface stuck on (netscape,
mozilla, galeon, depending on whim)


-dan

--

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

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/13/02 5:11 PM
Kent M Pitman <pit...@world.std.com> writes:

> Yes, I've noticed this, too.  But I find I'm wrong sometimes, or that I
> change.  And so I like not to rub it in.  

I remember asking RMS why Emacs didn't use lexical scoping; this was
back in the early 90s.  He said that if he had it over to do, it would
use lexical scoping.  I had no idea that it was such a hot-button
issue for him back when he was doing the design

Why is Scheme not a Lisp? Bruce Hoult 3/13/02 5:18 PM
In article <sfwu1rk...@shell01.TheWorld.com>,
 Kent M Pitman <pit...@world.std.com> wrote:

> olc...@interaccess.com (Thaddeus L Olczyk) writes:
>
> > On Tue, 12 Mar 2002 12:00:23 -0800, g...@jpl.nasa.gov (Erann Gat)
> > wrote:
> >
> > Use the simple and most basic test of whether or not Scheme is a Lisp.
> >
> > Assume you take a standard text book ( say one of the following
> > ACL by Paul Graham, Dr. Touretsky's book, Successful Lisp
> > or David Coopers book ). Assuming you have no previous experience
> > in Lisp ( or Scheme). Instal a Scheme compiler and start writing for
> > it. How much do you have to thumb through a Scheme reference.
> > If it's significantly less than the amount a C programmer thumbs
> > through a Pascal reference when writing a Pascal program, then
> > Scheme is a Lisp. If not then Scheme is not a Lisp. ( BTW no
> > C programmer or Pascal programmer would claim C is a dialect of Pacal.
> > )
>
> I'm worried that the same test, done in reverse, with a Scheme text and
> a Lisp compiler would conclude that Lisp is a Scheme.  That seems a bad
> property of the test.  It tests distance, not containment.

I think that is in fact the appropriate test.


> Also, when I first learned to program, it was with FORTRAN on punch cards on
> an IBM 1130.  Then our school bought a WANG 2200S minicomputer that
> ran BASIC and I thumbed through a manual.  I had no sense then of the
> space of computer languages.  I had seen only FORTRAN.  My initial
> assumption was that BASIC was just a FORTRAN variant.  Had I used
> your test, I might well have concluded that it confirmed my suspicions.

I'd agree that BASIC is a dialect of FORTRAN.  Most programs in one can
be painlessly restated in the other.

This is not true of either language and C or Pascal or Lisp.


> And also, I think both C and Pascal are members of the Algol family.
> But your test seems to presuppose they are unrelated languages.

I agree that C and Pascal are members of the Algol family (as are Scheme
and Dylan), but they've diverged too far to be considered to be dialects
of each other.

Even beginning Pascal texts make heavy use of lexically nested
functions, which can not be readily translated into C.  And beginning C
texts make heavy use of pointer/array conversion and pointer arithmetic,
which can not be readily translated into Pascal.


The same argument applies to, say, Scheme and ML.  There is a lot in
common, but ML texts make heavy use of implicit currying and pattern
matching, while Scheme texts make heavy use of runtime polymorphism.


> Scheme is its own language, not a dialect of Lisp.

Change that to "not a dialect of *Common* Lisp and I'd agree with you.  
Certainly it is its own language, but saying it's a Lisp is not
insulting it.


> Even Dylan can be called part of the Lisp language family, if you mean
> it in the historical sense of Erik's "Germanic" analogy, though I
> certainly again would not call it a dialect of Lisp.

Not only in the historical sense.  Most idiomatic Dylan and CL code that
I have seen can very easily be translated to the other language and
still be idiomatic.

-- Bruce

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/13/02 5:24 PM
Bruce Hoult <br...@hoult.org> writes:

> What proportion of code from SICP can be easily translated to Common
> Lisp or Dylan?  Just about anything that doesn't use call/cc (and much
> that does).

SICP never mentions call/cc, so that part is easy!  

However, SICP frequently uses variables to hold functions without
wanting extra hair.  For example, on p. 58 (of the 2nd edition), is
the following example for a "sigma" summation function:

(define (sum term a next b)
  (if (> a b)
    0
    (+ (term a)
       (sum term (next a) next b))))

People have barely begun the course when they get to this.  In CL,
you'd do the same thing if you wanted, by passing in functions and
using APPLY to call them.  

So in one sense, it's trivial to translate.  However, it would totally
defeat the pedagogic purpose to have to talk about APPLY at such an
early stage.

Similarly, functions are returned as values on pp. 72ff.

Any language with first class procedures can do this, of course, and
it's easy to add calls to APPLY (and friends) wherever necessary to
translate into Lisp.  In once sense, then, you can translate
everything easily.  In another sense, you would defeat the pedagogic
purpose of SICP if you had to.

SICP doesn't mention hygenic macros either, and it might be hard to
automatically translate them to CL macros; however, a human who looked
at and understood a Scheme macro definition, could surely produce the
equivalent Common Lisp with no trouble.

Thomas

Why is Scheme not a Lisp? Doug Quale 3/13/02 5:49 PM
Kent M Pitman <pit...@world.std.com> writes:

> Doug Quale <qua...@charter.net> writes:
>
> > ... Isn't it true that the Interlisp and Maclisp communities had no
> > significant mixing (when Interlisp was still alive)?  My impression is
> > that the communities were almost totally separate, and that many in
> > the Maclisp community had the same kind of disdain for Interlisp then
> > that some in the Common Lisp community show for Scheme now.
>
> You mean like British and American?

Yes, and we speak a common language don't we?  American English is
English, isn't it?  How does this support the idea that the Interlisp
community belongs to the Lisp community and Scheme doesn't?

> And I should also note that McCarthy has asked that no member of the Lisp
> family claim the unadorned name "Lisp".  That is, that it be reserved to
> the family.

I hope Erik Naggum is reading this, because he maintains that "Lisp"
is not understood to mean the Lisp family.

Also, you frequently seem to use Lisp yourself when you are in fact
assuming CL.

> But I mention this because we sometimes refer to "dialect of Lisp" yet the
> term "dialect of xxx" usually refers to a language, and there really is no
> language that is Lisp, so we're really saying "dialectal variants of
> languages in the Lisp family", and then that makes the the question more
> vague: what is in the question.

This is an interesting point.  Clearly "Scheme is a dialect of Lisp"
should have the same interpretation as "Interlisp is a dialect of
lisp", although they may have different truth values.  If it is
sensible to call Common Lisp a dialect of Lisp, then the question "Is
Scheme a dialect of Lisp" has meaning.

> > History is written
> > by the victors.  That answers a question, but I'm not certain if it's
> > the question that was asked.  Basically we've arrived at "Scheme is
> > not a Lisp because Common Lisp people say it isn't."  There is a nice
> > finality to this, if Common Lisp users have the ability to decree what
> > is and isn't a Lisp.
>
> For myself, the issue isn't to "define away" or "marginalize" another
> language.  It is merely to restrict the meaning of an otherwise
> useless word to a point where it can have meaning.

Do you mean that saying "Scheme is a member of the lisp family" would
make the word "lisp" useless?  I don't agree, but clearly that is a
matter of opinion.

> Certainly McCarthy is entitled to say what he thinks is criterial to Lisp,
> but I would make a different list.

As is your right.  The original question that spawned this thread
boils down to, "What is your list that makes Scheme not a Lisp?"  Some
people have had difficulty imagining what the list might be, since the
list should include Lisp 1.5, Maclisp, Interlisp, NIL, ZetaLisp,
Common Lisp and others and exclude Scheme.  I'm not sure whether your
list would include PSL or MuLisp as Lisps, since they had essentially
no cultural connection with Maclisp at all.  Presumably the list would
also not include T even though you yourself were responsible for some
nice parts of that language design.  Since I don't have your list, I
can't tell.

> And I don't know how I feel about him
> retaining the right to say what Lisp is.  I don't generally accord to the
> author of a book or director of a movie the right to dictate what the
> significance of that book or movie is.  Sometimes I'm not sure they even
> know.  I'm not saying McCarthy is an idiot by any means, nor even that he's
> not entitled to his opinion.  But I think we who have invested in the
> community have a right to determine it too.

I'm not granting him that right a priori, and in actual fact I don't
know if McCarthy considers Scheme to be a Lisp.  One of the things
that I can say in favor of McCarthy is that he has provided some
characteristics that could actually be used to determine whether or
not a programming language is a member of the lisp family in a fairly
objective and non-arbitrary fashion.  I can't really say that about
the community argument you have offered.

> So now, having learned this lesson, I invoke the same claim that I once
> eschewed--that I've settled in the Lisp community and have as much right
> as anyone to claim an opinion as to what Lisp is.  And no, we don't all
> agree.  That's ok. I addressed that above.

It's OK with you, it's OK with me, but it's obviously not OK with
everyone.  Another round of name-calling will ensue from some
ill-behaved members of the CL crowd.  You're certainly not responsible
for it, but it's a shame.

> > The great thing about [the political] argument is that it doesn't
> > require any comparison between Scheme and any other Lisp.  Only the
> > intent of Sussman and Steele matters; their background, the process
> > they used and the result they obtained is irrelevant.
>
> Well, I defend this position as one would a "thesis".  I find it an
> interesting point of view and I think it is both internally consistent
> and conversationally useful.  But I don't mean to suggest it's the only
> possible view.

There's no doubt it's consistent, but it has some unusual properties.
It basically hinges on your opinion that the Scheme community
deliberately broke away from the Lisp community.  In other words,
Common Lisp didn't force Scheme out, Scheme left on its own (before
Common Lisp was born).  This relies on your insight into the motives
of Sussman and Steele when they created Scheme.  Anyone lacking that
insight may have trouble with your argument without some additional
supporting evidence.  You have an advantage here, since you know
Sussman and Steele personally and I don't.

> I usually use the political argument in particular contexts that seem
> already political.

Why is the question "Is Scheme a Lisp?" political to you?  That really
gets to the heart of it.  It may explain why some Common Lisper's
react so emotionally the this question, and why that emotion surprises
Schemer's who expect that the answer might be based on syntax,
semantics or problem domain rather than politics.

> People pop up here and say "Should I use Lisp or
> Scheme?" and my immediate thought is "this is a political question"
> because what I really hear is "I'm going to want certain things, and
> when they are not there, I'm going to want to be in the community most
> sympathetic to my needs and most likely to cater to me".  Like it or not,
> you don't get to an understanding of why a community is what it is, or
> why it caters to one or another person or idea, without looking at
> history.

That question certainly is often political, but it wasn't the question
that was asked this time.  Even so, the full history of Lisp doesn't
seem to be well understood even in c.l.l.  I don't place you in this
group, but many people have strong opinions that Scheme is not a Lisp,
but don't know the circumstances in which McCarthy created Lisp around
1958 or 1959, or how Sussman and Steele came to create Scheme in 1977
and 1978.  Naturally you are far more familiar with much of that
history than I am since you experienced important parts of it first
hand.  It is certainly possible that what I have read is not true or
that I have misinterpreted it -- that's one of the reasons why I am
here.

I know you don't want to get drawn into an extended discussion of this
list, but which category includes Scheme that wouldn't include Common
Lisp?  I don't see how Scheme is any more block-structured than CL
except in superficial ways, even if you didn't list Common Lisp in
that category.

> I guess
> that's the thing that bugs me most about considering Scheme and Common
> Lisp to both be Lisps.  It just seems too easy to just say "hey,
> they've got parens. they must be the same".  It doesn't require much
> thought, and I don't think it yields much conceptual leverage.  I
> think it makes the world think harder and learn more to say these are
> not the same, and to force people to examine the differences.  So if
> you see me being stubborn on this, it's probably more about that and less
> any intent to be gratuitously exclusionary.

I know the "hey they've got parens, they must be the same" worry has a
lot of traction in this newgroup, but please forgive me if I say that
it sounds silly to me.  I can see that it is very important for the
Common Lisp community to emphasize its differences with Scheme, but I
can't understand why.  It's certainly your perogative, but if that's
your best argument, you can probably see why it might look like an
intent to be gratuituously exclusionary.

> (If I'm repeating myself uselessly, I'm relying on someone to hold me to
> my promise to just shut up.)

No, I always find what you have to say interesting even if I disagree.
I think others do too.


--
Doug Quale

Why is Scheme not a Lisp? Doug Quale 3/13/02 6:02 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Seems like this list is misleading and/or inaccurate. Probably because
> it was published in 1980 and we're applying it to 2000's context.

You overlooked that I pointed out the fact that McCarthy explicitly
wrote in 1999 that the paper still accurately reflected his opinions.

Also, I don't mean to be insulting, but you do know that John McCarthy
invented LISP in 1958 or 1959, right?  If you haven't read "Recursive
Functions of Symbolic Expressions and Their Computation by Machine,
Part I" by McCarthy from Commications of ACM, 1960, you should before
you continue.  (You can find it on line at
http://www-formal.stanford.edu/jmc/recursive.html).

Most of the rest of your comments are historically or technically
inaccurate.


--
Doug Quale

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Doug Quale 3/13/02 6:06 PM
Kent M Pitman <pit...@world.std.com> writes:

> It doesn't have to be a member of the Lisp family to use Lisp notation.
> I'd just say it uses Lisp-like notation, just as I'd say Java uses C-like
> notation.

What languages use Lisp-like notation that are not members of the Lisp
family?  Clearly such languages are possible, but they don't seem to
be plentiful.


--
Doug Quale

Why is Scheme not a Lisp? Bruce Hoult 3/13/02 6:33 PM
In article <gat-130302...@eglaptop.jpl.nasa.gov>,
 g...@jpl.nasa.gov (Erann Gat) wrote:

> People who use S-expression-based languages tend to
> embrace the idea of *extending* a programming langauge as a useful
> programming technique because extending an S-expression-based language is
> easy.  People who use non-S-expression-based languages tend not to even
> consider extending the language because doing so is all but impossible
> (with Dylan perhaps being a notable exception).

Which indicates that it is not the S-expressions that make the
difference, but the desire to make the syntax extensible.

It's harder to do a trivial parse of Dylan than to do a trivial parse of
Common Lisp or Scheme, but it's not all *that* hard -- there are only
three basic forms of macro, and everything is built using them:

  define ... end
  foo()
  bar ... end

Note that dylan-mode.el does a good job of indenting user-defined macro
constructs, even though it doesn't understand them.


Doing a semantic parse of Dylan is much harder, but then that's true of
Common Lisp as well -- "understanding" Dylan is pretty much the same as
"understanding" the CL "loop" macro.

-- Bruce

Why is Scheme not a Lisp? Bruce Hoult 3/13/02 6:56 PM
In article <87k7sgl...@becket.becket.net>,

 tb+u...@becket.net (Thomas Bushnell, BSG) wrote:

> Bruce Hoult <br...@hoult.org> writes:
>
> > What proportion of code from SICP can be easily translated to Common
> > Lisp or Dylan?  Just about anything that doesn't use call/cc (and much
> > that does).
>
> SICP never mentions call/cc, so that part is easy!  

Ah.  I loaned out my copy and it hasn't come back :-(


> However, SICP frequently uses variables to hold functions without
> wanting extra hair.  For example, on p. 58 (of the 2nd edition), is
> the following example for a "sigma" summation function:
>
> (define (sum term a next b)
>   (if (> a b)
>     0
>     (+ (term a)
>        (sum term (next a) next b))))
>
> People have barely begun the course when they get to this.  In CL,
> you'd do the same thing if you wanted, by passing in functions and
> using APPLY to call them.  
>
> So in one sense, it's trivial to translate.  However, it would totally
> defeat the pedagogic purpose to have to talk about APPLY at such an
> early stage.

Surely FUNCALL is sufficient?  And far easier to explain than APPLY.

* (defun sum (term a next b)


    (if (> a b)
      0
      (+ (funcall term a)
         (sum term (funcall next a) next b))))

SUM
* (sum (lambda (a) (* a a)) 5 #'1+ 10)

355

-- Bruce

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Duane Rettig 3/13/02 7:00 PM
Doug Quale <qua...@charter.net> writes:

Some CAD parts representation systems use Lisp-like notation, and
aren't Lisps (i.e. some are implemented in Lisp, but others are not).

--
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   duane@Franz.COM (internet)

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Bijan Parsia 3/13/02 7:49 PM
On Thu, 14 Mar 2002, Duane Rettig wrote:

> Doug Quale <qua...@charter.net> writes:
[snip]


> > What languages use Lisp-like notation that are not members of the Lisp
> > family?  Clearly such languages are possible, but they don't seem to
> > be plentiful.
>
> Some CAD parts representation systems use Lisp-like notation, and
> aren't Lisps (i.e. some are implemented in Lisp, but others are not).

How about the Knowledge Interchange Format (KIF):
         http://logic.stanford.edu/kif/kif.html

It's certainly Lisp like, but I feel rather confident that it isn't a Lisp
(though it could easily, I *think*, be made into one or part of
one; perhaps that's the "problem", anything with a sufficiently Lisp like
notation is very easily slurped into a Lisp).

There are a few Prologs about that use Lisp like notation (even aside from
the Prolog-in-Lisps, like Norvig's).

SXML, SXPath, and SXSLT? Olin Shivers S-rexps? The first two, and the
last, may not be programming langauges, but it's not clear that that is a
constraint. SXSLT is definitely one, being the sexpressization of XSLT,
which is an XMLization of a Scheme (i.e., DSSSL).

Then there's always Scheme... ;)

Cheers,
Bijan Parsia.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Doug Quale 3/13/02 7:49 PM
Duane Rettig <du...@franz.com> writes:

> Doug Quale <qua...@charter.net> writes:
>
> > What languages use Lisp-like notation that are not members of the Lisp
> > family?  Clearly such languages are possible, but they don't seem to
> > be plentiful.
>
> Some CAD parts representation systems use Lisp-like notation, and
> aren't Lisps (i.e. some are implemented in Lisp, but others are not).

Do these parts representation systems use Lisp-like notation for
programs, or just data?  I can use C to manipulate XML data, but C is
not XML.  The key idea in Lisp is that program is data, and that's
missing in those cases.  Do you have a language in mind?

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Christopher C. Stacy 3/13/02 8:10 PM
>>>>> On 13 Mar 2002 20:06:18 -0600, Doug Quale ("Doug") writes:

 Doug> Kent M Pitman <pit...@world.std.com> writes:
 >> It doesn't have to be a member of the Lisp family to use Lisp
 >> notation.  I'd just say it uses Lisp-like notation, just as I'd
 >> say Java uses C-like notation.

I think there have been assembly languages that used that  of syntax.

Also, didn't someone discover s-expressions used in some Microsoft
product?  I can't remember which kind of document it was; just that
some Lisper saw it and got momentarily excited.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Doug Quale 3/13/02 8:28 PM
Bijan Parsia <bpa...@email.unc.edu> writes:

> > Doug Quale <qua...@charter.net> writes:
> [snip]
> > > What languages use Lisp-like notation that are not members of the Lisp
> > > family?  Clearly such languages are possible, but they don't seem to
> > > be plentiful.
> >
> > Some CAD parts representation systems use Lisp-like notation, and
> > aren't Lisps (i.e. some are implemented in Lisp, but others are not).
>
> How about the Knowledge Interchange Format (KIF):
>          http://logic.stanford.edu/kif/kif.html

An excellent example.  I did not know about KIF, but it seems that it
emphasizes programs as data, which is a Lispy concept.  It isn't
really designed for programming, so it's something of a hybrid
executable data interchange format/programming language, which I think
is a really good idea.  (Comparisons with PostScript are apropriate.
Imagine how much nicer PostScript would be if it had a Lisp nature
instead of a Forth nature.)  KFI looks like what I think SGML/HTML/XML
should have been.

> There are a few Prologs about that use Lisp like notation (even aside from
> the Prolog-in-Lisps, like Norvig's).

Good.  I had forgotten about them.  Edinburg syntax has pretty much
dominated the Prolog world, much as Common Lisp as become dominant
over its rivals.

> SXML, SXPath, and SXSLT? Olin Shivers S-rexps? The first two, and the
> last, may not be programming langauges, but it's not clear that that is a
> constraint. SXSLT is definitely one, being the sexpressization of XSLT,
> which is an XMLization of a Scheme (i.e., DSSSL).

I don't think SXML and SXPath are programming languages.  Olin Shivers
S-rexps are clearly not a programming language at all, but SXSLT is
another good example.

Thanks for the examples.

--
Doug Quale

Why is Scheme not a Lisp? Erik Naggum 3/13/02 8:33 PM
* Thomas Bushnell, BSG

| (define (sum term a next b)
|   (if (> a b)
|     0
|     (+ (term a)
|        (sum term (next a) next b))))
|
| People have barely begun the course when they get to this.  In CL,
| you'd do the same thing if you wanted, by passing in functions and
| using APPLY to call them.  

  apply?  Scheme and Common Lisp both need apply for exactly the same
  reason.  Scheme and Common Lisp differ in the use of _funcall_.

  I have such pity on you poor Scheme victims that I wrote the following
  little macro just to prove that Common Lisp is able to accomodate your
  needs painlessly: at the very least it removes the funcall allergen.

(defmacro with-functions (functions &body body)
  `(macrolet ,(mapcar (lambda (function)
                         `(,function (&rest args)
                            `(funcall ,',function ,@args)))
                      functions)
     (locally (declare (function ,@functions))
       ,@body)))

| So in one sense, it's trivial to translate.  However, it would totally
| defeat the pedagogic purpose to have to talk about APPLY at such an early
| stage.

  But would you talk about apply in a Scheme text unless you had a list of
  variables?  Something tells me you are reaching, not just mistaken.

  Anyway, you can now write

(defun sum (term a next b)
  (with-functions (term next)

    (if (> a b)
      0
      (+ (term a)
         (sum term (next a) next b)))))

  instead of the supposedly horribly inelegant

(defun sum (term a next b)


  (if (> a b)
    0
    (+ (funcall term a)
       (sum term (funcall next a) next b)))))

  I frankly do not see how this minor problem turns into this major deal
  for Schemers.  Common Lispers change their language if something bothers
  them too much.  In an educational setting, it is not unusual for the
  teacher/master to set up a more pedagogical environment than programmers
  usually use.  If one uses or teaches the use of functions in variables a
  lot, I think it even makes sense to adopt a style like the above, since
  funcall may indeed make the code less readable.  with-functions also
  provides the lexically evident clues that these names are special.  The
  programmer does not have to check every function call to be certain that
  it has a different lexical than global meaning, as one must do in Scheme.
  There is no accidental "overwriting" global function definitions: You may
  call a variable "list" as long as you do not hand it to with-functions.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Doug Quale 3/13/02 8:35 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Doug Quale <qua...@charter.net> writes:
>
> > Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
> > > Doug Quale <qua...@charter.net> writes:
> > > > True.  "Is an Algol" doesn't parse, so it wouldn't make any sense.
> > > And yet "is a Lisp" does?
> > You must think it does.
>
> Why must I think it does?
>
> > If it doesn't, would you explain to me again what your complaint is?
>
> That you are claiming that a statement that doesn't exist is true, I
> guess.

Kent Pitman has explained at least twice in this thread that John
McCarthy wishes the term "Lisp" to be reserved for the lisp family of
languages.  Have you been reading his messages?

--
Doug Quale

Why is Scheme not a Lisp? Erik Naggum 3/13/02 8:48 PM
* Doug Quale

| I hope Erik Naggum is reading this, because he maintains that "Lisp" is
| not understood to mean the Lisp family.

  Does the world really have only one context in your mind?  Perhaps that
  is the fundamental nature of the troll?

| Also, you frequently seem to use Lisp yourself when you are in fact
| assuming CL.

  That is the _point_, dude.  Be nice and get it.

| Do you mean that saying "Scheme is a member of the lisp family" would
| make the word "lisp" useless?  I don't agree, but clearly that is a
| matter of opinion.

  No, that is precisely what would _give_ "Lisp" accurate meaning.

| As is your right.  The original question that spawned this thread
| boils down to, "What is your list that makes Scheme not a Lisp?"

  No, that is not what it boils down to.  It boils down to "we reject the
  reasons the Scheme freaks have to want to say Scheme is a Lisp", one of
  them being "oh, it just means the same as 'Scheme is in the Lisp family',
  which we stubbornly do not want to say because it probably does not bug
  the Common Lisp people"

  Please figure out that this is not about your anal-retentive "list of
  features" question.  When you keep making up things to argue against that
  people do not actually mean, and continue despite negative feedback, you
  _must_ be a stupid troll just out to annoy people.  Quit playing games.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Duane Rettig 3/13/02 9:00 PM
Doug Quale <qua...@charter.net> writes:

Well, if you really meant which languages _can_ use lisp-like
notation but are not members of the lisp family, then the answer is
_all_ of them (i.e. all non-lisp-family languages).

Bijan Parsia gave an example.  I have seen others from customers'
use, but they may be proprietary (the tendency I've seen in CAD is
to define their data structures in list format - I may be myopic
because of my lisp-centered viewpoint, but I even noticed this years
before I got into Lisp, in my hardware days).  But though the
external data representations are in list format, the languages are
not necessarily; they can just operate on them, just as you say.

The reason why I didn't answer Erann's question was because he
was specific about using lisp notation for both code and data,
and you asked a more pointed question.

--
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   duane@Franz.COM (internet)

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Joe Marshall 3/13/02 9:12 PM

"Erann Gat" <g...@jpl.nasa.gov> wrote in message
news:gat-1303021036490001@eglaptop.jpl.nasa.gov...
>
> So I have another question directed to those who say Scheme is not a Lisp:

> is the concept of "programming language with S-expression-based syntax"
> not important enough to deserve its own less verbose term?

Forget S-expressions, the *real* question is whether any language
without XML-based syntax will prevail.

Why is Scheme not a Lisp? Rahul Jain 3/13/02 11:05 PM
Doug Quale <qua...@charter.net> writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
>
> > Seems like this list is misleading and/or inaccurate. Probably because
> > it was published in 1980 and we're applying it to 2000's context.
>
> You overlooked that I pointed out the fact that McCarthy explicitly
> wrote in 1999 that the paper still accurately reflected his opinions.

And I showed that it doesn't reflect what CL really does.

> Also, I don't mean to be insulting, but you do know that John McCarthy
> invented LISP in 1958 or 1959, right?  If you haven't read "Recursive
> Functions of Symbolic Expressions and Their Computation by Machine,
> Part I" by McCarthy from Commications of ACM, 1960, you should before
> you continue.  (You can find it on line at
> http://www-formal.stanford.edu/jmc/recursive.html).

Yes, I read it probably the first month I started learning CL.

> Most of the rest of your comments are historically or technically
> inaccurate.

That comment is historically or technically inaccurate.

--

-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Rahul Jain 3/13/02 11:08 PM
Doug Quale <qua...@charter.net> writes:

> What languages use Lisp-like notation that are not members of the Lisp
> family?  Clearly such languages are possible, but they don't seem to
> be plentiful.

A Lisp implementation of a logic language, as in the one in PAIP, maybe?

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Thaddeus L Olczyk 3/13/02 11:56 PM
Wannabees?

Sorry I just couldn't resist.

Why is Scheme not a Lisp? Paul Graham 3/14/02 12:42 AM
You have a very good point here Wade, one of the only substantial
points in this rather long thread.  There is a conceptual core of
Lisp.  In fact, that was exactly McCarthy's point in designing it:
to show that if you start with a certain set of axioms, you can
make a whole language out of it.  Anything that includes that
core is Lisp.  (Including, amusingly, Python and Ruby if they get
too much more powerful in future versions.)

There is a separate problem of newsgroup names.  I have sometimes
wondered if comp.lang.lisp is supposed to be about Common Lisp or
Lisp in general.  If I want to post stuff about Arc, where should
it go?  I notice that earlier Erik Naggum said that comp.lang.lisp
is for Common Lisp, and since he appears to be comp.lang.lisp's
common-law husband, I should probably take his word for it.

So I suppose I should try to start comp.lang.arc.  Anyone know
how to do that?

--pg

"Wade Humeniuk" <hume...@cadvision.com> wrote in message news:<a6nt92$vfh$1...@news3.cadvision.com>...


> "Erann Gat" <g...@jpl.nasa.gov> wrote in message
> news:gat-1203021200230001@eglaptop.jpl.nasa.gov...
> >
> > I hesitate to ask this question because I really don't want to start a
> > flame war.  To me it seems clear that Scheme is a dialect of Lisp.  The
> > Scheme standard says it's a dialect of Lisp.  Many textbooks say it's a
> > dialect of Lisp (e.g. Norvig's book, which has a chapter called "Scheme -
> > an uncommon Lisp".  Quiennec I believe also includes Scheme as a dialect
> > of Lisp.)
> >
> > So my question is directed to those of you who say that Scheme is not a
> > Lisp, notably Erik, but I gather that there are many out there who agree
> > with him.  Why is Scheme not a Lisp?  Does Scheme lack some necessary
> > feature that is required to be considered a Lisp in your book?  Was Lisp
> > 1.5 a Lisp?
>
> Both Scheme and CL have concrete specifications, they are specific languages
> and by inspection you can tell one from the other.  From your question there
> seems to be an implication there is a "Lisp" which is independent of
> specific implementations.  A kind of abstract Lisp much like the idea of
> thought-form of a tree as opposed to  a specific tree (say a pine).  This
> Thought-Form-Lisp (TFL) has never existed but seems to be exerting a force
> on the development of languages like Scheme and now maybe Arc.  It may arise
> because of intrinsic insights that the Lisps have into programming in
> general (evidenced by how other programming languages start out small and
> then start to implement Lisp features because they are necessary).  I know
> that I am certainly attracted to Lisp for some deeper reason.  Maybe people
> have been caught by the aesthetics of their TFL.  It could explain why
> people can be so attached to the language which expresses their TFL best and
> some people's frustrations (because of reality constraints) of not being
> able to manifest their TFL.  This also may explain some people's anger at CL
> because of its the gall it shows by "specifying" Lisp.
>
> Wade

Why is Scheme not a Lisp? Eli Barzilay 3/14/02 12:57 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> > > 3. Representation of information on paper, from keyboards and in
> > >    other external media mostly by multi-level lists and
> > >    sometimes by S-expressions. It has been important that any
> > >    kind of data can be represented by a single general type.
>
> That was added to scheme later, I though.

No.


> > > 10. The representation of LISP programs as LISP data that can be
> > >     manipulated by object programs. This has prevented the
> > >     separation between system programmers and application
> > >     programmers. Everyone can ``improve'' his LISP, and many of
> > >     these ``improvements'' have developed into improvements to
> > >     the language.
>
> Again, I think (read) was a recent addition to Scheme, [...]

No.


> Oh well, this is a pretty useless post.

[resist obvious punchline.]

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

Why is Scheme not a Lisp? Paolo Amoroso 3/14/02 1:13 AM
On 13 Mar 2002 15:30:36 -0500, Christopher Browne <cbbr...@acm.org> wrote:

> If these criteria for "Lispness" were applied to Emacs Lisp and ILisp,
                                                                  ^^^^^
Do you mean ISLISP?


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]

Why is Scheme not a Lisp? Kent M Pitman 3/14/02 1:34 AM
Doug Quale <qua...@charter.net> writes:

> > I usually use the political argument in particular contexts that seem
> > already political.
>
> Why is the question "Is Scheme a Lisp?" political to you?

Because I have seen a lot of time wasted over the years with people trying
to talk CL into being small, when Scheme is already small, and I think
those people asking would be happier "getting their way" in Scheme than
banging their head against a wall in CL.  CL is not going to get smaller.
Anyone is allowed to create a CL subset.  But no one has.  And there have
been _plenty_ of opportunities.  All of the issues I've mentioned in this
paragraph are social issues, not technical ones.  And the desire to achieve
social ends such as "control", "happiness", etc. are political desires.

I repeat my mantra.  "There are no political answers, only political
questions."  If the result of the questions people ask is that politics
impede what they want, then they were asking for something political.
There is no non-political path out of a political question, however neutral
and technically you disguise the question.

> That really
> gets to the heart of it.  It may explain why some Common Lisper's
> react so emotionally the this question, and why that emotion surprises
> Schemer's who expect that the answer might be based on syntax,
> semantics or problem domain rather than politics.

In reference to Scheme, let me remark something on the Lisp1/Lisp2 debate:

First, I chose those names.  So I take responsibility for the fact that
they are confusing people on the matter of "is Scheme a Lisp".  But they
were chosen in a debate with Gabriel over namespaces.  I felt I was losing
the debate because people were interpreting the namespace debate as
"should CL be more like Scheme" and many people had so many warm fuzzies
for Scheme that it was winning debate points for things not related to the
debate. I needed a way to equalize the debate and make people understand
that Scheme could have had a Lisp2 and still been warm and fuzzy, and that
CL could have been Lisp1 and still been yucky and big, to express things
in the terms of the opposing side's natural biases.   The terms were chosen
in the heat of battle, and without regard to any other debates about Lisp
and Scheme.  I'm not even sure at that time that I had evolved the opinion
that Lisp and Scheme were as separate as I have come to think they were.
My idea that politics pervades everything is partly an aspect of where I
have stood throughout the history of CL, and how much politics has gone
before my personal eyes.

But ignoring the substring "Lisp" in the issue of Lisp1/Lisp2, and you
can think of it as ProgrammingLanguage1/ProgrammingLanguage2 (if this
doesn't cause some confusion with PL/1 in your mind, heh) if you
prefer, the real problem with Lisp1 as a model of the world is that it
tends to be accompanied by a world-view that says 2 is a politically
incorrect number generally.  That is, part of the reason people like
Lisp1 is that 0, 1, and infinity are numerically special, and 2 is
kind of messily "in between" 1 and infinity.  It brings immediately
out the question "why not 3?"  And the problem is that this same
mindset invades other decisions.  The Scheme community seems, in my
experience to attract not only people who believe in PL1, so to speak,
but also in the idea that there should be only one language.  That is,
it's frustrating to them that the world is not uniquely determined.
And as a consequence of this view, I see a lot less tolerance for multiple
points of view come out of that community.  The PL2 camp is more naturally
tolerant of context and point of view, and so I find it to be much more
tolerant of alternate models of aesthetic, of programming paradigm, etc.
Being PL2 isn't causing that, but is, I claim, statistically correlated.

And so back to your question of why Schemers expect things to be based on
aesthetics, it's because (a) they have a single notion of aesthetic and
don't much seem to question whether there are others (to abuse a mathy
metaphor, they do not acknowledge the notion of non-Euclidean Schemes); and
(b) they have the idea that aesthetic is the only way to make decisions,
becuase they want the world to have only one way to make decisions.  

All "politics" means to me is "tolerance for multiple points of view".
Politics is nothing more than "manners in the large".  It is to manners
as sociology is to psychology.  And manners is all about understanding that
your own selfish point of view is not the only point of view around, and
that you must consider others as individuals.  Politics is about understanding
that your own social group is not the ony one, and you must tolerate other
social groups.  (Because of the possibilities of subset relations and
many-to-one or one-to-many relations as  you go from manners to politics,
politics is more than just linearly more difficult than manners, and it tends
to make most people's head spin to think about it, which is why they don't
like it).  But when you cut away all the part about emotion, the fundamental
problem is that some people have a hard enough time coming up with a coherent
view of what they themselves think without leaving room for alternate,
incompatible models of the world.  And so they'd prefer, for simplicity,
to convince themselves that they don't need to think about those messy
thoughts.  They want the world to be simple.  But that want will not make
the world simple.  And they often don't apply the time needed to determine
whether people who don't think like them are being rational.  Disconnected
points of view often appear irrational if you don't spend the time to
understand them from the axioms up, and if you falsely assume that your
own axioms are "reasoned principles" and not "arbitrary choices".

> > People pop up here and say "Should I use Lisp or
> > Scheme?" ...

>
> That question certainly is often political, but it wasn't the question
> that was asked this time.

Well, they also ask questions like "why doesn't the FOO function take a
second argument of a FROB?" and they sit waiting to be told a technical
truth, implying that this is how decisions are made.  But if decisions are
not made this way, they will again be frustrated.  Because their argument
will inevitably be technical, as if they've not heard the subtext which is
"technical doesn't matter".

You see this same problem in the large when great computerware hits the market
and fails to sell because "technology doens't sell itself".  It must be
properly marketed. And yet over
and over, later people do casual post mortems where they conclude
"that thing must have been worthless because no one bought it" when they
should know full well there are a million reasons people might not buy
something besides technical issues.  Geez, a zillion people don't buy Linux
because they can't afford not to sell on Microsoft. That's not a technical
reason.  And a zillion people use Linux becuase it's the only freeware around.
That's not a technical reason either.  How much more plain can it be that
technical is not all there is?  Yet people somehow still think decisions
are or should be technical.  The scary part is that it's understandable
why non-technical matters come into play.  At the end of the day, we all
need to be fed.  Commercial things matter because it feeds us and provides
us free cash to have the luxury to even _care_ about elegance.  

> I know you don't want to get drawn into an extended discussion of this
> list, but which category includes Scheme that wouldn't include Common
> Lisp?  I don't see how Scheme is any more block-structured than CL
> except in superficial ways, even if you didn't list Common Lisp in
> that category.

If all you want to learn about is block structure, you don't need to learn
all of CL to lean this.  I think there are reasons to learn CL, but those
reasons are not "to learn block structure".  That's all I meant.  So in
binary partition of the universe into "block structured languages" and
"non-block-structured languages", CL is more overhead to learn to get the
idea of what separates the two sides.

Why is Scheme not a Lisp? Kent M Pitman 3/14/02 1:43 AM
sp...@bugbear.com (Paul Graham) writes:

> There is a separate problem of newsgroup names.  I have sometimes
> wondered if comp.lang.lisp is supposed to be about Common Lisp or
> Lisp in general.  If I want to post stuff about Arc, where should
> it go?  I notice that earlier Erik Naggum said that comp.lang.lisp
> is for Common Lisp, and since he appears to be comp.lang.lisp's
> common-law husband, I should probably take his word for it.

If it were administratively convenient to rename this newsgroup to
comp.lang.lisp.cl, I'd be the first to sign onto it.

I tend to be forgiving of the hermit crab effect of having a community
move into a space and give it an identity and then feel some proprietariness
about it, in spite of the lack of specificity in its name.  If we renamed
the group, it would create a complication for google searching, for
example.

> So I suppose I should try to start comp.lang.arc.  

yes, as a practical matter, in spite of the political hassle it would perhaps
cause, it might be better to just make a comp.lang.lisp.arc so you could
have a separate space for your own political party.  But if you felt the
mere fact of the name name afforded you such second class status as to
materially hamper your chances for success, I would personally take that
concern seriously and perhaps reconsider my opinion on renaming.

> Anyone know how to do that?

Nope, but I'm sure someone will volunteer the info.

I think we should all support you in the desire to do that so that you
have your space to speak among people who have signed onto the concept,
... and if it fails we should take your traffic here.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Kent M Pitman 3/14/02 1:47 AM
Doug Quale <qua...@charter.net> writes:

Statistics of existence is a bad thing to use when trying to
understand abstracts. You don't want to be redefining your abstract terms
overnight because someone gets ambitious and invents one.

- - - -

DSSSL (an XML-based document structure transformation language that
later seems to ahve been somewhat recast as XSLT to disguise the
notation no one liked).

LIL (lisp implementation language, more akin to machine language, but still
using the lispy syntax).

Embedded AI languages like AMORD and probably others I never used, like
maybe (micro)PLANNER and the Actor languages...

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Pierre R. Mai 3/14/02 5:18 AM
Doug Quale <qua...@charter.net> writes:

> is a really good idea.  (Comparisons with PostScript are apropriate.
> Imagine how much nicer PostScript would be if it had a Lisp nature
> instead of a Forth nature.)  KFI looks like what I think SGML/HTML/XML

It wouldn't have been PostScript then.  I can behold the beauty of
PostScript (and Forth), at the same time that I can see the beauty of
a page description language based on CL.

> I don't think SXML and SXPath are programming languages.  Olin Shivers
> S-rexps are clearly not a programming language at all, but SXSLT is
> another good example.

I'd think that a language that allowed you to express finite automata
would be considered a programming language.  It just isn't one that is
turing complete, of course, but I'd still call it a domain-specific
programming language.  Of course it is much more useful if embedded in
a more general purpose language.

Regs, Pierre.

--
Pierre R. Mai <pm...@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Pierre R. Mai 3/14/02 5:28 AM
Kent M Pitman <pit...@world.std.com> writes:

> LIL (lisp implementation language, more akin to machine language, but still
> using the lispy syntax).

See also Henry G. Baker's COMFY 6502/Z80 family of "higher-level"
assembly languages, dating from the 70s, but recast in modern CL in
his September 1997 column in ACM's SIGPLAN notices.  Last I looked the
TeX source of that column was available under

http://www.pipeline.com/~hbaker1/sigplannotices/column04.tex.gz

but this may have changed.

While one of the points of those languages is leveraging the
underlying Lisp's macro-facility, nothing prevents one from
implementing them in e.g. C, though that would be fairly stupid[1].

So they are clearly distinct languages, and while they are clearly
Lisp inspired, I think that calling them Lisps would more or less
reduce the definition of Lisp to "whatever someone who considers
himself a Lisper does", which seems a fairly useless definition for
general discourse.

Regs, Pierre.

Footnotes:
[1]  But then I think that implementing a C compiler in C is also a
     fairly stupid thing to do, unless one has to ;)

--
Pierre R. Mai <pm...@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein

Why is Scheme not a Lisp? Dorai Sitaram 3/14/02 6:34 AM
In article <4f52f844.02031...@posting.google.com>,

Paul Graham <sp...@bugbear.com> wrote:
>
>There is a separate problem of newsgroup names.  I have sometimes
>wondered if comp.lang.lisp is supposed to be about Common Lisp or
>Lisp in general.  If I want to post stuff about Arc, where should
>it go?  I notice that earlier Erik Naggum said that comp.lang.lisp
>is for Common Lisp, and since he appears to be comp.lang.lisp's
>common-law husband, I should probably take his word for it.
>
>So I suppose I should try to start comp.lang.arc.  Anyone know
>how to do that?

It may be politically astute, now that you still have
the chance, to call your language Arc Lisp in the title
of Arc's formal seminal document(s), while
continuing to use just Arc in ordinary parlance.

--d

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Bijan Parsia 3/14/02 6:42 AM
On 14 Mar 2002, Pierre R. Mai wrote:

> Doug Quale <qua...@charter.net> writes:
[snip]
> > I don't think SXML and SXPath are programming languages.  Olin Shivers
> > S-rexps are clearly not a programming language at all, but SXSLT is
> > another good example.
>
> I'd think that a language that allowed you to express finite automata
> would be considered a programming language.

So I thought :) What's nice about them as an example is that they are
*clearly* not a Lisp, but *because* of their sexpr nature, easily
embeddable in one.

>  It just isn't one that is
> turing complete, of course, but I'd still call it a domain-specific
> programming language.
[snip]

Yep. SXPath may be one too, given that it *is* a query language (of
sorts). Hmm. From the W3C spec:

"""XPath is the result of an effort to provide a common syntax and
semantics for functionality shared between XSL Transformations [XSLT] and
XPointer [XPointer]. The primary purpose of XPath is to address parts of
an XML [XML] document. In support of this primary purpose, it also
provides basic facilities for manipulation of strings, numbers and
booleans."""

Indeed, it contains a number of functions:
        http://www.w3.org/TR/xpath#corelib

And it expects host languages to define more (I suppose).

SXML sorta entails than any programming langauge with an XML syntax will
also have an s-expr syntax (not that *this* is particularly useful for the
current discussion, but what the heck!).

I found another, though I can't determine if it's a programming langauge
at all:
        http://theory.lcs.mit.edu/~rivest/sexp.html

(Well, that's the library, the application is:
        http://theory.lcs.mit.edu/~cis/sdsi.html)

Cheers,
Bijan Parsia.

Why is Scheme not a Lisp? Bijan Parsia 3/14/02 7:02 AM
On Wed, 13 Mar 2002, Erann Gat wrote:

[snip]
> <tangent>
> Personally, I don't think UML is a language.  I think an essential
> characteristic of a language is that it have fundamentally a
> one-dimensional structure, whereas the fundamental structure of UML is
> two-dimensional.  But that's just my opinion.
> </tangent>

There was Prograph, which seems reasonably two-dimensional.

I'm not sure why linear syntax is so significant (to you). Frege's
original logic notation was 2D and loads of people think it had a lot of
advantages. It lost out to *Principia*esque notations because of
typographical difficulties (so the story goes).

> Programming systems that use characters to represent source code seem to
> me to fall into two major categories: those that use S-expressions and
> those that do not.  The reason I think that this is a useful division is
> that S-expressions are a universal syntax that can represent both code and
> data.  Non-S-expression syntaxes can represent only code.  (Note: this is
> not inherently true.  There's no reason why you couldn't design some
> syntax other than S-expressions that could represent both code and data.
> It's just that no one has.)

Really? What about Prolog terms? They aren't S-expressions (certainly not
fully parenthesized ones), but they *do* represent both code and data (and
code *as* data).

I'm not entirely sure exactly how distinguishable they are (and it's
certianly easy enough to have s-expressive terms), but there does seem to
be *some* distinction.

[snip]
> (a.k.a. READ).  People who use S-expression-based languages tend to


> embrace the idea of *extending* a programming langauge as a useful
> programming technique because extending an S-expression-based language is
> easy.

Surely the case for Prolog, although Prolog also has lots of facilities
for munging syntax (i.e., you can make operations infex, right or left
associative, etc. without writing a parser).

>  People who use non-S-expression-based languages tend not to even
> consider extending the language because doing so is all but impossible
> (with Dylan perhaps being a notable exception).
[snip]

Smalltalk comes to mind, though it's certainly not *as* flexible. Rebol
seems a more notable exception, being less directly connected with
specific s-expr-bassed languages. (Rebol has a "dialecting" facility,
which basically gives you an LL parser to munge your symbol lists.) Ah, I
almost forgot Forth.

I'm of the mind that there are loads of other exceptions.

I think sexprs are *wonderful* things, but many of their virtues can be
achieved without them. Whether it's worth doing so is a slightly different
question :)

Cheers,
Bijan Parsia.


Why is Scheme not a Lisp? Janis Dzerins 3/12/02 1:01 PM
g...@jpl.nasa.gov (Erann Gat) writes:

> Please note that I don't want to get into the argument about whether or
> not Scheme is or is not a Lisp.  I'm just interested in hearing from those
> people who already believe that it isn't what their rationale is.

How about some googling?  This topic has been discussed here many
times by many people, and I doubt that they have changed their minds
recently.

--
Janis Dzerins

  Eat shit -- billions of flies can't be wrong.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Paul Graham 3/14/02 7:25 AM
If a language has car, cdr, cons, if, eq, atom, quote, and a
notation for functions in terms of conses, then it's Lisp.
I believe these imply all the other distinctive features of Lisp,
like runtime typing and garbage-collection.

S-expressions are key, but you also need to have, for example,
first-class functions.

--pg

> My own view, FWIW, is that the essence of Lisp is the use of S-expressions
> to represent both code and data.  On that view, both Common Lisp and
> Scheme are Lisps, and Python and Dylan are not.  (I realize that this view
> is at odds with McCarthy's original idea, but this would not be the first
> time that the person who came up with a great idea didn't immediately
> recognize it for what it was.)
>
> This is a view shared by many of my colleagues who are not computer
> scientists or software engineers.  In their mind, Lisp == S expressions.
> If a function call is written (f x y z) instead of f(x,y,z) then it's
> Lisp.  (This view has been the source of a great deal of frustration for
> me, because S-expressions are useful in contexts other than programming
> languages, but the prejudice against Lisp extends to the use of
> S-expressions in non-programming contexts.  But that's another story.)
>

Why is Scheme not a Lisp? Christopher Browne 3/14/02 7:19 AM
The world rejoiced as Kent M Pitman <pit...@world.std.com> wrote:
> But ignoring the substring "Lisp" in the issue of Lisp1/Lisp2, and you
> can think of it as ProgrammingLanguage1/ProgrammingLanguage2 (if this
> doesn't cause some confusion with PL/1 in your mind, heh)

What that actually makes me think about is the notion of there being a
PL/2.  _There_ lies a perverse thought...  :-)
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://www.ntlug.org/~cbbrowne/internet.html
Rules of the Evil Overlord #151. I will not set myself up as a
god. That perilous position is reserved for my trusted lieutenant.
http://www.eviloverlord.com/>

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Dorai Sitaram 3/14/02 7:45 AM
In article <4f52f844.02031...@posting.google.com>,
Paul Graham <sp...@bugbear.com> wrote:
>If a language has car, cdr, cons, if, eq, atom, quote, and a
>notation for functions in terms of conses, then it's Lisp.

In addition to your list (!), I would add I/O
procedures -- read, prin1/write, and at least one
of {load, eval} -- that operate directly on s-exps.  

--d

>I believe these imply all the other distinctive features of Lisp,
>like runtime typing and garbage-collection.
>
>S-expressions are key, but you also need to have, for example,
>first-class functions.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Bijan Parsia 3/14/02 7:49 AM
On 14 Mar 2002, Paul Graham wrote:

> If a language has car, cdr, cons, if, eq, atom, quote, and a
> notation for functions in terms of conses, then it's Lisp.
>
> I believe these imply all the other distinctive features of Lisp,
> like runtime typing and garbage-collection.
[snip]

Neither of which are distinctive features of Lisp, at least in the sense
of making Lisp stand out from a *slew* of other languages.

I'm interested to see how the initial set of features imply either runtime
typing *or* garbage collection. I fail to see that they do either, and
believe there are actual (rather that merely hypothetical)
counterexamples. But I'm really interested in the steps of the derivation.
 
Or is it in cons? I guess if cons is necessarily runtime typed...er...no,
I still don't *quite* see how it goes.

Is ML a Lisp?

        http://www-2.cs.cmu.edu/People/rwh/introsml/core/lists.htm


I'm a bit unclear about the "notation for functions in terms of
conses" requirement, also.

Cheers,
Bijan Parsia.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Ian Wild 3/14/02 8:19 AM
Dorai Sitaram wrote:
>
> In article <4f52f844.02031...@posting.google.com>,
> Paul Graham <sp...@bugbear.com> wrote:
> >If a language has car, cdr, cons, if, eq, atom, quote, and a
> >notation for functions in terms of conses, then it's Lisp.
>
> In addition to your list (!), I would add I/O
> procedures -- read, prin1/write, and at least one
> of {load, eval} -- that operate directly on s-exps.

That would mean you could /never/ have an embedded Lisp.

Why is Scheme not a Lisp? Lieven Marchand 3/13/02 12:36 PM
Matthias Blume <matt...@shimizu-blume.com> writes:

> PS: To the person who said that ML was created to "prove a point":  You
> are absolutely right, literally.  :-)

Oh? I thought the ambition was a bit larger, i.e., to prove a theorem?

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

Why is Scheme not a Lisp? Bruce Lewis 3/14/02 8:36 AM
Kent M Pitman <pit...@world.std.com> writes:

> But I mention this because we sometimes refer to "dialect of Lisp" yet the
> term "dialect of xxx" usually refers to a language, and there really is no
> language that is Lisp, so we're really saying "dialectal variants of
> languages in the Lisp family", and then that makes the the question more
> vague: what is in the question.

"Dialect of Chinese" refers to a family of languages, e.g. Cantonese is
not a dialect of Mandarin, nor vice versa.

FWIW, I got 800 google hits for
        "dialect of chinese"
and only 33 for
        "dialectal variant" chinese

This is consistent with my personal impression that "dialect of Chinese"
is the more common phrase.

--
<brlewis@[(if (brl-related? message)    ; Bruce R. Lewis
              "users.sourceforge.net"   ; http://brl.sourceforge.net/
              "alum.mit.edu")]>

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Dorai Sitaram 3/14/02 8:45 AM
In article <3C90CDAD...@cfmu.eurocontrol.be>,

I'm sorry I didn't understand that.  Is an "embedded
Lisp" something that has an s-exp syntax but doesn't
have read, prin1, etc?  Does this Lisp system have
ports (in the sense of doors) to the outside
world at all, and how does it accept a Lisp program to
run?  

--d

Why is Scheme not a Lisp? Paolo Amoroso 3/14/02 8:45 AM
On 14 Mar 2002 00:42:50 -0800, sp...@bugbear.com (Paul Graham) wrote:

> So I suppose I should try to start comp.lang.arc.  Anyone know
> how to do that?

The process is explained in the document:

  How to Create a New Usenet Newsgroup
  http://www.faqs.org/faqs/usenet/creating-newsgroups/part1/


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]

Wrong question... Bob Bane 3/14/02 8:59 AM
In terms of community interaction, the interesting question is not

        Is Scheme a Lisp?

but instead

        Are Schemers Lispers?

or more precisely

        Do Schemers and Lispers share common interests?

The answer to that one is clearly "some more than others."  Some things
are obviously shared: belief in the value of things like basic symbolic
and list processing, numeric types that don't lose information randomly
because of underlying machine properties, typed objects but untyped
variables, first-class functions, closures, garbage collection, etc.

Some things are less shared.  The Schemers who interpret RnRS as saying
that the reader for code must have different semantics than the reader
for data have less in common with the rest of the Lisp world that
generally uses the same reader for both.

I have no problem with Scheme being referred to as a Lisp.  I have a
problem with Schemers who see their Lisp as the One True Way, but I
would have that problem with the same attitude from any language
enthusiast.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Pierre R. Mai 3/14/02 8:34 AM
sp...@bugbear.com (Paul Graham) writes:

> If a language has car, cdr, cons, if, eq, atom, quote, and a
> notation for functions in terms of conses, then it's Lisp.

Why atom, given that it is only defined in terms of the negation of
consp? Why not consp instead?  And why is if special, and not, let's
say, cond?

> I believe these imply all the other distinctive features of Lisp,
> like runtime typing and garbage-collection.

I don't think that GC is implied by this, unless you spell it out as
an additional constraint.  The language in question could require the
use of "free-cons" to free garbage.

And the above list of criteria probably also allows the language to
require static type declarations, too.  It just needs to retain enough
information to allow atom to work.

I think it is much harder to fill Lisp with a definition that includes
everything that people like to call Lisp, but doesn't get so inclusive
as to be meaningless.

Regs, Pierre.

--
Pierre R. Mai <pm...@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Kent M Pitman 3/14/02 9:52 AM
"Pierre R. Mai" <pm...@acm.org> writes:

> sp...@bugbear.com (Paul Graham) writes:
>
> > If a language has car, cdr, cons, if, eq, atom, quote, and a
> > notation for functions in terms of conses, then it's Lisp.
>
> Why atom, given that it is only defined in terms of the negation of
> consp? Why not consp instead?  And why is if special, and not, let's
> say, cond?

Traditionally, there has not been a CONSP.  That's a fairly new operator.
ATOM goes way back.

The real problem with this list Paul has offered for features that
distinguish Lisp isn't that it fails to describe something common to
many (but not all) lispy languages, but that the set of things you can
usefully say that span all languages in the set it selects is
extraordinarily limited, and in fact, is mostly things we _don't_ want
said.  Like "LISP is only good for list processing and nothing else."
This is, irritatingly enough, the bottom line point of a number of
"survey courses" in languages, and it would be nice to outgrow this.
We won't do this by a stubborn insistence on tradition.  If you define
LISP in the "common features" way, like it or not, such irritating
statements are practically the only conclusion one could legitimately
reach!

Lisp is a dynamic language.  It accomodates change.  The definition of
what Lisp is should not be static.

> > I believe these imply all the other distinctive features of Lisp,
> > like runtime typing and garbage-collection.
>
> I don't think that GC is implied by this, unless you spell it out as
> an additional constraint.

I think during the bootstrapping process, some Lisp Machines might not have
had or used GC.  I think they just substituted enough address space that it
could run for a day or two even without GC.  Were they momentarily not
programming in Lisp?  Heh...

Or, as we sometimes did with Lisp Machines, but so much more often do with
Microsoft products, does booting the machine count as GC?

Rather than focus on GC, I would say "a removal of the need to explicitly
call 'free'" ... which is neutral as to what happens to garbage, just as
the CL spec is neutral on the matter.

> I think it is much harder to fill Lisp with a definition that includes
> everything that people like to call Lisp, but doesn't get so inclusive
> as to be meaningless.

Exactly.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erann Gat 3/14/02 9:46 AM
In article <32250518...@naggum.net>, Erik Naggum <er...@naggum.net> wrote:

> * Erann Gat
> | That's fine, but given the vehemence with which "Scheme is a Lisp" is
> | opposed it is not self-evident that "Scheme is a member of the Lisp
> | family of languages" would be any less objectionable.  In fact, to me
> | both sentences seem to mean precisely the same thing.
>
>   That is because you do not listen to other people, Erann.

No, it's because I don't share your penchant for splitting semantic
hairs.  (I actually think my problem is the exact opposite of what you
say.  I think I listen to people even when I know I shouldn't, like when
they are behaving like condescending jerks.)

I don't care if someone says "Clyde is an elephant" or "Clyde is a member
of the pachyderm family of animals" (except insofar as the latter seems
unnecessarily pedantic to me).  Likewise, "Scheme is a member of the Lisp
family of languages" is to me simply a wordier version of "Scheme is a
Lisp."  Nonetheless, I accept that you choose to distinguish between them,
and I'll try to respect that distinction.

Since you agree that Scheme is a member of the Lisp family of languages it
seems that what the historical disagreement is really about is whether the
word "Lisp" means "the Lisp family of languages" or "Common Lisp" (as
opposed to, say, whether the schema "X is a member of the class of Y" is
less offensive than "X is a Y").  Is that right?

E.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Kent M Pitman 3/14/02 10:11 AM
I <pit...@world.std.com> wrote:

> Lisp is a dynamic language.  It accomodates change.  The definition of
> what Lisp is should not be static.

I got a chuckle out of the similarity of issues raised in this article,
"Interstellar Travelers Will Have to Watch Their Language",
from today's Space.com ...

http://www.space.com/scienceastronomy/generalscience/interstellar_english_020314.html

Why is Scheme not a Lisp? Bruce Hoult 3/14/02 11:53 AM
In article <n9OQPOskJP=MpCZEIOP...@4ax.com>,
 Paolo Amoroso <amo...@mclink.it> wrote:

> On 14 Mar 2002 00:42:50 -0800, sp...@bugbear.com (Paul Graham) wrote:
>
> > So I suppose I should try to start comp.lang.arc.  Anyone know
> > how to do that?
>
> The process is explained in the document:
>
>   How to Create a New Usenet Newsgroup
>   http://www.faqs.org/faqs/usenet/creating-newsgroups/part1/

And the first prnciple is that you dn't create a newsgroup in
anticipation of traffic, but only when you already have traffic that is
threatening to take over a more general newsgroup.

Arc discussion should go on comp.lang.lisp.

-- Bruce

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Dorai Sitaram 3/14/02 11:59 AM
In article <sfwy9gv...@shell01.TheWorld.com>,

Kent M Pitman  <pit...@world.std.com> wrote:
>
>The real problem with this list Paul has offered for features that
>distinguish Lisp isn't that it fails to describe something common to
>many (but not all) lispy languages, but that the set of things you can
>usefully say that span all languages in the set it selects is
>extraordinarily limited, and in fact, is mostly things we _don't_ want
>said.  Like "LISP is only good for list processing and nothing else."
>This is, irritatingly enough, the bottom line point of a number of
>"survey courses" in languages, and it would be nice to outgrow this.
>We won't do this by a stubborn insistence on tradition.  If you define
>LISP in the "common features" way, like it or not, such irritating
>statements are practically the only conclusion one could legitimately
>reach!
>
>Lisp is a dynamic language.  It accomodates change.  The definition of
>what Lisp is should not be static.

Well, it is very reasonable for regular folks to
associate Lisp with LISt Processing.  No amount of
lobbying is likely to erase that association.  In
contrast to some earlier discounting of isolated
researcher types, it is likely easier to have _them_
rethink this than the man on the street (or even the
lexicographer on the street, it looks like!).

What the above grievance points out is that it is not
enough for a prog lang to be a Lisp.  It should be more
than a Lisp, and I would go along with any contention
that CL is maybe not getting enough recognition
for being more than a Lisp.

Maybe CL critiques of Scheme should proceed more
along the lines of "Scheme is just a Lisp" rather than
"Scheme is not a Lisp".  :-/

--d

Why is Scheme not a Lisp? Erann Gat 3/14/02 11:48 AM
In article <sfwzo1b...@shell01.TheWorld.com>, Kent M Pitman
<pit...@world.std.com> wrote:

> sp...@bugbear.com (Paul Graham) writes:
>
> > So I suppose I should try to start comp.lang.arc.  
> > Anyone know how to do that?
>
> Nope, but I'm sure someone will volunteer the info.

See e.g. http://www.cs.uu.nl/wais/html/na-dir/newgroup-faq.html

E.

Why is Scheme not a Lisp? Erann Gat 3/14/02 12:20 PM
In article
<Pine.A41.4.21L1.0203140944000.37702-100000@login9.isis.unc.edu>, Bijan
Parsia <bpa...@email.unc.edu> wrote:

> On Wed, 13 Mar 2002, Erann Gat wrote:
>
> [snip]
> > <tangent>
> > Personally, I don't think UML is a language.  I think an essential
> > characteristic of a language is that it have fundamentally a
> > one-dimensional structure, whereas the fundamental structure of UML is
> > two-dimensional.  But that's just my opinion.
> > </tangent>
>
> There was Prograph, which seems reasonably two-dimensional.
>
> I'm not sure why linear syntax is so significant (to you).

It's not linear syntax that is significant to me per se, it's the
*distinction* between representations of information that are inherently
one-dimensional versus those that are not.  The difference is significant
enough that each deserves its own name, e.g. "text" and "drawing".  I
think the distinction between these two is one of the most significant
distinctions in all of human intellectual endeavors.  Using the word
"language" to refer to both text and drawings blurs this distinction,
which IMO does a lot more harm than good.  So I prefer to reserve the word
"language" when applied to visual representations to refer to text.

I think two-dimensional representations have their place.  I'm a big fan
of LabView, for example.  But it's not a language in my book, though now
that I think about it I'm not sure what I would call it instead.

E.

Why is Scheme not a Lisp? Nils Goesche 3/14/02 2:33 PM

Or even better on alt.comp.lang.lisp.arc

Regards,
--
Nils Goesche                          PGP key ID 0x42B32FC9

"The sooner all the animals are dead, the sooner we'll find
 their money."                              -- Ed Bluestone

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/14/02 2:50 PM
sp...@bugbear.com (Paul Graham) writes:

> There is a separate problem of newsgroup names.  I have sometimes
> wondered if comp.lang.lisp is supposed to be about Common Lisp or
> Lisp in general.  If I want to post stuff about Arc, where should
> it go?  I notice that earlier Erik Naggum said that comp.lang.lisp
> is for Common Lisp, and since he appears to be comp.lang.lisp's
> common-law husband, I should probably take his word for it.

He's more like the one who shouts the loudest.

According to the charter of the newsgroup, it's for all dialects of
Lisp.

Why is Scheme not a Lisp? Kent M Pitman 3/14/02 3:37 PM

Ah.  So we just have to have a quick discussion about whether his is a
dialect of Lisp and we'll be all set.  ;)   HEY, JUST KIDDING...

Of curiosity, though, Paul, if you're reading this, have you tried or
would you be interested in trying to speak about Arc here?  Maybe if
you were careful in tagging the subject lines [ARC] people who didn't
want to follow the stuff could filter it out and we could know both
whether there was enough interest for a separate group and also
whether having a discussion in this joint forum if good or bad...

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erik Naggum 3/14/02 3:40 PM
* Erann Gat

| I don't care if someone says "Clyde is an elephant" or "Clyde is a member
| of the pachyderm family of animals" (except insofar as the latter seems
| unnecessarily pedantic to me).

  Is this intended to be anywhere close to what we are discussing here?  Do
  you _really_ not undestand what we are discussing, or is this just more
  of your obnoxiousness?  How about "Scheme is an elephant"?  Does the fact
  that this is meaningful tell you something about the English langauge?

| Likewise, "Scheme is a member of the Lisp family of languages" is to me
| simply a wordier version of "Scheme is a Lisp."  Nonetheless, I accept
| that you choose to distinguish between them, and I'll try to respect that
| distinction.

  Then, in the service of civility and reduced hostility, why not use the
  least offensive phrase when they are equivalent to you, but not to those
  who disagree with you?  Your continued refusal to get the point must mean
  that obonxiousness is the _purpose_ of sticking to "is a Lisp".

| Since you agree that Scheme is a member of the Lisp family of languages
| it seems that what the historical disagreement is really about is whether
| the word "Lisp" means "the Lisp family of languages" or "Common Lisp" (as
| opposed to, say, whether the schema "X is a member of the class of Y" is
| less offensive than "X is a Y").  Is that right?

  Perhaps you may, in time, figure out that words do not just have
  denotations and definitions, but also connotations and context-dependent
  meaning, that expressions have more than one value, that what we do not
  say is frequently as important as what we do say.  In _isolation_ "Lisp"
  is the family of languages, to those who know that "the Lisp family"
  exists in the first place.  To those who do not, "X is a Lisp and Y is a
  Lisp" means that X and Y have something in common, that knowing one makes
  it possible to predict something about the other.  This is not true of
  the interesting parts of Common Lisp and Scheme.  By de-emphasing this
  connotation, and emphasizing the "familiy" property of the name "Lisp",
  you do in fact communicate something that novices can use and learn
  something from, instead of just confusing them with misguided beliefs.

  Those who do know both languages, know that they and their communities
  differ enormously, and far more so than they are interestingly similar.
  American may not care much which of the Scandnavian counrties I come
  from, or which of the three official (make that four unofficial)
  Norwegian languages I speak, or which of the several and mutually
  unintelligible dialects of these languages I favor, but summing it all up
  in "Norwegian" is pretty accurate from 3000 miles away.  Over here,
  people ask me whether I actually say "sprog" and not "språk" and whether
  I say "benfri stek" instead of "beinfri steik" and some react with
  hostility because of this, which they believe is the language of the
  upper class, which is officially abolished in Norwegian political
  mythology, only because the illiterate mob use more diphthongs than the
  literate.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Visual Programming Christopher Browne 3/14/02 3:50 PM

I don't anything inherently prevents there from being a "true
language" that is visibly two dimensional in its representation.

The problem is that the instances we have actually seen rarely (if
ever) provide expressiveness not possible in the "one dimension" of
text, but rather provide some visual representation precisely useful
to conveniently represent some limited domain, for instance, that of
linking together lab instrument components.

We see:
 - E/R diagrams, to describe relationships between database fields;

 - Class diagrams, to similarly describe particular relationships
   between objects in an "object system;"

 - Sometimes diagrams to describe physical relationships between
   physical objects (as is the case with LabView, and as was the case
   with some continuous system simulators (essentially DE solvers).

The benefit I'd think you'd get out of the extra dimension would be
the ability to more easily describe linkages between objects.

But it's hardly a problem to describe arbitrary linkages between
objects with the "one dimension" of the semi-infinite line of text.

Whether it's in BASIC, with:

10 REM
20 DIM A(10)
30 A(1) = 5
40 GOTO 30
50 END
60 REM OOPS - the reference in 40 prevents this from terminating

  char *p;
  p = some_string;

or references of HTML:
  <a href= "#refinthisdoc"> internal reference </a>
  to <p> <a name="refinthisdoc"> some chunk of text

or references in Lisp:
  (let ((a 1)
        (b 2))
     (format t "Display value referencing a:~A and b:~A~%" a b))

there is no paucity of ways of doing crossreferences between objects.
They are of varying aptness, but they're certainly there, and there
are a _lot_ of idioms to indicate references in Plain Old Text.

Visual programming (and I refer not in the _slightest_ to the
often-sold-by-Microsoft tools that put thin GUIs on top of text tools)
still sits at the research stage, at least vis-a-vis anything
attempting any kind of generality.

After 50 years of "idiom-building" with text programs, we have a whole
lot of powerful idioms.  Such idioms are lacking in visual tools;
there barely _are_ visual tools.  You get some idioms to represent one
abstraction or another, whether E/R diagrams, finite state automata,
or object classes but the notion of these actually integrating deeply
enough that you could use them to totally represent a program, well,
that's just Not There Yet, and it's not evident that the well-known
"visual efforts" (UML, Visual Foo++) are actually leading in that
direction anyways.
--
(concatenate 'string "cbbrowne" "@acm.org")
http://www.ntlug.org/~cbbrowne/
Rules of the Evil Overlord #133. If I find my beautiful consort with
access to my fortress has been associating with the hero, I'll have
her executed. It's regrettable, but new consorts are easier to get
than new fortresses and maybe the next one will pay attention at the
orientation meeting. <http://www.eviloverlord.com/>

Why is Scheme not a Lisp? Christopher Browne 3/14/02 2:44 PM
Centuries ago, Nostradamus foresaw when Nils Goesche <car...@cartan.de> would write:
> In article <bruce-078563....@copper.ipg.tsnz.net>, Bruce Hoult wrote:
> > In article <n9OQPOskJP=MpCZEIOP...@4ax.com>,
> >  Paolo Amoroso <amo...@mclink.it> wrote:
> >
> >> On 14 Mar 2002 00:42:50 -0800, sp...@bugbear.com (Paul Graham) wrote:
> >>
> >> > So I suppose I should try to start comp.lang.arc.  Anyone know
> >> > how to do that?
> >>
> >> The process is explained in the document:
> >>
> >>   How to Create a New Usenet Newsgroup
> >>   http://www.faqs.org/faqs/usenet/creating-newsgroups/part1/
> >
> > And the first prnciple is that you dn't create a newsgroup in
> > anticipation of traffic, but only when you already have traffic that is
> > threatening to take over a more general newsgroup.
> >
> > Arc discussion should go on comp.lang.lisp.
>
> Or even better on alt.comp.lang.lisp.arc

No, it should head to comp.lang.lisp.  

On the one hand, propagation of the alt.* hierarchy is somewhat
dubious.

On the other hand, it would anti-support the principle of there being
traffic about Arc in an existant comp.* hierarchy newsgroup that needs
to get moved some place more specific.
--
(reverse (concatenate 'string "moc.adanac@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/lisp.html
Rules of the Evil Overlord #85. I will not use any plan in which the
final step is horribly complicated, e.g. "Align the 12 Stones of Power
on the sacred altar then activate the medallion at the moment of total
eclipse." Instead it will be more along the lines of "Push the
button." http://www.eviloverlord.com/>

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Kent M Pitman 3/14/02 3:58 PM
Erik Naggum <er...@naggum.net> writes:

> * Erann Gat
> | I don't care if someone says "Clyde is an elephant" or "Clyde is a member
> | of the pachyderm family of animals" (except insofar as the latter seems
> | unnecessarily pedantic to me).

BACKGROUND: Some reading along may not be aware that poor Clyde the
elephant is the canonical exemplar used in AI literature for discussing
problems in inheritance.  The standard example is that all mammals have
4 legs, and then to go sawing off one of Clyde's appendages and to start
to ask whether Clyde is therefore not an elephant.  This usually leads
to a discussion about whether negative inheritance is possible, and
whether Clyde really has 4 legs but that one of them is of type
MISSING-LEG (which helps a lot, actually, since you can then still discuss
the color of his missing leg, etc.), or whether he has just three legs
(which brings into question the notion that what it means to be "of a class"
is to have all the properties of the class, and to ask the implicit question:
"is there anything you can then depend on if exceptions are allowed?").


 
>   Is this intended to be anywhere close to what we are discussing here?  Do
>   you _really_ not undestand what we are discussing, or is this just more
>   of your obnoxiousness?  How about "Scheme is an elephant"?  Does the fact
>   that this is meaningful tell you something about the English langauge?

No, but it tells you something about what the speaker thinks of Scheme as
a product in the marketplace:  that it "has legs" (i.e., will sell well ;)

Just trying to keep the discussion from getting too "heavy" here.

Uh oh.  Stop me before I try to make more pack-a-term humor.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Christopher Browne 3/14/02 4:24 PM
Kent M Pitman <pit...@world.std.com> wrote:
> Just trying to keep the discussion from getting too "heavy" here.

There can't possibly be a _light_ conversation involving elephants.
:-)

> Uh oh.  Stop me before I try to make more pack-a-term humor.

It's all in fun until someone loses a trunk...
--
(concatenate 'string "cbbrowne" "@canada.com")
http://www3.sympatico.ca/cbbrowne/linuxdistributions.html
Rules of the Evil Overlord #210. All guest-quarters will be bugged and
monitored so that I can keep track of what the visitors I have for
some reason allowed to roam about my fortress are actually plotting.
http://www.eviloverlord.com/>

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Martti Halminen 3/14/02 4:20 PM
"Christopher C. Stacy" wrote:

> I think there have been assembly languages that used that  of syntax.
>
> Also, didn't someone discover s-expressions used in some Microsoft
> product?  I can't remember which kind of document it was; just that
> some Lisper saw it and got momentarily excited.

If you are thinking about the MS Word example here a few years back, it
was just a case of Word grabbing whole memory pages to store regardless
of their ownership or previous use; in that case catching some unrelated
AutoLisp code.

Another S-exp -style language would be one of the internal
representations in the gcc compiler.

--

Why is Scheme not a Lisp? Steve Long 3/14/02 5:04 AM
Subject-verb agreement problem. Were they were referring to Steele and Sussman
as the authors of Scheme or Common Lisp?  It's an interesting mistake in the
context of this discussion.

sl

Erik Naggum wrote:

> * tb+u...@becket.net (Thomas Bushnell, BSG)
> | But Scheme does call itself a Lisp!
> |
> | The very beginning of the R5RS reads:
> |
> | "The report gives a defining description of the programming language
> | Scheme. Scheme is a statically scoped and properly tail-recursive dialect
> | of the Lisp programming language invented by Guy Lewis Steele Jr. and
> | Gerald Jay Sussman."
>
>   But how can you trust a specification that says the Lisp programming
>   language was invented by Guy Lewis Steele, Jr., and Gerald Jay Sussman?


>
> ///
> --
>   In a fight against something, the fight has value, victory has none.
>   In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Erik Naggum 3/14/02 4:45 PM
* Thomas Bushnell, BSG

| He's more like the one who shouts the loudest.

  Grow up.

| According to the charter of the newsgroup, it's for all dialects of Lisp.

  comp.lang.lisp has no charter.  Newsgroups are what the users make them.

  Lacking a forum for arc, and providing its purpose is to build rather
  than destroy, I can think of no better forum than comp.lang.lisp for it
  until it gets its own forum and community.  When you have new forum all
  to yourself as a new community, the whole purpose is to confine articles
  to that forum, not clutter up whichever forum you split off from with
  useless whining that you did not "really" mean to split off.  However, if
  Scheme had, hypothetically, had no forum of their own, I certainly would
  have done everything I could to help create it, so the obnoxious, anal-
  retentive, one-bit, purity-before-usefulness people could go away there.
  So far, Arc seems only to suffer from bad taste.  That would be OK, at
  least for a while.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Nils Goesche 3/14/02 4:49 PM
Lieven Marchand <m...@wyrd.be> writes:

> Matthias Blume <matt...@shimizu-blume.com> writes:
>
> > PS: To the person who said that ML was created to "prove a point":  You
> > are absolutely right, literally.  :-)
>
> Oh? I thought the ambition was a bit larger, i.e., to prove a theorem?

IIRC, it /is/ the theorem :-)

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

PGP key ID 0xC66D6E6F

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erann Gat 3/14/02 4:28 PM
In article <sfw3cz2...@shell01.TheWorld.com>, Kent M Pitman
<pit...@world.std.com> wrote:

> >   How about "Scheme is an elephant"?  Does the fact
> >   that this is meaningful tell you something about the English langauge?
>
> No, but it tells you something about what the speaker thinks of Scheme as
> a product in the marketplace:  that it "has legs" (i.e., will sell well ;)

Unless the color of the elephant is white, of course.  :-)

E.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erik Naggum 3/14/02 6:01 PM
* Erik Naggum

> Is this intended to be anywhere close to what we are discussing here?  Do
> you _really_ not undestand what we are discussing, or is this just more
> of your obnoxiousness?  How about "Scheme is an elephant"?  Does the fact
> that this is meaningful tell you something about the English langauge?

* Kent M Pitman


| No, but it tells you something about what the speaker thinks of Scheme as
| a product in the marketplace:  that it "has legs" (i.e., will sell well ;)

  I had to look this up after I posted it just to be certain that I had not
  screwed up.  My Tenth Edition Merriam-Webster Collegiate Dictionary says
  elephan also means "One that is uncommonly large and hard to manage",
  which I think Scheme actually becomes once you tro use it.

  Incidentally, the elephant family is called Elephantidae, the only family
  of the order Proboscidea.  "Pachyderm" is an unscientific term, referring
  to "animals with thick skin", including such diverse animals as elephant,
  rhinoceros, and pig.  One emay conclude that Scheme freaks are not
  pachyderms in either literal or transferred meaning, but other than that,
  "pachyderm" has little use as a term.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erik Naggum 3/14/02 6:13 PM
* Martti Halminen

| Another S-exp -style language would be one of the internal
| representations in the gcc compiler.

  The good old WAIS sources appeared to be using Common Lisp syntax using a
  format like (:source {<keyword> <value>}*).

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? William D Clinger 3/14/02 6:56 PM
Kent M Pitman wrote:
> ....That is, part of the reason people like
> Lisp1 is that 0, 1, and infinity are numerically special, and 2 is
> kind of messily "in between" 1 and infinity.

I think Kent's onto something here, but I would put it just a little
differently.  This is where the technical meets the political.  The
folks who like first order languages aren't attracted to Lisp at all.
The folks who like second order languages are attracted to a Lisp2.
The folks who like higher order languages are attracted to a Lisp1.
Common Lisp is clearly the dominant Lisp2, Scheme the dominant Lisp1,
so the Lisp world has pretty well sorted itself out into Common Lisp
and Scheme.

(I'm saying that is what happened historically.  Whether CL or Scheme
should still be regarded as a Lisp is a different question, one that
has less to do with facts than with desires.)

Most OO languages are basically second order (objects, methods), and
they are the popular languages today.  Thus CL, itself an OO language,
fits the Zeitgeist.

Meanwhile the Scheme community has found common ground with Standard
ML, Haskell, and other languages where higher order functions are
prominent.

I believe the differences between the CL and Scheme communities have
much less to do with how well they adhere to someone's idea of a Lisp
ideal than with the second-order/OO versus higher-order/functional
issue I have tried to describe here.

Will

Why is Scheme not a Lisp? William D Clinger 3/14/02 7:02 PM
Rahul Jain wrote:
> Doug Quale <qua...@charter.net> writes:
> > Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
> > > Seems like this list is misleading and/or inaccurate. Probably because
> > > it was published in 1980 and we're applying it to 2000's context.
> >
> > You overlooked that I pointed out the fact that McCarthy explicitly
> > wrote in 1999 that the paper still accurately reflected his opinions.
>
> And I showed that it doesn't reflect what CL really does.

If this last remark were true, it would imply that the inventor
of Lisp holds opinions that imply that CL is not in the Lisp
family.

Let me hasten to add that, in my opinion, CL is indeed within
the Lisp family of languages, and that I strongly suspect that
John McCarthy holds a similar opinion.

Will

Why is Scheme not a Lisp? Kent M Pitman 3/14/02 7:29 PM
ces...@qnci.net (William D Clinger) writes:

> Most OO languages are basically second order (objects, methods), and
> they are the popular languages today.  Thus CL, itself an OO language,
> fits the Zeitgeist.

Do you mean in preferred style or in some deeper sense?  It seems to
me that CL primitively allows but just does not "prominently feature"
or "promote" higher order functions...

By contrast, Scheme doesn't really primitively offer OO, prominent or not.
Certainly it doesn't keep someone from layering it after, and to some degree
that's the intent of the language, that such stuff be the stuff of libraries.
But, at least from my (and probably many CL folks') point of view, it isn't
so much that this limits capability as that it robs the Scheme community of
a common terminology for talking about types.

The place where the language family metaphor breaks down is where we start
to talk about libraries.  The question is where the line is between libraries
and other user data, especially in a language that makes the libraries data.
Because libraries can be incompatible.  And not everyone knows every library.
So it calls into question what it means to "know Scheme" or to be
"Scheme-like" since there are almost no required features of Scheme; it is a
chameleon which, to put things in probably overly-provocative terms for point
of discussion, can claim anything but promise nothing.

Often people make lists of what Lisp is for the purpose of introductory
courses.  And often that list contains "program is data".  Of this my
standard reply is to observe that many languages can represent themselves
quite easily. BASIC can (arrays of strings).  Machine language can
(a range of memory).  What sets lisp apart isn't that it _can_, which is
easy to guarantee in a Turing powerful language, but that it _does_.
The power, I claim, is in Lisp's willingness to be arbitrary.  Scheme has
grudgingly recently allowed a very carefully concocted EVAL model back into
the language after years of absence.  Meanwhile, Lisp has gone on to add myriad
arbitrary new things, like a type system, a condition system, and so on.
These add capabilities, yes, but Scheme could add capabilities.  The power
really added is terminology--names for things we know we all have. Names
that are an attempt to create a common base that everyone uses.  To me, it's
the very arbitrariness that I sense the Scheme community eschews, and that
gives CL its power.

If you wanted a technical difference, I suppose I'd drive my stake in the
ground on that one.  Emacs Lisp, likewise, exploits the arbitrary.  There
could be many ways to do key bindings, but that would do no good to a vast
community of people needing to cooperate.  So specific, perhaps even flawed,
but "good enough" mechanisms exist for organizing tables of key bindings and
turning them on and off by mode.  And these are part of what it is to be
that Lisp, not just "extra libraries you might happen to load".  AutoLisp,
Interlisp, and even Maclisp did this.  

Scheme people have, by contrast, sometimes questioned the need even for an
ERROR function, claiming "Isn't it already an error just to call a function
named ERROR? What more do you need?"

> I believe the differences between the CL and Scheme communities have
> much less to do with how well they adhere to someone's idea of a Lisp
> ideal than with the second-order/OO versus higher-order/functional
> issue I have tried to describe here.

I think they have to do with who believes in the quest for the Holy
Grail of Canonically Right and who thinks it's a mirage (and that
there are myriad notions of Equally Right shimmering in all
directions).  I've compared it to the problem experienced by the
donkey (I think it is), who I've been told will starve to death if
placed equidistant between two carrots because he can't decide which
direction to go. (If it's not a donkey, you at least get the metaphor.)
There is sometimes tremendous value in just being arbitrary.

If you think CL is missing some higher order operation that it should have,
other than the known issues over tail calling and call/cc, I'd be curious
to know.  If these two items are what you mean by higher order, I am
perhaps missing your point somehow.  This isn't my preferred terminology,
so I require some hand-holding here if you want me to understand you.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/14/02 7:38 PM
Erik Naggum <er...@naggum.net> writes:

> | According to the charter of the newsgroup, it's for all dialects of Lisp.
>
>   comp.lang.lisp has no charter.  Newsgroups are what the users make them.

I already posted it.  At the time comp.lang.lisp originated (in 1982,
as net.lang.lisp), the customary way of declaring the charter for a
newsgroup was in the initial post after its creation, which
established that it was for all dialects of Lisp.

But you're rule is that comp.lang.lisp is for whatever *you* want, and
the other users only get a vote to the extent it agrees with you.

Why is Scheme not a Lisp? Wade Humeniuk 3/14/02 8:02 PM
sp...@bugbear.com (Paul Graham) writes:
> You have a very good point here Wade, one of the only substantial
> points in this rather long thread.  There is a conceptual core of
> Lisp.  In fact, that was exactly McCarthy's point in designing it:
> to show that if you start with a certain set of axioms, you can
> make a whole language out of it.  Anything that includes that
> core is Lisp.  (Including, amusingly, Python and Ruby if they get
> too much more powerful in future versions.)
>

Paul, excuse that this post is not a direct reply.  I did not get your
message on my news server.

If there is a conceptual Lisp with axioms, this is like having an algebra,
or group in mathemetics.  This goes to other discussions about the language
behind "Is Scheme a Lisp" as opposed to "Is Scheme a dialect of the family
of Lisp languages".  One can say that "Set1 is an Algebra" or the "Set of
Reals is a Field".  "Scheme is a Lisp" would then have meaning.

My background is not in computer science.  Is there a set of Lisp axioms?

Something like:

1) There exists a set of symbols S.  Any symbol s {an element of S} can be
bound to a value v (represented by (s,v)).
2) For any symbol s with value v there exists a binding function B, such
that B(s v)->(s,v). SETF
3) There exists an identity function such that I(s,v)->(s,v). IDENTITY
4) There exist values (v1 . v2) which are structured composites of two
values v1 and v2. CONS.
5) There exists an operator = such that (s1,v1)= (s1,v2) iff v1 is v2.  EQ.
........


Wade


Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/14/02 7:54 PM
Kent M Pitman <pit...@world.std.com> writes:

> I think they have to do with who believes in the quest for the Holy
> Grail of Canonically Right and who thinks it's a mirage...

I think what you say here is very well said; in many ways you've
captured something important about the difference between CL and
Scheme.

I'm not sure Scheme people think it's involved in a quest for the HGCR
however.  That's *almost* right, but not quite.  Scheme people
probably agree it's a mirage, but they are after something slightly
different, albeit very close.

The Scheme goal is perhaps not to find the HGCR, but to only add
language features that we are Really Confident belong to the HGCR.
For a long time it has been clear that macros are part of the HGCR,
but they weren't going to be added to Scheme until a "problem free"
definition, a Canonically Right one, if you like, was found.

Common Lisp, by contrast, knew that macros are really important,
greatly desired, and that people can do Just Fine, Thank You with a
macro facility even if it isn't Canonically Right.  And the Common
Lisp people are certainly correct about that.

Scheme is about, among other things, trying to avoid the "carrying
around old mistakes" problem.  There are a lot of small, relatively
inconsequential areas where Common Lisp has curious little
inconsistencies (like the difference between the way plists and alists
work, for example)--the inconsistencies don't matter much, but there
they are.

So the Scheme goal is try really hard to never have to say "oh, shoot!
I wish we'd done it differently!  but we'll keep it because it's good
enough."  My GNU/Linux system *still* has a function called "creat"
because of this, and Scheme is about trying not to do that.

As you so rightly point out, Common Lisp, by contrast, is about trying
really hard to maintain compatibility, to provide a standard namespace
for all the things any complete system will have, and so forth.  Those
are also hugely important tasks.

> If you think CL is missing some higher order operation that it should have,
> other than the known issues over tail calling and call/cc, I'd be curious
> to know.  

I don't know about "higher order".  Call/cc is the big one; proper
tail recursion is probably less important if you have decent general
iteration structures without it.

Some things that CL might profitably borrow from Scheme would be
proper tail recursion and hygenic macros.  Call/cc too, but of course,
that's not ever going to happen for all the obvious technical reasons.

Thomas

Why is Scheme not a Lisp? Kent M Pitman 3/14/02 8:17 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Some things that CL might profitably borrow from Scheme would be
> proper tail recursion

I think this could be managed under declarations and I wish some vendors
would experiment with this.

> and hygenic macros.

Hygenic macros solve a problem that CL does not have.
(They solve a problem introduced by Lisp1-ness. Heh.)
I see no need for these whatsoever.

> Call/cc too, but of course,
> that's not ever going to happen for all the obvious technical reasons.

I don't agree CL should have CALL/CC.  I don't even think Scheme should have
it.  I complained once to someone (probably Jonathan Rees) about the problem
that CALL/CC gives you back too much stuff.. I can't control how far out
it closes over.  I've been told there is something called a "delimited
continuation" that occurs in the literature that is probably what I want.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/14/02 8:30 PM
Kent M Pitman <pit...@world.std.com> writes:

> > and hygenic macros.
>
> Hygenic macros solve a problem that CL does not have.
> (They solve a problem introduced by Lisp1-ness. Heh.)
> I see no need for these whatsoever.

Hrm, maybe this is true, but I'm not sure about it.  There is a root
problem that I think CL still has, but maybe not.  Requires more
thought before I'd be confident either way.  (And another close read
of Chris Hansen's paper.)  But maybe you could say why you think the
problem exists in Scheme but not CL?

> I don't agree CL should have CALL/CC.  I don't even think Scheme should have
> it.  I complained once to someone (probably Jonathan Rees) about the problem
> that CALL/CC gives you back too much stuff.. I can't control how far out
> it closes over.  I've been told there is something called a "delimited
> continuation" that occurs in the literature that is probably what I want.

Hehe, there is call/ec (call-with-escape-continuation) which
essentially gives you one-way continuations.  

I'm not sure what kind of control you mean, however, so I don't know
what exactly the issue is that you're worried about.

Thomas

Why is Scheme not a Lisp? Erik Naggum 3/14/02 9:13 PM
* Thomas Bushnell, BSG

| But you're rule is that comp.lang.lisp is for whatever *you* want, and
| the other users only get a vote to the extent it agrees with you.

  CAN YOU GROW UP!?  You are regressing so fast you will be unborn in three
  weeks if you keep up this idiotic childishness.  Curb your anger and act
  like an adult!  Almost all the morons in this newsgroup resort to such
  obgiously retarded attacks when they do not get _their_ will around here,
  but not getting your will does not mean that somebody else gets theirs
  all the time.  One-bit people like you _really_ need to acquire more bits.

  Do you think you can figure out the difference between "I do _not_ want
  you pathetic, whining Scheme freaks here when you have your own stupid
  playground" and "I want to contol what _does_ go here"?  If cannot, you
  must be _fantastically_ dense.

  Once again, we must ask what the Scheme freaks seek in posting their
  idiotic drivel to comp.lang.lisp.  It looks a lot like a very childish
  desire to be accepted by their parents or grade school teacher or some
  other such authority, and when rejected, they turn to making a hell of a
  noise in the hopes of at least getting attention.  Grow the fuck up!

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/14/02 9:30 PM
Erik Naggum <er...@naggum.net> writes:

>   Do you think you can figure out the difference between "I do _not_ want
>   you pathetic, whining Scheme freaks here when you have your own stupid
>   playground" and "I want to contol what _does_ go here"?  If cannot, you
>   must be _fantastically_ dense.

Except there hasn't been such "pathetic whining", except for your
amazing diatribes.  It would be funny if it weren't so sad.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Rahul Jain 3/14/02 9:26 PM
Bijan Parsia <bpa...@email.unc.edu> writes:

> Is ML a Lisp?

I think that if scheme is a lisp, then it would be a very strange
concept to call ML not a lisp. ML and Scheme are on oppposite ends of
one spectrum (static typing) that Common Lisp is in the middle
of. However, in most other regards, ML can pretty much be considered
to be closer to scheme than it is to common lisp.

> I'm a bit unclear about the "notation for functions in terms of
> conses" requirement, also.

I think he basically means that code is expressed as cons-trees.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Kent M Pitman 3/14/02 9:36 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Kent M Pitman <pit...@world.std.com> writes:
>
> > > and hygenic macros.
> >
> > Hygenic macros solve a problem that CL does not have.
> > (They solve a problem introduced by Lisp1-ness. Heh.)
> > I see no need for these whatsoever.
>
> Hrm, maybe this is true, but I'm not sure about it.  There is a root
> problem that I think CL still has, but maybe not.  Requires more
> thought before I'd be confident either way.  (And another close read
> of Chris Hansen's paper.)  But maybe you could say why you think the
> problem exists in Scheme but not CL?

I could.  But not part of this thread--it's a real rat's nest of an
issue.  And, anyway, it's been copiously discussed.  Perhaps someone
who's not as burnt out right now as I am can dredge up the Google
reference?  (Thanks.)

> > I don't agree CL should have CALL/CC.  I don't even think Scheme
> > should have it.  I complained once to someone (probably Jonathan
> > Rees) about the problem that CALL/CC gives you back too much
> > stuff.. I can't control how far out it closes over.  I've been
> > told there is something called a "delimited continuation" that
> > occurs in the literature that is probably what I want.
>
> Hehe, there is call/ec (call-with-escape-continuation) which
> essentially gives you one-way continuations.  
>
> I'm not sure what kind of control you mean, however, so I don't know
> what exactly the issue is that you're worried about.

I'm going to try to defer this a few days.  Too many things going on.
Though maybe if someone who knows about "delimited continuations" wants to
offer an explanation of how they work in the interim, that would be cool.

The basic concept is to clip the effect of call/cc so that it closes over
only a certain amount of the pending "stack", not everything back to
creation.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Rahul Jain 3/14/02 9:33 PM
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> Maybe CL critiques of Scheme should proceed more along the lines of
> "Scheme is just a Lisp" rather than "Scheme is not a Lisp".  :-/

But why should we, or anyone else, tie down scheme to being "just a
lisp"? Let the scheme community do what they want, but don't define
scheme as a "superior lisp". I just don't see the point in scheme
clinging to the name "lisp" when the point of the name scheme was so
that it wasn't percieved as lisp!

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/14/02 9:43 PM
Kent M Pitman <pit...@world.std.com> writes:

> I could.  But not part of this thread--it's a real rat's nest of an
> issue.  And, anyway, it's been copiously discussed.  Perhaps someone
> who's not as burnt out right now as I am can dredge up the Google
> reference?  (Thanks.)

I'll look it up myself and see if I can figure it out.  

> The basic concept is to clip the effect of call/cc so that it closes over
> only a certain amount of the pending "stack", not everything back to
> creation.

Oh, I understand; yeah that's a reasonable desire.  I still wonder (no
need to answer if you don't like), what's the reason?  It sounds like
an efficiency tweak, but I wonder what the semantic advantages would
be.  I'll look up and see if I can find an answer myself, but I'd
appreciate pointers if anyone has some.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Christopher Browne 3/14/02 10:01 PM
Centuries ago, Nostradamus foresaw when Rahul Jain <rj...@sid-1129.sid.rice.edu> would write:
> ds...@goldshoe.gte.com (Dorai Sitaram) writes:
>
> > Maybe CL critiques of Scheme should proceed more along the lines of
> > "Scheme is just a Lisp" rather than "Scheme is not a Lisp".  :-/
>
> But why should we, or anyone else, tie down scheme to being "just a
> lisp"? Let the scheme community do what they want, but don't define
> scheme as a "superior lisp". I just don't see the point in scheme
> clinging to the name "lisp" when the point of the name scheme was so
> that it wasn't percieved as lisp!

If they so wanted to avoid the perception of association with Lisp,
they obviously didn't do a very good job of writing the standard.

After all, after, if what you suggest is true, namely that they
intended dissociation from Lisp, they broke that in the second
sentence of the standard by describing Scheme as a "dialect of the
Lisp programming language."

Kinda stupid to have the goal of dissociation and then start the
standard by describing how it's an instance of a Lisp...


--
(concatenate 'string "cbbrowne" "@acm.org")
http://www.ntlug.org/~cbbrowne/
Rules of the Evil Overlord #26. No matter how attractive certain
members of the rebellion are, there is probably someone just as
attractive who is not desperate to kill me. Therefore, I will think
twice before ordering a prisoner sent to my bedchamber.
<http://www.eviloverlord.com/>

Why is Scheme not a Lisp? Erik Naggum 3/14/02 10:12 PM
* Kent M Pitman

> Hygenic macros solve a problem that CL does not have.
> (They solve a problem introduced by Lisp1-ness. Heh.)
> I see no need for these whatsoever.

* Thomas Bushnell, BSG


| Hrm, maybe this is true, but I'm not sure about it.  There is a root
| problem that I think CL still has, but maybe not.  Requires more thought
| before I'd be confident either way.  (And another close read of Chris
| Hansen's paper.)  But maybe you could say why you think the problem
| exists in Scheme but not CL?

  Briefly put, the single namespace means that any variables used by the
  macro would cause any user-defined functions with the same name to become
  unusable in the body of the macro.  This requires a solution, and the
  solution is both real symbols, packages, and two namespaces, but in
  Scheme, they held on to the single namespace and had to invent hygienic
  macros, instead.  In Common Lisp, there is no danger of trampling on the
  functional value of a symbol just because you bind it lexically as a
  variable, so the body of the macro is undisturbed by any overlap in
  usage.  Also, since we have the ability to generate a symbol that cannot
  be reached by any name by the reader -- it is not interned in any package
  -- using either make-symbol or gensym, we have a choice of exporting a
  variable (or even function) from the macro to the body or to hide it with
  an invisible symbol.  Using such generated symbols poses no worse
  problems for any competent programmer than writing hygienic macros.
  There are even macros around that "rebind" variables hygienically.

  Thus hygienic macros is a necessary solution to a problem that arose from
  several bad design decisions in Scheme that plague the language in more
  ways than just requiring hygienic macros -- at least as seen from Common
  Lisp.  The single namespace, the lack of first-class symbols, exacerbated
  by the lack of packages, and the need for make-shift solutions to what
  should not have been problems, are all among the things that will
  continue to create problems.  Scheme therefore has to return to the
  drawing board and redesign itself instead of dragging this bggage along
  into the future.  At least it should try again with first-class symbols
  and packages.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/14/02 10:25 PM
Erik Naggum <er...@naggum.net> writes:

[ way too much ]

Was any of that *not* exactly the same kind of thing you said you
*don't* want here, at least, not when the languages are reversed?

It's so filled with mindless boosterism, the technical content is
almost absent.  But, taking a gander at the technical content, the
issue in your mind seems to be shadowing of global function names.

Can't the same thing happen with shadowing of top-level variable
names?

(As for the gensym issue, of course, gensym-like-solutions are exactly
how Scheme implementations implement hygenic macros.)

Thomas

Why is Scheme not a Lisp? Kent M Pitman 3/14/02 10:39 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Kent M Pitman <pit...@world.std.com> writes:
...
> > The basic concept is to clip the effect of call/cc so that it closes over
> > only a certain amount of the pending "stack", not everything back to
> > creation.
>
> Oh, I understand; yeah that's a reasonable desire.  I still wonder (no
> need to answer if you don't like), what's the reason?  It sounds like
> an efficiency tweak, but I wonder what the semantic advantages would
> be.  I'll look up and see if I can find an answer myself, but I'd
> appreciate pointers if anyone has some.

It has to do with externalization.

I used to see the Actor stuff that Henry Leiberman would use at the MIT
AI Lab printing out continuations to hand to objects in other machines.
The problem is that this exposes internal details of the running image
that go beyond the scope of the task to be performed...  Plus there are
some conceptual issues that have to do with GC that get involved, too,
I think.  I've not thought about it in a while so my brain may be fuzzy
on the details.

Why is Scheme not a Lisp? Erik Naggum 3/14/02 10:40 PM
* Thomas Bushnell, BSG

| Except there hasn't been such "pathetic whining", except for your
| amazing diatribes.  It would be funny if it weren't so sad.

  I am saddened that you are so deep into denial that you cannot even see
  what you are doing.  Please seek help to get out your anger rut.  At the
  very least, take a break from this newsgroup for a couple weeks.  You are
  too wound up to be able to think unclouded by emotion, and this does you
  no good.  You need to learn to deal with both diversity of opinion and
  the adversity of rejection of your opinions.  I also suggest you talk to
  someone about how you cope with cognitive dissonance.  Quit lying about
  me and what I say, want, or intend, and there is no need for me to post
  any correctives to your lies, either.  Now is a good time for you to zoom
  out and think carefully about what you want.  In case it is not clear: I
  want you noise-polluting Scheme freaks out of here, because there is very
  strong evidence of a serious culture clash whenever any one of you have
  the bad taste to wander into this forum or cross-post here.  And please,
  it is not because we do not handle disagreement -- we have plenty of it
  -- it is because you cannot deal with us being right and you being wrong
  in this newsgroup even if you have always been patted on the back and got
  the best grades for what you parrot from another forum.  If technical
  issues matter, if decisions of language design are made on technical
  grounds, and if call-with-current-continuation is a technically superior
  idea, how come no other language has this construct?  Either you have to
  face that "technical" does nto matter, or that this feature is no good.
  That is a question you do not receive where everybody agrees it is the
  best thing since sliced bread and there is something wron with the rest
  of the world for not having it, but that agreement does not exist here.
  It is such things that make up the reasons for splitting a community.
  Again, it is not because people cannot handle disagreement, it is just
  that some things are supposed to be agreed upon in a community -- they
  are precisely what the community is based on, it is because people agree
  on these things even though they disagree on a lot of others that they
  have come together.  Even if people fight all the time for what they
  think is right, there is serious psychological value in coming home to
  someone who love you for who you are and not have to fight.  That is what
  normal people seek in a reasonable community -- a place where people
  agree with them on certain things.  For instance, if people have to fight
  for their desire to use Common Lisp all day long and they have to face
  stupid and prejudiced people who denigrate Lisp and make their lives so
  much less enjoyable, they would naturally want to come to comp.lang.lisp
  and find people who agree with them that Common Lisp is a great language
  -- but that is precisely what you fucking annoying Scheme freaks deny us,
  what those who have some idiotic gripe with the standard deny us, what
  those who post web pages whining about braindamaged conditionals deny us,
  etc.  There are just some decisions we have made, we agree on them and
  their outcome, and we do not want to fight that battle over and over and
  over just because some of those who have not made that decision and who
  have their own forum to feel safe and secure in, choose to invade us with
  a constant barrage of annoying attitude problems.  I find you stupid
  dorks incredibly inconsiderate and rude, and I respodn to your total lack
  of civility in storming a political party meaning, or a church, or an
  abortion clinic, or a radio or TV station, or a newsgroup, with an agenda
  that basically says: "You guys are all wrong, and we are going to convert
  you!"  Such idiotic wars is not what technical newsgroups are for.  If
  you Scheme freaks want this kind of forum, I suggest you create a new
  forum, comp.lang.lisp.advocacy, where fools can bash eachothers' heads
  in, while adults can explore the space that opens up before them because
  they are comfortable with having made a particular decision.

  (I made that all one paragraph so people who read only the first should
  not get away with skipping all the juicy bits.)

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Kent M Pitman 3/14/02 10:48 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Erik Naggum <er...@naggum.net> writes:
>
> [ way too much ]
>
> Was any of that *not* exactly the same kind of thing you said you
> *don't* want here, at least, not when the languages are reversed?
>
> It's so filled with mindless boosterism, the technical content is
> almost absent.  But, taking a gander at the technical content, the
> issue in your mind seems to be shadowing of global function names.
>
> Can't the same thing happen with shadowing of top-level variable
> names?

No, it can't.  If the variable is in the same package and you shadow it,
then you presumably meant to.  In general the only top level variables
in CL are specials, and one doesn't bind them without a purpose.

Good style in macros is never to reference any variables free except those
named by the macro caller or except specials or except variables you
document that you will capture.

> (As for the gensym issue, of course, gensym-like-solutions are exactly
> how Scheme implementations implement hygenic macros.)

That's not really true.  Not the same gensyms as in CL.  That is, in
hygiene systems involving painting, symbols are painted without regard to
whether they are going to need to be gensymed, and list structure identity
is violated without regard to whether it is literal quoted lists or
semantically meaningful programs.  Lots more gensyms are made than are needed.

Sometimes people say this doesn't matter.  But I find it to be the same kind
of doesn't matter as "it doesn't matter if the police search your house when
you're out for the day. as long as you're doing nothing illegal, they
will leave it as they found it, and it will not matter that they were there".
To me, it does matter.  Among other things, it exposes the processed program
text to bugs due to errors in the "doesn't matter" processing, just as my
delicate glass objects are exposed to risk if the police screw up and bump
a table they shouldn't while they're making a "doesn't matter" search of
my house.

While working on T in 1981, I had prototyped a solution to this which
I never got to publishing.  A couple years later, Bawden came up with
and did publish more or less the same idea as I had been working on
and even gave it a nice name (I think it was called "syntactic
closures" ...?) but the Scheme community did not go in that direction.
They went with the Kohlbecker painting solution instead, which I don't
endorse.

Why is Scheme not a Lisp? Erik Naggum 3/14/02 11:07 PM
* Erik Naggum
| [ way too much ]

* Thomas Bushnell, BSG


| Was any of that *not* exactly the same kind of thing you said you *don't*
| want here, at least, not when the languages are reversed?
|
| It's so filled with mindless boosterism, the technical content is almost
| absent.

  Take a long break, will you?  Your mind is no longer able to deal with
  the _purpose_ that a normal, rational, sane person would have in reading
  and posting to a technical newsgroup.  Just get rid of your anger.  It is
  misplaced and counterproductive, and you have become so hypersensitive to
  what you perceive as hostilities that you completely fail to understand
  that you are by now _causing_ most of it.

  If you want people to agree with you that Scheme is such a great
  language, when it clearly is not _universally_ so, comp.lang.scheme
  should be your chosen forum.  Ov here, where there is no such "safe
  heven" from criticism, you just have to learn to cope with rejection of
  your core beliefs or get the hell out of here.  Scheme is _not_ protected
  from criticism in this forum.  When someone thinks Scheme sucks so bad it
  used to be abolished, they are likely to say so here, but _not_ in
  comp.lang.scheme, because that would be trolling.  This should not a big
  issue -- it is how all human forums works.  You guys should just figure
  out that your local belief that "Scheme is a superior Lisp" is _false_ in
  comp.lang.lisp, even though it is the raison d'être for comp.lang.scheme
  and therefore am unquestioned truth there.

  But take long a break, Thomas Bushnell!  You really _need_ it, now.  Find
  your way back to whatever desire or purpose prompted you to read and post
  to comp.lang.lisp.   This is not a proper forum for venting your spleen
  about anyone.  You, of all people, should know that, being as you wave
  the "charter" and want to control what is permissible here.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/14/02 11:05 PM
Kent M Pitman <pit...@world.std.com> writes:

> No, it can't.  If the variable is in the same package and you shadow it,
> then you presumably meant to.  In general the only top level variables
> in CL are specials, and one doesn't bind them without a purpose.

> Good style in macros is never to reference any variables free except those
> named by the macro caller or except specials or except variables you
> document that you will capture.

Um, so it sounds like the answer is "yes, it *does* happen with
top-level variables, but because of style and packaging
considerations, no problems actually come up".  (Which is a perfectly
good explanation; given that fact, I agree that CL doesn't really need
a hygenic macro system the way Scheme does.

> [In Scheme]


> Lots more gensyms are made than are needed.

Indeed, this is true; I think the expectation is that optimizing
compilers will notice the unused gensyms and elide them cleanly.
(Whether that is done in practice or not is something I don't really
know.)  

> They went with the Kohlbecker painting solution instead, which I don't
> endorse.

Isn't that just one implementation strategy?  I thought there were
several quite different underlying implementations possible (and in
use), with painting being only one of the alternatives.  (I'm close to
the extent of my depth here, so forgive my ignorance if the answer is
obvious.)

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Bruce Hoult 3/14/02 11:23 PM
In article <87vgbyz...@photino.sid.rice.edu>,
 Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:

> Bijan Parsia <bpa...@email.unc.edu> writes:
>
> > Is ML a Lisp?
>
> I think that if scheme is a lisp, then it would be a very strange
> concept to call ML not a lisp. ML and Scheme are on oppposite ends of
> one spectrum (static typing) that Common Lisp is in the middle
> of. However, in most other regards, ML can pretty much be considered
> to be closer to scheme than it is to common lisp.

Scheme and ML fail my "Can you easily transliterate textbook programs
from one language into the other language?" test.  Scheme examples make
frequent use of runtime polymorphism.  ML examples make frequent use of
implicit currying.


> > I'm a bit unclear about the "notation for functions in terms of
> > conses" requirement, also.
>
> I think he basically means that code is expressed as cons-trees.

I don't see why that is important for languages that don't have "eval"
or procedural macros, such as ML, Dylan, and (believe it or not) Scheme
until recently.

-- Bruce

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erik Naggum 3/14/02 11:36 PM
* Christopher Browne

| If they so wanted to avoid the perception of association with Lisp,
| they obviously didn't do a very good job of writing the standard.

  It serves a standard well to be accurate about its heritage (which I have
  pointed out that it is not, ironically).  There is no point in talking
  about it when teaching the language, because those who are learning it
  are most probably not aware of what the heritage means in the first place
  -- and if you have paid attention, you will notice that such historical
  things as language families is not foreign to me, but confused marketing
  is _the_ issue.

  I note in passing that the Dylan Reference Manual completely avoids any
  reference to Lisp.  Whatever some propagandists think, this can be used
  to send them on their way back to comp.lang.dylan.  How useful!

  I note in passing that reading the RnRS documents is not what _I_ would
  recommend anyone to do who were not ready to understand a lot more than
  they need to program in it.

| After all, after, if what you suggest is true, namely that they intended
| dissociation from Lisp, they broke that in the second sentence of the
| standard by describing Scheme as a "dialect of the Lisp programming
| language."
|
| Kinda stupid to have the goal of dissociation and then start the standard
| by describing how it's an instance of a Lisp...

  Only if you have only one-bit answers.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Rahul Jain 3/14/02 11:36 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Some things that CL might profitably borrow from Scheme would be
> proper tail recursion

if only anyone could define what is "proper" on all concievable
platforms.

> and hygenic macros.

That's been done by Dorai Sitaram, "macros by example".

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/14/02 11:50 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> tb+u...@becket.net (Thomas Bushnell, BSG) writes:
>
> > Some things that CL might profitably borrow from Scheme would be
> > proper tail recursion
>
> if only anyone could define what is "proper" on all concievable
> platforms.

Um, is there really a problem here?  Proper tail recursion is defined
in terms of the space complexity of the computation.  You have to give
a careful definition of which syntactic contexts count as a "tail
call".  

The Scheme standard requires that an unbounded number of active tail
calls must be supported; there may be other ways of saying the same
idea.

According to the Scheme standard, a more formal definition is in the paper:

William Clinger. Proper Tail Recursion and Space Efficiency. To appear
in Proceedings of the 1998 ACM Conference on Programming Language
Design and Implementation, June 1998.

Thomas

Why is Scheme not a Lisp? Rahul Jain 3/14/02 11:52 PM
ces...@qnci.net (William D Clinger) writes:

> If this last remark were true, it would imply that the inventor
> of Lisp holds opinions that imply that CL is not in the Lisp
> family.

I think that CL is different enough from the original LISP that it
_could_ be considered a different language. Just like C99 could be
considered a different language than K&R C, but even more so. But the
issue is that the CL community traces direct lineage to the original
LISP community, and as Kent has repeatedly claimed, that's what
matters when defining what a language is and is not. Scheme is a
"fork" from that community of people who wanted very different things
than what the mainstream Lispers wanted.

> Let me hasten to add that, in my opinion, CL is indeed within
> the Lisp family of languages, and that I strongly suspect that
> John McCarthy holds a similar opinion.

Yes, I think that's true more because of the reasoning I gave above
than any feature list.

While McCarthy's list is a nice summary of the ideas he considers
essential to a Lisp, it doesn't by any means cover what others want
from Lisp nor what distingushes Lisp from anything else.

Personally, I require at least symbols with packages, complete macros,
compiler macros, an object system with various features I won't
enumerate here, reader macros, and conditions from a Lisp. But I don't
bother trying to rigorously define what is a Lisp because I know that
categories in natural language are fuzzy.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Erann Gat 3/14/02 11:50 PM
In article <32251615...@naggum.net>, Erik Naggum <er...@naggum.net> wrote:

>   ... the lack of first-class symbols ...

Scheme has first-class symbols.  See R5RS section 6.3.3

E.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Rahul Jain 3/15/02 12:16 AM
Christopher Browne <cbbr...@acm.org> writes:

> Kinda stupid to have the goal of dissociation and then start the
> standard by describing how it's an instance of a Lisp...

Right, that's what confuses me. But it is clear from the actual
description and community of scheme that they definitely didn't want
to be a subset of the Lisp community.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Rahul Jain 3/15/02 12:19 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
> Um, is there really a problem here?  Proper tail recursion is defined
> in terms of the space complexity of the computation.  You have to give
> a careful definition of which syntactic contexts count as a "tail
> call".  

You can search google groups for past discussions about what can and
cannot be considered a tail call. There was no conclusion.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Rahul Jain 3/15/02 12:26 AM
Bruce Hoult <br...@hoult.org> writes:

> In article <87vgbyz...@photino.sid.rice.edu>,
>  Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:
> > Bijan Parsia <bpa...@email.unc.edu> writes:
> > > Is ML a Lisp?

> > I think that if scheme is a lisp, then it would be a very strange
> > concept to call ML not a lisp. ML and Scheme are on oppposite ends of
> > one spectrum (static typing) that Common Lisp is in the middle
> > of. However, in most other regards, ML can pretty much be considered
> > to be closer to scheme than it is to common lisp.

> Scheme and ML fail my "Can you easily transliterate textbook programs
> from one language into the other language?" test.

So the syntax is what matters? Java is a C, then? And what textbook
are you talking about? I can't believe that there are textbooks which
don't use call/cc and there should be textbooks which use CL's
condition system, and there are surely ones that use throw/catch. I
don't consider throw/catch to call/cc to be an "easy" transformation.

> Scheme examples make frequent use of runtime polymorphism.

Right, that's the static typing axis.

> ML examples make frequent use of implicit currying.

That's syntactic sugar, really.

> > > I'm a bit unclear about the "notation for functions in terms of
> > > conses" requirement, also.

> > I think he basically means that code is expressed as cons-trees.

> I don't see why that is important for languages that don't have "eval"
> or procedural macros, such as ML, Dylan, and (believe it or not) Scheme
> until recently.

Yes, exactly. :)

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Rahul Jain 3/15/02 12:29 AM
Erik Naggum <er...@naggum.net> writes:

> * Christopher Browne


> | Kinda stupid to have the goal of dissociation and then start the standard
> | by describing how it's an instance of a Lisp...
>
>   Only if you have only one-bit answers.

Hmm, yes. But it would have made more sense for them to make clear
that they were on a trajectory away from Lisp.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/15/02 12:35 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> You can search google groups for past discussions about what can and
> cannot be considered a tail call. There was no conclusion.

Oh, indeed; like I said, you must carefully determine what counts as a
tail call.  That is indeed fraught with difficulties.  

But you asked about what could be considered "proper", instead of what
could be considered a "tail call".  The proper part is easy and
unambiguous.  The tail call part is not.

There are certain things you might think are tail contexts in Scheme
where the R5RS does not require proper tail recursion, for example.

Adding proper tail recursion to Common Lisp would require such careful
work too.

Thomas

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Thomas Bushnell, BSG 3/15/02 12:38 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Right, that's what confuses me. But it is clear from the actual
> description and community of scheme that they definitely didn't want
> to be a subset of the Lisp community.

Really?  When the description says "Scheme .. is a dialect of the Lisp
programming language", you think that makes it clear they don't want
to be a subset of the Lisp community?  Every Scheme description I have
ever seen says something like that, and you conclude that they
*definitely* don't want to be part of the Lisp community?

Indeed, even the Common Lisp language texts list Scheme as a dialect
of Lisp.  

What is it that is making your conclusion so clear to you?

Thomas

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Bruce Hoult 3/15/02 12:59 AM
In article <87u1rix...@photino.sid.rice.edu>,
 Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:

> Bruce Hoult <br...@hoult.org> writes:
>
> > In article <87vgbyz...@photino.sid.rice.edu>,
> >  Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:
> > > Bijan Parsia <bpa...@email.unc.edu> writes:
> > > > Is ML a Lisp?
>
> > > I think that if scheme is a lisp, then it would be a very strange
> > > concept to call ML not a lisp. ML and Scheme are on oppposite ends of
> > > one spectrum (static typing) that Common Lisp is in the middle
> > > of. However, in most other regards, ML can pretty much be considered
> > > to be closer to scheme than it is to common lisp.
>
> > Scheme and ML fail my "Can you easily transliterate textbook programs
> > from one language into the other language?" test.
>
> So the syntax is what matters? Java is a C, then?

No, syntax does not matter.  For example, Common Lisp and Dylan can
usually be easily transliterated into each other, but the syntax is
quite different.


> And what textbook are you talking about? I can't believe that there
> are textbooks which don't use call/cc

As someone just pointed out, SICP doesn't mention call/cc.  I hadn't
realised that, but SICP is pretty much the clasic
textbook-that-uses-scheme.


> and there should be textbooks which use CL's
> condition system, and there are surely ones that use throw/catch. I
> don't consider throw/catch to call/cc to be an "easy" transformation.

I wouldn't either.  CL and Scheme aren't very close in this area.  On
the other hand, CL and Dylan have very similar condition systems --
Dylan unifies conditions and restarts but that's more a theoretical
tidiness thing than a practical problem.


> > Scheme examples make frequent use of runtime polymorphism.
>
> Right, that's the static typing axis.
>
> > ML examples make frequent use of implicit currying.
>
> That's syntactic sugar, really.

True, and you can emulate it in Scheme using lambdas and/or an explicit
"curry", but it's used heavily enough in ML to cause a lot of code
expansion when translated to Scheme.

Perhaps a better example (which I mentioned yesterday but forgot today)
is the heavy use of pattern matching in ML.


> > > > I'm a bit unclear about the "notation for functions in terms of
> > > > conses" requirement, also.
>
> > > I think he basically means that code is expressed as cons-trees.
>
> > I don't see why that is important for languages that don't have "eval"
> > or procedural macros, such as ML, Dylan, and (believe it or not) Scheme
> > until recently.
>
> Yes, exactly. :)

Well, if you think that "eval" is essential then list *it*, not the
incidental "notation for functions in terms of conses".

-- Bruce

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Ian Wild 3/15/02 1:25 AM
Dorai Sitaram wrote:
>
> In article <3C90CDAD...@cfmu.eurocontrol.be>,
> Ian Wild  <ian....@eurocontrol.int> wrote:
> >Dorai Sitaram wrote:
> >>
> >> In article <4f52f844.02031...@posting.google.com>,
> >> Paul Graham <sp...@bugbear.com> wrote:
> >> >If a language has car, cdr, cons, if, eq, atom, quote, and a
> >> >notation for functions in terms of conses, then it's Lisp.
> >>
> >> In addition to your list (!), I would add I/O
> >> procedures -- read, prin1/write, and at least one
> >> of {load, eval} -- that operate directly on s-exps.
> >
> >That would mean you could /never/ have an embedded Lisp.
>
> I'm sorry I didn't understand that.  Is an "embedded
> Lisp" something that has an s-exp syntax but doesn't
> have read, prin1, etc?  Does this Lisp system have
> ports (in the sense of doors) to the outside
> world at all, and how does it accept a Lisp program to
> run?

Err....I feed my program to the compiler and it generates
the bytes that get burned into ROMs that make the doorbell
play the opening sequence of "All You Need is Love".  I
can write my program in a choice of languages, assembler,
C, and PL/M spring to mind, but you're suggesting I can
/never/ use Lisp unless I also fit a screen and keyboard
to the doorbell.  (Plus, I'd guess, a disc drive to
give "load" somewhere to look.)

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Rahul Jain 3/15/02 1:44 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Really?  When the description says "Scheme .. is a dialect of the Lisp
> programming language", you think that makes it clear they don't want
> to be a subset of the Lisp community?

Wow.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Rahul Jain 3/15/02 1:52 AM
Bruce Hoult <br...@hoult.org> writes:

> In article <87u1rix...@photino.sid.rice.edu>,
>  Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:
> > Bruce Hoult <br...@hoult.org> writes:
> > > In article <87vgbyz...@photino.sid.rice.edu>,
> > >  Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:
> > > > I think that if scheme is a lisp, then it would be a very strange
> > > > concept to call ML not a lisp.

> > > Scheme and ML fail my "Can you easily transliterate textbook programs

> > > from one language into the other language?" test.

> > So the syntax is what matters? Java is a C, then?

> No, syntax does not matter.  For example, Common Lisp and Dylan can
> usually be easily transliterated into each other, but the syntax is
> quite different.

It all depends on what's "usual".

> > And what textbook are you talking about? I can't believe that there
> > are textbooks which don't use call/cc

> As someone just pointed out, SICP doesn't mention call/cc.  I hadn't
> realised that, but SICP is pretty much the clasic
> textbook-that-uses-scheme.

So we should use a book that uses a language to teach general concepts
as the standard textbook for that language? I don't get the point of
this "textbook program" idea.

> > > ML examples make frequent use of implicit currying.

> > That's syntactic sugar, really.

> True, and you can emulate it in Scheme using lambdas and/or an explicit
> "curry", but it's used heavily enough in ML to cause a lot of code
> expansion when translated to Scheme.

Same with porting code that uses CLOS or conditions to Scheme. Or code
that uses call/cc to Lisp.

> Perhaps a better example (which I mentioned yesterday but forgot today)
> is the heavy use of pattern matching in ML.

That can be done without too much trouble with COND. As much trouble
as any other differences between the languages.

> > > > > I'm a bit unclear about the "notation for functions in terms of
> > > > > conses" requirement, also.
> > > > [...]

> > > I don't see why that is important for languages that don't have "eval"
> > > or procedural macros, such as ML, Dylan, and (believe it or not) Scheme
> > > until recently.
> > Yes, exactly. :)

> Well, if you think that "eval" is essential then list *it*, not the
> incidental "notation for functions in terms of conses".

Perl has eval, too.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Discussions, was Re: Why is Scheme not a Lisp? Stefan Schmiedl 3/15/02 4:08 AM
On Fri, 15 Mar 2002 06:40:31 GMT,
Erik Naggum <er...@naggum.net> wrote:
>   Such idiotic wars is not what technical newsgroups are for.

All of you would do the public image of comp.lang.lisp a great
favour, if you would carry out those pointless arguments (not even
discussions) consisting of accusations and counter-accusations with
often unnecessarily harsh language in private.

Thank you for your consideration.

S.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erik Naggum 3/15/02 4:11 AM
* Rahul Jain <rj...@sid-1129.sid.rice.edu>

| Hmm, yes. But it would have made more sense for them to make clear
| that they were on a trajectory away from Lisp.

  Precisely, positions can be close to eachother, but the direction of the
  momentum or the heading to the destination may be quite different.  What
  is so annoying with "Scheme is a (dialect of) Lisp" when published
  recently (as opposed to when it was written) is that they imply that Lisp
  has moved in the same direction Scheme has, and that is patently _false_.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Discussions, was Re: Why is Scheme not a Lisp? Erik Naggum 3/15/02 4:49 AM
* Stefan Schmiedl

| All of you would do the public image of comp.lang.lisp a great
| favour, if you would carry out those pointless arguments (not even
| discussions) consisting of accusations and counter-accusations with
| often unnecessarily harsh language in private.

  Why did you post this?  Could it be because your message would not have
  worked if you mailed it to people privately?  There is some insight here.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Dorai Sitaram 3/15/02 5:38 AM
In article <3C91BE29...@cfmu.eurocontrol.be>,

Ian Wild  <ian....@eurocontrol.int> wrote:
>Dorai Sitaram wrote:
>>
>> I'm sorry I didn't understand that.  Is an "embedded
>> Lisp" something that has an s-exp syntax but doesn't
>> have read, prin1, etc?  Does this Lisp system have
>> ports (in the sense of doors) to the outside
>> world at all, and how does it accept a Lisp program to
>> run?
>
>Err....I feed my program to the compiler and it generates
>the bytes that get burned into ROMs that make the doorbell
>play the opening sequence of "All You Need is Love".  I
>can write my program in a choice of languages, assembler,
>C, and PL/M spring to mind, but you're suggesting I can
>/never/ use Lisp unless I also fit a screen and keyboard
>to the doorbell.  (Plus, I'd guess, a disc drive to
>give "load" somewhere to look.)

I would say you have a Lisp _program_.  The case is not
uncommon I will grant you that.  I don't know about
doorbells, but there are Lisp programs that are
downloaded into untethered robots that do their thing.
These programs are for example an event-driven loop
that responds to sensations (obstacles, temperature,
battery dry-up), internal dead-reckoning calculations,
&c.  But I would differentiate this Lisp program from
the Lisp language implementation that was used in its
creation.  The former is no more a Lisp than a
factorial function written in Lisp is a Lisp (the
factorial has no cons/car/cdr or I/O either).

But I can see why my inclusion of s-exp-aware I/O
routines seems to unduly tie Lisp's definition to
current hardware practice, which may well vanish with
time (or "evolution" to use a common trope here), but I
hope I am saved by the fact that "read" and
"prin1" are defined in terms of "ports" (or
"streams" in CL parlance) rather than files, and while
I did mention "load" which I think is file-specific
even in CL, I only meant one of {load, eval}.  

Thank you for your stimulating post.

--d

Discussions, was Re: Why is Scheme not a Lisp? Rolf Mach 3/15/02 5:49 AM
Stefan,

I completely agree.

Sincerely

Rolf Mach


Stefan Schmiedl wrote:

--


__________________________________________________________________________________________

XANALYS  -  www.xanalys.com

Data Analysis and Lisp Development Tools
Software zur Datenanalyse und Lisp Entwicklungsumgebungen
__________________________________________________________________________________________

Rolf Mach
Business Development & Sales Manager, Europe

An der Schaafhansenwiese 6
D-65428 Ruesselsheim, Germany
Phone ++49 +6142 938197
Fax ++49 +6142 938199
rm...@xanalys.com
__________________________________________________________________________________________

Watson  -  PowerCase  -  Quenza  -  LispWorks


Why is Scheme not a Lisp? Dorai Sitaram 3/15/02 6:01 AM
In article <87n0xaz...@photino.sid.rice.edu>,

Rahul Jain  <rj...@sid-1129.sid.rice.edu> wrote:
>tb+u...@becket.net (Thomas Bushnell, BSG) writes:
>
>> and hygenic macros.
>
>That's been done by Dorai Sitaram, "macros by example".

I write to caution anyone who may be misled:

Actually it is not hygienic (yet).  I plan to make it
so sometime, but it requires more knowledge of the CL
special form armamentarium in its entirety than I
currently have, but more importantly, even if it is
done, it is unlikely to find much or even any use.
Based on buzz here, I think it may not even have value
as proof-of-concept, because I think everybody agrees
it can be done if one really wants it.

Hygiene requires much more knowledge of the underlying
language than some other Scheme programs that I have
rather more cavalierly scm2cl'ed.

--d

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Christopher Browne 3/15/02 6:01 AM
In the last exciting episode, ds...@goldshoe.gte.com (Dorai Sitaram) wrote::
> In article <3C90CDAD...@cfmu.eurocontrol.be>,

> Ian Wild  <ian....@eurocontrol.int> wrote:
> >Dorai Sitaram wrote:
> >>
> >> In article <4f52f844.02031...@posting.google.com>,
> >> Paul Graham <sp...@bugbear.com> wrote:
> >> >If a language has car, cdr, cons, if, eq, atom, quote, and a
> >> >notation for functions in terms of conses, then it's Lisp.
> >>
> >> In addition to your list (!), I would add I/O
> >> procedures -- read, prin1/write, and at least one
> >> of {load, eval} -- that operate directly on s-exps.
> >
> >That would mean you could /never/ have an embedded Lisp.
>
> I'm sorry I didn't understand that.  Is an "embedded
> Lisp" something that has an s-exp syntax but doesn't
> have read, prin1, etc?  Does this Lisp system have
> ports (in the sense of doors) to the outside
> world at all, and how does it accept a Lisp program to
> run?  

Hmm.

With ACL, I am led to believe that if you leave EVAL 'turned on' in a
deployed system, you may find you need to pay some _ferocious_
licensing fees.

As a result, if there's not Real Need for someone to do programming
work on the target system, there would be a substantial economic
incentive to _not_ make that necessary.

Does that mean that it's not Lisp running on the target system,
because there might be no EVAL there?  I wouldn't think so...
--
(concatenate 'string "cbbrowne" "@acm.org")
http://www.ntlug.org/~cbbrowne/
Rules of the Evil Overlord #26. No matter how attractive certain
members of the rebellion are, there is probably someone just as
attractive who is not desperate to kill me. Therefore, I will think
twice before ordering a prisoner sent to my bedchamber.
<http://www.eviloverlord.com/>

data hygiene [Re: Why is Scheme not a Lisp?] Kent M Pitman 3/15/02 6:20 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> While McCarthy's list is a nice summary of the ideas he considers
> essential to a Lisp, it doesn't by any means cover what others want
> from Lisp nor what distingushes Lisp from anything else.
>
> Personally, I require at least symbols with packages,

Yes.  And I think the "with packages" is an important but very subtle point,
so I want to underscore this so it doesn't get lost as a triviality.

Very, very early Lisps did not have packages, but did quickly come up
with obarrays, which were object-oriented equivalents of same.  They
were essential to namespacing.  And I would argue that the function GENSYM
is the most trivial and low-tech variant of the "package" concept.

When McCarthy says "properties on symbols" and Scheme doesn't have this,
it isn't as trivial as saying "add a library function".  Adding that
function immediately confronts the fact that Scheme has no separation of
data among programs in the symbol space.  What this means is that if my
program does
 (setf (get 'person-1 'name) "Fred)
and your program does
 (setf (get 'person-1 'name) "Mary")
then we are going to clobber each others' data very fast.  Scheme "solves"
this by using things like hash tables and lexical namespaces so that
we each do something more akin to
 (setf (gethash 'person1 my-name-table) "Fred")
where we each have a lexical variable my-name-table in our own space but
really we are doing gethash each on our own database.  This doesn't
_really_ solve the problem though because while it separates the programs
it doesn't allow them to interact.  I cannot later 'relate', at the symbol
level, your person-1 with my person-1, without doing a global renaming.
And the problem is increased in complexity every time a new entrant enters
the field.  I cannot in Scheme construct the notion of passing
 '(kent:person-1 rahul:person-1)

Or if I do, then KENT:PERSON-1 is a symbol with a 13-letter name and the
functions that do the accessing have to first decode it to find a hidden
symbol PERSON-1 within it and also a function or table that corresponds
to Kent's NAME operation/resource.  

Scheme data separation, by being forced back into the function, works
against one of the key things for which Lisp was built, which is
accessible, symbolic, data-driven representation of information.  It
focuses back heavily on programmatic embedding of knowledge, which is
an earmark of most other languages.  It does this, not surprisingly,
because this allows all kinds of program optimizations, but in a sense
it forgets that the whole _point_ of "dynamic" programming is to
accept some non-optimizations in favor of programmatic flexibility.

The Common Lisp package system is a frequent source of complaint from
the Scheme community, who often rail against it thinking that a module
system is a more "obvious" choice of separation.  I have continually
maintained, though perhaps not well-articulated, that the two are
utterly orthogonal concepts.  One separates data, the other program.
As soon as you start talking data, my experience is that Schemers kind
of go to sleep and say "oh, well, data has no semantics and so is
irrelevant".  But it really does matter in the sense that I mean
semantics, which is not something formal and denotationally described,
but is something meaningful in terms of a set of data layouts that are
well-enough described that their nature impacts computation in just
the same primitive ways as do the differences between lists and
arrays.  You can't get to the fourth element of a list without
visiting the third, because that's just how lists work.  In package
systems, symbols are more complex beasts and merely knowing their name
is not enough to find them.  The Scheme folks I've engaged in
discussion on this matter don't like this because of all the hair this
introduces in symbol sharing, search lists, import lists, export
lists, shadowing, etc.  It drips of arbitrary (see my recent post on
the fear of the arbitrary, I won't repeat it here).

I have to admit that from time to time I myself have been troubled
almost to the point of embarrassment about packages, but it's really
not the data structure which troubles me, it's the operations on them.
Packages themselves seem sound.  I think of Scheme symbols as I do the
CL KEYWORD package.  There is a certain luxurious simplicity in the
ability to put things into it when you can prove that you have an
issue so simple and limited that it will never need to combine with
(and therefore clash with) the data of another module.  But lots of
times you can't, and in the great big scary world where you have to
risk that your application will get successful enough that it will
live in the same address space that another successful application
will live, packages do matter.

We could probably do a lot to reform the operators we have on packages,
but that's just an API issue and won't affect the underlying and profound
issue of whether you can mix and match data from one application with
data from another application and then sort it back out without having
confused yourself about identity.

It's funny that Schemers don't care at all about this issue because it
is an issue I'll hereby dub "data hygiene" and is as importnat as
"program hygiene".  Very, very early Lisp didn't have it because the
concept of multiple programs and images and successful applications didn't
come up.  But I'll be that all modern Lisps either do have this or
are highly simplified extensions languages where people don't share code.

Oh yes, there were some other things Rahul had been talking about.
Now that I've laid some conceptual groundwork, let me get back to those:

> complete macros, compiler macros,

These, once again, involve the merging of symbolic _data_ from varying
environments.  In Lisp, data hygiene protects us from a problem in
programmatic hygiene. [Aside: I just love how empowering a new piece
of terminology can be.  Look how concisely I can now say that thing I
used to have to say by appeal to Lisp1/Lisp2 stuff and letting
variables vary and functions not vary and all that...  Now, with this
new term "data hygiene" that's all in the noise and I can just speak
of the abstract about the forces at play without addressing the
distracting details of their implementation, just as "program hygiene"
allows people to abstract away from the messy details of its own
implementation.]

In any case, I think that it's easy to see that a fairly direct
consequence of there being too little data hygiene in programs is what
leads to the very complex nature of the macro systems used by Scheme.
They've taken a simple idea, haired it up, then packaged it in a way
they hope will make it look simple again--the only price being I can't
do all the things with macros that I used to be able to do.  Bleah.
This works exactly counter to what Scheme has done with its passion for
higher order functions, where they frown on exactly that thing we have
done with (for example) keyword arguments to functions, or even worse
with LOOP.  They often talk about how these kinds of "making certain
common things easy at the expense of generality" is bad, yet that's
precisely what has been done with their macro system--they have made
certain common things easy at the expense of generality.  And now that
I have this program hygiene vs data hygiene line I can view, I can see
clearly where the line is and it all seems obvious to me in a kind of
precise way what the damage was, when before I felt like I was randomly
nitpicking with no rhyme or reason.

Once again, Scheme has moved away from symbolic data representation as
being the central, general thing.  They still have it.  And for toy
things, it's quite easy.  But for general uses, it's gotten harder.
And that's what bugs me.

> an object system with various features I won't
> enumerate here,

But I will enumerate a couple that have been on my list for a long time
because I can cast them into my new way of thinking:

I have often said that the key difference between the CL system and the
various Scheme systems I've seen and/or used (I have to qualify it for
Scheme since it has no standard and it could be others have different
experience with different systems) is that CL likes to "name" things.
I call this the "absolute" model of reference.  Like absolute pathnames.
In CL, it makes sense to actually talk about
 (defmethod foo:x :after ((a bar:y) (b baz:z)) ...)
from anywhere and it will mean the same thing because the symbols naming
the types and operations are absolute references.  But in Scheme you
generally refer to names only through their lexical bindings, and so
you get only pedigree names.  And to get full generality, Scheme pretty
much makes you use objects everywhere that CL would use symbols, because
objects have enough "identity" to keep from getting confused.  If you
just used symbols x, y, and z, applications would clash.  But in Scheme you
refer to x and its value is #<OPAQUE-REFERENCE 12345> in your program and
you can write a method on it, while someone else refers to X but means
#<OPAQUE-REFERENCE 54321> and they can write a method on it.  But you are
hampered in seeing what's going on because symbols are no good to you in
expressing the relationships symbolically.  In the world of multiple clients,
the names would collide and there'd be a mess.

CL, by exploiting data hygiene, has made it possible for there to be an
orderly way to separate symbol namespaces and yet to share them when needed
and visually to  see what is going on when that happens in a way that is
largely known to be intelligible and practical to users worldwide after
20 years of usage.

> reader macros,

I agree this is critical.  I don't know why Scheme doesn't use this more.
I see no technical obstacle.

> and conditions from a Lisp.

This goes back to naming.  In a protocol-based system, you must be able
to name conditions.  Several scheme systems have been devised that are
workable.  Big surprise: they don't name conditions with names, but with
objects.  Now I understand why better, though: names would clash.

> But I don't
> bother trying to rigorously define what is a Lisp because I know that
> categories in natural language are fuzzy.

Well, in spite of that, I'm happy you wrote your post, because it kind of
catalyzed some thought on this that at least I am happy with.

The bottom line is that I think McCarthy was creating a language that was
about using symbols to represent real chunks of knowledge, and I think
Scheme, in its desire to make something (I can't quite figure out what:
the spec? the symbol itself? certain common code?) "look pretty", has
crippled the capability to use that specific data type in the most general
way, the way that it was originally intended.

Again, if you're looking for a technical divergence, I'm happy to say this
is not just "oh, ok, they messed up on one little detail". I  think this is
a big, big thing that pervades the character of the whole language.

In debugging Scheme, there is constant data hiding going on.  Having a symbol
is never enough to really know its meaning because every symbol has meaning
only in a context.  (I'll spare you the irony of a detailed comparison of
this to the Lisp1/Lisp2 debate, where they often express disdain about
having to know the context to understand a symbol.)  There's always a piece
of extra info ("the lexical environment") which if you had would make the
symbol meaningful, but it doesn't travel coupled with the symbol, and so
the symbol carries far less meaning than it does in, well, in what I think
of as a Lisp.

Maybe I'm just saying it takes more than just a symbol datatype in your
language to be a symbolic processing language.  This would  mean I made
a MAJOR technical gaff in my Slashdot article when I suggested it was ok
to study either Common Lisp or Scheme as exemplars of symbolic processing
languages.  Darn.  Live and learn.

Why is Scheme not a Lisp? Kent M Pitman 3/15/02 6:26 AM
g...@jpl.nasa.gov (Erann Gat) writes:

Well, first, Erik's using shorthand here (which I don't think confused you,
but which is lost in the context of the ellipsis).  First-class symbols in
specifying language semantics; certainly it has the datatype and I don't
think he was denying that.

As to your point, though, Erann, the addition of first-class symbosl in the
language semantics is a very recent addition.  A patch because many of us
have complained about this for so long.  Traditionally, Scheme has not had
this.  Nor has it had EVAL.

But even acknowledging that they now do this, just in case you aren't reading
all my posts, do please see my post under a subject line I've renamed to
be "data hygiene".  It might offer some additional perspective on a closely
related issue.  (Then again, maybe it'll just be incoherent.  I didn't quite
have enough sleep and should go back to bed.  Maybe it's one of those things
where stuff sounds really good to you in a dream state but then when you wake
up you've put your wallet in the refrigerator...)

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Kent M Pitman 3/15/02 6:30 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

Perhaps the plain fact that it's more important that they feel
themselves technically right than that they win friends?  They did not
compromise for the sake of attracting audience from the prior
community.  They were plainly willing to lose every last user and
start anew.

This is not a black&white issue with right&wrong stamped on one side or
the other.  But certainly Rahul is not being irrational for having drawn
the conclusion he has drawn.

Why is Scheme not a Lisp? Geoff Summerhayes 3/15/02 7:18 AM

"Kent M Pitman" <pit...@world.std.com> wrote in message
news:sfwofhpewld.fsf@shell01.TheWorld.com...

> g...@jpl.nasa.gov (Erann Gat) writes:
>
> (Then again, maybe it'll just be incoherent.  I didn't quite
> have enough sleep and should go back to bed.  Maybe it's one of those things
> where stuff sounds really good to you in a dream state but then when you wake
> up you've put your wallet in the refrigerator...)
>

Nothing wrong with a little `cold hard cash' once in a while.

-=-=-=-=-=-

Geoff

Why is Scheme not a Lisp? Bruce Lewis 3/15/02 7:47 AM
Kent M Pitman <pit...@world.std.com> writes:

> Hygenic macros solve a problem that CL does not have.
> (They solve a problem introduced by Lisp1-ness. Heh.)
> I see no need for these whatsoever.

You never need to use gensym when writing CL macros?  Maybe you meant to
say, "a problem doubled by Lisp1-ness."

Non-hygienic macros are definitely useful, but this bashing of hygienic
macros doesn't seem right.

--
<brlewis@[(if (brl-related? message)    ; Bruce R. Lewis
              "users.sourceforge.net"   ; http://brl.sourceforge.net/
              "alum.mit.edu")]>

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Bruce Lewis 3/15/02 7:57 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> I just don't see the point in scheme clinging to the name "lisp" when
> the point of the name scheme was so that it wasn't percieved as lisp!

I think you're seeing an agenda where there is none.

http://www.informatik.uni-bremen.de/~net/history.html

   Following the tradition of the AI languages ``Planner'' and
   ``Conniver'', Steele and Sussman named their language ``Schemer''; the
   name was later truncated to ``Scheme'' to fit the 6-character filename
   limitation of the ITS operating system.


--
<brlewis@[(if (brl-related? message)    ; Bruce R. Lewis
              "users.sourceforge.net"   ; http://brl.sourceforge.net/
              "alum.mit.edu")]>

Why is Scheme not a Lisp? Duane Rettig 3/15/02 9:00 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
>
> > tb+u...@becket.net (Thomas Bushnell, BSG) writes:
> >
> > > Some things that CL might profitably borrow from Scheme would be
> > > proper tail recursion
> >
> > if only anyone could define what is "proper" on all concievable
> > platforms.

>
> Um, is there really a problem here?  Proper tail recursion is defined
> in terms of the space complexity of the computation.  You have to give
> a careful definition of which syntactic contexts count as a "tail
> call".  

I was willing to overlook this once, because I understand what you
mean by "Proper Tail Recursion" (which is actually different from
"proper tail recursion"), and you did start out with the mention of it
in relation to Scheme.  But because you are not posting to a scheme
newsgroup, you must lose the terminology idioms which are not common
to this newsgroup, or you will ultimately not be understood.

Definitions we can live with in c.l.l:

tail call:  A call in tail position (i.e. there is no more work to
do in the caller after the call, and the value(s) from the callee
are what will be returned).

tail recursion: 1. Usually, a tail call where the caller and callee
are the same function.  2. a tail call

tail call optimization:
tail call elimination:
tail recursion optimization:
tail recursion elimination:
tail merging: The elimination of the stack in a tail call or or a tail
recursion, by turning a call-to-subroutine into a jump and reusing the
caller's stack space.

proper tail recursion: a tail call with no bugs

Proper Tail Recursion: tail merging done The Scheme Way.

All Common Lisp implementations have tail recursion.  And if their
tail recursion is not proper, then a bug report to the vendor is
appropriate.

Most Common Lisp implementations even do tail recursion optimization,
but none of them do Propoer Tail Recursion as defined by the Scheme
spec (as a CL implementor, I wouldn't do anything according to the
Scheme spec, unless I were purporting to conform to that spec.  Any
apparent conformances to such specs are purely coincidental).

> The Scheme standard requires that an unbounded number of active tail
> calls must be supported; there may be other ways of saying the same
> idea.
>
> According to the Scheme standard, a more formal definition is in the paper:
>
> William Clinger. Proper Tail Recursion and Space Efficiency. To appear
> in Proceedings of the 1998 ACM Conference on Programming Language
> Design and Implementation, June 1998.

These are all references to Scheme definitions.  If you want to communicate
to the Common Lisp community, you should base your terminology on the
lowest common denominator, so that we poor, improper Common Lispers can
understand it.

So, in summary, if I had been you I would have been more clear by saying
something like "Some things that CL might profitably borrow from Scheme
would be their definition of tail recursion optimization..."
(which I disagree with, but at least what you were suggesting would
have been more clear).

--
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   duane@Franz.COM (internet)

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/15/02 9:07 AM
Duane Rettig <du...@franz.com> writes:

> All Common Lisp implementations have tail recursion.  And if their
> tail recursion is not proper, then a bug report to the vendor is
> appropriate.

:)  I was unaware of the terminological difference.  Thanks for
pointing it out!

> Most Common Lisp implementations even do tail recursion optimization,
> but none of them do Propoer Tail Recursion as defined by the Scheme
> spec [...]

Sure, but that's because "tail position" is not well defined, right
[and is language-detail dependent anyhow]?  Or is there some other
difference your getting at?

Why is Scheme not a Lisp? William D Clinger 3/15/02 9:14 AM
Kent M Pitman wrote:
> If you think CL is missing some higher order operation that it should have,
> other than the known issues over tail calling and call/cc, I'd be curious
> to know.  If these two items are what you mean by higher order, I am
> perhaps missing your point somehow.

Yes, you are.  I was talking about the fact that the defining
feature of Lisp2, separate environments for values and for
functions, creates a bias against higher-order thinking.  In
Lisp2, functions are usually bound in a different environment
from other values, so Lisp2 programmers do not think of
functions simply as values.  Thus, for example, you can find
examples of Common Lisp programmers who do not see the need
for hygienic macros, claiming that function names cannot be
shadowed.  Are they unaware of FLET and LABELS?  Probably not.
Probably they're just aware that FLET and LABELS are so seldom
used as not to cause a problem for macro writers.  Why aren't
FLET and LABELS used?  There are many reasons, but one is the
cultural bias against higher-order thinking that results from
a Lisp2.

In Scheme, by contrast, LET, LETREC, and local definitions are
quite often used to define local functions.  There are many
reasons for this, too, but one is that local functions are
convenient in higher-order programs, and Scheme, being a Lisp1,
has attracted people who like to write higher-order programs.

If you still don't get it, consider what it is like to simulate
higher order functions using function objects in Java.  To call
a function object f, you use a special syntax such as f.call(_)
instead of writing f(_).  The .call can be viewed as a kind of
cast that coerces from the value domain to the function domain.
Common Lisp's FUNCALL can be viewed as a similar coercion.
Many of the people who are attracted to Lisp in the first place
don't like to clutter their programs with all these injections
and coercions from one type to another.  They're annoying and
unnecessary.  If you're a first- or second-order thinker, then
you probably won't agree with this, and you'll be happy with a
Lisp2.  If you're a higher-order thinker, you'd be happier
with a Lisp1 if all else were equal.

It wouldn't be, of course.

Will

Why is Scheme not a Lisp? Duane Rettig 3/15/02 10:00 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Duane Rettig <du...@franz.com> writes:
>
> > All Common Lisp implementations have tail recursion.  And if their
> > tail recursion is not proper, then a bug report to the vendor is
> > appropriate.
>
> :)  I was unaware of the terminological difference.  Thanks for
> pointing it out!

No problem.

> > Most Common Lisp implementations even do tail recursion optimization,
> > but none of them do Propoer Tail Recursion as defined by the Scheme
> > spec [...]
>
> Sure, but that's because "tail position" is not well defined, right
> [and is language-detail dependent anyhow]?

No, in fact it is because it _is_ well-defined and applies to most
languages, but the water is muddied by the fact that the tail-recursion
terminology has been hijacked by the Scheme definition.

Note that although I didn't give a formal definition of tail position,
I did give it informally as a part of the more trivial tail-call
definition:

| tail call:  A call in tail position (i.e. there is no more work to
| do in the caller after the call, and the value(s) from the callee
| are what will be returned).

This informal definition is trivial and can apply to any stack-based
language.  Of course, there is always the possibility of contention
as to what constitutes "work", but the answer (e.g. any operations that
might deal with the stack or other non-register resources) could be
viewed as common understanding anyway, so I didn't bother to define
it that carefully for the purposes of discussion in this newsgroup.

> Or is there some other difference your getting at?

No; I'm fighting to take back hijacked terminology.

--
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   duane@Franz.COM (internet)

data hygiene [Re: Why is Scheme not a Lisp?] Thomas Bushnell, BSG 3/15/02 10:23 AM

Data-hygene would be important if symbols in Scheme had all the
features that they do in Common Lisp.  Kent's example is doing the
following in two different programs:

 (setf (get 'person-1 'name) "Fred)
 (setf (get 'person-1 'name) "Mary")

Since plists convert every symbol into a global variable, these two
certainly do have to be separated, and the Common Lisp package system
is a fine way of doing that.

But in Scheme, a symbol has no global properties.  Or rather, if you
like, the only global property it can have are is definition in the
top level environment.  And modules solve that problem.  

But Kent's right that another thing suddenly pops up:

"I cannot later 'relate', at the symbol level, your person-1 with my
person-1, without doing a global renaming."

Sure, this is certainly true.  In Common Lisp, the two person-1's are
relateble, in that each program has easy access to the other.  (And
the package system helps make that access even easier, and well
controlled.)

Here the difference is going to just be one of style.  It's actually
program hygene now, and making that access as easy as Kent would like
would be *breaking* a hygene barrier.  (As seen from the Schemey
perspective.)  That is, from the Scheme perspective, we're dealing
with global variables here, and We Don't Like Global Variables.  Or at
least, that's the point.

I'm not here "railing" against the Common Lisp package system.  I
think it's clearly the right thing in a language with "heavy"
symbols--symbols that have plists and all that.  

Now you argue that this has made the macro system in Scheme "very
complex", but I think that's looking at the wrong side of the
problem.  Scheme macros, from the user's perspective, are as simple as
can be: they reliably Just Work.  Everytime I worry (oh, will this
shadow something wrongs) and I bother figuring it out, I realize,
"nope, the rules nicely make sure the Right Thing will happen".  

The complexity is in the *implementation*, to preserve that quite
simple appearance to the user.

Thomas

Why is Scheme not a Lisp? Rahul Jain 3/15/02 10:26 AM
ces...@qnci.net (William D Clinger) writes:

> Yes, you are.  I was talking about the fact that the defining
> feature of Lisp2, separate environments for values and for
> functions, creates a bias against higher-order thinking.

Not at all. _You_ may find such a grammatical structure inconvenient,
but I find it highly conductive to efficient programming as well as
compatible with higher-order thinking.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/15/02 10:36 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> ces...@qnci.net (William D Clinger) writes:
>
> > Yes, you are.  I was talking about the fact that the defining
> > feature of Lisp2, separate environments for values and for
> > functions, creates a bias against higher-order thinking.
>
> Not at all. _You_ may find such a grammatical structure inconvenient,
> but I find it highly conductive to efficient programming as well as
> compatible with higher-order thinking.

But then that means that CL macros are not hygenic, because FLET
captures bindings in exactly the ways that are the point behind
hygenic macros.

Erik said if you separate function and variable namespaces, then you
don't need hygenic macros.  That's true only because

1) Global definitions are almost always functions.
2) Global data definitions have special names, by convention , and
   people never shadow those.
3) People don't make local bindings in the function namespace.

It's right that Lisp2 doesn't force you to follow those rules, but if
you don't follow them, then you can't claim that CL macros are
hygenic.

Thomas

Why is Scheme not a Lisp? Thomas F. Burdick 3/15/02 10:48 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
>
> > ces...@qnci.net (William D Clinger) writes:
> >
> > > Yes, you are.  I was talking about the fact that the defining
> > > feature of Lisp2, separate environments for values and for
> > > functions, creates a bias against higher-order thinking.
> >
> > Not at all. _You_ may find such a grammatical structure inconvenient,
> > but I find it highly conductive to efficient programming as well as
> > compatible with higher-order thinking.
>
> But then that means that CL macros are not hygenic, because FLET
> captures bindings in exactly the ways that are the point behind
> hygenic macros.

But in CL, we have packages.  If your macro expands to a call to
cl:car, and my consuming function calls the macro in an flet which
binds autos:car, we have no conflict.

> Erik said if you separate function and variable namespaces, then you
> don't need hygenic macros.  That's true only because
>
> 1) Global definitions are almost always functions.
> 2) Global data definitions have special names, by convention , and
>    people never shadow those.

Right.

> 3) People don't make local bindings in the function namespace.

No, see above.  And btw, I use local functions all the time.

> It's right that Lisp2 doesn't force you to follow those rules, but if
> you don't follow them, then you can't claim that CL macros are
> hygenic.

No one's claiming that they're hygenic, just that it's not a problem
that they're not, and it can actually be a good thing that they're
not.

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

data hygiene [Re: Why is Scheme not a Lisp?] Rahul Jain 3/15/02 10:48 AM
Kent M Pitman <pit...@world.std.com> writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
> > But I don't
> > bother trying to rigorously define what is a Lisp because I know that
> > categories in natural language are fuzzy.

> Well, in spite of that, I'm happy you wrote your post, because it kind of
> catalyzed some thought on this that at least I am happy with.

No problem, and thanks for the wonderfully insightful reply!

> The bottom line is that I think McCarthy was creating a language that was
> about using symbols to represent real chunks of knowledge,

Yep, this is reflected in the title of the original paper on Lisp,
"Recursive Functions of Symbolic Expressions and their Computation by
Machine". The primary reason Lisp has gotten where it is today is
because of that specific conceptual foundation. Even though he didn't
intend, at first, to use the language to directly manipulate itself
(or did he?), it ended up being trvial to do for this reason.

> and I think Scheme, in its desire to make something (I can't quite
> figure out what: the spec? the symbol itself? certain common code?)
> "look pretty",

My impression was that they wanted it to "feel pretty". But I don't
think they were as interested in making the act of coding like that,
rather the act of reading the spec.

> has crippled the capability to use that specific data type in the
> most general way, the way that it was originally intended.

Yes, I find that to be the worst deficiency of scheme, since with that
capability, all other deficiencies are moot (at least in theory).

> Again, if you're looking for a technical divergence, I'm happy to say this
> is not just "oh, ok, they messed up on one little detail". I  think this is
> a big, big thing that pervades the character of the whole language.

Yes, and it reveals that their focus is totally different from that of
the Lisp community.

> Maybe I'm just saying it takes more than just a symbol datatype in your
> language to be a symbolic processing language.  This would  mean I made
> a MAJOR technical gaff in my Slashdot article when I suggested it was ok
> to study either Common Lisp or Scheme as exemplars of symbolic processing
> languages.  Darn.  Live and learn.

Hehe, I noticed that I didn't like your mention of Scheme as a
symbolic processing language, but your post has made me realize
exactly why that is so.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

First-class symbols (Re: Why is Scheme not a Lisp?) Erann Gat 3/15/02 9:59 AM
In article <sfwofhp...@shell01.TheWorld.com>, Kent M Pitman
<pit...@world.std.com> wrote:

> g...@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <32251615...@naggum.net>, Erik Naggum
<er...@naggum.net> wrote:
> >
> > >   ... the lack of first-class symbols ...
> >
> > Scheme has first-class symbols.  See R5RS section 6.3.3
>
> Well, first, Erik's using shorthand here (which I don't think confused you,
> but which is lost in the context of the ellipsis).

No, I think I really am confused :-)  Here's the unelided sentence:

* Erik:
> The single namespace, the lack of first-class symbols, exacerbated
> by the lack of packages, and the need for make-shift solutions to what
> should not have been problems, are all among the things that will
> continue to create problems.

I think I really don't understand what he means by "first class symbols."
The phrase "first-class function" usually means that functions can be
passed as arugments and returned as values.  Scheme symbols have those
properties as well.  So one of us is obviously missing something, and I'm
pretty sure it's me.

> First-class symbols in
> specifying language semantics; certainly it has the datatype and I don't
> think he was denying that.

Could you explain what you mean by that?  I understand that CL semantics
are specified in terms of symbols.  What I don't understand is why this is
considered so important.  Is this really about special variables?  Because
if it is then it seems to me that you can easily emulate special variables
in Scheme using dynamic bind.  (I'm not saying this as Scheme propoganda.
I'm saying this as an indication of where my understanding is at to help
people frame a response.)

> As to your point, though, Erann, the addition of first-class symbosl in the
> language semantics is a very recent addition.  A patch because many of us
> have complained about this for so long.  Traditionally, Scheme has not had
> this.  Nor has it had EVAL.

R4RS had symbols so they go back at least to 1991.  I can't find an online
copy of RNRS for N<4 so I don't know if they go back any further than
that.

> But even acknowledging that they now do this, just in case you aren't reading
> all my posts, do please see my post under a subject line I've renamed to
> be "data hygiene".  It might offer some additional perspective on a closely
> related issue.  (Then again, maybe it'll just be incoherent.  I didn't quite
> have enough sleep and should go back to bed.  Maybe it's one of those things
> where stuff sounds really good to you in a dream state but then when you wake
> up you've put your wallet in the refrigerator...)

Thanks.  I'll go look this up.

E.

Why is Scheme not a Lisp? Rahul Jain 3/15/02 11:09 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> But then that means that CL macros are not hygenic, because FLET
> captures bindings in exactly the ways that are the point behind
> hygenic macros.

But it doesn't capture the binding of the symbol it doesn't have in
its package.

> Erik said if you separate function and variable namespaces, then you
> don't need hygenic macros.  That's true only because

  0) Lisp has packages.


> 1) Global definitions are almost always functions.
> 2) Global data definitions have special names, by convention , and
>    people never shadow those.
> 3) People don't make local bindings in the function namespace.

3 is wrong. I have no idea where you got that.

> It's right that Lisp2 doesn't force you to follow those rules, but if
> you don't follow them, then you can't claim that CL macros are
> hygenic.

No one claimed that they are. Your reading skills are deteriorating.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Coby Beck 3/15/02 11:12 AM

"Doug Quale" <qua...@charter.net> wrote in message
news:87sn73c40c.fsf@charter.net...

> Kent M Pitman <pit...@world.std.com> writes:
> > But I mention this because we sometimes refer to "dialect of Lisp" yet
the
> > term "dialect of xxx" usually refers to a language, and there really is
no
> > language that is Lisp, so we're really saying "dialectal variants of
> > languages in the Lisp family", and then that makes the the question more
> > vague: what is in the question.
>
> This is an interesting point.  Clearly "Scheme is a dialect of Lisp"
> should have the same interpretation as "Interlisp is a dialect of
> lisp", although they may have different truth values.  If it is
> sensible to call Common Lisp a dialect of Lisp, then the question "Is
> Scheme a dialect of Lisp" has meaning.
>

I think I've got it: Scheme is a dialect of a kind of a Lisp and InterLisp
is a kind of a dialect of a Lisp and Dylan is a descendent of a dialect of a
kind of Lisp and Common Lisp is kind of a compromise between diverse
dialects of differing kinds of Lisps where Lisp refers to a set of dialects
of kinds of languages that that share a philisophical kindred
spirit....(kind of ;)

--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")

Why is Scheme not a Lisp? Dorai Sitaram 3/15/02 11:16 AM
In article <43cz1h...@beta.franz.com>,
Duane Rettig  <du...@franz.com> wrote:
>[counseling the use of "tail call elimination"
> instead of "proper tail recursion"]

>
>No; I'm fighting to take back hijacked terminology.

I quite agree that "tail-call elimination" is the
better term.  TCE obviously can happen even in
situations where there is no recursion at all, let
alone tail recursion.  TCE is the term I have
always used and prefer, even if I am less likely than
you to imagine a potential useful alternate meaning for
"proper tail recursion".

I haven't done a poll, but I think TCE is indeed
preferred by most people, esp when they are
talking specifically about the phenomenon.  (Or
"tail-call optimization", which I of course don't like
because it suggests optionality, although CLers may
like it precisely because of that.  I have even heard
"mandatory tail-call optimization"...)

I've only ever seen "properly tail-recursive" used
adjectivally of an entire language (to mean that it
does TCE), and while it seems even less likely than
"proper tail recursion" to have a PUAM, it doesn't have
the clarity of "tail-call eliminating".  "Properly
tail-recursive" is however the term used in the now
notorious second sentence of the R*RS.  But hark: You
now have two R*RS authors wading through this very
thread -- perhaps you could persuade them to
s/properly tail-recursive/tail-call eliminating/.  

--d

data hygiene [Re: Why is Scheme not a Lisp?] Rahul Jain 3/15/02 11:13 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> I'm not here "railing" against the Common Lisp package system.  I
> think it's clearly the right thing in a language with "heavy"
> symbols--symbols that have plists and all that.  

Or in a language with multiple programs that do symbolic processing on
the same data and want to keep their own "markers" in the data.

> Now you argue that this has made the macro system in Scheme "very
> complex", but I think that's looking at the wrong side of the
> problem.  Scheme macros, from the user's perspective, are as simple as
> can be: they reliably Just Work.

Unless you want to do something where they Just Won't. And all this
syntactic bloat being forced for a little theoretical
"perfection". Not a language for me, for sure.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Bruce Hoult 3/15/02 12:19 PM
In article <877koex...@photino.sid.rice.edu>,
 Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:

> Bruce Hoult <br...@hoult.org> writes:
>
> > In article <87u1rix...@photino.sid.rice.edu>,
> >  Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:
> > > Bruce Hoult <br...@hoult.org> writes:
> > > > In article <87vgbyz...@photino.sid.rice.edu>,
> > > >  Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:
> > > > > I think that if scheme is a lisp, then it would be a very strange
> > > > > concept to call ML not a lisp.
>
> > > > Scheme and ML fail my "Can you easily transliterate textbook programs
> > > > from one language into the other language?" test.
>
> > > So the syntax is what matters? Java is a C, then?
>
> > No, syntax does not matter.  For example, Common Lisp and Dylan can
> > usually be easily transliterated into each other, but the syntax is
> > quite different.
>
> It all depends on what's "usual".

Of course.  Unfortunately it's always going to be subjective.


> > > And what textbook are you talking about? I can't believe that there
> > > are textbooks which don't use call/cc
>
> > As someone just pointed out, SICP doesn't mention call/cc.  I hadn't
> > realised that, but SICP is pretty much the clasic
> > textbook-that-uses-scheme.
>
> So we should use a book that uses a language to teach general concepts
> as the standard textbook for that language? I don't get the point of
> this "textbook program" idea.

The idea is *precisely* that the book should have programs that do some
general, useful, thing rather than programs intended to illustrate
obscure and seldom-used corners of the language.


> > > > ML examples make frequent use of implicit currying.
>
> > > That's syntactic sugar, really.
>
> > True, and you can emulate it in Scheme using lambdas and/or an explicit
> > "curry", but it's used heavily enough in ML to cause a lot of code
> > expansion when translated to Scheme.
>
> Same with porting code that uses CLOS or conditions to Scheme.

I agree.  CL and Scheme are probably the two Lisps with the greatest
distance between them.  CL code using CLOS and conditions is easy to
port to Dylan.


> Or code that uses call/cc to Lisp.
                              ^^^^^ Common Lisp

I already covered that.  Most Scheme programs don't use call/cc heavily.

> > Perhaps a better example (which I mentioned yesterday but forgot today)
> > is the heavy use of pattern matching in ML.
>
> That can be done without too much trouble with COND. As much trouble
> as any other differences between the languages.

"Too much trouble" is subjective.  I'd say it's too much trouble to just
use cond.  If you had a destructuring-cond then it might not be.

> > > > > > I'm a bit unclear about the "notation for functions in terms of
> > > > > > conses" requirement, also.
> > > > > [...]
> > > > I don't see why that is important for languages that don't have "eval"
> > > > or procedural macros, such as ML, Dylan, and (believe it or not) Scheme
> > > > until recently.
> > > Yes, exactly. :)
>
> > Well, if you think that "eval" is essential then list *it*, not the
> > incidental "notation for functions in terms of conses".
>
> Perl has eval, too.

My point exactly.  More than one c.l.ler has pointed out how close Perl
5 is getting to being a Lisp.

-- Bruce

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Bruce Hoult 3/15/02 12:21 PM
In article <32251830...@naggum.net>, Erik Naggum <er...@naggum.net>
wrote:

> * Rahul Jain <rj...@sid-1129.sid.rice.edu>
> | Hmm, yes. But it would have made more sense for them to make clear
> | that they were on a trajectory away from Lisp.
>
>   Precisely, positions can be close to eachother, but the direction of the
>   momentum or the heading to the destination may be quite different.  What
>   is so annoying with "Scheme is a (dialect of) Lisp" when published
>   recently (as opposed to when it was written) is that they imply that Lisp
>   has moved in the same direction Scheme has, and that is patently _false_.

Lisp can't move in a direction.  It just is.  Platonic.  Pure.  Common
Lisp can move in a direction.

-- Bruce

data hygiene [Re: Why is Scheme not a Lisp?] Bruce Lewis 3/15/02 12:49 PM
Kent M Pitman <pit...@world.std.com> writes:

> I cannot in Scheme construct the notion of passing
>  '(kent:person-1 rahul:person-1)
>
> Or if I do, then KENT:PERSON-1 is a symbol with a 13-letter name and the
> functions that do the accessing have to first decode it to find a hidden
> symbol PERSON-1 within it and also a function or table that corresponds
> to Kent's NAME operation/resource.  

I think you're making too much of this.

You can always pass something like this:
  (list kent 'person-1 rahul 'person-1)
where kent and rahul are hash tables, assoc lists, closures or
something.

Or you could define some global lookup table for 'kent and 'rahul, and
just pass '((kent person-1) (rahul person-1)).  I don't see any major
design flaw here.

Do you really think packages and property lists are prereqs for a
symbolic processing language?

--
<brlewis@[(if (brl-related? message)    ; Bruce R. Lewis
              "users.sourceforge.net"   ; http://brl.sourceforge.net/
              "alum.mit.edu")]>

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Rahul Jain 3/15/02 12:46 PM
Bruce Hoult <br...@hoult.org> writes:

> Lisp can't move in a direction.  It just is.  Platonic.  Pure.  Common
> Lisp can move in a direction.

Hmm, maybe you should take a linguistics class, they explain why
symbols don't have one static meaning. Languages change.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Rahul Jain 3/15/02 12:42 PM
Bruce Hoult <br...@hoult.org> writes:

> In article <877koex...@photino.sid.rice.edu>,
>  Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:
> > Bruce Hoult <br...@hoult.org> writes:
> > > No, syntax does not matter.  For example, Common Lisp and Dylan can
> > > usually be easily transliterated into each other, but the syntax is
> > > quite different.

> > It all depends on what's "usual".

> Of course.  Unfortunately it's always going to be subjective.

Or rather, a concept that should be defined in terms of community
instead of some arbitrary transient critera.

> The idea is *precisely* that the book should have programs that do some
> general, useful, thing rather than programs intended to illustrate
> obscure and seldom-used corners of the language.

call/cc is a general, useful things. throw/catch is a common
technique, and scheme programmers need to use call/cc to do that.

> > > Perhaps a better example (which I mentioned yesterday but forgot today)
> > > is the heavy use of pattern matching in ML.

> > That can be done without too much trouble with COND. As much trouble
> > as any other differences between the languages.

> "Too much trouble" is subjective.  I'd say it's too much trouble to just
> use cond.  If you had a destructuring-cond then it might not be.

Right, just a simple macro. Or maybe it's not so simple in scheme? I
can't imagine why.

> > Perl has eval, too.

> My point exactly.  More than one c.l.ler has pointed out how close Perl
> 5 is getting to being a Lisp.

Except that it doesn't have any of the features that I find defining
in Lisp. (code (and data) represented as cons-trees of symbols in
packages, most importantly.)

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Bruce Lewis 3/15/02 1:06 PM
ces...@qnci.net (William D Clinger) writes:

> Kent M Pitman wrote:
> > If you think CL is missing some higher order operation that it should have,
> > other than the known issues over tail calling and call/cc, I'd be curious
> > to know.  If these two items are what you mean by higher order, I am
> > perhaps missing your point somehow.
>
> Yes, you are.  I was talking about the fact that the defining
> feature of Lisp2, separate environments for values and for
> functions, creates a bias against higher-order thinking.

Whoa!  Slow down, Will.  It's obvious from Kent's post that you need to
define higher-order here.  It looks like you're talking about
higher-order functions: functions that manipulate functions that
manipulate functions.

Functions that manipulate other data types are first-order functions.
Functions that manipulate first-order functions are second-order
functions.  Am I using your terminology?

Absent definition, "higher order thinking" just sounds like "superior
thinking," making your post even more inflammatory.

> In Lisp2, functions are usually bound in a different environment from
> other values, so Lisp2 programmers do not think of functions simply as
> values.  Thus, for example, you can find examples of Common Lisp
> programmers who do not see the need for hygienic macros, claiming that
> function names cannot be shadowed.  Are they unaware of FLET and
> LABELS?  Probably not.  Probably they're just aware that FLET and
> LABELS are so seldom used as not to cause a problem for macro writers.
> Why aren't FLET and LABELS used?  There are many reasons, but one is
> the cultural bias against higher-order thinking that results from a
> Lisp2.

I think you're making too much of what you see in this Usenet
discussion.  Yes, Lisp1 makes using higher-order functions more
convenient.  However, someone who knows how to use higher-order
functions will use them in any language, most assuredly in a language
that includes lambda.  If you want to argue that a Lisp1 is better for
people learning about higher-order functions, go for it.  But don't
paint "Lisp2 programmers" with one brush.

> Many of the people who are attracted to Lisp in the first place
> don't like to clutter their programs with all these injections
> and coercions from one type to another.  They're annoying and
> unnecessary.

Let the language with no idioms that anyone views as "clutter" cast the
first stone.

> If you're a higher-order thinker, you'd be happier
> with a Lisp1 if all else were equal.
>
> It wouldn't be, of course.

Right, so even higher-order thinkers may have valid reasons for choosing
CL, even if it means having to type #' a lot.

--
<brlewis@[(if (brl-related? message)    ; Bruce R. Lewis
              "users.sourceforge.net"   ; http://brl.sourceforge.net/
              "alum.mit.edu")]>

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Christopher C. Stacy 3/15/02 1:11 PM
>>>>> On 15 Mar 2002 13:38:02 GMT, Dorai Sitaram ("Dorai") writes:

 Dorai> In article <3C91BE29...@cfmu.eurocontrol.be>,
 Dorai> Ian Wild  <ian....@eurocontrol.int> wrote:
 >> Dorai Sitaram wrote:
 >>>
 >>> I'm sorry I didn't understand that.  Is an "embedded
 >>> Lisp" something that has an s-exp syntax but doesn't
 >>> have read, prin1, etc?  Does this Lisp system have
 >>> ports (in the sense of doors) to the outside
 >>> world at all, and how does it accept a Lisp program to
 >>> run?
 >>
 >> Err....I feed my program to the compiler and it generates
 >> the bytes that get burned into ROMs that make the doorbell
 >> play the opening sequence of "All You Need is Love".  I
 >> can write my program in a choice of languages, assembler,
 >> C, and PL/M spring to mind, but you're suggesting I can
 >> /never/ use Lisp unless I also fit a screen and keyboard
 >> to the doorbell.  (Plus, I'd guess, a disc drive to
 >> give "load" somewhere to look.)

 Dorai> I would say you have a Lisp _program_.

No, he's saying his robot doorbell has a Lisp runtime system
that is capable of running Lisp programs downloaded into it.

The same thing is true in C: there is a C runtime system in the robot
or credit-card terminal, and it probably does not include printf.

Why is Scheme not a Lisp? Kent M Pitman 3/15/02 1:14 PM
ces...@qnci.net (William D Clinger) writes:

> Kent M Pitman wrote:
> > If you think CL is missing some higher order operation that it should have,
> > other than the known issues over tail calling and call/cc, I'd be curious
> > to know.  If these two items are what you mean by higher order, I am
> > perhaps missing your point somehow.
>
> Yes, you are.

Hmm.  (Reading what you've written, I'm still not so sure I'm missing
something.  I certainly accept that you think I am.  My personal take
is that I perceive the same fact set differenlty than you.  But it's
really of no consequence as long as we can understand each other well
enough to debate, and I certainly find your presentation of the
perceived problem lucid enough to continue...)

> I was talking about the fact that the defining
> feature of Lisp2, separate environments for values and for
> functions, creates a bias against higher-order thinking.

This is a nice succinct example of where we take a different view on
the same data.  I perceive that you think writing #'foo is somehow a
negativity because you don't what to write it.  I think what you don't
see is that I don't have any negative take on the writing of #'foo and
so I am not negatively biased away from using it.

To cast things into provocative terms, I might say "what creates a bias
against higher-order thinking in CL is the people lined up with picket
signs outside the School of CL Programming's doorsteps saying "#' is ugly".
I don't think it's a necessary truth, but I think if you chant it enough,
you might make some headway.  And certainly you will make people feel like
they are offending someone by doing it.  But in the end, all that means is
you will cause people not to do higher order programming since that _is_
the syntax we do it in.  You will not cause a change in the language this
way.  Indeed, if you want to encourage higher order programming, you need
to get Nike to sponsort a set of signs for your picketers that say
"Just call it" and that ignore the syntax.

> In Lisp2, functions are usually bound in a different environment
> from other values, so Lisp2 programmers do not think of
> functions simply as values.

This is surely isn't true of me.  I do.  That's what I find so incredible
about this discussion.  I look at #'car and think of it as just another
function.  One I file in a special "hot file" of quickly available functions
so that it will be available EVEN IF there is a local lexical binding
shadowing it.  I regard it as diminishing the importance of the function
named by #'car if you allow it to be shadowed!  That says, "it might not be
important to get to this function in this context" and that strikes me as
extraordinariliy bizarre!

> Thus, for example, you can find
> examples of Common Lisp programmers who do not see the need
> for hygienic macros, claiming that function names cannot be
> shadowed.

Function names cannot be _unpreventably_ shadowed.  Both CL and Scheme
allow the writing of buggy code, of course.  

I realized after my post on "data hygiene" that the issue is that Scheme
provides two-argument EVAL but CL needs only 1-argument EVAL because the
"meaning" (read: the appropriate binding environment) of symbols to EVAL
is obvious just from the symbols.  Moreover, in CL  you can construct
mixed-use expressions that are tricky to compose in Scheme without layering
extra levels of expression.  Consider:  
  (eval '(cl:car (foo:bar alpha:*beta*))).
Now in Scheme you would have to first receive the environment in which
FOO and *BETA* were meaningful in order to do
  (lambda (foo-environment alpha-environment)
    (eval `(car ',(',(eval 'bar foo-environment)
                   ',(eval '*beta* alpha-environment)))
          (scheme-report-environment 5)))
or else you have to receive the actual values of those symbols from someone
who has done you the service of looking those things up
  (lambda (bar *beta*)
    (eval `(car ,(',bar ',*beta*)) (scheme-report-environment 5)))
or
  (lambda (bar *beta*)
    (eval `(car ,(bar *beta*)) (scheme-report-environment 5)))
[the second is more concise, but kind of does EVAL the favor of doing part of
its job for it beforehand].

> Are they unaware of FLET and LABELS?

To understand this situation, you must work by cases:

First, I consider minimal competence of a programmer to include the
requirement that the programmer is not only aware of FLET and LABELS
but is aware of his own code and the consequences of his own code.

FLET and LABELS can certainly shadow names, _however_

 (a) if a programmer shadows his own names, I must conclude he intends to
     and I take this as the same kind of gesture as I would in scheme if
     one issued a "please capture" request to a hygienic macro system

 (b) if a programmer shadows another's names, they are declaring themselves
     implementor of that other programmer's code.  This is bad style, IMO,
     and in general should never be done in well-styled code.  (It is,
     however, sometimes done and sometimes even defensibly in an attempt
     to patch broken code.)

  Probably not.

> Probably they're just aware that FLET and LABELS are so seldom
> used as not to cause a problem for macro writers.

No, I use them all the time.  But I don't run into trouble because I
(a) never shadow my own names and (b) I never bind the names of
another package.   Doing (a) assures I do not break my own macros
and (b) assures I don't break others' macros.  So macros just work.

> Why aren't FLET and LABELS used?

Because a lot of the time we don't need them.  I use them any time I
don't have a simpler way to do something.  I use them a _lot_ in macrology,
which  you'd think would get me into trouble if macro hygiene were not
present, but my code works quite reliably because there _is_ hygiene.  It
is just partially enforced at the data level, something Scheme does not have
in its weakened notion of symbols.

> There are many reasons, but one is the
> cultural bias against higher-order thinking that results from
> a Lisp2.

I just don't agree.

> In Scheme, by contrast, LET, LETREC, and local definitions are
> quite often used to define local functions.  There are many
> reasons for this, too, but one is that local functions are
> convenient in higher-order programs, and Scheme, being a Lisp1,
> has attracted people who like to write higher-order programs.

I don't disagree with this analysis of Scheme, though I think Scheme
has done a disservice to others elsewhere by teaching its benefits as
a contrast to the way others do things, rather than acknowledging
other legitimate systems where higher order function are available.
People come out of Lisp courses thinking it is a lemma that we don't
have higher order functions that work, and so do not stop to examine
that perhaps this is false.

You're certainly right that people who teach higher order functions
tend to come from a Scheme background, but this is not a technical
issue, it's an issue of historical preference ... er, "compatibility
with the past", that thing we're sometimes reviled for, but just not
Lisp's past. Someone else's past.  And, as you can see, there is value
to this.  Because it attracts a certain kind of person.  I just wish
you didn't keep all the knowledge of higher order functions bottled up
in the Scheme community by making it socially unacceptable for people
with that knowledge to socialize with people from other communities
without becoming hostile and evangelistic.  (Not you personally,
necessarily, though I think your personal rhetoric does sometimes have
this effect, even though I know it's not your intent.  But I mean "you"
collectively, meaning the "Scheme establishment".)

I would liken this problem to the problem of producing equal rights
among the races or the genders.  The problem between races or genders
arises in the first place becausee people like things in black and
white (if you'll pardon the unintended pun, by which I really only
mean "binary").  They want the good guys to be recognizable quickly
from the bad guys, and what could be easier than looking at skin color
or gender?  So forgetting who caused the first order effect, the fact
is that when the move for equality happened, the oppressors were of
one race and the oppressed were of another, or the oppressors were of
one gender and the oppressed of another.  So, heh, it was easy to tell
again who the bad guys were and who the good guys were.  And the
campaign for equality was mounted..  But wonder of wonders, the
problem wasn't solved overnight and now here's the mess: people are
still sometimes oppressed and people are sometimes not.  And _neither_
the oppressed nor the oppressors are any longer recognizable simply by
their "look".  At that point, we've seen that society gets into a mess
because some people start to realize that their allies come in both
kinds but others really preferred the battle lines to be easily drawn
and continue to behave as if the other gender or race were the enemy
because it's easier, in effect repeating the underlying sin against
which they are fighting: identifying a problem on the basis of a
superficial earmark rather than on the basis of who is really causing
what.

Now, one solution to this is for CL folks to claim that Scheme is a
Lisp and to claim we all are of the same "race" or "gender" because we
have the same look.  But that's a simplistic solution because if you
_really_ want to do outreach, and not simply rail against Bad Guys and
Good Guys who can be recognized on sight by some earmark that has
nothing to do with what you were complaining about, then at some point
you have to stop labeling people by how they look and you have to start
to say that what they do matters.

I think that what we do is more complex than it looks at first
glance, and I'm really just tired of being railed at for being
automatically wrong by people not taking a deep look at it.  (Whether
that's you or not depends on what's in your heart, and I'm not
attaching any personal animosity to you--I'm asking you to
self-identify, and also to look seriously at what we do in the way
_we_ look at it, not how it looks from the outside, and say "do really
competent programmers in this language mean to say that higher order
functions are bad?" and I think the answer is no.  Do we use them as
the court of first resort?  No.  But can we quickly change things to be
fully general when needed? Certainly.  I change programming styles quickly
to accomodate a local need, and I'm quick to use higher order functions
where I think it will help.  I just don't always think it will, and if
my problems get solved without them, I don't find that a criticism of higher
order functions any more than it's a criticism of my favorite operator,
unwind-protect, that I don't use it in every case either because a lot of
the time I just don't need it.  It's there when I do need it and it makes
me feel safe.  And that's enough.)

Also,  historically and empirically, CL makes substantially more use
of higher order functions than Maclisp did because it has done the work to
make the issues of environment closure really work.  Maclisp's FUNCTION was
a joke and the *FUNCTION kludge was almost too silly for words.  CL has
cleaned up a lot of that, and CL users have embraced that.  If you look at
the first derivative and think in terms of languages that are moving toward
more users using higher order functions, we're doing just fine, thank you.
Had we made faster change, we might have sunk the language.  That could have
been because it would be hard to compile or just because it was so different
no one would have adopted it.  People take things at the rate they want to
take things.  But my point is that the _language_ is not holding anyone back.
You see before you a community which has not sought to go in your direction
as aggressively as you yourself prefer to, but for people who don't have that
as their agenda, they've done a _lot_ of stuff with higher order functions.
In that sense, again empirically, it is simply unfair to conclude that the
language works against it.

It would be an equally unfair criticism to say that Object-Oriented COBOL
works against message passing just because it retains the syntax of earlier
dialects of COBOL and doesn't throw them away for C++ or CLOS syntax.
The fact is that the user community of COBOL wouldn't likely buy that as
a continuation of COBOL, so it would be a pointless gesture to make such a
change.  Languages do what it is appropriate to do for their user base, and
again should be judged in that light.

Nor are COBOL programmer neo-luddites for not moving forward.  Their goal is
not "writing the coolest program" it's "doing accounting" or "doing some
specific business service".  Good enough is good enough.    We don't all have
the luxury to or need for rewriting our programs just to have them in some
other form.  Some of us have things to accomplish.  And that doesn't diminish
our appreciation for other tools and ideas, it just says sometimes we don't
need fancy tools.  1.6Ghz processors are cool, but there are still things I
can do on my Mac-Quadra (or even my Mac-Plus, for which Tetris comes to mind)
that are "good enough" and simply are not diminished by their lack of more
advanced programming underlying them.

> If you still don't get it,

(I still don't think I've missed anything yet, but I appreciate the multiple
renditions.)

> consider what it is like to simulate
> higher order functions using function objects in Java.  To call
> a function object f, you use a special syntax such as f.call(_)
> instead of writing f(_).  The .call can be viewed as a kind of
> cast that coerces from the value domain to the function domain.

But this isn't the worst of it.  The worst, IMO, is that you have to
build something more complex than a function [an object] in order to
get something anonymous [by destructuring the more complex function
using a method call to get the only part you wanted in the first
place] ... and you can't syntactically abstract away from it.  I have
such negative feelings about Java that it's hard for me to see through
to the minor problem you're talking about for the other major things
around it.  This piece of notation doesn't bother me per se, but the fact
that I can't abstract away from it does bother me.

> Common Lisp's FUNCALL can be viewed as a similar coercion.

Indeed it can.  Though it can be abstracted away from if that's really
a burden.

> Many of the people who are attracted to Lisp in the first place
> don't like to clutter their programs with all these injections
> and coercions from one type to another.

Yet, in total fairness, they will tolerate notation like

  (call-with-input-from-string
    (lambda (stream)
      ... stuff ...)
    string)

when

  (with-input-from-string (string stream)
    ... stuff ...)

would be simpler, not because the issue here is baggage, but because the
issue here is one of "purity" commanding a tolerance for hefty syntax.
I just don't get it how the argument switches only to the issue of
"syntax being too cumbersome" in a few cases like (funcall f ...) but
switches away from syntax being to cumbersome when the end result is
something functional.  I don't see the rule of "cumbersome syntax is bad"
being uniformly applied. Maybe again, I am missing something? ;)

> They're annoying and unnecessary.

No, they are a price some of us don't blink at paying.  You see them as
a burden because you prefer your chosen syntax, but the point is that we
are, I think, trying to discuss not "chosen syntax" but "access to higher
order functions", so if I don't see a burden in using FUNCALL, and I find
it kind of aesthetic, in what sense does my seeing something I think is
aesthetic keep me from using higher order functions?  It might keep someone
from using my language, and that's a different question, but the question is
whether my language, for the users who have chosen it, is anti-higher-order,
and I don't think you've answered that.

> If you're a first- or second-order thinker,

Which I don't think I am.  I'm quick to go meta every time it actually
seems to do something for me.

I don't tend to use meta-objects, incidentally, not because I wouldn't love
to, but because of some lingering historical prejudices that are mostly
inappropriate in this day and age.  Most people around me are smart enough
to get past this baggage that sometimes holds me back.

> then you probably won't agree with this,

Right conclusion, wrong causal relation. ;)  That is,

> and you'll be happy with a Lisp2.

I'm happy with a Lisp2 because the notation that seems to shackle you
is not an impediment to the things you imagine it would impede you
from doing.

> If you're a higher-order thinker,

(I have to say, I'm finding this just mildly insulting.)

> you'd be happier with a Lisp1 if all else were equal.

No, I wouldn't.  I've used Scheme several times for work and sometimes for
play and have been around it all my adult life.  I am never happy with it
because I just don't like the Lisp1 notation.  I find it needlessly cramping
simply to have the binding of a variable preclude my access to the same-named
function.  I find that easily as offensive and cumbersom and putoffish
as I believe you find FUNCALL.  I don't, however, make claims that the Lisp1
notation "doesn't work" for people who use it; obviously, it does.  Just as
FUNCALL works for us.  I recognize this as purely a personal choice issue in
style.  I'm just sad that you do not have a symmetric view of our world, and
a symmetric understanding that this is, really, just a matter of choice, and
not a matter of some personally-offensive claim like "if you were a higher
order thinker, you would realize you wanted my notation".  I think I know
you did not mean to say it this way, but I must repeat it back to you this
way because that's how my ears hear it and because you may find it useful
to modify your tone to make your point better to myself and others.

> It wouldn't be, of course.

By which I guess you mean, all else wouldn't be equal.  Yes, we agree on that.

Thanks for your helpful reply.  I hope I've adequately defended my position
here and that maybe you can see that it isn't as black and white as you
might believe.

First-class symbols (Re: Why is Scheme not a Lisp?) Joe Marshall 3/15/02 1:35 PM

"Erann Gat" <g...@jpl.nasa.gov> wrote in message
news:gat-1503020959160001@eglaptop.jpl.nasa.gov...

> > > In article <32251615...@naggum.net>, Erik Naggum
> <er...@naggum.net> wrote:
> >
> > The single namespace, the lack of first-class symbols, exacerbated
> > by the lack of packages, and the need for make-shift solutions to what
> > should not have been problems, are all among the things that will
> > continue to create problems.
>
> I think I really don't understand what he means by "first class symbols."
> The phrase "first-class function" usually means that functions can be
> passed as arugments and returned as values.  Scheme symbols have those
> properties as well.  So one of us is obviously missing something, and I'm
> pretty sure it's me.

While I hesitate to put words in Erik's mouth, I think that Erik is
referring
to the fact that the symbols in Scheme have very little to do with the
symbolic identifiers in the code.

In Common Lisp, when you bind a special variable, or when you define a
function, there is a both a distinguished name (the symbol) and a
distinguished location (the function or value cell) where the value
is *required* to be stored, and these are available at top level.
So if you wrote a function `foo', the compiler will arrange for that
function to be in the function cell of the symbol `foo'.

To contrast this with Scheme, the compiler arranges it so that the
identifier `foo' will recover the current value of foo, but this
has nothing to do with the symbol `foo'.  Having the symbol `foo'
won't (in general) let you modify the value or function associated
with that name.

What this means is that the process of `linking' in Common Lisp
is required to maintain its data keyed by symbols.  This gives
one an API to the link info which is very handy for debugging,
introspection, and other advanced functionality.

Note that most Scheme implementations provide some functionality
along these lines, but there is no defined standard.

data hygiene [Re: Why is Scheme not a Lisp?] Kent M Pitman 3/15/02 1:21 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> ... But Kent's right that another thing suddenly pops up:


>
> "I cannot later 'relate', at the symbol level, your person-1 with my
> person-1, without doing a global renaming."
>
> Sure, this is certainly true.  In Common Lisp, the two person-1's are
> relateble, in that each program has easy access to the other.  (And
> the package system helps make that access even easier, and well
> controlled.)
>
> Here the difference is going to just be one of style.  It's actually
> program hygene now, and making that access as easy as Kent would like
> would be *breaking* a hygene barrier.

But this means that doing the thing you can do so easily in CL with
 (make-instance 'frob 'a 3 'b 4 'fred:a 7)
is basically impossible to do in Scheme with symbols.  You _must_ use
non-symbols for the keyword markers.  And as soon as you do this, you're
not a "symbol processing language", IMO.

> I'm not here "railing" against the Common Lisp package system.  I
> think it's clearly the right thing in a language with "heavy"
> symbols--symbols that have plists and all that.  

But the Scheme symbol system is basically no more powerful than the Lisp
KEYWORD package, and there are known limits to what that can do for you.

The term 'keyword' is even used sometimes in place of 'symbol' in Scheme
bookmaking, underscoring the fact.

> Now you argue that this has made the macro system in Scheme "very
> complex", but I think that's looking at the wrong side of the
> problem.  Scheme macros, from the user's perspective, are as simple as
> can be: they reliably Just Work.

For those macros you can write at all.  What about CL's LOOP?  Can you
write that in Scheme's macro system?  Does the failure to be able to write
a certain syntactic extension count as 'just working'?

> Everytime I worry (oh, will this
> shadow something wrongs) and I bother figuring it out, I realize,
> "nope, the rules nicely make sure the Right Thing will happen".  

I never lose sleep over this particular problem. I lose more sleep
over the loss of general-purpose symbol analysis and manipulation under
full control of a Turing machine, which is what Scheme does.  If it did
give you this full control, things would not "just work", I claim. Unless
you had something else looking out for you--like our conventions for
data hygiene.

> The complexity is in the *implementation*, to preserve that quite
> simple appearance to the user.

Provided you only want to do a subset of the things with your macro system
that CL people routinely do.  (Dylan, with its hygienic system, has the
same limitations.)  I'm not saying there's not a lot you can do.  But a
general purpose turing-machine-like equivalence has yet to be drawn that
I've seen.

First-class symbols (Re: Why is Scheme not a Lisp?) Kent M Pitman 3/15/02 1:43 PM
g...@jpl.nasa.gov (Erann Gat) writes:

> No, I think I really am confused :-)  Here's the unelided sentence:
>
> * Erik:
> > The single namespace, the lack of first-class symbols, exacerbated
> > by the lack of packages, and the need for make-shift solutions to what
> > should not have been problems, are all among the things that will
> > continue to create problems.
>
> I think I really don't understand what he means by "first class symbols."
> The phrase "first-class function" usually means that functions can be
> passed as arugments and returned as values.  Scheme symbols have those
> properties as well.  So one of us is obviously missing something, and I'm
> pretty sure it's me.

For many years, up until R5RS, the syntax was not (as with CL) about
s-expressions.  It was really about open parens and whitespace and stuff.
There was no EVAL and it was possible to compile Scheme without calling
READ.  In this sense, the language was not defined on "symbols" but on
some etherial syntax that looked like the syntax for symbols.  Symbols
and lists existed as data but had no relation to the names and other
syntax things used in the language definition.

A patch was recently applied to the spec that said you can optionally
call READ and can interpret these rules to be about structure instead
of about syntax.  But that wasn't how it was for a long time.

>
> > First-class symbols in
> > specifying language semantics; certainly it has the datatype and I don't
> > think he was denying that.
>
> Could you explain what you mean by that?  I understand that CL semantics
> are specified in terms of symbols.  What I don't understand is why this is
> considered so important.  Is this really about special variables?

No.

> Because
> if it is then it seems to me that you can easily emulate special variables
> in Scheme using dynamic bind.  (I'm not saying this as Scheme propoganda.
> I'm saying this as an indication of where my understanding is at to help
> people frame a response.)
>
> > As to your point, though, Erann, the addition of first-class symbosl in the
> > language semantics is a very recent addition.  A patch because many of us
> > have complained about this for so long.  Traditionally, Scheme has not had
> > this.  Nor has it had EVAL.
>
> R4RS had symbols so they go back at least to 1991.  I can't find an online
> copy of RNRS for N<4 so I don't know if they go back any further than
> that.

It's not about the having or not having of a symbol datatype.  It's
about names in the language not being symbols because nothing in the
language said that consed structure was even in play when applying
language semantics, however similar data may have been to such consed
structure.

Why is Scheme not a Lisp? Christopher Browne 3/15/02 1:56 PM
Centuries ago, Nostradamus foresaw when Kent M Pitman <pit...@world.std.com> would write:
> ces...@qnci.net (William D Clinger) writes:
> No, I wouldn't.  I've used Scheme several times for work and
> sometimes for play and have been around it all my adult life.  I am
> never happy with it because I just don't like the Lisp1 notation.  I
> find it needlessly cramping simply to have the binding of a variable
> preclude my access to the same-named function.  I find that easily
> as offensive and cumbersom and putoffish as I believe you find
> FUNCALL.

It's certainly a disputable matter whether or not it's a truly
_fundamental_ problem that it's bad that, in Scheme, you can't do

(define foo (lambda (list prefix-fun)
   (add-prefix-fun-to-each-element)))

I don't think it's vastly unfair to compare this to the PL/1 sort of
thing of:

   IF IF = 5 THEN
     LET LET = 7
   ENDIF

[That might not quite be legitimate PL/1; hopefully the namespace
"collisions" are obvious enough :-).]

In contrast, it's kind of irritating that Common Lisp prevents me from
writing:

  (defun c2f (t)
     "Convert Celcius temperature to Fahrenheit"
     (+ 32 (* 9/5 t)))

It is kind of nice to be able to use LIST as a variable name in CL,
but that strikes me as being about as important as the fact that new
macro schemes for Scheme keep making it pretty easy to redefine IF.
(I haven't much call for redefining IF, as the existing one works
_perfectly well_.  That's one of the irritations of Alternative Macro
Systems; they almost always focus on reimplementing something that
already works well...)
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://www3.sympatico.ca/cbbrowne/linux.html
You will pay for your sins.  If you have already paid, please disregard
this message.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Lieven Marchand 3/15/02 9:00 AM
ds...@goldshoe.gte.com (Dorai Sitaram) writes:
> and while I did mention "load" which I think is file-specific
> even in CL

LOAD can take a stream as argument.

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

Why is Scheme not a Lisp? Erik Naggum 3/15/02 2:07 PM
* Kent M Pitman
> Hygenic macros solve a problem that CL does not have.  (They solve a
> problem introduced by Lisp1-ness. Heh.)  I see no need for these
> whatsoever.

* Bruce Lewis
| You never need to use gensym when writing CL macros?

  Please realize the difference between a requirement and a choice.

| Non-hygienic macros are definitely useful, but this bashing of hygienic
| macros doesn't seem right.

  It would not have been right in comp.lang.scheme.  You are not in
  comp.lang.scheme.  Over here, the obsessived-compulsive drive for
  "hygiene" is basically the object of some ridicule.  People who scrub
  (like doctors) before they eat, after they have been in touch with
  potentially disease-carrying materials (bonus points for overstating the
  potential), and, say, before touching anything valuable, like a book or a
  keyboard, may find like-minded people who consider this proper behavior,
  but they should also prepare themselves to have their views rejected by
  other people in sometimes hostile and sometimes derogatory ways.

  If you want some of the worst design decisions in Scheme to be protected
  from ridicule, choose comp.lang.scheme.  If you consider the derogatory
  implication of calling Scheme macros "hygienic" (which is just as snotty
  as we expect from the Scheme community), some ridicule back at a language
  that needs them because it dirties _itself_ should be par for the course.
  It is not Common Lisp that dirties itself and "lacks hygiene", it is what
  Scheme would do.  However, it is fairly obvious that the choice of the
  word "hygiene" is intended to communicate a superiority and instead of
  calling Common Lisp macros just "macros", they become "non-hygienic".
  What the hell is _that_?  Scheme freaks who hijack the premise for a
  discussion like that are bad people in my book.  Duane Rettig made a
  similar point about "proper tail recusion", which I chuckled when
  reading, because I had been taken in by the "improper" tail recursion
  that would be found in every other language.  Scheme is chock full of
  snotty terminology like that and it is, frankly, really, really annoying.

  I have read some of the most ludicrous nonsense about Common Lisp macros
  in comp.lang.scheme, where the common perception seemed to be that Common
  Lisp dirties itself _exactly_ the same way Scheme does, and it seems that
  Scheme freaks generally tend to think Common Lisp is nothing more than a
  variant of Scheme, that all the choices made by Scheme are also made by
  Common Lisp, except the ones that Common Lisp "missed" and that Common
  Lisp therefore sucks.  However, this is the problem with Scheme freaks
  when they wander outside their little playpen -- they do not _know_ that
  their terminology is Scheme-specific, they do not _know_ that they have
  made a huge number of design decisions that are different from other
  members of the Lisp family, and yet they have the _gall_ to parade their
  arrogant ignorance outside their chosen forum, huffing and puffing like
  some mighty little dragon.  _This_ is what has caused me to regard Scheme
  as an inferior language with inferior people in its community for so
  long, since no sane person would have to engage in such tactics to feel
  good about themselves and what they do.  "Look, I'm hygienic and you're
  not, and I'm proper and you're not" is not particularly mature rhetoric,
  but it _is_ a pretty good marketing strategy for something that is in
  need of such rhetoric.  But then the Scheme freaks want to pretend that
  what they do is _technical_ and _not_ political.  That is when the sheer
  dishonesty becomes a little too much to bear for non-fans of Scheme.
 
///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Dorai Sitaram 3/15/02 2:13 PM
In article <uy9gtl...@theworld.com>,

Christopher C. Stacy <cst...@theworld.com> wrote:
>
>
>No, he's saying his robot doorbell has a Lisp runtime system
>that is capable of running Lisp programs downloaded into it.
>
>The same thing is true in C: there is a C runtime system in the robot
>or credit-card terminal, and it probably does not include printf.
>

OK, I'm happy to withdraw my s-exp-aware I/O
requirement for a language to be a Lisp.  

--d

data hygiene [Re: Why is Scheme not a Lisp?] Rahul Jain 3/15/02 2:31 PM
Bruce Lewis <brl...@yahoo.com> writes:


> You can always pass something like this:
>   (list kent 'person-1 rahul 'person-1)
> where kent and rahul are hash tables, assoc lists, closures or
> something.

So instead of having proper namespaces for symbols in the first place,
we should pass around the namespace as an extra arg for everything
that MIGHT require a symbol argument?

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

First-class symbols (Re: Why is Scheme not a Lisp?) Erik Naggum 3/15/02 2:51 PM
* Erann Gat

| I think I really don't understand what he means by "first class symbols."
| The phrase "first-class function" usually means that functions can be
| passed as arugments and returned as values.  Scheme symbols have those
| properties as well.  So one of us is obviously missing something, and I'm
| pretty sure it's me.

  But what can you do with a symbol in Scheme?  Can you read and write its
  value?  At least you can call a (first-class) function that has been
  pased to you.  Can you call a symbol in Scheme if its global value is a
  function?  If symbols are _only_ interned constant strings, I do not see
  the value of calling them "symbols" in the Lisp sense of the word.  This
  is one of the cost of flirting too much with the Algol family.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Bruce Hoult 3/15/02 3:50 PM
In article <sfw1yel...@shell01.TheWorld.com>,

 Kent M Pitman <pit...@world.std.com> wrote:

> > Now you argue that this has made the macro system in Scheme "very
> > complex", but I think that's looking at the wrong side of the
> > problem.  Scheme macros, from the user's perspective, are as simple as
> > can be: they reliably Just Work.
>
> For those macros you can write at all.  What about CL's LOOP?  Can you
> write that in Scheme's macro system?  Does the failure to be able to write
> a certain syntactic extension count as 'just working'?
>
> [...]

>
> Provided you only want to do a subset of the things with your macro system
> that CL people routinely do.  (Dylan, with its hygienic system, has the
> same limitations.)

When I read the first para above I wasn't sure whether you intended to
lump Dylan with Scheme.  I'm not up on the latest Scheme macro systems,
but at least in Dylan the macro system is powerful enough to implement
LOOP.  Not only that, but it's part of the standard library.


> I'm not saying there's not a lot you can do.  But a general purpose
> turing-machine-like equivalence has yet to be drawn that I've seen.

Dylan macros are Turing-equivalent, although I think you'd be nuts to do
anything that made use of that fact.

To my mind, macros are for providing nice syntax for things that you
find you want to do frequently but that would be tedious to type or ugly
to read.  Making simple examples of tail recursion look like iteration
does in other languages, for example.  Or hiding ugliness such as the
way you can use anonymous clases to implement anonymous functions in
Java -- which I think you said earlier today would be reasonably
acceptable if you could hide it in a macro.

-- Bruce

First-class symbols (Re: Why is Scheme not a Lisp?) Erann Gat 3/15/02 4:03 PM
In article <sfwn0x9...@shell01.TheWorld.com>, Kent M Pitman
<pit...@world.std.com> wrote:

> For many years, up until R5RS, the syntax was not (as with CL) about
> s-expressions.  It was really about open parens and whitespace and stuff.
> There was no EVAL and it was possible to compile Scheme without calling
> READ.  In this sense, the language was not defined on "symbols" but on
> some etherial syntax that looked like the syntax for symbols.  Symbols
> and lists existed as data but had no relation to the names and other
> syntax things used in the language definition.

OK.  But I still don't see why this should be such a big deal.  Common
Lisp syntax always denotes data, and has rules for interpreting certain
kinds of data as code.  Scheme has one syntax for programs, and another
syntax for data, and the syntax for programs just happens to be a subset
of the syntax for data.  The difference to me seems purely rhetorical.  At
the end of the day I can call READ to translate character sequences into
data, and LOAD to translate those same character sequences into code.  (In
fact, I can write EVAL in R4RS Scheme in terms of PRINT and LOAD.)  And
the whole issue, which never seemed to me (even ten years ago) like an
issue to begin with, is now rendered doubly moot by the addition of EVAL
to Scheme.

In other words, what is it you want to do that the "lack of first class
symbols" (whatever that means) prevents you from doing?

> > Is this really about special variables?
>
> No.

...

> It's not about the having or not having of a symbol datatype.  It's
> about names in the language not being symbols because nothing in the
> language said that consed structure was even in play when applying
> language semantics, however similar data may have been to such consed
> structure.

So I still don't see why this should be important except rhetorically.
Why does it matter if the interpretation of "((lambda (x) (foo x)) (zot))"
is given in terms of symbols or not as long as the net result is the same
in both cases?

The only *real* difference I can think of is that in CL one can do
something like (symbol-value (intern (read))), in other words, computing
the dynamically bound value of a symbol whose identity is not known at
compile time.  (If you know the value of the symbol at compile time then
(symbol-value 'X) is just X.)  Before R5RS this did not have a
straightforward Scheme equivalent.  (Now it's just (eval (string->symbol
(read)) (interaction-environment)).)  That's why I asked if this was
"really about special variables."  Since the answer to that is no I think
I'm still missing something.

E.

First-class symbols (Re: Why is Scheme not a Lisp?) Erann Gat 3/15/02 4:45 PM
In article <32252215...@naggum.net>, Erik Naggum <er...@naggum.net> wrote:

> * Erann Gat
> | I think I really don't understand what he means by "first class symbols."
> | The phrase "first-class function" usually means that functions can be
> | passed as arugments and returned as values.  Scheme symbols have those
> | properties as well.  So one of us is obviously missing something, and I'm
> | pretty sure it's me.
>
>   But what can you do with a symbol in Scheme?  Can you read and write its
>   value?

Yes:

(symbol-value x) == (eval x (interaction-environment))
(set x v) == (eval `(set! ,x value) (interaction-environment))

>   Can you call a symbol in Scheme if its global value is a function?

Yes:

((eval f (interaction-environment)) arg1 arg2 ...)

or

(define (function f) (eval f (interaction-environment)))
((function f) ...)

Note that in the most common case where the identity of f is known at
compile time this becomes simply (f arg1 arg2 ...).

You can even do:

(define (funcall f . args)
  (cond ((symbol? f) (apply (eval f (interaction-environment)) args))
        ((procedure? f) (apply f args))
        ((vector? f) (apply vector-ref f args))       ;-)
        ((and (cons? f) (eq (car f) 'lambda)) ...)
        ...
        (else ... ) ; error - f is not callable

> If symbols are _only_ interned constant strings, I do not see
> the value of calling them "symbols" in the Lisp sense of the word.

So this is what I am struggling to understand.  I have always thought that
interned-constant-string is the "essence of symbolness".  Whether symbols
are mapped to values by having those values be "part of" the symbol as in
CL, or through a separate environment object as in Scheme, seems to me at
least on a practical level to be a relatively minor detail.

What do you see as the value (in the economic sense) of a symbol in the
Lisp sense of the word?  What can you do with a Lisp symbol that you can't
do with a Scheme symbol?  The only thing I can think of, even in pre-R5RS
scheme, is computing the dynamic binding of a symbol whose identity is not
known until run time.

E.

data hygiene [Re: Why is Scheme not a Lisp?] Kent M Pitman 3/15/02 5:20 PM
Bruce Lewis <brl...@yahoo.com> writes:

> Kent M Pitman <pit...@world.std.com> writes:
>
> > I cannot in Scheme construct the notion of passing
> >  '(kent:person-1 rahul:person-1)
> >
> > Or if I do, then KENT:PERSON-1 is a symbol with a 13-letter name and the
> > functions that do the accessing have to first decode it to find a hidden
> > symbol PERSON-1 within it and also a function or table that corresponds
> > to Kent's NAME operation/resource.  
>
> I think you're making too much of this.
>
> You can always pass something like this:
>   (list kent 'person-1 rahul 'person-1)
> where kent and rahul are hash tables, assoc lists, closures or
> something.

But then I'm not using symbols as my basic guide word.  In MAKE-INSTANCE,
for example, the convention is

  (make-instance <class> key1 value1 key2 value2 ...)

Now it either _is_ or _is not_ "good enough" to have keys be symbols.  
In CL it _is_ "good enough" because even a class made from two classes
made by different people who both want a SIZE keyword (e.g., it's both
a physical-object with width 19 (inches) and a screen-object with width
1024 (pixels) can be accomodated if they choose initargs of
  'physob:width 19 'drawing-area:width 1024
and moreover this can be done in a way such that within each of those
packages it isn't cumbersome because they just use
  'width 19
in the scope of their own little domains where they are not mixed together.
But to do (defclass the-big-picture (physob:monitor drawing-area:screen) ...)
would be a disaster if you're using symbols as the markers.  Yes, you
could say the whole make-instance protocol needs to be
  (make-instance thing '(drawing-area screen) 19 '(drawing-area width) 1024)
but in addition to just plain looking bad, you have slowed things down by
requiring an equal comparison instead of an eq comparison, and have introduced
the need to error check that I didn't do '(drawing-area screen ham-sandwich).

What Scheme does is not what you suggest but rather to define some

 (define-key width)
to expand to
 (define width (make-key 'width))
so that you do:
 (make-instance monitor width 19)
in the physob 'module' or
 (make-instance drawing-area width 1024)
in the drawing-area 'module' since you'll have done separate define-key
operations in both of those modules and you won't be colliding.  This means
if you want to mix these things you have to do
 (define drawing-area-width (value-from-environment 'width
                              drawing-area-environment))
 (define physob-width (value-from-environment 'width physob-environment))
and then you do
 (make-instance the-big-picture monitor-width 19 drawing-area-width 1024)
but the important thing to understand when you are all done with all this
hair is that you are not using symbols to guide you, but you have substituted
objects that are non-symbols to use as guides because symbols (as defined in
Scheme) don't compare well with EQ (a shared INTERN makes it too easy for them
to clash) and other objects do (because other objects are not interned).
So Scheme has made 'intern' a hindrance in certain cases, not a help.

> Or you could define some global lookup table for 'kent and 'rahul, and
> just pass '((kent person-1) (rahul person-1)).  I don't see any major
> design flaw here.

Bleah.  So in Macsyma internals instead of:

 ((macsyma:mplus macsyma:simp) macsyma-user:$X 3)

I would write:

 (((macsyma mplus) (macsyma simp)) (macsyma-user $X) 3)

Forgive me if I'm already using s-expression for some other purpose than
what you've devised and if this causes me _substantial_ difficulty.

The whole point of symbols is to attach meaning to, but by interning all
symbols in the same package, that is, by not having a package system,  you've
robbed me of that.

> Do you really think packages and property lists are prereqs for a
> symbolic processing language?

That's not how I would have expressed the problem, but if push comes to
shove... yes.

The problem is that what you're saying is that an atom, to use it in the
original sense of the word, "an atomic unit of meaning", is really not
atomic.  

Java has symbols in the sense that Scheme does.  It calls them
canonical strings.  I want more of symbols than that.  Java is not a symbol
processing language.

Why is Scheme not a Lisp? Erik Naggum 3/15/02 6:18 PM
* William D Clinger
| Yes, you are.  I was talking about the fact that the defining feature of

| Lisp2, separate environments for values and for functions, creates a bias
| against higher-order thinking.

  No, it does not.  This is completely bogus reasoning.  And if it is your
  gripe with funcall, which seems to be a standard problem for Scheme
  freaks, even though they have _apply_ just as Common Lisp does, I have
  posted a macro called "with-functions" that effectively removes the
  funcall from sight and declares the variables as functions.  This should
  shift the bias back in the favor of "higher-order thinking".  That macro
  took me seven minutes to write, debug, and test (,', always confuses me).
  The distance between a Common Lisp and "higher-order thinking" is thus
  seven minutes of my time, and a google search and cut-and-paste for you.
  Please quit griping about this non-existing problem.

| In Lisp2, functions are usually bound in a different environment from
| other values, so Lisp2 programmers do not think of functions simply as
| values.

  This sounds totally bogus.  It certainly does not follow from the premise.

| Thus, for example, you can find examples of Common Lisp programmers who
| do not see the need for hygienic macros, claiming that function names
| cannot be shadowed.
 
  You can find examples of absolutely anything, and if you include jails
  and mental hospitals, even more, so this must be the weakest of all
  possible ways to express a criticism.

  It probably surprises you to learn that symbols in the common-lisp
  package cannot be defined or bound in a conforming program, so it is
  actually _true_ that "function names cannot be shadowed" (which is a very
  strange way of saying it. but I can sort of reverse-engineer the proper
  meaning from it).  At least a macro can expect the standard environment
  to apply, and I believe macros should do just that, and if they require
  additional environments, they should use symbols in a package over which
  the macro author has control.

  Because of packages and the restrictions on using symbols in the
  common-lisp package, there is no need to ensure that you have the right
  definition of any symbol in the common-lisp package with a function
  definition.  This, if you bind a variable "list" in Scheme, you have
  clobbered the standard function "list" for the body of the form that
  binds it, but if you try to name a local function "list" in Common Lisp,
  you already have an error in your program, one that a compiler should be
  reporting to you.

| Are they unaware of FLET and LABELS?  Probably not.  Probably they're


| just aware that FLET and LABELS are so seldom used as not to cause a
| problem for macro writers.

  Are you unaware of the restrictions on symbols in the Common Lisp
  package?  If you are, please see ANSI X3.226-1994 11.1.2.1.2.

| Why aren't FLET and LABELS used?  There are many reasons, but one is the


| cultural bias against higher-order thinking that results from a Lisp2.

  Nonense.  It does not result from a Lisp-2 at all.  That is just a stupid
  argument that Scheme freaks like to offer, and it is so goddamn _stale_.

| If you still don't get it, consider what it is like to simulate higher


| order functions using function objects in Java.  To call a function
| object f, you use a special syntax such as f.call(_) instead of writing
| f(_).  The .call can be viewed as a kind of cast that coerces from the
| value domain to the function domain.  Common Lisp's FUNCALL can be viewed
| as a similar coercion.

  HELLO!?  I PUBLISHED A MACRO THAT REMOVED FUNCALL FROM VIEW SO THAT YOU
  FUCKING OBNOXIOUS SCHEME FREAKS NO LONGER HAVE ANYTHING TO WHINE ABOUT!
  YOU MORONS HAVE SPENT *YEARS* WHINING ABOUT THIS, YET IT TOOK ME NO MORE
  THAN SEVEN MINUTES TO GET RID OF IT AND CONFLATE THE NAMESPACES FOR A
  SPECIFIC LIST OF VARIABLE NAMES.  What does this show, _other_ than that
  Scheme freaks are _much_ more interested knocking and denigrating Common
  Lisp than doing anything useful and constructive?

  If you still do not get it, figure out that Common Lisp has the power and
  capacity to change its syntax so it can accomodate such perversely anal-
  retentive needs as removing an operator from sight (even though you
  _still_ need apply).

| Many of the people who are attracted to Lisp in the first place don't
| like to clutter their programs with all these injections and coercions
| from one type to another.

  If they had anything approaching a usable intelligence, they would figure
  out how to write the macro I wrote, and I did not even have a problem
  with funcall to begin with, I was just so goddamn tired of the useless,
  incompetent whining from people who were so clueless they could not even
  write a little macro to get what they wanted.

| They're annoying and unnecessary.

  No, this is a conclusion about Common Lisp drawn from Scheme premises.
  Common Lisp is not a dialect of Scheme.  This is _precisely_ what this is
  all about.  You Scheme freaks are so full of yourself that you cannot
  even see that other people are _able_ to make other design choices than
  you have.  You think everything other people do is _wrong_, do you not?
  Some of you guys sure act like you have a one-bit right/wrong flag, and
  of course you do nothing wrong, so therefore what other people do must be
  _wrong_, since it is not what you do, and what you do is _right_.

  Common Lisp programmers do not regard this the same way you do.  _If_
  they do, they write something like the macro I wrote.  There _is_ no
  problem to a Common Lisp programmer -- a beginner would ask if it could
  be fixed and an experienced Common Lisp programmer would just do it.  It
  is _only_ a problem to Scheme freaks who have a grudge against Common
  Lisp and want to confirm their delusions of superiority to themselves.

| If you're a first- or second-order thinker, then you probably won't agree
| with this, and you'll be happy with a Lisp2.  If you're a higher-order
| thinker, you'd be happier with a Lisp1 if all else were equal.

  Lisp-1 and Lisp-2 have nothing whatsoever to do with this issue.  Even
  funcall is a non-issue.  What matters is probably what Kent Pitman has
  been hinting at: People who want a one-bit universe where purity and
  elegance and such follow very simple rules are much more attracted to
  functional programming languages _and_ Lisp-1.  You have the causality
  all wrong, here, and this is quite obvious: People are not _naturally_
  "higher-order thinkers", but there is much evidence to support a view
  that some people have a hard time dealing with "horizontal complexity"
  and much prefer "vertical complexity" on very small initial space.  These
  two types are fairly incompatible.  A vertical complexity guy will look
  at a horizontal complexity guy and think he is not superskilled in
  anything and therefore untrustworthy and useless (many academics fall
  into this trap), whereas a horizontal complexity guy who meets a vertical
  complexity will be stunned how little he knows about the world about some
  corner of which he has this astonishing amount of knowledge.

  Now, the most interesting thing happens is when they meet one of their
  own type: A vertical complexity guy will trust another and defer
  authority to him automatically in his "area", thinking (1) that he, too,
  has spent a lifetime in some incredibly small area, and (2) that you
  cannot go wrong if you study something long enough, especially not if
  some accredited university has granted him a degree.  However, those who
  master horizontal complexity much more easily, generally display an
  amazing amount of insight and knowledge in many areas, draw analogies
  from all kinds of areas, and they can communicate with others who master
  horizontal complexity with ease and can understand, not trust, those who
  have more knowledge in one area than another, because their knowledge is
  integrated into a system intended to mirror the world they experience.
  The vertical complexity guys have built their "system" from axioms and
  theorems that others have provided, before they may be able to provide
  their own deep insight into something that requires extremely specialized
  skills to appreciate.

  I suspect that functional programming (and Scheme) appeals to those who
  find that they master vertical complexity more easily and dynamic
  programming (and Common Lisp) appeals to those who find that they master
  horizontal complexity more easily.  However, this is _NOT_ (repeat: NOT)
  a one-bit flag in your personality.  But, *sigh*, what's the use?
  One-bit people are going to respond as if it is, as I have I created but
  two pigeonholes and want to stuff all of mankind into one of them, anyway.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Kent M Pitman 3/15/02 6:35 PM
Christopher Browne <cbbr...@acm.org> writes:

> In contrast, it's kind of irritating that Common Lisp prevents me from
> writing:
>
>   (defun c2f (t)
>      "Convert Celcius temperature to Fahrenheit"
>      (+ 32 (* 9/5 t)))

No, it doesn't.  You can just do

 (defpackage temperature
   (:use "CL")
   (:shadow "T"))

 (in-package "TEMPERATURE")

 (defconstant true 'cl:t)

and you're all set.
 
Exactly because CL has packages, it's easy to redefine even reserved words.

> It is kind of nice to be able to use LIST as a variable name in CL,
> but that strikes me as being about as important as the fact that new
> macro schemes for Scheme keep making it pretty easy to redefine IF.
> (I haven't much call for redefining IF, as the existing one works
> _perfectly well_.  That's one of the irritations of Alternative Macro
> Systems; they almost always focus on reimplementing something that
> already works well...)

I have a lot of call for both LIST as a function and LIST as a variable.
I don't like making the decision about what every detail of the body of a
function will look like when I've barely typed "(defun foo (list".

Why is Scheme not a Lisp? Erik Naggum 3/15/02 6:59 PM
* Thomas Bushnell, BSG
| But then that means that CL macros are not hygenic, because FLET captures
| bindings in exactly the ways that are the point behind hygenic macros.
|
| Erik said if you separate function and variable namespaces, then you
| don't need hygenic macros.

  No, I said quite a bit more than that.  Separating function and variable
  values is a necessary condition, not a sufficient condition to not need
  hygienic macros.  Please return to the textbooks of whatever introductory
  course at your university or high school deals with argumentation and
  logic and LOOK UP THE DIFFERENCE BETWEEN NECESSARY AND SUFFICIENT,
  because you have truly not understood this and repeatedly make the
  mistake of conflating them.

  I recommend a book I came across by accident 12 years ago: The Art of
  Reasoning by David Kelley.  I have the first hardcover edition from 1988,
  but I see there is a third edition out in paperback:

http://www.amazon.com/exec/obidos/ASIN/0393972135

  There are probably lots and lots of books about thinking, but most of
  them seem to start with the assumption that you cannot think and thus
  have to learn it.  This book starts with assumption that you can think,
  you only need to train yourself and stay away from the mistakes.
  Thinking is an acquired skill, but most people have somehow gotten by.
  There is some value to not ignoring that fact.  However, many academics
  seem to have lost the ability to think clearly somewhere on the way to
  become extremely specialized in some arbitrarily complex field and they
  have certainly been rewarded with a highly characterized version of real
  thinking skills that is more about not feeling than about thinking.

| That's true only because
|
| 1) Global definitions are almost always functions.
| 2) Global data definitions have special names, by convention , and
|    people never shadow those.
| 3) People don't make local bindings in the function namespace.
|
| It's right that Lisp2 doesn't force you to follow those rules, but if you
| don't follow them, then you can't claim that CL macros are hygenic.

  Excuse me for knowing the Common Lisp language so well that I tend to
  forget that there are people out there with a strong desire _not_ to
  learn it before they shoot their mouths off.  Now is a good tiem for you
  to wonder what it means that I also talked about packages and try to
  figure out what a Common Lisp programmer must know in order to use his
  language.  In particular, a Common Lisp programmer has either read and
  understood 11.1.2.1.2 in the standard, or he has an implementation of
  Common Lisp (or a teacher) that enforces it.  In either case, he learns
  that he can trust that if he sees a function call to common-lisp:car, he
  _knows_ what it will do, with absolute certainty -- no need to check the
  lexical environment, no need to afraid someone clobbered it, no need to
  scrub off the non-hygienic crap that Scheme accretes because it has no
  package concept _and_ no distinction between functional and variable
  values so all the good variables names are taken.

  The reason Scheme needs hygienic macros is the same as the reason Scheme
  programmers do not call their arguments "list", but "lst".  We do not
  have _that_ problem in Common Lisp, either.  In short, Common Lisp is
  already a clean language, it does not need hygiene to clean up after its
  design decisions.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erik Naggum 3/15/02 7:09 PM
* Christopher Browne
| With ACL, I am led to believe that if you leave EVAL 'turned on' in a
| deployed system, you may find you need to pay some _ferocious_ licensing
| fees.

  That would be compile, not eval.  Please do not post beliefs when it
  takes less effort to check than to correct.

  The premise for your article gone, the whole point vanishes.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erik Naggum 3/15/02 7:12 PM
* Kent M Pitman
| Perhaps the plain fact that it's more important that they feel themselves
| technically right than that they win friends?

  Hey, something wrong with that?

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Discussions, was Re: Why is Scheme not a Lisp? Erik Naggum 3/15/02 7:24 PM
* Rolf Mach <rm...@xanalys.com>
| __________________________________________________________________________________________
|
| XANALYS  -  www.xanalys.com
|
| Data Analysis and Lisp Development Tools
| Software zur Datenanalyse und Lisp Entwicklungsumgebungen
| __________________________________________________________________________________________
|
| Rolf Mach
| Business Development & Sales Manager, Europe
|
| An der Schaafhansenwiese 6
| D-65428 Ruesselsheim, Germany
| Phone ++49 +6142 938197
| Fax ++49 +6142 938199
| rm...@xanalys.com
| __________________________________________________________________________________________
|
| Watson  -  PowerCase  -  Quenza  -  LispWorks

  Oh, great, another thread of huffing and puffing moralists on a mission.

  Stefan, this is what happens when you post such messages.  Jerks who have
  no moral fiber of their own but are outraged by the immorality they see
  in others _always_ come crawling out of the woodwork when someone posts
  such off-topic messages as you do.  Again, please try to understand why
  it is an exceptionally bad idea to PUBLICLY POST a request for _others_
  to use private communication.  Rolf Mach does not _understand_ your point
  even though he "completely agrees" with you.  I mean, just how stupid can
  you get?  This is because there is always something wrong with _other_
  people in the eyes of moralistic retards like that.  Intellectual
  dishonesty at it worst is displayed in people who fail so utterly to
  grasp the message but you suddenly feel righeous about their anger.

  So, AVOID THE GERMAN XANALYS OFFICE!  They hire _managers_ who have no
  idea when it is a good idea to be an official spokesperson for their
  company and when they have a typical Southern German _personal_ opinion.
  God knows what they will do if they do not "like" the software you make.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/15/02 8:05 PM
* Thomas Bushnell, BSG
| Data-hygene would be important if symbols in Scheme had all the features
| that they do in Common Lisp.

  I think you trivialize a very good article to the point of unspeakable
  rudeness.  Try to understand the point that Scheme is actually lacking an
  important feature, and that it just lost a serious claim to "Lispness" by
  virtue of a design decision that goes all the way back to Algol, and not
  at all to Lisp.

  Perhaps it can be said as imply as this:  In the Algol family, the symbol
  table is a compiler construction.  In the Lisp family, the symbol table
  is a run-time resource.  In this sense, Scheme is a member of the Algol
  family and not a member of the Lisp family.

  The problem is not that data-hygiene would be important, it is that
  data-hygiene _is_ important and Scheme does not support it, while it
  makes a terrible stink about program-hygiene.  Where does all this "code
  is data" propaganda go when you so strongly favor one at the expense of
  the other?  It suddenly sounds hollow for Scheme.

| That is, from the Scheme perspective, we're dealing with global variables
| here, and We Don't Like Global Variables.  Or at least, that's the point.

  What a silly position to take.

| Now you argue that this has made the macro system in Scheme "very
| complex", but I think that's looking at the wrong side of the problem.

  wrong = non-Scheme.  How typical!  How unwilling to understand and think.

| Scheme macros, from the user's perspective, are as simple as can be: they
| reliably Just Work.  Everytime I worry (oh, will this shadow something

| wrongs) and I bother figuring it out, I realize, "nope, the rules nicely
| make sure the Right Thing will happen".

  A person who always agrees with those in power is free in any political
  system, even a dictatorship.  Common Lisp tries to accomodate people who
  do not always agree on everything, only on a small set of things that
  enable people to be free even when they disagree violently about other
  things.  Scheme freaks tend to regard my desire to keep comp.lang.lisp a
  place where we agree on a small number of things that enable a large
  degree of freedom, as the kind of dictatorship _they_ live in, where so
  much is dictated to be The Right Thing that only those who agree with all
  of it are free.  But Common Lisp is a different political animal -- it is
  a working political compromise formed in order to get something done and
  to enable people to do unexpectedly complex and interesting things --
  such as Artificial Intelligence.  Scheme is about doing One Right Thing,
  whatever that might be -- I do not care to find out.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Pierpaolo BERNARDI 3/15/02 8:12 PM

"Erik Naggum" <er...@naggum.net> ha scritto nel messaggio
news:3225237002391622@naggum.net...

> * Christopher Browne
> | With ACL, I am led to believe that if you leave EVAL 'turned on' in a
> | deployed system, you may find you need to pay some _ferocious_ licensing
> | fees.
>
>   That would be compile, not eval.  Please do not post beliefs when it
>   takes less effort to check than to correct.

Uh?  Obtaining any information from Franz regarding prices
is so hard that I recently gave up after 15 days that I was trying
to buy their compiler.

Or, do you know a better way for checking this than asking them?

P.

Why is Scheme not a Lisp? William D Clinger 3/15/02 9:49 PM
Bruce Lewis wrote:
> Functions that manipulate other data types are first-order functions.
> Functions that manipulate first-order functions are second-order
> functions.  Am I using your terminology?

Yes.

> Absent definition, "higher order thinking" just sounds like "superior
> thinking," making your post even more inflammatory.

Sorry.  It's a compliment when we say someone is a thinker of the first
order, so the pun that I had in my head as I was writing that is that
"first order thinking" would be identified with "superior thinking",
"second order thinking" would be the next best thing, and "higher order
thinking" would be arbitarily worse.

I prefer that interpretation to the inflammatory one.

Will

First-class symbols (Re: Why is Scheme not a Lisp?) Rahul Jain 3/15/02 11:19 PM
g...@jpl.nasa.gov (Erann Gat) writes:

> What do you see as the value (in the economic sense) of a symbol in the
> Lisp sense of the word?  What can you do with a Lisp symbol that you can't
> do with a Scheme symbol?

True symbolic processing with multiple applications working on the same data.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? William D Clinger 3/15/02 11:20 PM
Kent M Pitman wrote:
> This is a nice succinct example of where we take a different view on
> the same data.  I perceive that you think writing #'foo is somehow a
> negativity because you don't what to write it.  I think what you don't
> see is that I don't have any negative take on the writing of #'foo and
> so I am not negatively biased away from using it.

Yes.  What I said was misleading here.  It's not that having to write
#'foo instead of foo is a burden, it's that the explicit coercion from
function to value, if you will, induces a subtle psychological set that
functions are not values, or at least not like other values.

> You will not cause a change in the language this way.

I'm not trying to change Common Lisp.  (I did try once upon a time,
and that was enough for one lifetime.)

> > In Lisp2, functions are usually bound in a different environment
> > from other values, so Lisp2 programmers do not think of
> > functions simply as values.
>
> This is surely isn't true of me.

Sorry.  This is the broad brush for which Bruce Lewis rightly criticized
my post.  What I meant is that the defining characteristic of a Lisp2
tends to nudge the thinking of Lisp2 programmers in the direction of
not thinking of functions simply as values.  I'm glad you have not been
susceptible to this.

You very likely disagree with the suitably qualified version of what
I was trying to say, but I hope you understand what I was trying to
say.

> Function names cannot be _unpreventably_ shadowed.  Both CL and Scheme
> allow the writing of buggy code, of course.  

Sure, but we were talking about this with regard to hygienic macros,
which make it impossible to hide the function name from the macros that
use it.  This does eliminate certain classes of bugs.  Not all classes
of bugs.

I think your point is that packages provide the same hygiene when used
properly.

>  (b) if a programmer shadows another's names, they are declaring themselves
>      implementor of that other programmer's code.  This is bad style, IMO,
>      and in general should never be done in well-styled code....

I think the problems of this sort tend to arise when using a macro
written by someone else that introduces local bindings into your
code of which you are not aware, and don't really want to be aware.
You may say that is bad style, but then certain kinds of macros,
e.g. Scheme's CASE, become harder to write.  I would guess that
the standard technique for CL macros is to gensym the introduced
names.

> I don't disagree with this analysis of Scheme, though I think Scheme
> has done a disservice to others elsewhere by teaching its benefits as
> a contrast to the way others do things, rather than acknowledging
> other legitimate systems where higher order function are available.

Well, it isn't Scheme that has done this, but perhaps individual
instructors who use Scheme.  I don't think you're talking about me
here, for example.

> People come out of Lisp courses thinking it is a lemma that we don't
> have higher order functions that work, and so do not stop to examine
> that perhaps this is false.

It seems to me that almost all currently popular languages in the
Lisp family have higher order functions, so it would be a shame if
instructors are giving the impression that they don't.  I was not
aware that this is a problem.  I suspect that instructors who use
Scheme are pretty good about giving the impression that Scheme has
higher order functions.

> You're certainly right that people who teach higher order functions
> tend to come from a Scheme background, but this is not a technical
> issue, it's an issue of historical preference ...

This was getting close to the heart of what I was trying to say.  I
agree that instructors with a Scheme background are more likely to
teach higher order functions, but I was stating my belief that the
cause of this lies in historical events of 27 to 15 years ago.  Not
only was Scheme one of the first languages in the Lisp family to
support higher order functions in the sense that we understand them
today (lexical scope and all that), but as a Lisp1 it named functions
the same way it named all values.  Furthermore Common Lisp probably
would have subsumed Scheme had CL been a Lisp1, but standardizing
CL as a Lisp2 elevated Scheme to the position of being the most
viable Lisp1 with Cambridge Polish syntax.

This was important historically because, for whatever reasons, be
they mistaken or otherwise, a lot of the people who cared about
higher order functions believed it was important to name functions
the same way as other values, and thus preferred Lisp1 to Lisp2.
People with this belief, mistaken or otherwise, formed the core of
the Scheme community during the 1980s.  These beliefs, mistaken or
otherwise, need to be understood (but not necessarily accepted) by
people who want to understand the historical evolution of the
relationship between Scheme and other languages in the Lisp family,
which is a lot of what I understand this thread to be about.

> I'm asking you to
> self-identify, and also to look seriously at what we do in the way
> _we_ look at it, not how it looks from the outside, and say "do really
> competent programmers in this language mean to say that higher order
> functions are bad?" and I think the answer is no.

Agreed.

> But my point is that the _language_ is not holding anyone back.
> You see before you a community which has not sought to go in your direction
> as aggressively as you yourself prefer to, but for people who don't have that
> as their agenda, they've done a _lot_ of stuff with higher order functions.

Agreed.

> In that sense, again empirically, it is simply unfair to conclude that the
> language works against it.

Not agreed.  The absence of garbage collection in C++ makes it hard to use
objects effectively, but C++ programmers have done a lot of stuff with
objects despite that obstacle.  I'm talking about a much more subtle
obstacle, which may exist only in the minds of those who think they see
it, but nonetheless had historical consequences.

> No, I wouldn't.  I've used Scheme several times for work and sometimes for
> play and have been around it all my adult life.  I am never happy with it
> because I just don't like the Lisp1 notation.

I have no problem with that.

> Thanks for your helpful reply.  I hope I've adequately defended my position
> here and that maybe you can see that it isn't as black and white as you
> might believe.

I think you've done a good job of that.  It's been pleasant to talk to
you again, Kent, even in this impersonal and public forum.

Will

Why is Scheme not a Lisp? Rahul Jain 3/15/02 11:42 PM
ces...@qnci.net (William D Clinger) writes:

> Yes.  What I said was misleading here.  It's not that having to write
> #'foo instead of foo is a burden, it's that the explicit coercion from
> function to value, if you will, induces a subtle psychological set that
> functions are not values, or at least not like other values.

It may induce that in you. Other people are perfectly acceptable with
record and record meaning different things in different syntactic
contexts.

> Sure, but we were talking about this with regard to hygienic macros,
> which make it impossible to hide the function name from the macros that
> use it.  This does eliminate certain classes of bugs.  Not all classes
> of bugs.

Common Lisp has hygenic macros, too.

> I think the problems of this sort tend to arise when using a macro
> written by someone else that introduces local bindings into your
> code of which you are not aware,

Then the person who wrote the documentation for that macro would be
irresponsible.

> and don't really want to be aware.

Then _you_ would be irresponsible for refusing to read the
documentation of a macro you want to use.

> You may say that is bad style,

It is bad style to enforce style rules.

> but then certain kinds of macros, e.g. Scheme's CASE, become harder
> to write.

You mean anaphoric macros? Documentation, again.

> I would guess that the standard technique for CL macros is to gensym
> the introduced names.

Or to document the introduced names, if it is desired to have them
visible/captured in the macro's scope.

> This was getting close to the heart of what I was trying to say.  I
> agree that instructors with a Scheme background are more likely to
> teach higher order functions,

A halfway decent instructor of Lisp, ML, Haskell, or most other
languages would do the same.

> as a Lisp1 [Scheme] named functions the same way it named all
> values.

No, it evaluates the functional application position the same way that
it evaluates the positions of the values passed to the function.

> Not agreed.  The absence of garbage collection in C++ makes it hard to use
> objects effectively, but C++ programmers have done a lot of stuff with
> objects despite that obstacle.  I'm talking about a much more subtle
> obstacle, which may exist only in the minds of those who think they see
> it, but nonetheless had historical consequences.

People can invent obstacles for their own thinking all they want. That
does not entitle them to claim that others (who have not invented
those obstacles) are unable to do the things that thoes invented
obstacles would prevent. This has nothing to do with GC and OOP, since
that is a _real_ barrier which causes _inefficient_ and _buggy_
programs to be created (using refcounting or non-compacting GC at
best).

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Kent M Pitman 3/16/02 2:26 AM
ces...@qnci.net (William D Clinger) writes:

> > You will not cause a change in the language this way.
>
> I'm not trying to change Common Lisp.  (I did try once upon a time,
> and that was enough for one lifetime.)

Heh.  I very vividly remember you trying, by the way.  And I consider
that an important part of the historical process.  It's not as if
Scheme people didn't sit on the committee and have their input, so
it's not that we acted out of ignorance.  And, as you well know, both
Steele and Gabriel, much more powerful driving forces on the committee
than you or I, were well-versed in Scheme's mechanics and technical
benefits.  So if an argument had been raised which was being unfairly
trounced by a roomful of people who were just foolishly stuck being
"confused", I'm confident that one of them would have forced us into a
teaching lesson.

You may not have changed much per se, and maybe it felt like a waste
to you, but had you and a few others with similar leanings not been
there I would be far less sure that we had given certain Scheme ideas
a fair hearing.  I think we had in the design rooms a fair microcosm
of the ideas that were to be played out later, and I think had we been
able to poll the community at large, there is at least good likelihood
the outcome would have been similar.

As expressed in the personal note at the end of my recent paper on Conditions
 http://world.std.com/Papers/Condition-Handling-2001.html
there are sometimes cases in which I felt the committee was not competent
to judge what the community needed or wanted (nor perhaps was the community
as a whole competent to judge what it needed).  That's a much more scary
situation for those voting on matters, IMO.  But I think at least in the
functional programming case, people did hear and understand the issues.
They may or may not have "chosen badly", but with the help or you and
others of your leanings present, I think they understood the stakes.

I sometimes see my role in the possibly-moribund Scheme authors
committee as the well-meaning but ineffectual mirror of yours in the
CL community, so we are kindred spirits you and I, each doomed to have
all the power of a nagging conscience in the face of actions beyond
our control....

> > > In Lisp2, functions are usually bound in a different environment
> > > from other values, so Lisp2 programmers do not think of
> > > functions simply as values.
> >
> > This is surely isn't true of me.
>
> Sorry.  This is the broad brush for which Bruce Lewis rightly criticized
> my post.  What I meant is that the defining characteristic of a Lisp2
> tends to nudge the thinking of Lisp2 programmers in the direction of
> not thinking of functions simply as values.  I'm glad you have not been
> susceptible to this.
>
> You very likely disagree with the suitably qualified version of what
> I was trying to say, but I hope you understand what I was trying to
> say.

Well, I guess the point I'm trying to get you to see is that there is
a difference between the technical and the social.

Teaching is a social matter and hopefully can improve even as CL remains
stable.

Scheme, in part because the language is small and in part just because
it came out of universities, has put more attention into teaching than
CL has.  A consequence is that people are often unguided in their uses
of some operators.

This is made worse by a subtle pressure through the CS world to
separate technical and non-technical matters.  When I published my
Maclisp manual, long ago, some people ragged on me for publishing
"style notes" inline in the actual manual.  They said it was not
appropriate for that style of document.  But the users loved it, and I
got letters of praise from people who couldn't understand why that
wasn't done more, given how desperately it was needed.  Often we
separate the activities of documenting and analyzing/advising, saying
the latter will follow later under separate cover.  But then, often it
doesn't.

> > Function names cannot be _unpreventably_ shadowed.  Both CL and Scheme
> > allow the writing of buggy code, of course.  
>
> Sure, but we were talking about this with regard to hygienic macros,
> which make it impossible to hide the function name from the macros that
> use it.  This does eliminate certain classes of bugs.  Not all classes
> of bugs.
>
> I think your point is that packages provide the same hygiene when used
> properly.

Yes.


 
> >  (b) if a programmer shadows another's names, they are declaring themselves
> >      implementor of that other programmer's code.  This is bad style, IMO,
> >      and in general should never be done in well-styled code....
>
> I think the problems of this sort tend to arise when using a macro
> written by someone else that introduces local bindings into your
> code of which you are not aware, and don't really want to be aware.
> You may say that is bad style, but then certain kinds of macros,
> e.g. Scheme's CASE, become harder to write.  I would guess that

> the standard technique for CL macros is to gensym the introduced
> names.

Or layered abstractions upon it.  I rarely use GENSYM directly in my
own code, though I usually expand out the abstraction when I post code here.
Privately I usually use something like LispWorks' macros WITH-UNIQUE-NAMES
and REBINDING. e.g.,

  (defmacro with-foo ((datum . options) &body code)
    (with-unique-names (function)
      `(flet ((,function () ,@code))
         (declare (dynamic-extent #',function))
         (call-with-foo #',function ,datum ,@options))))

  (defun call-with-foo (thunk datum &rest options)
    (let ((*foo* (apply #'make-foo datum options)))
      (funcall thunk)))

This doesn't get involved in gensyms directly and yet is quite hygienic
in practice.  Since CL must deal with with order-of-argument issues as
well, one must sometimes also do:

  (defmacro set-to-value (new-value (op . args))
    (rebinding (new-value)
      `(setf (,op ,@args) ,new-value)))

which is the same as:

  (defmacro set-to-value (new-value (op . args))
    (let ((new-value-var (gensym "NEW-VALUE")))
      `(let ((,new-value-var ,new-value))
         (setf (,op ,@args) ,new-value-var))))

but is substantially more readable.

> > I don't disagree with this analysis of Scheme, though I think Scheme
> > has done a disservice to others elsewhere by teaching its benefits as
> > a contrast to the way others do things, rather than acknowledging
> > other legitimate systems where higher order function are available.
>
> Well, it isn't Scheme that has done this, but perhaps individual
> instructors who use Scheme.  I don't think you're talking about me
> here, for example.

Fair enough.  My turn to feel bad for overgeneralizing.

In my own defense, I never used to do this and used to speak of Scheme
warmly until members of the Scheme community started launching potshots
at CL.  In particular, what sent me over the edge was a particular remark
made at a particular L&FP conference in which a speaker presenting a paper
basically said something to the effect of "we didn't do that because it
would take us down the road toward being like Common Lisp" as if everyone
would "just know" that was a "Bad Thing".  And everyone _did_ seem to know
what he meant and not be offended.  I called him on it out loud in the Q&A
after the paper, and various people reacted as if it was _me_ who was
picking a fight, when he'd been allowed to cast general aspersions against
our language as a whole with nary a word.  Since most of the influential
Scheme folks were typically present at such conferences in that day, I
took this quite badly and have been much more sensitive since then to
further such sentiments, which I've seen from all quarters, and in no small
number from people coming out of Scheme courses.

If I would start seeing words of support from the Scheme community, and
active encouragement from such influential people that they should embrace
and respect CL, I would take a different posture.

But the problem runs deep because this issue of "single view of
aesthetic" runs deep.  This is the place where I think it all comes
from.  People simply do not understand what I sometimes grudgingly
call "non-Euclidean aesthetics".  (I say grudgingly because even then
it suggests that "planar aesthetics" tought by Scheme are somehow
statistically to be favored as more useful in practice, and I'm not at
all sure that's appropriate.  But at least it adds respectability to
my point because non-Euclidean geometry is not disrespected or
pooh-poohed by Mathemeticians.)  

> > People come out of Lisp courses thinking it is a lemma that we don't
> > have higher order functions that work, and so do not stop to examine
> > that perhaps this is false.
>
> It seems to me that almost all currently popular languages in the
> Lisp family have higher order functions, so it would be a shame if
> instructors are giving the impression that they don't.  I was not
> aware that this is a problem.  I suspect that instructors who use
> Scheme are pretty good about giving the impression that Scheme has
> higher order functions.

Well, I think people are giving the impression that the Lisp2 issue
poisons everything.  People seem to come out aware of the Lisp1/Lisp2
distinction (not always by name, but by concept) but unaware that this
doesn't render the langauge utterly unaesthetic.  They are taught no
degree of tolerance.  No ability to understand it as "differently
aesthetic".  And the undoing process is painful.

They are also taught that there is something generally greasy about
CL, and this again is a problem.  I related a story a while back about
an ISLISP design meeting where I had something from CL I wanted to
factor into ISLISP and some members of the committee literally refused
to touch (with their hands, I mean physically) or read (as if it might
slip in through their eyes and run out of control) the single piece of
paper describing the feature I wanted.  It's just one page, I said.
But those member said, in effect, and I am really trying hard not to
exaggerate because the incident requires no exaggeration, that any
touch of CL would poison ISLISP and (they didn't use these terms, but
it's more concise:) send it down the path to the dark side.  I just
don't know what to do when I'm up against this kind of stuff.  [It
took us a long time in committee to work past this kind of foolish
prejudice and finally get down to work.  I don't know if it's that the
membership changed or those specific people grew more tolerant, but we
ultimately did get past that kind of thing and produce a decent (if
tiny) standard for ISLISP, I think.]

But I don't think that particular incident with ISLISP, nor the one
with L&FP, were just isolated things.  They were done in the presence
of others who seemed not at all bothered by what had happened. I see
it as part of a systematic process of reinforcing the acceptability of
speaking ill of CL, and I see it the same ugly way as I do people
being racially bigoted.  I see some backlash in the Lisp community
from this, and perhaps on some days am guilty of it myself, but this
is almost essential to not being walked all over.  Powerful negative
words sadly call for powerful negative words in return because that is
the nature of the academic debate: One plants a stake and others
respond.  Those who fail to respond are deemed to have nothing to say.
So when people criticize CL, Scheme is criticized in return.  And
that's a shame.

> > You're certainly right that people who teach higher order functions
> > tend to come from a Scheme background, but this is not a technical
> > issue, it's an issue of historical preference ...
>
> This was getting close to the heart of what I was trying to say.  I
> agree that instructors with a Scheme background are more likely to
> teach higher order functions, but I was stating my belief that the
> cause of this lies in historical events of 27 to 15 years ago.  Not
> only was Scheme one of the first languages in the Lisp family to
> support higher order functions in the sense that we understand them
> today (lexical scope and all that), but as a Lisp1 it named functions
> the same way it named all values.  Furthermore Common Lisp probably
> would have subsumed Scheme had CL been a Lisp1, but standardizing
> CL as a Lisp2 elevated Scheme to the position of being the most
> viable Lisp1 with Cambridge Polish syntax.

This is an interesting thought.

My immediate thought to test it is to think of the failure of Eulisp,
at least to the extent of its failure to displace either CL or Scheme.
You'd think would have immediately attracted the interest of all the
Scheme community if they were so starved for more functionality.  As
nearly as I can tell, and they might object to the characterization,
there was nothing remarkably different than CL in Eulisp except notation,
nor anything remarkably different from Scheme than libraries, yet this
"obvious" compromise failed somehow to grab either community.  

Just NIH? I don't know.  Maybe.  Perhaps your remark is correct but
that there was only a narrow window in which such a change could have
been made.

> This was important historically because, for whatever reasons, be
> they mistaken or otherwise, a lot of the people who cared about
> higher order functions believed it was important to name functions
> the same way as other values, and thus preferred Lisp1 to Lisp2.
> People with this belief, mistaken or otherwise, formed the core of
> the Scheme community during the 1980s.  These beliefs, mistaken or
> otherwise, need to be understood (but not necessarily accepted) by
> people who want to understand the historical evolution of the
> relationship between Scheme and other languages in the Lisp family,
> which is a lot of what I understand this thread to be about.

Yes, I agree.

Do you think it would be useful or productive at this point to try to
create a Lisp1 preprocessor for CL?  Because the Scheme community tolerates
more of a clear separation between "preprocessing" and "runtime" than
the CL community does [we using things like COMPILE and EVAL much more
freely, I sense], it might be a possible thing.  I don't know if it would
do any good though.

> > I'm asking you to
> > self-identify, and also to look seriously at what we do in the way
> > _we_ look at it, not how it looks from the outside, and say "do really
> > competent programmers in this language mean to say that higher order
> > functions are bad?" and I think the answer is no.
>
> Agreed.
>
> > But my point is that the _language_ is not holding anyone back.
> > You see before you a community which has not sought to go in your
> > direction as aggressively as you yourself prefer to, but for
> > people who don't have that as their agenda, they've done a _lot_
> > of stuff with higher order functions.
>
> Agreed.
>
> > In that sense, again empirically, it is simply unfair to conclude that the
> > language works against it.
>
> Not agreed.  The absence of garbage collection in C++ makes it hard to use
> objects effectively, but C++ programmers have done a lot of stuff with
> objects despite that obstacle.  I'm talking about a much more subtle
> obstacle, which may exist only in the minds of those who think they see
> it, but nonetheless had historical consequences.

Yes, if what you mean to say is that history did not unfold randomly
but that certain patterns of ensuing politics and flows of usage were
direct consequences of political decisions, then sure, I agree.

I just wish those same smart people would seem to retain more of an
open mind about the difference between their "preferred notation" (as
in, I actively prefer Lisp2 and can't stand using Lisp1 notation, but
I understand that others either don't mind or actively prefer Lisp2)
and "necessary notation" (as in my perception that some Lisp1 people
think Lisp2 is bankrupt).
 
It would be a lot easier to be friendly about Scheme people in our
midst if we weren't constantly having to begin conversations
defensively, knowing statistically that the person walking to the CL
world from the Scheme world was actively predisposed not to like us.
Someone out there is doing it.  I'm not entirely sure who, though.
I just see the second-order effects mostly.

> > No, I wouldn't.  I've used Scheme several times for work and sometimes for
> > play and have been around it all my adult life.  I am never happy with it
> > because I just don't like the Lisp1 notation.
>
> I have no problem with that.
>
> > Thanks for your helpful reply.  I hope I've adequately defended my position
> > here and that maybe you can see that it isn't as black and white as you
> > might believe.
>
> I think you've done a good job of that.  It's been pleasant to talk to
> you again, Kent, even in this impersonal and public forum.

:-)  You too...

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Kent M Pitman 3/16/02 2:29 AM
Erik Naggum <er...@naggum.net> writes:

> * Kent M Pitman
> | Perhaps the plain fact that it's more important that they feel themselves
> | technically right than that they win friends?
>
>   Hey, something wrong with that?

I thought of both you and I as I made that remark.  No, nothing wrong
with it at all.  But in the specific case of doing design, it has
consequences on which community follows you and which does not.
Politics is all about deciding when to cater to old friends and when
to make new ones.

First-class symbols (Re: Why is Scheme not a Lisp?) Erik Naggum 3/16/02 3:29 AM
* Erann Gat

| Yes:
|
| (symbol-value x) == (eval x (interaction-environment))
| (set x v) == (eval `(set! ,x value) (interaction-environment))
|
| >   Can you call a symbol in Scheme if its global value is a function?
|
| Yes:
|
| ((eval f (interaction-environment)) arg1 arg2 ...)
|
| or
|
| (define (function f) (eval f (interaction-environment)))
| ((function f) ...)

  And you guys have a problem with _funcall_!?  *laugh*

| So this is what I am struggling to understand.  I have always thought
| that interned-constant-string is the "essence of symbolness".

  Huh?  How odd.  That is the essence of keyword symbols, Scheme symbols.

| Whether symbols are mapped to values by having those values be "part of"
| the symbol as in CL, or through a separate environment object as in
| Scheme, seems to me at least on a practical level to be a relatively
| minor detail.

  How can you be convinced that it has major ramifications?

| What do you see as the value (in the economic sense) of a symbol in the
| Lisp sense of the word?

  The same value I see in a word: _meaning_.  Scheme symbols lack meaning.
  They are names, but they name -- nothing.  Some people think words are
  just names, too, that the _only_ property a word has is its spelling
  (some of the more "creative" spellers not even that), and each word has
  meaning only according to the person you ask.  That looks like a Scheme
  view to me.  I believe a saner approach is to consider a word to have a
  life of its own, independent of the individual user, but created as a
  community effort as a common reference intended both to carry meaning and
  to facilitate communication and understanding.  Some people believe that
  words give us the ability to think abstractly about ideas that are far
  too complex to grasp concretely, even ideas that have no concrete meaning.

| What can you do with a Lisp symbol that you can't do with a Scheme symbol?

  Use it as a designator for a function or a class or even a string.  Ask
  it about its home package.  Use its property list.  Unintern it and still
  keep it around.  Copy it, optionally including its values.  Have you
  never used symbols in Common Lisp, except to name lexical variables?

  If you have only used the "Scheme-compatible subset" of Common Lisp,
  Erann, I suddenly understand why you think the way you do about Common
  Lisp.  It also dawns on me, belatedly, that this follows from Paul
  Graham's attempts to re-create several Scheme features in Common Lisp
  with On Lisp -- and why he needs Arc and could _not_ use Common Lisp as
  his implementation vehicle.


 
| The only thing I can think of, even in pre-R5RS scheme, is computing the
| dynamic binding of a symbol whose identity is not known until run time.

  Well, interactive environments, "little languages", etc, seem to be
  _very_ different things in Scheme and Common Lisp.  You can probably find
  some useful information in this difference.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erik Naggum 3/16/02 3:55 AM
* "Pierpaolo BERNARDI" <pierpaolo...@hotmail.com>

| Uh?  Obtaining any information from Franz regarding prices is so hard
| that I recently gave up after 15 days that I was trying to buy their
| compiler.

  If you sent them mail from your hotmail.com account, chances are it was
  considered spam or a prank and was just dropped on the floor.  If you
  have a real mail account, too, it sounds strange.  However, if we can
  trust tradition, you will receive a message from them now.  (Better have
  a valid e-mail address ready.)

| Or, do you know a better way for checking this than asking them?

  Yes.  I know the answer.  :)

  Seriously, Franz Inc have put almost all of their product information and
  documentation on their Web site.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Erik Naggum 3/16/02 4:04 AM
* Erik Naggum
> Precisely, positions can be close to eachother, but the direction of the
> momentum or the heading to the destination may be quite different.  What
> is so annoying with "Scheme is a (dialect of) Lisp" when published
> recently (as opposed to when it was written) is that they imply that Lisp
> has moved in the same direction Scheme has, and that is patently _false_.

* Bruce Hoult
| Lisp can't move in a direction.  It just is.  Platonic.  Pure.  Common
| Lisp can move in a direction.

  Sometimes, I wonder what a hang-up looks like.  Thank goodness for USENET.
  But sometimes, I wonder if some people post annoying articles on purpose.

  Please note that I did not say that Lisp has moved.  I argued that it is
  false that the Scheme freaks imply that that Lisp has moved (in the same
  direction Scheme has).  Please think before you respond next time.  Not
  every reference to "Lisp" is really a reference to "Common Lisp" just
  because of your hang-up, you see.  Sometimes, somebody have thought about
  what they have said much more than you can imagine.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Lieven Marchand 3/15/02 1:38 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> But in Scheme, a symbol has no global properties.  Or rather, if you
> like, the only global property it can have are is definition in the
> top level environment.  And modules solve that problem.  

Or they would if Scheme had modules. I don't expect to get the Scheme
community to agree to a module system in my lifetime.

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

First-class symbols (Re: Why is Scheme not a Lisp?) Erann Gat 3/16/02 8:41 AM
In article <32252669...@naggum.net>, Erik Naggum <er...@naggum.net> wrote:

> * Erann Gat
> | Yes:
> |
> | (symbol-value x) == (eval x (interaction-environment))
> | (set x v) == (eval `(set! ,x value) (interaction-environment))
> |
> | >   Can you call a symbol in Scheme if its global value is a function?
> |
> | Yes:
> |
> | ((eval f (interaction-environment)) arg1 arg2 ...)
> |
> | or
> |
> | (define (function f) (eval f (interaction-environment)))
> | ((function f) ...)
>
>   And you guys have a problem with _funcall_!?  *laugh*

"You guys"?  I'm a Common Lisper, remember?  Well, maybe I'm an
ex-Common-Lisper, but I'm definitely not a Schemer.  I have never done any
significant development in Scheme.  (In my youth I was fond of T for a
while, but even then I did my development in a T-compatibity package
written in Mac Common Lisp.)

>   How can you be convinced that it has major ramifications?

Show me something I can do with a Common Lisp symbol that it would take
more than a few lines of code to do in Scheme.  And I mean something
useful, not something that simply derives directly from a definitional
difference, like querying a symbol for its package.

> | What do you see as the value (in the economic sense) of a symbol in the
> | Lisp sense of the word?
>
>   The same value I see in a word: _meaning_.  Scheme symbols lack meaning.
>   They are names, but they name -- nothing.  Some people think words are
>   just names, too, that the _only_ property a word has is its spelling
>   (some of the more "creative" spellers not even that), and each word has
>   meaning only according to the person you ask.  That looks like a Scheme
>   view to me.  I believe a saner approach is to consider a word to have a
>   life of its own, independent of the individual user, but created as a
>   community effort as a common reference intended both to carry meaning and
>   to facilitate communication and understanding.  Some people believe that
>   words give us the ability to think abstractly about ideas that are far
>   too complex to grasp concretely, even ideas that have no concrete meaning.

OK, that's fine, but it sounds more like a philosophical argument (or an
aesthetic one, or a pedagogical one) than a practical one to me.  I find
this ironic because it's usually the Scheme peopl who make those kinds of
arguments, where Common Lisp (I thought) is supposed to be the Lisp for
practical people who want to dispense with the philosophy and just get
work done.

Also, it seems to me that Common Lisp doesn't provide any more inherent
meaning for symbols than Scheme does.  (Well, CL does provide a priori
meaning to *more* symbols than Scheme does, but I don't think that's what
you were referring to.  CL does provide more built-in *mechanisms* for
associating meanings with symbols, but that's not the same thing as
providing *meaning*.  Finally, it's easy to reproduce most of those
mechanisms in Scheme if you really want them.

So I still don't see why this is a big deal.

> | What can you do with a Lisp symbol that you can't do with a Scheme symbol?
>
>   Use it as a designator for a function or a class or even a string.

I can use a Scheme symbol as a designator for a function or a string (or
any other Scheme value).  It's true I can't use it to designate a class,
but that's because Scheme doesn't have classes.  It's got nothing to do
with any feature (or lack thereof) of the *symbol*.  I can't use a Scheme
symbol to designate a hash table either, but that just because Scheme
doesn't have hash tables.

> Ask it about its home package.

True, but why would I ever want to do that?

>  Use its property list.

I can add property lists to Scheme in half a dozen lines of code (maybe less).

> Unintern it and still keep it around.  Copy it, optionally including its
> values.

Again, why would I want to?

> Have you never used symbols in Common Lisp, except to name lexical variables?

Of course I have.  Maybe I haven't used them the "right way", or maybe
I've never done anything that needed any of the capabilities that you
describe above.  And that's basically my question: what kinds of tasks are
these capabilities useful for?  I can't think of any.

>   If you have only used the "Scheme-compatible subset" of Common Lisp,
>   Erann, I suddenly understand why you think the way you do about Common
>   Lisp.  It also dawns on me, belatedly, that this follows from Paul
>   Graham's attempts to re-create several Scheme features in Common Lisp
>   with On Lisp -- and why he needs Arc and could _not_ use Common Lisp as
>   his implementation vehicle.

Don't conflate my point of view with Paul's.  The reason I'm not using
Common Lisp any more is mostly political.  I would go back to it in a
minute if I thought I could do so without damaging my career.  It's really
ironic: you think I'm a Scheme freak, and my JPL colleagues all think I'm
a Common Lisp freak.  At least one of you must be wrong.

> | The only thing I can think of, even in pre-R5RS scheme, is computing the
> | dynamic binding of a symbol whose identity is not known until run time.
>
>   Well, interactive environments, "little languages", etc, seem to be
>   _very_ different things in Scheme and Common Lisp.  You can probably find
>   some useful information in this difference.

That seems like a non-sequitur, but that notwithstanding, what do you see
as the differences?

E.

First-class symbols (Re: Why is Scheme not a Lisp?) Nils Goesche 3/16/02 1:00 PM
g...@jpl.nasa.gov (Erann Gat) writes:

> In article <32252669...@naggum.net>, Erik Naggum <er...@naggum.net> wrote:
>
> >   The same value I see in a word: _meaning_.  Scheme symbols lack meaning.
> >   They are names, but they name -- nothing.  Some people think words are
> >   just names, too, that the _only_ property a word has is its spelling
> >   (some of the more "creative" spellers not even that), and each word has
> >   meaning only according to the person you ask.  That looks like a Scheme
> >   view to me.  I believe a saner approach is to consider a word to have a
> >   life of its own, independent of the individual user, but created as a
> >   community effort as a common reference intended both to carry meaning and
> >   to facilitate communication and understanding.  Some people believe that
> >   words give us the ability to think abstractly about ideas that are far
> >   too complex to grasp concretely, even ideas that have no concrete meaning.
>
> OK, that's fine, but it sounds more like a philosophical argument (or an
> aesthetic one, or a pedagogical one) than a practical one to me.  I find
> this ironic because it's usually the Scheme peopl who make those kinds of
> arguments, where Common Lisp (I thought) is supposed to be the Lisp for
> practical people who want to dispense with the philosophy and just get
> work done.

Hehe.  Well, I understand much less of all these things than you
people do, but even I can tell that there /is/ some important
difference between Scheme and (Common) Lisp -- the typical Scheme
program looks much different than the typical Lisp program.
Also, the /feeling/, the /experience/ of writing in Scheme is
much different than of writing in Lisp.  I am sure many people
can feel that because it's so obvious.  But it's hard to tell why
this is so; there /must/ be a reason, only it is hard to find.
Sure, everybody can see that, on the surface, Scheme, CL, Lisp1
and Lisp2 have lots of similarities, but when you dive into them
you suddenly see that they are really different -- but the
/reason/ for that must lie very deep, somewhere at the very root
of things, and hence the answer necessarily will sound more
philosophical than anything else, and it won't be easy at all to
recognize that it /is/ the answer, even if already identified.

That the answer lies in the meaning of symbols, of names, is a
very interesting idea, but it is, of course, hard to tell whether
it is the true answer, let alone to prove it.

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

PGP key ID 0xC66D6E6F

First-class symbols (Re: Why is Scheme not a Lisp?) Erik Naggum 3/16/02 1:05 PM
* Erann Gat

| "You guys"?  I'm a Common Lisper, remember?  Well, maybe I'm an
| ex-Common-Lisper, but I'm definitely not a Schemer.

  I am not so sure about that.  I think some of your unhappiness with
  Common Lisp comes from a Scheme-like mindset.  The same goes for Paul
  Graham.  I found a somewhat apt quote the other day: "After a year of
  therapy, my psychiatrist said to me: 'Maybe life isn't for everyone'"
  (credited to Larry Brown).

| Show me something I can do with a Common Lisp symbol that it would take
| more than a few lines of code to do in Scheme.

  But that is _so_ not the point.  As Kent has belabored, the whole purpose
  of a language is to gove people a common frame of reference, a way of
  naming things that makes it possible to talk about them.  It is quite
  amazing that you still do not understand this.  A few lines of code is
  precisely what we do _not_ want.  A simple, named concept is what this is
  all about.

| > | What do you see as the value (in the economic sense) of a symbol in the


| > | Lisp sense of the word?
| >
| >   The same value I see in a word: _meaning_.  Scheme symbols lack meaning.
| >   They are names, but they name -- nothing.  Some people think words are
| >   just names, too, that the _only_ property a word has is its spelling
| >   (some of the more "creative" spellers not even that), and each word has
| >   meaning only according to the person you ask.  That looks like a Scheme
| >   view to me.  I believe a saner approach is to consider a word to have a
| >   life of its own, independent of the individual user, but created as a
| >   community effort as a common reference intended both to carry meaning and
| >   to facilitate communication and understanding.  Some people believe that
| >   words give us the ability to think abstractly about ideas that are far
| >   too complex to grasp concretely, even ideas that have no concrete meaning.
|
| OK, that's fine, but it sounds more like a philosophical argument (or an
| aesthetic one, or a pedagogical one) than a practical one to me.  I find
| this ironic because it's usually the Scheme peopl who make those kinds of
| arguments, where Common Lisp (I thought) is supposed to be the Lisp for
| practical people who want to dispense with the philosophy and just get
| work done.

  Do you even understand your own question, Erann?  What kind of answer
  would you expect?  Fucking stupid troll.

| So I still don't see why this is a big deal.

  I think you never will and that it is a waste of time to try to tell you.

  You would look much better as an ex-Schemer than an ex-Common Lisper.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Thomas F. Burdick 3/16/02 1:07 PM
ces...@qnci.net (William D Clinger) writes:

> Kent M Pitman wrote:
> > This is a nice succinct example of where we take a different view on
> > the same data.  I perceive that you think writing #'foo is somehow a
> > negativity because you don't what to write it.  I think what you don't
> > see is that I don't have any negative take on the writing of #'foo and
> > so I am not negatively biased away from using it.
>
> Yes.  What I said was misleading here.  It's not that having to write
> #'foo instead of foo is a burden, it's that the explicit coercion from
> function to value, if you will, induces a subtle psychological set that
> functions are not values, or at least not like other values.

I suppose you could think of it that way.  I think of it as looking up
a function object by name.  I don't doubt that it may present a subtle
disincentive to use functions as values to some people (maybe mostly
people who learned Lisp1's and Lisp2's when Lisp2's were dynamically
scoped), but as someone who learned Lisp long after lexical scoping
made its way into Lisp2's, I really don't feel any tug against using
functions as values.  I might get a person object from the name of the
person: (gethash 'john *person-hash*), but that doesn't make me
disinclined to use person objects as values.  Hell, the call to
gethash is more cumbersome than the call to function.

And I actually find Lisp1 notation a little disconcerting.  I would be
far less likely to write something like

  (((foo bar) baz) qux)

than

  (let ((fn (funcall (foo bar) baz)))
    (funcall fn qux))

I'm sure that if I used a Lisp1 for long enough, I could get
comfortable with the Lisp1 way of saying it, but it looks ugly and
inelegant to me; I like funcall, it's pretty.  I'm sure it's pretty
for the same reason that Lisp1 notation looks nice to Lisp1'ers: the
concept is nice, and you're seeing it written in a manner you're
comfortable with.

> >  (b) if a programmer shadows another's names, they are declaring themselves
> >      implementor of that other programmer's code.  This is bad style, IMO,
> >      and in general should never be done in well-styled code....
>
> I think the problems of this sort tend to arise when using a macro
> written by someone else that introduces local bindings into your
> code of which you are not aware, and don't really want to be aware.
> You may say that is bad style, but then certain kinds of macros,
> e.g. Scheme's CASE, become harder to write.  I would guess that
> the standard technique for CL macros is to gensym the introduced
> names.

Yep.  It's not a practical problem if the macro writer documents what
bindings are introduced, but I'd still prefer to control the names
myself, as the macro consumer.  It's so easy to use gensyms to make
this a non-issue, that if the macro writer can't get that right, I
wouldn't trust the macro anyway.

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

Why is Scheme not a Lisp? Tim Bradshaw 3/16/02 1:51 PM
* William D Clinger wrote:

> Yes, you are.  I was talking about the fact that the defining
> feature of Lisp2, separate environments for values and for
> functions, creates a bias against higher-order thinking.  In

> Lisp2, functions are usually bound in a different environment
> from other values, so Lisp2 programmers do not think of
> functions simply as values.  Thus, for example, you can find

> examples of Common Lisp programmers who do not see the need
> for hygienic macros, claiming that function names cannot be
> shadowed.  Are they unaware of FLET and LABELS?  Probably not.

> Probably they're just aware that FLET and LABELS are so seldom
> used as not to cause a problem for macro writers.  Why aren't

> FLET and LABELS used?  There are many reasons, but one is the
> cultural bias against higher-order thinking that results from
> a Lisp2.

This indicates to me that you really don't think like a CL person
would.  Firstly there is a promise by the language that CL function
names cannot be legally shadowed by FLET/LABELS.  Secondly the package
system means that you are seriously unlikely to tramp on code written
by other people, unless you want to.  Finally, sometimes you want to.

Of course, if your language doesn't have packages, then you're
probably in trouble.  

> In Scheme, by contrast, LET, LETREC, and local definitions are
> quite often used to define local functions.  There are many
> reasons for this, too, but one is that local functions are
> convenient in higher-order programs, and Scheme, being a Lisp1,
> has attracted people who like to write higher-order programs.

I just looked at a program I'm working on at the moment.  Of 333
defun/defmethod uses I have 50 flet/label uses.  This is not what I
would call `so seldom used'. (I also have 59 uses of funcall/apply).

--tim

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) IPmonger 3/16/02 7:48 PM
Bruce Lewis <brl...@yahoo.com> writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
>
>> I just don't see the point in scheme clinging to the name "lisp" when
>> the point of the name scheme was so that it wasn't perceived as lisp!
>
> I think you're seeing an agenda where there is none.
>
> http://www.informatik.uni-bremen.de/~net/history.html
>
>    Following the tradition of the AI languages ``Planner'' and
>    ``Conniver'', Steele and Sussman named their language ``Schemer'';
>    the name was later truncated to ``Scheme'' to fit the 6-character
>    filename limitation of the ITS operating system.

    I thought about this too when Rahul posted his initial response.
  But, as you've posted the excerpt, it has become clear that the
  obviously intentional pun involved in the naming does not /preclude/
  the notion that the name was also a double entendre.

-jon
--
------------------
Jon Allen Boone
ipmo...@delamancha.org

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Pierpaolo BERNARDI 3/16/02 9:10 PM

"Erik Naggum" <er...@naggum.net> ha scritto nel messaggio
news:3225268547127061@naggum.net...

> * "Pierpaolo BERNARDI" <pierpaolo...@hotmail.com>
> | Uh?  Obtaining any information from Franz regarding prices is so hard
> | that I recently gave up after 15 days that I was trying to buy their
> | compiler.
>
>   If you sent them mail from your hotmail.com account, chances are it was
>   considered spam or a prank and was just dropped on the floor.  If you
>   have a real mail account, too, it sounds strange.

I have not used the hotmail address, and I have not said that
they have not replied to me.  There has been an exchange of
everal emails.  Just that the bozo who replied didn't want to
tell me their prices.  Some bit of information that she gave
was in contradiction with their offer, and so on.  BTW, *they*
contacted me first with a 'special offer'.

>   However, if we can
>   trust tradition, you will receive a message from them now.  (Better have
>   a valid e-mail address ready.)

They know my email address, but it doesn't matter *now*:
luckily, they are not the sole CL vendor.

I wonder how they manage to stay in business.

P.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/16/02 10:57 PM
Kent M Pitman <pit...@world.std.com> writes:

>  (defpackage temperature
>    (:use "CL")
>    (:shadow "T"))
>
>  (in-package "TEMPERATURE")
>
>  (defconstant true 'cl:t)

I didn't think CL packages nested.  

That said, the point was to allow T to be a local variable name in
*one* function, not to shadow it across an entire package.

Thomas

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/16/02 10:58 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Common Lisp has hygenic macros, too.

So you say.  Kent Pitman says that CL does *not* have hygenic macros,
but that it's not a problem in CL.  

Hrm.

data hygiene [Re: Why is Scheme not a Lisp?] Thomas Bushnell, BSG 3/16/02 11:05 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Unless you want to do something where they Just Won't. And all this
> syntactic bloat being forced for a little theoretical
> "perfection". Not a language for me, for sure.

Huh?  There is far less "syntactic bloat" in Scheme macros, which
involve two concepts (a binding concept and a
what-is-a-syntax-transformation concept), in which it Just Works,
reliably, always---compared to the several different levels of macro
definition in CL, and the concomitant confusion often experienced.

The really significant difference is not the hygene one, which CL
could have without too much trouble.  The big difference is that CL
thinks of macros as *functions* from forms to forms, and Scheme has a
simpler pattern transformation method.

The CL one allows for slightly more general macros; normally of course
a CL macro is just a pattern transformation, but sometimes one wants
to do more stuff, and the Scheme version doesn't permit that.  It
would be nice to get a standard Scheme macro system that included
transformation *functions* like CL has.

(However, at present, there are two reasons Scheme lacks it; one is
that the needed interactions between the hygene rules and the
transformation functions are murky.  The other is that the Scheme
world has only recently gotten the standard macros that it has, and
some time and experience with them needs to happen before they go
getting extended into the more general functional method that CL
uses.)

Thomas

data hygiene [Re: Why is Scheme not a Lisp?] Thomas Bushnell, BSG 3/16/02 11:08 PM
Lieven Marchand <m...@wyrd.be> writes:

> tb+u...@becket.net (Thomas Bushnell, BSG) writes:
>
> > But in Scheme, a symbol has no global properties.  Or rather, if you
> > like, the only global property it can have are is definition in the
> > top level environment.  And modules solve that problem.  
>
> Or they would if Scheme had modules. I don't expect to get the Scheme
> community to agree to a module system in my lifetime.

I do.  :)  All existing full-size Scheme systems have some kind of
module system IIRC.  And, in fact, they have essentially similar
features, so its easy to write a mapping from any one of them to the
others.

I think that means that a generic module system will show up before
too long.  The real thing that holds back agreement on a common module
system is agreement on a common way to turn environments into first
class objects (which, I think, is really necessary for specifying how
the module system works).

Thomas

Why is Scheme not a Lisp? Rahul Jain 3/16/02 11:04 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

CL has hygenic macros if you feel like it. It also has non-hygenic
macros. It's just that you can use the same facility to do both. In
fact, you would implement hygenic macros using the non-hygenic macro
facility.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Rahul Jain 3/16/02 11:08 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> I didn't think CL packages nested.  

That's what you call nesting?

> That said, the point was to allow T to be a local variable name in
> *one* function, not to shadow it across an entire package.

Then that function needs to be defined in a package where the symbol
table is what you want it to be. You seem to not understand what
symbols and packages are at all...

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

First-class symbols (Re: Why is Scheme not a Lisp?) Thomas Bushnell, BSG 3/16/02 11:16 PM
"Joe Marshall" <prunes...@attbi.com> writes:

> To contrast this with Scheme, the compiler arranges it so that the
> identifier `foo' will recover the current value of foo, but this
> has nothing to do with the symbol `foo'.  Having the symbol `foo'
> won't (in general) let you modify the value or function associated
> with that name.

Indeed this is true.

In Scheme, the thing that is missing here is not some kind of
first-classness of the symbol, but rather, the first-classness of the
environment.  (An environment, in Scheme-speak, is a mapping from
symbols to bindings.)

Common Lisp has various public ways to access one special environment
(the dynamic environment), and thus for special variables, there is a
convenient and accessible mapping from the symbol name to its dynamic
value.

Scheme indeed lacks this (in the standard).  Those implementations
that have first-class environments certainly do provide just this
mapping, but there is controversy in the Scheme world about whether
first-class environments are a Good Thing, and among those (like me)
who think they are, about what the right interfaces should look like.

I'd note that Common Lisp (IIUC) does not provide access to any
environments but the current dynamic environment, right?  The Scheme
solution would need to provide access to all of them.

This has compiler implications that are really significant.  If a
function has its environment captured into an environment object, then
the compilation of that code needs to maintain a symbol->variable
table explicitly, at some cost.  So you don't want to do it for every
procedure, but only those where the compiler can show that the
environment has been captured.

But that's fraught with difficulty.  If you can capture "the present
environment" in some function, can you walk up the call chain to the
next stack frame up (and thus capture its environment)?  If so, then
nearly any function could, in principle, have its environment
captured, and so the compiler is screwed.  (Or, actually, the
implementation gets a *lot* hairier.)

It's not that these are impossible problems, but they are some of the
reasons that there is great diversity of opinion about what the Right
Thing is, and Scheme generally only moves when all the players have
agreed on the Right Thing.

Thomas

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/16/02 11:30 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> > That said, the point was to allow T to be a local variable name in
> > *one* function, not to shadow it across an entire package.
>
> Then that function needs to be defined in a package where the symbol
> table is what you want it to be. You seem to not understand what
> symbols and packages are at all...

Instead of insulting me, why not see what I'm saying?

In Scheme, the following is allowed:

(define (foo t)
  (+ t 50))

In CL, the equivalent is not.

But that function is part of a jillion functions, some of which might
well want to be written the normal way, with "t" meaning "canonical
true value", and only this one function wanting to shadow the name.

Kent's "solution" says "make your entire package have a different name
for "canonical true value".  That is only a real solution if packages
nest, so that I can embed the FOO function in a little package, which
is still part of the bigger package that I'm writing.  And even then,
it's rather a lot of hair.

This is all no big deal; it was just somebody lamenting that Lisp
traditionally overloads two symbol names (t and nil) in Very Special
Ways.  

Thomas

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/16/02 11:33 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> tb+u...@becket.net (Thomas Bushnell, BSG) writes:
>
> > Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
> >
> > > Common Lisp has hygenic macros, too.
> >
> > So you say.  Kent Pitman says that CL does *not* have hygenic macros,
> > but that it's not a problem in CL.  
>
> CL has hygenic macros if you feel like it. It also has non-hygenic
> macros. It's just that you can use the same facility to do both. In
> fact, you would implement hygenic macros using the non-hygenic macro
> facility.

I don't think there is any way to implement hygenic macros in CL.  The
macro needs to know expansion context things, to detect whether it is
shadowing a local, in ways that are not computable without looking at
the surrounding context of the expansion.  CL macros, unless they've
been radically extended since the last time I studied them, do not
have access to the surrounding context.

And even if you could implement a fully hygenic macro in CL, that
still isn't the point; the point is that Scheme actually *has* such a
facility, and CL doesn't.  

But I certainly agree with Kent Pitman that given the total language
context of CL, it's really much less necessary.

Thomas

data hygiene [Re: Why is Scheme not a Lisp?] Rahul Jain 3/16/02 11:34 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
>
> > Unless you want to do something where they Just Won't. And all this
> > syntactic bloat being forced for a little theoretical
> > "perfection". Not a language for me, for sure.
>
> Huh?  There is far less "syntactic bloat" in Scheme macros,

I was actually talking about other aspects of the language, but this
works, too.

> which involve two concepts (a binding concept and a
> what-is-a-syntax-transformation concept), in which it Just Works,
> reliably, always

Sounds like a good description of CL macros. Except that syntax
tranformations are a far more general concept in CL.

> ---compared to the several different levels of macro definition in
> CL, and the concomitant confusion often experienced.

"Several different levels"? What on earth are you talking about?

> The CL one allows for slightly more general macros;

"Slightly"? That's like saying that complex numbers are slightly more
general than natural numbers. A turing machine is far more powerful
than a very simple pattern-matching engine. AFAIK, all you can do in
scheme macros is destructure based on indefinitely repeated patterns.

> (However, at present, there are two reasons Scheme lacks it;

Really, there is just one: the lack of proper symbolic processing.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

First-class symbols (Re: Why is Scheme not a Lisp?) Rahul Jain 3/16/02 11:42 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> "Joe Marshall" <prunes...@attbi.com> writes:

> In Scheme, the thing that is missing here is not some kind of
> first-classness of the symbol,

Except that there are lots of other things that having namespaces for
symbols will let you do. Like symbolic processing.

> but rather, the first-classness of the environment.  (An
> environment, in Scheme-speak, is a mapping from symbols to
> bindings.)

Yes, that's only one feature of environments in CL.

> Common Lisp has various public ways to access one special environment
> (the dynamic environment),

> Scheme indeed lacks this (in the standard).

Yes, scheme lacks a dynamic environment.

> I'd note that Common Lisp (IIUC) does not provide access to any
> environments but the current dynamic environment, right?  The Scheme
> solution would need to provide access to all of them.

Scheme doesn't have a "dynamic" environment in the sense of
dynamically scoped values. There are only lexical environments, which
any sane language allows to be compiled away, so they should only be
accessible at compile-time, as they are in CL.

> This has compiler implications that are really significant. [...] So


> you don't want to do it for every procedure, but only those where
> the compiler can show that the environment has been captured.

Or just forbid capturing it, and make the compilation happen at
compile-time. If someone wants the actual semantics of the code to
change at runtime, they have EVAL and COMPILE for just that in CL.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Rahul Jain 3/16/02 11:50 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
>
> > > That said, the point was to allow T to be a local variable name in
> > > *one* function, not to shadow it across an entire package.
> >
> > Then that function needs to be defined in a package where the symbol
> > table is what you want it to be. You seem to not understand what
> > symbols and packages are at all...
>
> Instead of insulting me, why not see what I'm saying?

Instead of taking your misunderstanding as a personal defect, why not
try to correct it?

> In Scheme, the following is allowed:

> (define (foo t)
>   (+ t 50))

> In CL, the equivalent is not.

Because CL has macros that do symbolic processing. In CL, symbols
matter. If you want a specific symbol, use it.

> But that function is part of a jillion functions, some of which might
> well want to be written the normal way, with "t" meaning "canonical
> true value", and only this one function wanting to shadow the name.

Then you shouldn't be making a mess of your code this way. Either
choose one syntax or another. It's not that hard to do.

> Kent's "solution" says "make your entire package have a different name
> for "canonical true value".  That is only a real solution if packages
> nest, so that I can embed the FOO function in a little package, which
> is still part of the bigger package that I'm writing.  And even then,
> it's rather a lot of hair.

Would it be better for value lookups to be locked in at read time? I
think not. I'd rather be clear in what my code says and let the
language retain the power I need from it.

> This is all no big deal; it was just somebody lamenting that Lisp
> traditionally overloads two symbol names (t and nil) in Very Special
> Ways.

Which can be changed by you very trivially if you so desire.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Rahul Jain 3/16/02 11:52 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> I don't think there is any way to implement hygenic macros in CL.  The
> macro needs to know expansion context things, to detect whether it is
> shadowing a local,

I'm puzzled as to why a hygenic macro should be creating shadowing at
all. Isn't the point of hygenic macros to NOT cause any shadowing?

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/17/02 12:09 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> tb+u...@becket.net (Thomas Bushnell, BSG) writes:
>
> > I don't think there is any way to implement hygenic macros in CL.  The
> > macro needs to know expansion context things, to detect whether it is
> > shadowing a local,
>
> I'm puzzled as to why a hygenic macro should be creating shadowing at
> all. Isn't the point of hygenic macros to NOT cause any shadowing?

The point of a hygenic macro is that the macro can use whatever
variables it likes in its expansion.  If the macro does not itself
bind them, then they must not interact at all with the variables that
exist in the surrounding code, even if they happen to share the same
name.

Implementing this efficiently generally requires looking at the
surrounding context to know whether a particular variable might be
shadowed (and thus should be renamed by the compiler).  

Thomas

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/17/02 12:07 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Instead of taking your misunderstanding as a personal defect, why not
> try to correct it?
>
> > In Scheme, the following is allowed:
>
> > (define (foo t)
> >   (+ t 50))
>
> > In CL, the equivalent is not.
>
> Because CL has macros that do symbolic processing. In CL, symbols
> matter. If you want a specific symbol, use it.

You know, macros really have nothing to do with whether "t" is a
special magic symbol.  Or if you think they do, maybe you could
describe the connection?  

> Then you shouldn't be making a mess of your code this way. Either
> choose one syntax or another. It's not that hard to do.

What are the two "syntaxes" that you're talking about?  

> > Kent's "solution" says "make your entire package have a different name
> > for "canonical true value".  That is only a real solution if packages
> > nest, so that I can embed the FOO function in a little package, which
> > is still part of the bigger package that I'm writing.  And even then,
> > it's rather a lot of hair.
>
> Would it be better for value lookups to be locked in at read time? I
> think not. I'd rather be clear in what my code says and let the
> language retain the power I need from it.

Um, no, nobody wants value lookups to be locked in at read time.
Except, that is, for the one case of "t" and "nil".  Those values
*are* locked in at read time, by making those two symbols Very
Special.

That's the problem.  It's a teeny problem (and it wasn't I that
brought it up), but it's a problem.  It's forced upon CL by
compatibility considerations, and that's a perfectly good reason for
CL to maintain the historic practice.  But it doesn't make the
historic practice right.

Thomas

data hygiene [Re: Why is Scheme not a Lisp?] Thomas Bushnell, BSG 3/17/02 12:03 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> > The CL one allows for slightly more general macros;
>
> "Slightly"? That's like saying that complex numbers are slightly more
> general than natural numbers. A turing machine is far more powerful
> than a very simple pattern-matching engine. AFAIK, all you can do in
> scheme macros is destructure based on indefinitely repeated patterns.

By "slightly", I meant that the additional computational power is
rarely used.  But indeed, I think it's really nice, and it would be
great if a good method of doing it were added to the Scheme standard.  

> > (However, at present, there are two reasons Scheme lacks it;
>
> Really, there is just one: the lack of proper symbolic processing.

Huh?  You're just mouthing words that others have given you, without
understanding them at all.  'tis a real shame, but it's expected
boosterism.  Indeed, if did anything else, Erik Naggum would start
shouting at you and calling you names, so I don't blame you.  

In any case, that isn't any kind of response.

Frankly, I really enjoy reading Kent's messages, because

1) He knows whereof he speaks, and really understands the deep issues,
2) He isn't convinced that CL is the Only Way To Do Anything
3) I learn a lot.

But that's not true of your messages; they are just getting in the way
of a conversation that I'm enjoying a great deal.  Please don't snipe.

Thomas
 

Why is Scheme not a Lisp? Rahul Jain 3/17/02 1:48 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> > Because CL has macros that do symbolic processing. In CL, symbols
> > matter. If you want a specific symbol, use it.

> You know, macros really have nothing to do with whether "t" is a
> special magic symbol.  Or if you think they do, maybe you could
> describe the connection?  

If a macro inside the body of a function that rebinds T uses T, then
it will not work as the macro writer expected. This is because CL
macros, again, are symbolic in nature, and not value-oriented as it
seems scheme macros must be.

> > Then you shouldn't be making a mess of your code this way. Either
> > choose one syntax or another. It's not that hard to do.

> What are the two "syntaxes" that you're talking about?  

One with T as a variable and one with T as a symbolic constant.

> > > Kent's "solution" says "make your entire package have a
> > > different name for "canonical true value". [...] And even then,

> > > it's rather a lot of hair.
> >
> > Would it be better for value lookups to be locked in at read time? I
> > think not. I'd rather be clear in what my code says and let the
> > language retain the power I need from it.
>
> Um, no, nobody wants value lookups to be locked in at read time.

How else will you get values in scheme, since symbols don't have
values? Where else will the value of "t" as used in my macro come
from? This is one reason why scheme _needed_ to have #t and #f,
whether or not it was explicit at the time. Unfortunately, a user
cannot implement such a feature.

> Except, that is, for the one case of "t" and "nil".  Those values
> *are* locked in at read time, by making those two symbols Very
> Special.

Wrong. The values of T and NIL are locked into the SYMBOLS. Nothing
says that the string "t" has a true value.

> That's the problem.  It's a teeny problem (and it wasn't I that
> brought it up), but it's a problem.  It's forced upon CL by
> compatibility considerations,

In reality, this whole difference is just a side-effect of the issue
of symbolic processing.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

data hygiene [Re: Why is Scheme not a Lisp?] Rahul Jain 3/17/02 1:40 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> By "slightly", I meant that the additional computational power is
> rarely used.  But indeed, I think it's really nice, and it would be
> great if a good method of doing it were added to the Scheme standard.  

It's only rarely used if all your macros have simple patterns to
them. I don't know if you can you destructure a plist with scheme
macros, can you?

> > > (However, at present, there are two reasons Scheme lacks it;

> > Really, there is just one: the lack of proper symbolic processing.

> Huh?  You're just mouthing words that others have given you, without
> understanding them at all.

PAIP explains symbolic processing quite well. I have a feeling much of
the techniques used there would be next to impossible to do in scheme
with multiple such systems operating on the same data. Norvig doesn't
use packages because he already knows everything about what will be
done to the data.

> 'tis a real shame, but it's expected boosterism.

Your refusal to accept that some people might actually enjoy being
able to cleanly do symbolic processing and calling the features which
allow that misfeatures is what I'd call boosterism. You haven't
proposed any equivalent alternative, and until you do so, you have no
right to imply that we are misguided for liking namespaces for
symbols.

> In any case, that isn't any kind of response.

I've already explained what I mean by symbolic processing. Kent
replied and elaborated on the idea in a much more precise way. If you
don't understand it, please read that post again.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

First-class symbols (Re: Why is Scheme not a Lisp?) Erik Naggum 3/17/02 1:52 AM
* Thomas Bushnell, BSG

| In Scheme, the thing that is missing here is not some kind of
| first-classness of the symbol, but rather, the first-classness of the
| environment.

  As seen from Common Lisp, symbols in Scheme are just like identifiers in
  the Algol family, but you also have a type for an interned string that
  has nothing to do with the identifiers.  These are really two different
  things.  Real Lisps have real symbols.

| Common Lisp has various public ways to access one special environment
| (the dynamic environment), and thus for special variables, there is a
| convenient and accessible mapping from the symbol name to its dynamic
| value.

  I wish you would at least _try_ to understand the Common Lisp way.

| It's not that these are impossible problems, but they are some of the
| reasons that there is great diversity of opinion about what the Right
| Thing is, and Scheme generally only moves when all the players have
| agreed on the Right Thing.

  But looking for The Right Thing is not a Right Thing.  Part of the reason
  that Scheme is such an unattractive language is that it tries to say that
  "there is such a thing as a universal and globally unique Right Thing",
  and this is _such_ a ludicrous position in the first place.  Sometimes,
  when I hear Scheme people talk, and you among them, I get the impression
  that there are 26 people trying to argue which is the Only Right Letter
  and they are _so_ in the need of someone to say "Hey, dudes!  One word:
  _alphabet_".

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Rahul Jain 3/17/02 1:50 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> > tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> > > I don't think there is any way to implement hygenic macros in CL.  The
> > > macro needs to know expansion context things, to detect whether it is
> > > shadowing a local,

> > I'm puzzled as to why a hygenic macro should be creating shadowing at
> > all. Isn't the point of hygenic macros to NOT cause any shadowing?

> Implementing this efficiently generally requires looking at the


> surrounding context to know whether a particular variable might be
> shadowed (and thus should be renamed by the compiler).  

So how does GENSYM not provide this functionality? Why worry about
renaming it when you can use a symbol which is guaranteed to not exist
anywhere else? I thought I did this kind of stuff all the time.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/17/02 2:15 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> How else will you get values in scheme, since symbols don't have
> values? Where else will the value of "t" as used in my macro come
> from? This is one reason why scheme _needed_ to have #t and #f,
> whether or not it was explicit at the time. Unfortunately, a user
> cannot implement such a feature.

"Symbols don't have values"?  They don't in CL either, except for
special variables, for which you might want to say that.  

#t and #f are constants, and that's why Scheme makes them not just
symbols.  The issue is that symbols are *all* available for variable
names.  There is no more reason to have t use up a variable name than
6.

> > Except, that is, for the one case of "t" and "nil".  Those values
> > *are* locked in at read time, by making those two symbols Very
> > Special.
>
> Wrong. The values of T and NIL are locked into the SYMBOLS. Nothing
> says that the string "t" has a true value.

And nothing I said was about the string "t"; it was about the
*symbols*, which are Very Special.

> In reality, this whole difference is just a side-effect of the issue
> of symbolic processing.

Your new mantra of the day!  If you knew what it meant... oh, no,
you're just chanting.  Ok.

Thomas

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/17/02 2:16 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> > Implementing this efficiently generally requires looking at the
> > surrounding context to know whether a particular variable might be
> > shadowed (and thus should be renamed by the compiler).  
>
> So how does GENSYM not provide this functionality? Why worry about
> renaming it when you can use a symbol which is guaranteed to not exist
> anywhere else? I thought I did this kind of stuff all the time.

Implementing it *efficiently*.  I don't think you understand what the
issues are with hygienic macros; maybe you should go read the papers.

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/17/02 2:29 AM
* Thomas Bushnell, BSG

| Huh?  There is far less "syntactic bloat" in Scheme macros, which
| involve two concepts (a binding concept and a
| what-is-a-syntax-transformation concept), in which it Just Works,
| reliably, always---compared to the several different levels of macro
| definition in CL, and the concomitant confusion often experienced.

  I do not think anyone disputes the usefulness of something that either
  Just Works or just does not apply, but Common Lisp is not about making it
  possible to do only the Right Thing.  I had to listen to one of the worst
  specimens of politician on the news last night in order to catch some
  real news, and it is clear that this Christian Democrat-like hypocrite
  really has as his concept of politics to create a whole nation where all
  people do the Right Thing according to his demented religious views.  I
  mean, it is the Taliban regime all over again, only with a mad Christian.
  Listening to this madman, I came to think of Scheme freaks.  In contrast
  to Common Lisp, which offers people a way to do whatever they want to do,
  Scheme offers a way to do whatever the Scheme designers want them to do,
  and if you want to do something else, the message is "You don't want to
  to do that."

  Confusion is the result of lack of knowledge, insight, and thinking, not
  a property of the subject matter.

| The really significant difference is not the hygene one, which CL could
| have without too much trouble.

  You know, you have spelled this "hygene" consistently for a while, so I
  think you may not know it is actually spelled "hygiene".

| The big difference is that CL thinks of macros as *functions* from forms
| to forms, and Scheme has a simpler pattern transformation method.

  So Common Lisp macros can implement Scheme macros, but not vice versa.

| The CL one allows for slightly more general macros; normally of course a
| CL macro is just a pattern transformation, but sometimes one wants to do
| more stuff, and the Scheme version doesn't permit that.

  That seems to be a case of "it Just Doesn't Work".

| (However, at present, there are two reasons Scheme lacks it; one is that
| the needed interactions between the hygene rules and the transformation
| functions are murky.

  I read this to mean "it is better left to human intelligence", and that
  is just what Common Lisp does.

  Oh, another thing Scheme says to people when it refuses to give people
  the freedom do what they think is best is: "You couldn't figure out the
  Right Thing on your own if you tried".  I can do without that attitude.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Thomas Bushnell, BSG 3/17/02 2:30 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> It's only rarely used if all your macros have simple patterns to
> them. I don't know if you can you destructure a plist with scheme
> macros, can you?

Some kinds of "looking inside" work just fine.  For example, you can
expand a LET form the following way:

((let ((var value) ...) forms ...)
 ((lambda (var ...)
    forms ...)
  (value ...)))

So the ((var value) ...) repetition can be destructured, and then you
can look inside it with var ... and value ... and everything works
just fine.

So the amount of destructuring you can do easily covers the cases
people usually want (and match what is generally considered good style
for both Scheme and CL types).  But one might have a good reason to
want something like LET, only with no extra parens, for example;
something like:

(my-let (var-1 value-1 var-2 value-2 ...) forms ...)

Indeed, that's what you want for destructuring a plist.  But I think
it's generally thought by Lispers that it's a shame that plists and
alists have different structure, and if it were to be done over again,
plists would have the alist structure.  So you can't destructure a
plist easily, but except when actually dealing with plists, you are
advised in Common Lisp to use alists instead, in general.  

Incidentally, it's been shown now that it *is* possible to do
arbitrary destructuring with Scheme macros, because it turns out that
with letrec-syntax you can create mutually recursive macro definitions
that are Turing complete.  But I certainly wouldn't claim that the
results are pretty or easily understandable.

> Your refusal to accept that some people might actually enjoy being
> able to cleanly do symbolic processing and calling the features which
> allow that misfeatures is what I'd call boosterism.

I haven't called them misfeatures at all.  I've said they seem to me
to be the right thing within the broader world of Common Lisp.

> You haven't proposed any equivalent alternative, and until you do
> so, you have no right to imply that we are misguided for liking
> namespaces for symbols.

Never said you were misguided at all.

Thomas


data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/17/02 2:36 AM
* Thomas Bushnell, BSG

| Indeed, if did anything else, Erik Naggum would start shouting at you and
| calling you names, so I don't blame you.

  Please quit lying about me and what I want and would do.  When you repeat
  this crap over and over, it is a serious case of hostility on your part.
  You are no longer being attacked, but you choose to attack me out of the
  blue repeatedly.  This is not a forum for your hatred and irrationality.

  Thomas Bushnell, you are intellectually dishonest and an evil person.
  Please cease and desist, and get help from a priest or something to get
  over your need to blame other people for your own character deficiencies
  and your psychotic break.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Erik Naggum 3/17/02 4:16 AM
* Thomas Bushnell, BSG

| Um, no, nobody wants value lookups to be locked in at read time.  Except,
| that is, for the one case of "t" and "nil".  Those values *are* locked in
| at read time, by making those two symbols Very Special.

  Hey, dude, acquire clue, _then_ talk, will you?  Your ability to stop
  talking when your clue runs out is sorely lacking.  This indicates that
  you talk only to score rhetorical points for yourself, not to discuss
  anything of value to you or any others.  Please latch out of your hostile
  mode and start to think.  You used to be able to think, I remember.

  This is the real story: t and nil are declared constants, just like pi
  and most-positive-fixnum.  t and nil happen to have themselves as their
  constant value, but that is quite irrelevant to the binding issue.  This
  has nothing to do with the reader, either.  The standard says: The
  consequences of binding and assigning a constant variable are undefined.
  The value of a named constant may not be changed by assignment or
  binding.  So this has nothing to do with t or nil being special symbols,
  it has nothing to do with read-time, it has to do with the rules for
  binding and assigning constant variables.

  I wonder why you are not griping about pi, too.  Perhaps you are simply
  unaware of the idea of constant variables?  Does Scheme have constant
  variables?  No.  It has #f and #t, instead.  Does Scheme have a constant
  value for pi?  No.

  Now, it may illuminate the discussion to see why it is _necessary_ that
  constant variables not be rebound or assigned to.  First, there should be
  no need for a run-time lookup of their value -- the compiler should be
  free to inline the value.  Like, a test for nil-ness should be no more
  than a single instruction.  So if you change the value of a declared
  constant (it can be done), you get hosed by the system.  Second, to make
  a constant variable useful to programmers, they must know that they can
  rely on it.  This, somewhat ironically, follows from the _integrated_
  macro system in Common Lisp, and it would _not_ follow from the macro bag
  on the side of Scheme.  How do you capture the universal (stronger than
  global) value of a declared constant when you can shadow the binding and
  perhaps even make it lexical?  What would happen to macro bodies if you
  could change the value of t or nil?  Serious lossage!  To be able to rely
  on your Common Lisp environment, as in trust it, constants _must_ be
  known to have their one and only constant value.  This also means that if
  it is at all possible that it is not a constant and that you might want
  to re-bind the value, do not make it a constant.  Consequently, ther are
  few real constants around.  pi and e are the mathematical ones with their
  arbitrary names from a different domain, and t and nil are the boolean
  ones with their arbitrary names from the Common Lisp domain.  That is
  just how things are.  Deal with it.  Like it the way it is and spend your
  mental energy on solving your problems _with_ Common Lisp as a constant
  as far you are concerned.  This part of Common Lisp is not going to be
  changed.  However, if you really, really want to, you can do this:

(defpackage "LOSERVILLE"
  (:use "COMMON-LISP" ...)
  (:shadow "T"))

(defparameter t cl:t)

  so in Loserville, you may bind t, and most of the time, it will still
  work.  If you want it to work all the time, do not move to Loserville.

  The magnitude of the confusion and the absence of insight that must exist
  prior to making such an incredibly bogus claim as "Those values *are*
  locked in at read time, by making those two symbols Very Special" is just
  _staggering_.  The cluelessness that this betrays is so fantastically
  destructive to your credibility that it approaches the idiocy you keep
  committing when you post lies about what I would do just because you need
  to feed your psychotic imagination.  You know just about as much about
  Common Lisp as you do about me, and you have _no_ control over your
  blabbering.  It is _fantastically_ annoying to have people like you
  around.  Go away!

| That's the problem.  It's a teeny problem (and it wasn't I that brought
| it up), but it's a problem.  It's forced upon CL by compatibility
| considerations, and that's a perfectly good reason for CL to maintain the
| historic practice.  But it doesn't make the historic practice right.

  Do you have the mental capacity to back down when you are wrong?

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Paul Foley 3/17/02 4:43 AM
On 16 Mar 2002 23:30:51 -0800, Thomas Bushnell, BSG wrote:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
>> > That said, the point was to allow T to be a local variable name in
>> > *one* function, not to shadow it across an entire package.
>>
>> Then that function needs to be defined in a package where the symbol
>> table is what you want it to be. You seem to not understand what
>> symbols and packages are at all...

> Instead of insulting me, why not see what I'm saying?

Perhaps you need to be clearer about what you're saying.  You do seem
to be saying that you don't understand symbols.  In particular, you
seem not to understand that a symbol is distinct from its name.
That's probably why you think that just interning the name and calling
that a "symbol" is good enough.

> In Scheme, the following is allowed:

> (define (foo t)
>   (+ t 50))

> In CL, the equivalent is not.

Huh?

  (defun foo (t)
    (+ t 50))

is perfect legal Common Lisp -- as long as this T is not CL:T, because
that's a constant, and you can't use constants as variables, obviously!

> But that function is part of a jillion functions, some of which might
> well want to be written the normal way, with "t" meaning "canonical

"t" doesn't mean anything, in isolation.  You're talking about the
symbol named "T" in the COMMON-LISP package, which is just one symbol
named "T" out of potentially millions, any others of which have no
relation to the "canonical true value" whatsoever.  There's nothing
special about either the name "T" or the COMMON-LISP package.

> true value", and only this one function wanting to shadow the name.

So put it in a different package.  You *can* even do things like

  (eval-when (:compile-toplevel :execute)
    (shadow 'cl:t))

  (defun foo (t)
    (+ t 50))

  (eval-when (:compile-toplevel :execute)
    (shadowing-import 'cl:t))

if you really want to.  I don't know why you'd want to, though.

> Kent's "solution" says "make your entire package have a different name
> for "canonical true value".

Not it doesn't.  Kent supplied a symbol named TRUE for that value, but
of course you can continue to use the old name if you prefer; CL:T and
TEMPERATURE::T are independent symbols.

>                              That is only a real solution if packages
> nest, so that I can embed the FOO function in a little package, which
> is still part of the bigger package that I'm writing.

You mean like USE-PACKAGE?

> This is all no big deal; it was just somebody lamenting that Lisp
> traditionally overloads two symbol names (t and nil) in Very Special
> Ways.  

Where's the "overloading"?  And what do you mean by "Very Special
Ways"?  There's nothing particularly special about them; you can make
any symbol a constant with DEFCONSTANT.

--
Malum est consilium quod mutari non potest             -- Publilius Syrus

(setq reply-to
  (concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

data hygiene [Re: Why is Scheme not a Lisp?] Paul Foley 3/17/02 5:25 AM
On 17 Mar 2002 00:03:10 -0800, Thomas Bushnell, BSG wrote:

>> > The CL one allows for slightly more general macros;

> By "slightly", I meant that the additional computational power is
> rarely used.

Define "rarely".  Just looking at a few of my files, I count 46 macro
definitions, of which 19 are simple pattern rewrites and 27 do some
computation in the expander function.  I doubt that's atypical.

--
Malum est consilium quod mutari non potest             -- Publilius Syrus

(setq reply-to
  (concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

Why is Scheme not a Lisp? Paul Foley 3/17/02 5:25 AM
On 17 Mar 2002 02:15:21 -0800, Thomas Bushnell, BSG wrote:

> #t and #f are constants, and that's why Scheme makes them not just
> symbols.  The issue is that symbols are *all* available for variable
> names.  There is no more reason to have t use up a variable name than
> 6.

Oh, so you can use 6 as a variable name in Scheme, then, can you?

--
Malum est consilium quod mutari non potest             -- Publilius Syrus

(setq reply-to
  (concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

Why is Scheme (not ?) a Lisp? David Golden 3/17/02 5:32 AM

To even be able to argue  reasonably coherently about the differences, one
must understand both Scheme and CL at a very deep level at the very least -
which I don't. (I would note that lots of the comments in this traditional
Scheme/CL flamethread seem to show a large degree of misunderstanding or
just trolling from both sides...).

I'd say that only members of some sort of "Lisp" community would
be able to do the argung in the first place.

I would say that the name "Lisp" denotes languages like
Scheme and CL, among others.   Show a non-Lisper with some computing
experience either Scheme or CL, and they'll identify either as Lisp.  Your
identifier in  human society is what other people call you, not the name
you choose for yourself.  

From the "outside", Scheme and CL are Lisps, and the arguments between
Scheme and CL people are similar to the arguments between Roman Catholics
and Protestants - they're both just more vampire-cultist christians to the
outside observer, though a member of either group will argue at length
about con/trans-substantiation, the status of the virgin mary, etc....

So, probably only a devoted member of the community is going to be able to
understand the issues involved, and thus I would lump both Scheme and CL
together as implementations of different  "aspects" of an underlying
archetypal Lisp that the Lisp community recognises at a subconcious level,  
by the fact that people on this group are even arguing about Sheme and CL
in the first place.

Saying "Our Lisp is the One True Lisp, and what you're calling Lisp is Not
Lisp" is _just_ like the stupid schisms you see in religions.

Much better to say Scheme and CL are aspects of the One,,,


--
Don't eat yellow snow.


Why is Scheme not a Lisp? Erik Naggum 3/17/02 5:55 AM
* Thomas Bushnell, BSG

| Implementing it *efficiently*.  I don't think you understand what the
| issues are with hygienic macros; maybe you should go read the papers.

  Perhaps you should explain it better?  You, too, seem to demand that
  other people pay for your lacking education, but when it gets time to
  reverse this principle, you seem to get just as exasperated as those you
  do not listen to.  At least this shows _me_ something, if not you.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Erik Naggum 3/17/02 5:59 AM
* Paul Foley <myc...@actrix.gen.nz>

| Oh, so you can use 6 as a variable name in Scheme, then, can you?

  I think even Scheme has the ability to make anything a symbol using
  enough backslashes.  (symbolp '\6) => t

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Tim Bradshaw 3/17/02 5:55 AM
* Thomas Bushnell wrote:

> Implementing it *efficiently*.  I don't think you understand what the
> issues are with hygienic macros; maybe you should go read the papers.

Can you be clear what you mean about `efficiently'.  For instance if I
blindly rename *all* symbols I bind then probably for a typical macro
this is 0-10 symbols, and the overhead is entirely at macro expansion
time.  There must be some other meaning of `efficient' here.

--tim

Why is Scheme not a Lisp? Tim Bradshaw 3/17/02 6:37 AM
* Paul Foley wrote:
> So put it in a different package.  You *can* even do things like

>   (eval-when (:compile-toplevel :execute)
>     (shadow 'cl:t))

>   (defun foo (t)
>     (+ t 50))

>   (eval-when (:compile-toplevel :execute)
>     (shadowing-import 'cl:t))

Would not this work (in a package where T is not CL:T)

(define-symbol-macro t cl:t)

do the trick?

Now you can bind T painlessly, but free references mean CL:T and the
compiler can do any constant folding &c.

--tim

Why is Scheme (not ?) a Lisp? Bijan Parsia 3/17/02 7:34 AM
On Sun, 17 Mar 2002, David Golden wrote:

>
> To even be able to argue  reasonably coherently about the differences, one
> must understand both Scheme and CL at a very deep level at the very least -

Not at all. Lisp1 vs. Lisp2 seems simple enough. Pattern transformation
macros vs. computational macros (er..is there a better standard
name?). Primarily functional vs. multi-paradigm. Etc.

Of course, for the latter, it helps to understand what a functional
language vs. a muti-pardigm (or perhaps, strongly OO) language is, but
that should be more or less general knowledge. If you don't understand
*that* then, ok, you probably can't make that distinction between scheme
and lisp, but then maybe you shouldn't make judgements about their
differences at all.

[snip]


> I'd say that only members of some sort of "Lisp" community would
> be able to do the argung in the first place.

If this is supposed to be because you have to have used Lisps extensive,
yadda yadda, then I don't think that's true. Or, at least, not in any
strongly interesting sense.

> I would say that the name "Lisp" denotes languages like
> Scheme and CL, among others.

It's really weird how you set up the Lisp Community as the only place
where such analysis is *possible*, cast yourself out of the Lisp
Community, *then make a pronoucement* that ordinarily is based on the sort
of analysis which you just said you can't do (correctly).

>   Show a non-Lisper with some computing
> experience either Scheme or CL, and they'll identify either as Lisp.

Presumably either on superficial grounds ("parens with prefix operators"),
possible mistaken advertizing ("well, we did both in our lisp section
class"), a very certain perspective ("well, compared to C, they're lisps,
as is Perl"), or on real grounds because they followed some debates and
came down on the scheme is a lisp side.

Only the last is remotely interesting intellectual, though the others
might be interesting from a marketing perspective.

>  Your
> identifier in  human society is what other people call you, not the name
> you choose for yourself.  

And now we have the justifying principle which is to make it all work: And
it is a repugnant one. Even if convention and some sort of community
consensus is necessary for "correct" labeling, why must it be the
community of the studiously ignorant?

I had a student ask about my name, and I told him it was Iranian, and he
asked if my family had been Muslim, and I said, "No, Zorostrian". "Ah", he
said, "they were Parsis". I said, no, the Parsis are the decendents of
those Zorostrians that fled to India. He told be it didn't matter, I was a
Parsi.

Well, look, "bob", not only was he wrong, but he was a jerk.

> From the "outside", Scheme and CL are Lisps,

Not necessarily. If you look at the various grounds I listed for the
"outsider's" perspective, you'll see that some are JUST FREAKING
WRONG. E.g., KIF is not a Lisp. Prolog with Sexprs syntax isn't a
Lisp. Yet both may be classified as a lisp by the person with a parens
fixation.

> and the arguments between
> Scheme and CL people are similar to the arguments between Roman Catholics
> and Protestants - they're both just more vampire-cultist christians to the
> outside observer, though a member of either group will argue at length
> about con/trans-substantiation, the status of the virgin mary, etc....

This is *really* offensive.

Interesting that you conflate all Protestants.

Really interesting that the outsiders have *all* the defining
power. Sorry, that's not how it usually goes. Oh, and yes, my ancesters
are *Iranian*, not *Persian*. Thanks ;)

I guess the notions of respect and tolerance and understanding are just
completely foreign.

[snip]

I guess this must of been a joke. If so, it didn't come off very well.

Bijan Parsia.

Why is Scheme (not ?) a Lisp? Julian Stecklina 3/17/02 9:11 AM
Bijan Parsia <bpa...@email.unc.edu> writes:

[...]

> > and the arguments between
> > Scheme and CL people are similar to the arguments between Roman Catholics
> > and Protestants - they're both just more vampire-cultist christians to the
> > outside observer, though a member of either group will argue at length
> > about con/trans-substantiation, the status of the virgin mary, etc....
>
> This is *really* offensive.

That lies in the eye of the beholder. :) I do _not_ feel
offended. Even though I live in a mainly protestant area, but nobody
does care here either.

Regards,
Julian
--
Meine Hompage: http://julian.re6.de

Um meinen oeffentlichen Schluessel zu erhalten:
To get my public key:
http://math-www.uni-paderborn.de/pgp/

Why is Scheme not a Lisp? Kent M Pitman 3/17/02 10:01 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
>
> > Common Lisp has hygenic macros, too.
>
> So you say.  Kent Pitman says that CL does *not* have hygenic macros,
> but that it's not a problem in CL.  

An MIT guy and a Harvard guy went into a bathroom together and went up
to the urinal to pee.  After finishing, the MIT guy went to leave the room
without washing his hands.  The Harvard guy, appalled, called after him:
"At Haahhhhvaahhhd, they teach us to wash our hands after we urinate."
The MIT guy looked back at him and said, "At MIT they teach us not to
urinate on our hands."

Moral?  The goal of hygiene is effect, not process.

... with apologies, btw, to Harvard folks.  No slight intended.  I'm sure
you've got your own MIT/Harvard jokes where you've exchanged heroes and
villains from the original and correct form of the joke and where it still
kinda almost sounds funny, at least to you guys...

Why is Scheme not a Lisp? Kent M Pitman 3/17/02 10:11 AM
Tim Bradshaw <t...@cley.com> writes:

Yes, I was going to suggest this.  That's the reason I talked the (X3)J13
committee into accepting DEFINE-SYMBOL-MACRO in the language in the first
place--it allows the implementation of compatibility with Scheme in a
straightforward way, both for this and for lexical globals.

Doing this would probably satisfy a Schemer.  I don't think it would satisfy
a CL person because (eq (not nil) 't) won't work.  But the choice is really
just what universe you want to live in.  There are many tools for creating
different world-models in CL...

data hygiene [Re: Why is Scheme not a Lisp?] Kent M Pitman 3/17/02 10:15 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> The really significant difference is not the hygene one, which CL
> could have without too much trouble.  The big difference is that CL

> thinks of macros as *functions* from forms to forms, and Scheme has a
> simpler pattern transformation method.

I had to laugh here because the Scheme community would never tolerate
me saying a statement like "The real issue between the scheme sort
function and the CL sort function is that Scheme thinks everything is
just handled by a single general function and CL pattern-matches on a
few simple keywords for finer grained functional control."  I would be
laughed out of the room for calling a less general mechanism
"simpler".

Not that I don't agree that pattern or keyword things are simpler.

I just don't agree that you shouldn't have access to the fully general
system (which, btw, CL SORT doesn't keep you from doing, it just _also_
lets you manage things by keywords, and which, btw, Scheme macros don't
let you do because it _only_ lets you manage things by pattern matching).

Why is Scheme not a Lisp? Pierre R. Mai 3/17/02 10:03 AM
ces...@qnci.net (William D Clinger) writes:

> Kent M Pitman wrote:
> > This is a nice succinct example of where we take a different view on
> > the same data.  I perceive that you think writing #'foo is somehow a
> > negativity because you don't what to write it.  I think what you don't
> > see is that I don't have any negative take on the writing of #'foo and
> > so I am not negatively biased away from using it.
>
> Yes.  What I said was misleading here.  It's not that having to write
> #'foo instead of foo is a burden, it's that the explicit coercion from
> function to value, if you will, induces a subtle psychological set that
> functions are not values, or at least not like other values.

That sounds confused.  (function foo) doesn't "coerce" a "function" to
a "value".  It looks up the value that the symbol foo is bound to in
the currently active "function" environment.

Now how muddied must a programmer's mind be, to believe that there is
a fundamental difference between values based on the environment that
they came from?  Do Scheme programmers regularly feel that values
obtained from the global lexical environment are fundamentally
different from values obtained from some other environment?  I don't
think so.

I'm fairly certain that CL programmers don't see a fundamental
difference between values looked up in different symbol namespaces
(aka packages),  and neither would a CL programmer see a fundamental
difference between the value he gets from (function foo), to the one
he gets from foo, or (symbol-function 'foo) or (gethash 'foo ...), or
any other form.  They are all values, though some of them might be of
type function and some of another type.

It rather seems to me that your own slightly confused understanding of
Common Lisp is the reason for the bias perceived by you, and nothing
that CL programmers encounter or entertain.

Regs, Pierre.

--
Pierre R. Mai <pm...@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein

Why is Scheme (not ?) a Lisp? Bijan Parsia 3/17/02 11:00 AM
On 17 Mar 2002, Julian Stecklina wrote:

> Bijan Parsia <bpa...@email.unc.edu> writes:
>
> [...]
>
> > > and the arguments between
> > > Scheme and CL people are similar to the arguments between Roman Catholics
> > > and Protestants - they're both just more vampire-cultist christians to the
> > > outside observer, though a member of either group will argue at length
> > > about con/trans-substantiation, the status of the virgin mary, etc....
> >
> > This is *really* offensive.

To me.

> That lies in the eye of the beholder. :) I do _not_ feel
> offended. Even though I live in a mainly protestant area, but nobody
> does care here either.

Actually, it's not the Prot/catholic/christian bash that offended me
:) Well, much.

I dislike the appropriation of "outside observer". As niether Christian
(or religious), nor Schemer, nor CLer (more than dabbler), I *really*
resent the idea that the "outside observer" is supposed to be such a
stupid jerk as is painted above. Outsider ~= ignorance and not caring
about that ignorance.

Cheers,
Bijan Parsia.

Why is Scheme not a Lisp? Joe Marshall 3/17/02 11:34 AM

"Tim Bradshaw" <t...@cley.com> wrote in message
news:ey3bsdne1u0.fsf@cley.com...

I think that what he means is `automatically' or `transparently'.
If a `hygienic macro' is one that avoids all name conflicts, then you
can get them by judicious use of GENSYM.  What Scheme's pattern matching
macros give you is automatic deduction of what needs to be GENSYM'ed.

This can in fact be done in Common Lisp by `painting' the code that
is being substituted, but while this may be `the right thing' for Scheme,
it is `solving a non-problem' in Common Lisp.

First-class symbols (Re: Why is Scheme not a Lisp?) Joe Marshall 3/17/02 11:46 AM

"Rahul Jain" <rj...@sid-1129.sid.rice.edu> wrote in message
news:87g02ztzb7.fsf@photino.sid.rice.edu...

> tb+u...@becket.net (Thomas Bushnell, BSG) writes:
>
> > "Joe Marshall" <prunes...@attbi.com> writes:
>

[Lot's of Thomas Bushnell, BSG's opinions elided.]

Please be careful cutting and pasting.  The post had no
content attributable to me, yet it appeard that at least
some of it must have been.

~jrm

Why is Scheme not a Lisp? William D Clinger 3/17/02 12:10 PM
Erik Naggum wrote:
>   It probably surprises you to learn that symbols in the common-lisp
>   package cannot be defined or bound in a conforming program, so it is
>   actually _true_ that "function names cannot be shadowed" (which is a very
>   strange way of saying it. but I can sort of reverse-engineer the proper
>   meaning from it).

It probably surprises you that I was one of the people who
pointed out the need for this restriction when Common Lisp
was being standardized.

Will

Why is Scheme not a Lisp? William D Clinger 3/17/02 12:13 PM
Thomas Bushnell wrote
> It's right that Lisp2 doesn't force you to follow those rules, but if
> you don't follow them, then you can't claim that CL macros are
> hygenic.

On 15 March, at 11:10:19 PST, Rahul Jain quoted the above and replied:
> No one claimed that they are. Your reading skills are deteriorating.

On 15 March, at 23:50:16 PST, Rahul Jain wrote:
> Common Lisp has hygenic macros, too.

For the record:  Common Lisp does not have hygienic macros.

Hygienic macros are not just macros that avoid inadvertent
name captures provided all programmers involved follow a
certain programming discipline and don't make any mistakes,
as everyone agrees is true of CL macros; hygienic macros
are macros that avoid name captures no matter how incompetent
the programmers and no matter how many mistakes they make.

"Hygienic macros" were invented circa 1986 by Eugene
Kohlbecker, and have been the subject of quite a few research
papers since then; see http://library.readscheme.org/ and
click on "Macros".

It would not be hard to add hygienic macros to Common Lisp,
although the fact that CL is a Lisp2 does create a certain
technical problem that do not arise in a Lisp1.  I would be
happy to discuss this with anyone who has first understood
the concept of hygienic macros and the standard algorithms
for implementing them.

Will

Why is Scheme not a Lisp? William D Clinger 3/17/02 12:59 PM
Kent M Pitman wrote:
> I sometimes see my role in the possibly-moribund Scheme authors
> committee as the well-meaning but ineffectual mirror of yours in the
> CL community, so we are kindred spirits you and I, each doomed to have
> all the power of a nagging conscience in the face of actions beyond
> our control....

Quite so.

> If I would start seeing words of support from the Scheme community, and
> active encouragement from such influential people that they should embrace
> and respect CL, I would take a different posture.

I cannot in good conscience encourage everyone to embrace CL,
just as I cannot in good conscience encourage everyone to
embrace Scheme or Java.  They're just programming languages,
and people should use a language when it's a good tool for
the job at hand, and avoid a language when it's the wrong
tool.

I do encourage people to respect Common Lisp, just as they
should respect Scheme or C++ or Java.  That is to say, all
programming languages deserve critical respect:  Acknowledge
what they do right, but don't turn a blind eye to their
shortcomings, and don't pretend they are anything more than
what they are.

Programming languages don't have feelings, so their feelings
aren't hurt when they are criticized.  The people who form a
language community have feelings, though, and those feelings
are easily hurt when their favorite language is criticized.
If we were all more careful not to identify ourselves with
our favorite language(s), and to view our favorite language(s)
more critically, our feelings wouldn't be so easily hurt.

> So when people criticize CL, Scheme is criticized in return.  And
> that's a shame.

Not to mention a waste of time.

> Do you think it would be useful or productive at this point to try to
> create a Lisp1 preprocessor for CL?

No.  Maybe I'm wrong, but I think it's too late in the game.
CL and Scheme have by now found their own niches and user
communities, with remarkably little overlap.

That wasn't the ideal outcome, but it wasn't the worst possible
outcome either.

It's been nice talking to you, Kent.  I think we've made some
progress toward understanding each other's point of view.

Will

Why is Scheme not a Lisp? Kent M Pitman 3/17/02 1:10 PM
Paul Foley <myc...@actrix.gen.nz> writes:

> On 17 Mar 2002 02:15:21 -0800, Thomas Bushnell, BSG wrote:
>
> > #t and #f are constants, and that's why Scheme makes them not just
> > symbols.  The issue is that symbols are *all* available for variable
> > names.  There is no more reason to have t use up a variable name than
> > 6.
>
> Oh, so you can use 6 as a variable name in Scheme, then, can you?

Actually, it troubles me enormously that Scheme has special cases from its
usual rule about special forms and functions.  I always felt like it would
be "cleaner" if the car of the form were always a special form.  So one would
write

 (LAMBDA (FOO)
   (CALL (VAR +) (VAR FOO) (QUOTE 3)))

I'm amused to see the otherwise pristine Scheme world take

 (LAMBDA (FOO)
   (+ FOO 3))

as a "clean and regular" notation since it involves special cases that need
not be in the language definition.  Then again, they are special cases that
suit the people who designed Scheme, so they are more blessed than
the special cases other languages have, which don't suit the people who
designed Scheme.  This is an important distinction.  ;)

If the Scheme language were more regular, the Lisp1/Lisp2 issue would be a
lot less prominent.  A lot of the aggravation is caused by selling the
leftover real estate after the special operator namespace was grabbed.
If CL had made a decision to say it was ok to use other &names for variables,
the Scheme people would be all over us for the "irregular special case of"
 (defun foo (&x &optional &y)
   (+ &x (or &y 3)))
which would be a perfectly valid program.  Both Lisp1 and Lisp2 designers
realized it was too lucrative a space to just leave empty after the allocation
of special operators.  CL made the arbitrary but consistent decision to
allow "function names" and "macro names" in the car of a form when special
forms were not there.  Scheme made the arbitrary decision but consistent
decision to allow arbitrary expressions in the car of a form when there was
no special form.  But then, weirdly, Scheme went back and haired up the rule
with even more strangeness because now the rule is "Maybe it's a special form?", No? "Maybe it's a macro?", No? "Ok, now claim it's consistent to put a
form here".  But it's really not like that at all.  Because LET is not a
variable and I can't use LET anywhere but the head of a list to get its
magic meaning.  So the Scheme rule is quite inconsistent.  CL, by contrast,
pretty consistently says "look, it's an operator or nothing" and then it
triages by operator type.  That's in my book more consistent than the
Scheme rule.  And it bugs me to take grief for it as if we're the inelegant
language.   I'm happy to say there's some inelegance on both sides for wanting
to grab the shorthand notation of (f x) at all where f is not a primop; but
if we're not going to stop there and we're going to delve deeper, I think
Scheme has its own share of dirty laundry to answer for.

Why is Scheme not a Lisp? Kent M Pitman 3/17/02 1:21 PM
Kent M Pitman <pit...@world.std.com> writes:

> Actually, it troubles me enormously that Scheme has special cases from its
> usual rule about special forms and functions.  I always felt like it would
> be "cleaner" if the car of the form were always a special form.  So one would
> write
>
>  (LAMBDA (FOO)
>    (CALL (VAR +) (VAR FOO) (QUOTE 3)))

This post got de-railed as I went down a side-rant that had no relation
to why I had opted to respond.

What I meant to say and never got to is that this notation permits, without
ambiguity,

 (LAMBDA (1 2 3)
   (CALL (VAR +) (VAR 1) (VAR 2) (VAR 3)))

There's just not an easy shorthand for variables that are not symbols...

And you have to define what predicate is used.  I usually prefer EQUAL so
I can contemplate notations like:

 (LAMBDA ((FUNCTION F) F)
   (CALL #'F F))

Heh.

These are all just "possible worlds not visited" in Lisp design space.
They are vaguely related to the world I talked about recently when I
mentioned a bridge between the CL and Scheme worlds.  There is a lot more
detail one has to do, and I had worked out some of that...

Why is Scheme (not ?) a Lisp? Christopher Browne 3/17/02 2:09 PM
In an attempt to throw the authorities off his trail, Bijan Parsia <bpa...@email.unc.edu> transmitted:

>> and the arguments between Scheme and CL people are similar to the
>> arguments between Roman Catholics and Protestants - they're both
>> just more vampire-cultist christians to the outside observer,
>> though a member of either group will argue at length about
>> con/trans-substantiation, the status of the virgin mary, etc....

> This is *really* offensive.

> Interesting that you conflate all Protestants.

Protestants _do_ tend to have a fair bit of common ground, in having
stemmed from common religious roots, in much the same way that pretty
much all Scheme implementors and users would be reasonably expected to
have common respect for R*RS, having Rather A Lot of Parentheses in
their language, liking the notion of having first class functions
around, and such.

> Really interesting that the outsiders have *all* the defining
> power. Sorry, that's not how it usually goes. Oh, and yes, my
> ancesters are *Iranian*, not *Persian*. Thanks ;)

I'm quite sure that the distinction isn't of too much import to me,
not only from a strict utilitarian perspective, but also since both
those names of peoples are _English_, and thus are highly likely to be
of much more recent provenance than whatever were the names that
Iranian or Persian ancestors actually used.

Personally, I figure that "Iranian" more than likely traces back to
some word in Farsi, and that "Persian" likely also traces back to some
(perhaps distinct) word in Farsi, and that any differences that result
are likely to be most meaningful in Farsi (or whichever other
language, almost certainly _predating English_, is most relevant).

Getting too excited about the English words strikes me as being as
silly as getting deeply into bizarre interpretations of the Bible
based on the niceties of English words, when reality is that the Bible
was certainly _not_ written in the English language.

It's sorta like trying to draw sweeping conclusions about the CL
standard based on looking at snippets of assembly language generated
by CMU/CL.  There may be legitimate conclusions to be found, but it
would be far more worthwhile to actually read the HyperSpec...

> I guess the notions of respect and tolerance and understanding are
> just completely foreign.

They're pretty "foreign" notions; with the number of "wars of
intolerance" that have circled the globe, over the millenia, it is not
at all clear to me that there is anywhere that they could be
considered to be "domestic" notions...
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www3.sympatico.ca/cbbrowne/finances.html
Why do we put suits in a garment bag, and put garments in a suitcase?

data hygiene [Re: Why is Scheme not a Lisp?] Thomas Bushnell, BSG 3/17/02 2:03 PM
Kent M Pitman <pit...@world.std.com> writes:

> I just don't agree that you shouldn't have access to the fully general
> system (which, btw, CL SORT doesn't keep you from doing, it just _also_
> lets you manage things by keywords, and which, btw, Scheme macros don't
> let you do because it _only_ lets you manage things by pattern matching).

Most Scheme systems of course do provide access "under the hood" to
the lower level non-hygenic system (though, with the general
acceptance of R5RS macros, this is becoming *less* common for some
curious reason).

The real problem is that providing transformation functions, rather
than just pattern matches, makes it gobs harder to figure out just how
hygiene is supposed to work.  Do you have any ideas on what might do
the trick?

Thomas

Why is Scheme not a Lisp? Rahul Jain 3/17/02 2:19 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
>
> > How else will you get values in scheme, since symbols don't have
> > values? Where else will the value of "t" as used in my macro come
> > from? This is one reason why scheme _needed_ to have #t and #f,
> > whether or not it was explicit at the time. Unfortunately, a user
> > cannot implement such a feature.
>
> "Symbols don't have values"?  They don't in CL either, except for
> special variables, for which you might want to say that.  

I'm not (only) talking about specials, but functions and constants,
too. basically anything provided by the language standard.

> #t and #f are constants, and that's why Scheme makes them not just
> symbols.  The issue is that symbols are *all* available for variable
> names.  There is no more reason to have t use up a variable name than
> 6.

Right, and when my application wants to define a constant, how does it
do so?

> > > Except, that is, for the one case of "t" and "nil".  Those values
> > > *are* locked in at read time, by making those two symbols Very
> > > Special.

> > Wrong. The values of T and NIL are locked into the SYMBOLS. Nothing
> > says that the string "t" has a true value.

> And nothing I said was about the string "t"; it was about the
> *symbols*, which are Very Special.

Exactly, the symbols. This is where scheme differs. None of the
semantics of code can be determined from the symbols. Symbols are
dependent creatures which only have meaning in a specific lexical
environment. Otherwise, you'll be likely to use the wrong meaning.

> > In reality, this whole difference is just a side-effect of the issue
> > of symbolic processing.

> Your new mantra of the day!  If you knew what it meant... oh, no,
> you're just chanting.  Ok.

I get the impression that THIS is your new mantra. Denying that I know
what I'm talking about can be a very effective way of allowing
yourself to keep believing what you think to be true.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Matthias Blume 3/17/02 2:42 PM
"Joe Marshall" <prunes...@attbi.com> writes:

Please, notice that there are *two* different kinds of inadvertant name capture
that Scheme macros avoid.  Only one of them can be worked around using gensym
at macro expansion time.

(I do understand that common lispers feel that the other kind does not occur very
often or at all in their code.  No need to point this out.)

Why is Scheme not a Lisp? Kent M Pitman 3/17/02 2:55 PM
Matthias Blume <bl...@hanabi.research.bell-labs.com> writes:

> Please, notice that there are *two* different kinds of inadvertant
> name capture that Scheme macros avoid.  Only one of them can be
> worked around using gensym at macro expansion time.

I'm not sure I understand what you mean here.  Do you want to say the two
issues so we're all on the same page.

data hygiene [Re: Why is Scheme not a Lisp?] Bruce Hoult 3/17/02 3:18 PM
In article <m2663vm...@mycroft.actrix.gen.nz>,
 Paul Foley <myc...@actrix.gen.nz> wrote:

> On 17 Mar 2002 00:03:10 -0800, Thomas Bushnell, BSG wrote:
>
> >> > The CL one allows for slightly more general macros;
>
> > By "slightly", I meant that the additional computational power is
> > rarely used.
>
> Define "rarely".  Just looking at a few of my files, I count 46 macro
> definitions, of which 19 are simple pattern rewrites and 27 do some
> computation in the expander function.  I doubt that's atypical.

How often is the computation *necessarily* done in the expander
function, and how often could it be left to the compiler to constant
expression evaluate?

This may not be easy to judge.

-- Bruce

data hygiene [Re: Why is Scheme not a Lisp?] Rahul Jain 3/17/02 3:17 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
>
> > It's only rarely used if all your macros have simple patterns to
> > them. I don't know if you can you destructure a plist with scheme
> > macros, can you?
>
> Some kinds of "looking inside" work just fine.  For example, you can
> expand a LET form the following way:

Yes, I'm aware that it can destructure repeated lists of isomorphic
structure. That's why I asked specifically about plists, which are
another macro syntax I have used.

> Indeed, that's what you want for destructuring a plist.  But I think
> it's generally thought by Lispers that it's a shame that plists and
> alists have different structure, and if it were to be done over again,
> plists would have the alist structure.  So you can't destructure a
> plist easily, but except when actually dealing with plists, you are
> advised in Common Lisp to use alists instead, in general.  

Maybe in some cases, but &key is essentially a plist structure, and
one of my macros destructures an &key-like form without any predefined
keys. (for use in outputting HTML)

Note that I'm not using the plist for its key-value mapping structure,
but for the syntactic structure, how it is typed in.

> Incidentally, it's been shown now that it *is* possible to do
> arbitrary destructuring with Scheme macros, because it turns out that
> with letrec-syntax you can create mutually recursive macro definitions
> that are Turing complete.  But I certainly wouldn't claim that the
> results are pretty or easily understandable.

Sounds like they're figuring out the "hygenic macro Y-combinator" or
something. It's amazing what brilliant people can do with
artificially-limited tools. :)

My guess at how to do this would be to essentially have each of the
definitons be a "parsing state" and effectively generate a
state-machine to parse the entire macro structure by recursive
descent. Sounds like a painful way to do it, however.

> > Your refusal to accept that some people might actually enjoy being
> > able to cleanly do symbolic processing and calling the features which
> > allow that misfeatures is what I'd call boosterism.

> I haven't called them misfeatures at all.  I've said they seem to me
> to be the right thing within the broader world of Common Lisp.

Then why do you insist that they are "bad"? I can't see any other
reason for insisting that we are wrong for liking them.

> Never said you were misguided at all.

I think saying that we are wrong for liking packages is effectively
the same thing, and that what I (at least) percieve you mean.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

First-class symbols (Re: Why is Scheme not a Lisp?) Rahul Jain 3/17/02 3:27 PM
"Joe Marshall" <prunes...@attbi.com> writes:

> Please be careful cutting and pasting.  The post had no
> content attributable to me, yet it appeard that at least
> some of it must have been.

Oops, sorry about that.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

data hygiene [Re: Why is Scheme not a Lisp?] Rahul Jain 3/17/02 3:31 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Most Scheme systems of course do provide access "under the hood" to
> the lower level non-hygenic system (though, with the general
> acceptance of R5RS macros, this is becoming *less* common for some
> curious reason).

Because they realize that hygenic macros are the right way to
implement macros given the rest of Scheme.

> The real problem is that providing transformation functions, rather
> than just pattern matches, makes it gobs harder to figure out just how
> hygiene is supposed to work.  Do you have any ideas on what might do
> the trick?

It's not hygiene, it's the NEED for hygeine caused by the fact that I
can't say "I want the meaning of such-and-such symbol-name from
such-and-such package". The surrounding code of the macro can shadow
any definition of any token, and the macro will unwittingly use that
definition, not the one it expected.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Rahul Jain 3/17/02 3:34 PM
Matthias Blume <bl...@hanabi.research.bell-labs.com> writes:

> Please, notice that there are *two* different kinds of inadvertant
> name capture that Scheme macros avoid.  Only one of them can be
> worked around using gensym at macro expansion time.

> (I do understand that common lispers feel that the other kind does
> not occur very often or at all in their code.  No need to point this
> out.)

I think it's more accurate to say, that if it happens, it happens out
of intent, not accident, due to the package system. (assuming you're
talking about lexical shadowing of bindings to symbols that are used
in the macros.)

I suppose it could happen out of accident, but that's like saying that
someone using floating point "accidentally" created an algorithm which
resulted in catastrophic cancellation. It's an accident caused by the
user not knowing how to use his tools.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Bruce Hoult 3/17/02 3:46 PM
In article <87u1rfs...@photino.sid.rice.edu>,
 Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:

> tb+u...@becket.net (Thomas Bushnell, BSG) writes:
>
> > Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:
>
> > > Because CL has macros that do symbolic processing. In CL, symbols
> > > matter. If you want a specific symbol, use it.
>
> > You know, macros really have nothing to do with whether "t" is a
> > special magic symbol.  Or if you think they do, maybe you could
> > describe the connection?  
>
> If a macro inside the body of a function that rebinds T uses T, then
> it will not work as the macro writer expected. This is because CL
> macros, again, are symbolic in nature, and not value-oriented as it
> seems scheme macros must be.

That depends on whether unbound names in macros are lexically or
dynamically scoped.

I don't know what happens in Scheme, but in Dylan if a macro uses the
canonical True value #t (or any other name, for that matter) then the
binding used is the one current at the point that the macro is
*defined*, not used.

-- Bruce

First-class symbols (Re: Why is Scheme not a Lisp?) Joe Marshall 3/17/02 3:45 PM

"Rahul Jain" <rj...@sid-1129.sid.rice.edu> wrote in message
news:87it7u22sl.fsf@photino.sid.rice.edu...

> "Joe Marshall" <prunes...@attbi.com> writes:
>
> > Please be careful cutting and pasting.  The post had no
> > content attributable to me, yet it appeard that at least
> > some of it must have been.
>
> Oops, sorry about that.

No problem.

(It's hard enough defending my *own* opinions, let alone
someone else's!)

Why is Scheme not a Lisp? Rahul Jain 3/17/02 3:56 PM
Bruce Hoult <br...@hoult.org> writes:

> In article <87u1rfs...@photino.sid.rice.edu>,
>  Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote:

> > If a macro inside the body of a function that rebinds T uses T, then
> > it will not work as the macro writer expected. This is because CL
> > macros, again, are symbolic in nature, and not value-oriented as it
> > seems scheme macros must be.

> That depends on whether unbound names in macros are lexically or
> dynamically scoped.

Scheme doesn't have dynamic scope, however.

> I don't know what happens in Scheme, but in Dylan if a macro uses the
> canonical True value #t (or any other name, for that matter) then the
> binding used is the one current at the point that the macro is
> *defined*, not used.

Right, that's because #t is a magical string (at least in scheme), not
a symbol with a bound (lexical or dynamic) value. There is no way to
define such "magical strings" in scheme, since there are no
read-macros. In CL, we have defconstant.

The locking-in of "symbol-values" in macros at
macro-definition-eval-time means that macros don't do symbolic
manipulations, but value manipulations. This is a very reasonable, and
essential, way of dealing with macros in languages which do not have
namespaces for symbols.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

data hygiene [Re: Why is Scheme not a Lisp?] Thomas Bushnell, BSG 3/17/02 4:10 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Sounds like they're figuring out the "hygenic macro Y-combinator" or
> something. It's amazing what brilliant people can do with
> artificially-limited tools. :)
>
> My guess at how to do this would be to essentially have each of the
> definitons be a "parsing state" and effectively generate a
> state-machine to parse the entire macro structure by recursive
> descent. Sounds like a painful way to do it, however.

It is really quite a surprise that people figured out a way to write
arbitrary macro expanders in R5RS macros.  

Nobody would say that it's painful, however: they'd say that trying to
write general functional macros in it is downright insane.  :)

It's in the realm of a curiosity; no more.

> > I haven't called them misfeatures at all.  I've said they seem to me
> > to be the right thing within the broader world of Common Lisp.
>
> Then why do you insist that they are "bad"? I can't see any other
> reason for insisting that we are wrong for liking them.

I don't insist that they are bad.  The are the best thing anyone's
ever come up with in Common Lisp.  There may be better things--there
are things that people have problems with--but it's not clear if there
is a solution that works as well.

> > Never said you were misguided at all.
>
> I think saying that we are wrong for liking packages is effectively
> the same thing, and that what I (at least) percieve you mean.

No, I never said you were wrong for liking packages.  Packages are
right for Common Lisp, but would be wrong for Scheme.

Thomas

Why is Scheme not a Lisp? Matthias Blume 3/17/02 4:17 PM
Kent M Pitman <pit...@world.std.com> writes:

One is the inadvertant capture of a variable by a local binding inserted by the macro.
(That's the kind that gensym works around well.)

The other is the inadvertant capture of a variable that is referenced
freely in a macro's expansion, where the capture is due to a a local
binding in the macro expansion's context which was not present at the
time the macro was defined.
(That's the kind that does not occur often in CL because most of such
free references are either to functions or to specials -- for which we rely
basically on convention to prevent capture from occuring.)

data hygiene [Re: Why is Scheme not a Lisp?] Rahul Jain 3/17/02 4:22 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> No, I never said you were wrong for liking packages.  Packages are
> right for Common Lisp, but would be wrong for Scheme.

Right, packages are the best way we know of so far for doing symbol
namespacing, symbol namespacing is essential to doing symbolic
processing. Lisp is a symbolic processing language at the core. Scheme
is something else, best left to the Scheme community to define (after
all, they are the ones who defined the language and define the ways in
which it will grow in the future).

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

data hygiene [Re: Why is Scheme not a Lisp?] Thomas Bushnell, BSG 3/17/02 4:54 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> tb+u...@becket.net (Thomas Bushnell, BSG) writes:
>
> > No, I never said you were wrong for liking packages.  Packages are
> > right for Common Lisp, but would be wrong for Scheme.
>
> Right, packages are the best way we know of so far for doing symbol
> namespacing, symbol namespacing is essential to doing symbolic
> processing.

Define here what you mean by "symbolic processing" and "symbol
namespacing".

I didn't say they were the best way we know of for all possible
definitions.  Indeed, what I said was carefully written, and your
rewriting is *not* what I said, under the appearance of agreement.

I said that packages are the best thing we know of for Common Lisp.
Common Lisp symbol namespaces are *not* the only way to do symbolic
processing.

Thomas
 

Why is Scheme not a Lisp? Thomas F. Burdick 3/17/02 7:11 PM
Erik Naggum <er...@naggum.net> writes:

> (defpackage "LOSERVILLE"
>   (:use "COMMON-LISP" ...)
>   (:shadow "T"))
>
> (defparameter t cl:t)
>
>   so in Loserville, you may bind t, and most of the time, it will still
>   work.  If you want it to work all the time, do not move to Loserville.

Couldn't you instead do

  (setf (symbol-value 't) cl:t)

and not be stuck with a special variable?  I don't see anything that
prohibits it (although I admit to not looking too hard, partly because
I like this behavior).

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

Why is Scheme not a Lisp? Eli Barzilay 3/17/02 7:54 PM
Kent M Pitman <pit...@world.std.com> writes:

> [...]  I always felt like it would be "cleaner" if the car of the


> form were always a special form.  So one would write
>
>  (LAMBDA (FOO)
>    (CALL (VAR +) (VAR FOO) (QUOTE 3)))

The new MzScheme syntax system has something very similar to this, so
you can redefine "special" macros that determine what happens to
applications, variables and (quoted) values.

  http://download.plt-scheme.org/doc/200alpha12/html/mzscheme/mzscheme-Z-H-11.html#%_sec_11.5

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

Why is Scheme not a Lisp? Eli Barzilay 3/17/02 7:59 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Bruce Hoult <br...@hoult.org> writes:
>
> > I don't know what happens in Scheme, but in Dylan if a macro uses
> > the canonical True value #t (or any other name, for that matter)
> > then the binding used is the one current at the point that the
> > macro is *defined*, not used.
>
> Right, that's because #t is a magical string (at least in scheme),
> not a symbol with a bound (lexical or dynamic) value. There is no
> way to define such "magical strings" in scheme, since there are no
> read-macros. In CL, we have defconstant.

Either you didn't read all of what Bruce wrote ("any other _name_"),
or you're unaware of the second usage of hygienic macros in Scheme --
the first usage would roughly be translated to CL by using gensyms for
new bindings and this second usage could be translated by planting
values in the macro output.

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

Why is Scheme not a Lisp? Kent M Pitman 3/17/02 8:06 PM
t...@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:

> Erik Naggum <er...@naggum.net> writes:
>
> > (defpackage "LOSERVILLE"
> >   (:use "COMMON-LISP" ...)
> >   (:shadow "T"))
> >
> > (defparameter t cl:t)
> >
> >   so in Loserville, you may bind t, and most of the time, it will still
> >   work.  If you want it to work all the time, do not move to Loserville.
>
> Couldn't you instead do
>
>   (setf (symbol-value 't) cl:t)
>
> and not be stuck with a special variable?  I don't see anything that
> prohibits it (although I admit to not looking too hard, partly because
> I like this behavior).

The better way to do this is

 (define-symbol-macro t cl:t)

Just because T is BOUNDP doesn't mean you can reference it free in CL.
CL does not define the meaning of free variables that are not special.
It does, however, define the meaning of a global symbol macro.

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Espen Vestre 3/18/02 1:06 AM
Erik Naggum <er...@naggum.net> writes:

>   So, AVOID THE GERMAN XANALYS OFFICE!  

Xanalys delivers excellent service to ther european customers through
their office in Germany.

That their representative is a man who prefers politeness is hardly
a reason to avoid them...
--
 Espen - a satisfied customer

What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?) Peter Lewerin 3/18/02 1:11 AM
>>Uh oh.  Stop me before I try to make more pack-a-term humor.
>
> It's all in fun until someone loses a trunk...

Tusk, tusk.

Why is Scheme not a Lisp? Erik Naggum 3/18/02 1:51 AM
* William D Clinger
| It probably surprises you that I was one of the people who pointed out
| the need for this restriction when Common Lisp was being standardized.

  Yes, that surprises me.  But thanks for the information, and also that it
  got that way.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/17/02 9:12 AM
Paul Foley <myc...@actrix.gen.nz> writes:

> On 17 Mar 2002 02:15:21 -0800, Thomas Bushnell, BSG wrote:
>
> > #t and #f are constants, and that's why Scheme makes them not just
> > symbols.  The issue is that symbols are *all* available for variable
> > names.  There is no more reason to have t use up a variable name than
> > 6.
>
> Oh, so you can use 6 as a variable name in Scheme, then, can you?

No, the point (which, I labor to repeat, was not mine, and is one that
CL programmers seem to frequently lament) is that not everything that
fits the *syntax* of a variable name can be used as one.

It's a minor design wart, that's all.

Thomas

data hygiene [Re: Why is Scheme not a Lisp?] Thomas Bushnell, BSG 3/17/02 9:15 AM
Paul Foley <myc...@actrix.gen.nz> writes:

> On 17 Mar 2002 00:03:10 -0800, Thomas Bushnell, BSG wrote:
>
> >> > The CL one allows for slightly more general macros;
>
> > By "slightly", I meant that the additional computational power is
> > rarely used.
>
> Define "rarely".  Just looking at a few of my files, I count 46 macro
> definitions, of which 19 are simple pattern rewrites and 27 do some
> computation in the expander function.  I doubt that's atypical.

Perhaps not; are you sure that the computing ones can't be done with
Scheme-style rewrites?  (Note that Scheme rewrites all for cond-like
pattern matching.)  

Thomas

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/17/02 9:11 AM
Paul Foley <myc...@actrix.gen.nz> writes:

> Perhaps you need to be clearer about what you're saying.  You do seem
> to be saying that you don't understand symbols.  In particular, you
> seem not to understand that a symbol is distinct from its name.
> That's probably why you think that just interning the name and calling
> that a "symbol" is good enough.

Um, I never said any of that.

> is perfect legal Common Lisp -- as long as this T is not CL:T, because
> that's a constant, and you can't use constants as variables, obviously!

Which is, exactly, what the person was lamenting about; that two
particular symbols -- *symbols* -- are unavailable as variables.

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/17/02 9:14 AM
Tim Bradshaw <t...@cley.com> writes:

> * Thomas Bushnell wrote:
>
> > Implementing it *efficiently*.  I don't think you understand what the
> > issues are with hygienic macros; maybe you should go read the papers.
>
> Can you be clear what you mean about `efficiently'.  For instance if I
> blindly rename *all* symbols I bind then probably for a typical macro
> this is 0-10 symbols, and the overhead is entirely at macro expansion
> time.  There must be some other meaning of `efficient' here.

It's expansion time overhead.  The previous common implementation of
hygienic macros in Scheme was O(n^2) [at expansion time] and this was
judged to be prohibitive enough that it helped kept it out of the
standards.

Jonathan Rees (and someone else whose name escapes me at present)
wrote "Macros That Work", which gives a better algorithm for hygienic
expansion which is O(n).

Thomas

Why is Scheme not a Lisp? Erik Naggum 3/18/02 2:44 AM
* William D Clinger
| Programming languages don't have feelings, so their feelings aren't hurt
| when they are criticized.  The people who form a language community have
| feelings, though, and those feelings are easily hurt when their favorite
| language is criticized.  If we were all more careful not to identify
| ourselves with our favorite language(s), and to view our favorite
| language(s) more critically, our feelings wouldn't be so easily hurt.

  This seems to make exactly the mistake I have tried (obviously in vain)
  to warn against over many years: Do not drop the context of the forum in
  which you say something.  In particular, if someone argues privately that
  he thinks CL sucks, that is his opinion and he is entitled to it and to
  express it, and I may decide to ignore it, ask why, challenge his views,
  or express my disagreement according to my own desires at the time.
  However, if he goes to a forum for people who like Common Lisp and
  expresses the same opinion, it is no longer an opinion he is entitled to
  express in that forum.  This is really not different from being critical
  of someone's choice of furniture -- as long as you are not a guest at
  their house.  If you have such a gripe with it, do not visit their house.
  If you think CL sucks, do not annoy people who expressly meet in order to
  share their common appreciation for Common Lisp.  I mean, lots of bad
  people hate cats, but if they show up at a cat show and "express their
  opinion", they have done something clearly wrong.  Is this really so hard
  for people who have a personal and emotional opinion about CL to grasp?

  Similarly, people who meet to discuss something, with a purpose to learn
  and understand and become more proficient and skilled, have no use for a
  jerk who wants to bug and annoy people with his pet peeves that run
  counter to such purposes.  In a professional forum, and I consider both
  comp.lang.lisp and comp.lang.scheme as such, people have a moral
  obligation to be intelligent.  Stupditity has no place in such forums.

  So this is _not_ about any personal feelings being hurt, nobody should be
  personally offended by anyone's opinions, noobody should "identify" with
  the language in any personal sense, but the forum _is_ identified with
  the language, and it _is_ rude an hostile to attack that which _is_ the
  purpose of the forum, and that means nobody should even consider posting
  about his hatred for Common Lisp in this forum any more than anybody
  should consider posting about his hatred for gays in soc.motss or for
  cats in rec.pets.cats.  It really is this simple.  Yet Scheme freaks come
  here quite often to express their very strong dislike of some Common Lisp
  feature or another, and there are a few people who seem to think that
  they can get help solving their problems if they tell everybody how they
  hate Common Lisp or the sorry "fact" that they cannot use Common Lisp, or
  that it costs too much, or whatever.  This is where people who want to
  use Common Lisp come to help eachother do that, where people who want to
  learn about Common Lisp come to figure things out together, where people
  who want to influence the future direction of Common Lisp can share their
  thoughts and get feedback, but one of the most important traditions in
  the Common Lisp history is: You do not screw the installed base.  To want
  to do so is very hostile to this community, because it is one of the very
  few things that has come to be the basis of our agreement on language
  design.  It is not open for debate, and any desire for change that amount
  to breaking something is simply idiotic in this forum and betrays a
  serious lack of insight into how Common Lisp came to be.  If one does not
  like that, keep that personal opinion away from people who have come
  together in this forum because they _do_ like it.  If it were not for
  that premise, Common Lisp would not be, or would be a _very_ different
  language.

| No.  Maybe I'm wrong, but I think it's too late in the game.  CL and
| Scheme have by now found their own niches and user communities, with
| remarkably little overlap.

  I would appreciate if you could take this conclusion back to the Scheme
  community.  A large number of Scheme folks appear to think that Common
  Lisp somehow "should" have an overlap of interests with them.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Erik Naggum 3/18/02 4:24 AM
* Espen Vestre

| That their representative is a man who prefers politeness is hardly
| a reason to avoid them...

  That he cannot distinguish between his professional role and his personal
  opinions, is.  That he cannot "completely agree" with a desire not to
  post without posting, certainly indicates a several lack of politeness.

  Sure, he prefers politeness, but mostly by requiring others to behave.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Erik Naggum 3/18/02 4:29 AM
* Thomas Bushnell, BSG

| No, the point (which, I labor to repeat, was not mine, and is one that
| CL programmers seem to frequently lament) is that not everything that
| fits the *syntax* of a variable name can be used as one.

  What on earth are you you talking about?  Is it a "problem" that a symbol
  that has been pervasively declared special cannot be lexically bound,
  too?  Do you want _syntax_ to distinguish specials and contants?  Or what?

| It's a minor design wart, that's all.

  You have clearly not understand what a constant variable is.  You
  probably have not even understood special binding, either.

  How many warts does Scheme have from an ML point of view?  Would that be
  a fair way to argue about language warts, or would you prefer to speak
  about language Scheme warts relative to Scheme's design?  If so, why on
  earth are you talking about warts in Common Lisp relative to Scheme's
  design goals?  With all this talk about eval-time environments, you still
  do not seem to manage the concept of a context in human communication.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Espen Vestre 3/18/02 5:05 AM
Erik Naggum <er...@naggum.net> writes:

>   That he cannot distinguish between his professional role and his personal
>   opinions, is.  

Are you counting out the possibility that these two interests may
coincide?
That lisp vendors actually may be interested in a more friendly
climate in comp.lang.lisp?

C.l.l is a phantastic forum for knowledge transfer and community
building.  Even in the noisy scheme vs. CL thread, I've read a lot of
really insightful comments, especially from Kent Pitman and you
(which e.g. helped me understand why I like CL and have a distaste for
scheme myself). But the noise level is high, and the level of rudeness
is sometimes quite unnecessary. So in its current state, I don't think
c.l.l. is something lisp vendors can point at and say: "Look here and
see how the lisp community is thriving, see how helpful it is!" (as
an example of the opposite, flame wars are virtually non-existant on
the quite active info-mcl mailing list).

I can _understand_ why you and others react the way you do sometimes,
but I don't think it's a wise thing to do. This is something I try to
tell my kids as well (I'm a person who has a tendency to shout loud
when I really dislike something, so I speak of experience...): Try to
react as polite and calm as you can. By overreacting in a dispute, you
only risk being regarded as the "impossible" party.
--
  (espen)

Why is Scheme (not ?) a Lisp? David Golden 3/18/02 7:01 AM
Bijan Parsia wrote:

> Outsider ~= ignorance and not caring
> about that ignorance.
>

Huh?  My argument was not that the outsider was ignorant, but that to the
outsider the differences may be inconsequential...   i.e. Being fully aware
of the differences (not ignorant of them) and not caring about them...

The rest of your argument rests on _your_ assumption of ignorance on
the part of the outsider.

I don't think I painted the outsider as a *stupid* jerk. Jerk, maybe.  It's
possible to be fully aware of the intricacies of christianity, or lisp, and
 _still_ recognise that roman catholic., the orthodox churches and the
various flavours of protestant churches are all subsets of "christianity",
or that christianity, islam and judaism are all subsets of "monotheistic
religion", just as one could recognise that scheme or common lisp are
subsets of some "lisp" ideal, and that the "lisp" ideal is a subset of
"programming language concepts".

--
Don't eat yellow snow.

data hygiene [Re: Why is Scheme not a Lisp?] Janis Dzerins 3/17/02 2:53 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> But I think it's generally thought by Lispers that it's a shame that
> plists and alists have different structure, and if it were to be
> done over again, plists would have the alist structure.  So you
> can't destructure a plist easily, but except when actually dealing
> with plists, you are advised in Common Lisp to use alists instead,
> in general.

How do you come up with this stuff?

--
Janis Dzerins

  Eat shit -- billions of flies can't be wrong.

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Nils Goesche 3/18/02 8:58 AM
In article <kw663u3...@merced.netfonds.no>, Espen Vestre wrote:
> Erik Naggum <er...@naggum.net> writes:
>
>> That he cannot distinguish between his professional role and his personal
>> opinions, is.  
>
> Are you counting out the possibility that these two interests may
> coincide?
> That lisp vendors actually may be interested in a more friendly
> climate in comp.lang.lisp?

The best way to achieve a friendlier climate would be to post some
friendly, helpful articles.  Posting hidden attacks against
regular posters now and then will be less effective, I'd say.

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

PGP key ID 0x42B32FC9

Why is Scheme not a Lisp? Bruce Lewis 3/18/02 9:00 AM
Erik Naggum <er...@naggum.net> writes:

>   I have read some of the most ludicrous nonsense about Common Lisp macros
>   in comp.lang.scheme

When did you read that?  I've seen plenty of sentiment on c.l.s favoring
define-macro (present in many Scheme implementations for a long time and
analagous to CL's defmacro) over the hygienic define-syntax introduced
in R5RS.

I can neither remember nor google anything on c.l.s about Common Lisp
macros specifically.

--
<brlewis@[(if (brl-related? message)    ; Bruce R. Lewis
              "users.sourceforge.net"   ; http://brl.sourceforge.net/
              "alum.mit.edu")]>

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/18/02 9:30 AM
Erik Naggum <er...@naggum.net> writes:

>   However, if he goes to a forum for people who like Common Lisp and
>   expresses the same opinion, it is no longer an opinion he is entitled to
>   express in that forum.  

Except that nobody here has been saying that Common Lisp sucks.

data hygiene [Re: Why is Scheme not a Lisp?] Thomas Bushnell, BSG 3/18/02 9:39 AM
Janis Dzerins <jo...@latnet.lv> writes:

> tb+u...@becket.net (Thomas Bushnell, BSG) writes:
>
> > But I think it's generally thought by Lispers that it's a shame that
> > plists and alists have different structure, and if it were to be
> > done over again, plists would have the alist structure.  So you
> > can't destructure a plist easily, but except when actually dealing
> > with plists, you are advised in Common Lisp to use alists instead,
> > in general.
>
> How do you come up with this stuff?

Um, it's true.  plists and alists have unfortunately different
representations, for historical reasons.  The alist representation is
better (for one thing, it's just prettier, but also, it allows for NIL
properties).  

plists are stuck with the first way, however, because there is just
way too much code that knows how they work.  But if you want to make
your own assoc list, you always use the alist representation and not
the plist representation, with the exception of what you store on
actual symbols' plists.

Thomas

Why is Scheme not a Lisp? Nils Goesche 3/18/02 9:41 AM

But that's exactly the impression you get when wading through these
giant Scheme threads we have these days.  Every day I open my news
reader to read my beloved comp.lang.lisp, but all I get these days
are hundreds of articles about Scheme.  I don't *care* about Scheme.
And I care even less about reading arguments trying to convince
me that I should rather use some ``eugenic'' macros or some such to
replace my beloved Common Lisp macros.  Can't people at least use some
name that isn't clearly intended to be insulting when talking about
these things on comp.lang.lisp?  How about calling them ``castrated''
macros instead?

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

PGP key ID 0x42B32FC9

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/18/02 9:53 AM
Nils Goesche <car...@cartan.de> writes:

> But that's exactly the impression you get when wading through these
> giant Scheme threads we have these days.  Every day I open my news
> reader to read my beloved comp.lang.lisp, but all I get these days
> are hundreds of articles about Scheme.  I don't *care* about Scheme.

Huh?  An article that says Common Lisp sucks is not an article about
Scheme.

In any case, I would suggest you use a newsreader that enables you to
cleanly ignore all the articles with the term "Scheme" in them.

data hygiene [Re: Why is Scheme not a Lisp?] Kent M Pitman 3/18/02 10:05 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Janis Dzerins <jo...@latnet.lv> writes:
>
> > tb+u...@becket.net (Thomas Bushnell, BSG) writes:
> >
> > > But I think it's generally thought by Lispers that it's a shame that
> > > plists and alists have different structure, and if it were to be
> > > done over again, plists would have the alist structure.  So you
> > > can't destructure a plist easily, but except when actually dealing
> > > with plists, you are advised in Common Lisp to use alists instead,
> > > in general.
> >
> > How do you come up with this stuff?
>
> Um, it's true.  plists and alists have unfortunately different
> representations, for historical reasons.  The alist representation is
> better (for one thing, it's just prettier, but also, it allows for NIL
> properties).  

Both representations take the same conses.  Some people disagree that alist
notation is better because they don't like the way the dot is presented
conditionally.  (A . (B C)) does not print that way.  Some people use
(A (B C)) as the notation just to get better printing, at the expense of a
cons in storage and a cdr in access.  I don't think that's unambiguously
pretty.  Furthermore, NIL is certainly possible in both properties and alists.
(GET-PROPERTIES 'X '(FOO)) will tell the difference, as will
(GET 'X 'FOO *MISSING*).  

A real difference between plists and alists is that better operations
are provided for plists in CL than alists [this is an arbitrary and fixable
problem] because SETF of GET/GETF has no analog in the alist domain.  

Another difference is that the "locative" (a cell to which you
could make a datastructure modification) of (GET 'X 'FOO) is "the rest
of the plist" from (FOO 7 BAR 9 ...) and so reveals data that is not part
of the answer; while the locative of the analogous ASSOC call reveals no
such unrelated data.  (FOO . 7) does not reveal a subsequent (BAR . 9).
On the other hand, the locative result also contains information that allows
resuming the search while for alists there is no way to resume because
the tail is not returned.

> plists are stuck with the first way, however, because there is just
> way too much code that knows how they work.

I don't know what this means.  That's true of all successful data and its
associated operations.  It's not a linguistic criticism other than the use
of the pejorative word "stuck".

> But if you want to make
> your own assoc list, you always use the alist representation and not
> the plist representation, with the exception of what you store on
> actual symbols' plists.

I'm lost here.

Why is Scheme not a Lisp? Kent M Pitman 3/18/02 10:17 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Nils Goesche <car...@cartan.de> writes:
>
> > But that's exactly the impression you get when wading through these
> > giant Scheme threads we have these days.  Every day I open my news
> > reader to read my beloved comp.lang.lisp, but all I get these days
> > are hundreds of articles about Scheme.  I don't *care* about Scheme.
>
> Huh?  An article that says Common Lisp sucks is not an article about
> Scheme.

Well, some of us have been around a while and recognize particular
arguments as standard earmarks of someone who has happened into the
wrong language community, that is, someone whose aesthetic sense is
better satisfied by a language with a different axiomatic/design base.
 
People often ask questions of "why is it thus" here and the answer is
"this is a community built on two major things: compatibility where
things are not broken, and getting a usable result where things are broken".
We have not obsessed in this community over "whether there was another way".
We want to move forward and unless we are shown we are in an out-and-out
hill-climbing problem, we are not likely to look back and say "gosh, were
there other ways?"  There are other languages that do differently, and
that sit in a loop forever questioning whether they have done the right
thing.

Scheme was held back for a couple years trying to decide if
 (define (f x) x)
was a substitute for
 (define f (lambda (x) x))
or whether there was "not enough community consensus".

In my life, I want to have gotten to new vistas to talk about.  I
don't want to keep repeating the same battles.  I want it to be enough
that what we did we did for a reason.  I don't care a hoot about
showing that it was the best reason, which I consider a waste of the
only truly valuable commodity in life: time.

It's one thing to suggest that a system is absolutely so bankrupt that it
cannot survive the decision it made, but there is no evidence that CL has
done that.  And people who want to turn this into a conversation on "wouldn't
modules be better than packages" or "isn't call/cc better than catch" or
"aren't fully general functions better than keywords" or "isn't this macro
scheme better than that macro scheme" are just repeating the past.  They are
not doing e-commerce or driving spaceships or making search engines come up
with better results or making good people's credit card applications get
bounced less often or finding terrorists nor writing programs that make
poetry or music.

> In any case, I would suggest you use a newsreader that enables you to
> cleanly ignore all the articles with the term "Scheme" in them.

When someone comes to the US Republic party convention and says "why
don't we spend more on social programs? why don't we eschew the
religious right? etc." it doesn't always contain the word "Democrat"
in the text, but it's not uncommon for the suggestion to be "you might
be better placed elsewhere".  That person may not agree, but it's the
right of the people of the community to choose to abstract the issue
that way because it's highly predictive of not only that conversation
but of future ones.

[Btw, I'm an independent and don't like either party, just about equally.
 I'm just using this as an exmaple, so let's not debate US politics..]

data hygiene [Re: Why is Scheme not a Lisp?] Thomas Bushnell, BSG 3/18/02 10:26 AM
Kent M Pitman <pit...@world.std.com> writes:

> Furthermore, NIL is certainly possible in both properties and
> alists.  (GET-PROPERTIES 'X '(FOO)) will tell the difference, as
> will (GET 'X 'FOO *MISSING*).

I'm sorry, I was totally wrong in what I wrote about NIL on plists; of
course it can be there and the accessor functions have been sensitive
to it for ages.  I think my brain was caffeine-starved or something.

Why is Scheme not a Lisp? Erik Naggum 3/18/02 10:40 AM
* Bruce Lewis

| When did you read that?

  Over the course of many years.  The hostility towards "non-hygienic"
  macros has been extremely tense, and the anger directed at Common Lisp
  has been very strong at times.  I investigated Scheme thoroughly when I
  had gotten fed up with C++ and decided to find something else to do with
  my life than waste it away at idiotic languages.

| I can neither remember nor google anything on c.l.s about Common Lisp
| macros specifically.

  Maybe a less specific search will yield better results?

  I find it odd that anyone would rise to try to claim that the Scheme
  community is not hostile to Common Lisp.  It looks like an attempt to say
  "it's not our fault!", which only the bad guys need to say.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Duane Rettig 3/18/02 11:00 AM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> Janis Dzerins <jo...@latnet.lv> writes:
>
> > tb+u...@becket.net (Thomas Bushnell, BSG) writes:
> >
> > > But I think it's generally thought by Lispers that it's a shame that
> > > plists and alists have different structure, and if it were to be
> > > done over again, plists would have the alist structure.  So you
> > > can't destructure a plist easily, but except when actually dealing
> > > with plists, you are advised in Common Lisp to use alists instead,
> > > in general.
> >
> > How do you come up with this stuff?
>
> Um, it's true.  plists and alists have unfortunately different
> representations, for historical reasons.  The alist representation is
> better (for one thing, it's just prettier,

There's nothing historical about the difference between plists and
alists.  Each have their pros and cons (excuse the pun :-).  You've
touched on some of alists' pros, now let me point out alists' cons
(pun completely intended, here): there are more of them.  In other
words, plists take up less space, because they cons less.

> but also, it allows for NIL properties).  

Huh?  How is it not possible to have a nil plist value?

CL-USER(1): (list (getf '(b foo a nil) 'a :default) (getf '(b foo a nil) 'c :default))
(NIL :DEFAULT)
CL-USER(2):

> plists are stuck with the first way, however, because there is just
> way too much code that knows how they work.  [...]

If we had it to do over again, I'd still fight to keep plists...

--
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   duane@Franz.COM (internet)

data hygiene [Re: Why is Scheme not a Lisp?] Duane Rettig 3/18/02 11:00 AM
Duane Rettig <du...@franz.com> writes:

> tb+u...@becket.net (Thomas Bushnell, BSG) writes:
>
> > Janis Dzerins <jo...@latnet.lv> writes:
> >
> > > tb+u...@becket.net (Thomas Bushnell, BSG) writes:
> > >
> > > > But I think it's generally thought by Lispers that it's a shame that
> > > > plists and alists have different structure, and if it were to be
> > > > done over again, plists would have the alist structure.  So you
> > > > can't destructure a plist easily, but except when actually dealing
> > > > with plists, you are advised in Common Lisp to use alists instead,
> > > > in general.
> > >
> > > How do you come up with this stuff?
> >
> > Um, it's true.  plists and alists have unfortunately different
> > representations, for historical reasons.  The alist representation is
> > better (for one thing, it's just prettier,
>
> There's nothing historical about the difference between plists and
> alists.  Each have their pros and cons (excuse the pun :-).  You've
> touched on some of alists' pros, now let me point out alists' cons
> (pun completely intended, here): there are more of them.  In other
> words, plists take up less space, because they cons less.

Oops.  I was wrong.  Plists and alists do cons the same.  I never think
about it.  I guess I would back off of my original statement and say
that plists are represented with fewer parens, which could count as
an aesthetic pro.

> > but also, it allows for NIL properties).  
>
> Huh?  How is it not possible to have a nil plist value?
>
> CL-USER(1): (list (getf '(b foo a nil) 'a :default) (getf '(b foo a nil) 'c :default))
> (NIL :DEFAULT)
> CL-USER(2):
>
> > plists are stuck with the first way, however, because there is just
> > way too much code that knows how they work.  [...]
>
> If we had it to do over again, I'd still fight to keep plists...

I still stand by this, but for the same reason I would tend to remain
inclusive about anything else in CL; CL is all about inclusiveness,
and not about reduction to only one way of doing things.

--
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   duane@Franz.COM (internet)

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Espen Vestre 3/18/02 11:45 AM
Nils Goesche <car...@cartan.de> writes:

> The best way to achieve a friendlier climate would be to post some
> friendly, helpful articles.  

Well, comp.lang.lisp does actually already _has_ lots of friendly,
helpful articles. The problem is that the *unfriendly* articles cause
some newcomers leave immediately and some longterm members of the
community to give up.

> Posting hidden attacks against regular posters now and then will
> be less effective, I'd say.

Although I agree in principle, this description is unfair if applied as
"an hidden attack" against any of the posters in question here. Google
can confirm that.

Trivia: Google counts 219 occurences of "moron" in comp.lang.lisp. You
can find a lot of important CL symbol names with a lower frequency
than that...
--
  (espen)

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Erik Naggum 3/18/02 11:56 AM
* Espen Vestre

| Are you counting out the possibility that these two interests may
| coincide?

  No.  Using 23 lines of his 48-line "me too" article for advertising is an
  extremely poor professional as well as personal decision.  Banner ads are
  bad enough on the Web.  Here on USENET, we have a pretty general rule
  against advertising and for using only 4-line signatures.  We also have a
  general rule against posting "me too" articles.  I mean, America Online
  got to be synonymous with that kind of idiotic newbie behavior, and now
  it is used by a Lisp vendor to tell the world that not only is their
  German office run by a moron, they advertise in his moronic articles.

| That lisp vendors actually may be interested in a more friendly
| climate in comp.lang.lisp?

  Of course they are.  Does it help to post idiotic "me too" posts with
  huge ads?  No.  Should they learn from this and avoid doing it in the
  future?  Yes.  Does it help to post idiotic "you other guys please use
  mail while I continue posting" posts?  No.  Should they learn from this
  and avoid doing it in the future?  Yes.  Has Rolf Mach done the same
  idiotic things before?  Yes.  Has he learned from it?  No.  Does he think
  that there is always something wrong with people who do not follow his
  rules?  Yes.  Is any of this an instance of _politeness_?  No, most
  certainly not.  Hence my reaction.

| Even in the noisy scheme vs. CL thread, I've read a lot of really
| insightful comments, especially from Kent Pitman and you (which e.g.
| helped me understand why I like CL and have a distaste for scheme myself).

  I am happy about this.

| But the noise level is high, and the level of rudeness is sometimes quite
| unnecessary.

  I regret that, naturally, but in polite company, when someone tells you
  that you are doing something useless, you back down, you do _not_ start
  to yell back, defend yourself, or start telling stupid lies about the
  person who simply corrected something or made a joke you took personally
  to begin with.  I actually criticize _actions_, but the response I get to
  that from the morons is 100% pure personal attacks.


 
| So in its current state, I don't think c.l.l. is something lisp vendors
| can point at and say: "Look here and see how the lisp community is
| thriving, see how helpful it is!" (as an example of the opposite, flame
| wars are virtually non-existant on the quite active info-mcl mailing
| list).

  The list probably has a pretty specific purpose to which people adhere.
  The more people are aware of their purpose in doing something, the less
  they stray from it.  I want the purpose here to be: Discuss Common Lisp,
  do not try to re-open old issues for the 4711th time, do not instigate
  trouble with open hostility towards things you do not "like".  I argue
  that a professional _likes_ his tools, or he just uses different tools.
  A professional who dislikes his tools is a contradiction in terms.  If
  you cannot stand the dirt you get under your fingernails in one line of
  work, get yourself a different job or another line of work.

  The purpose of comp.lang.lisp is different to Scheme freaks and whiners:
  They want to spend all their time here attacking design decisions in
  Common Lisp which they use to fault somebody else for their own personal
  failure either to succeed with Common Lisp or to learn how to use it to
  solve their problems.  All this idiocy about Python, for instance, is
  like going to a cat show and whine endlessly about how dogs are better
  than cats.  Then there are the moronic "politeness crowd" which has no
  purpose here whatsoever, other than to harrass people with extremely
  impolite behavior of their own, as if anyone can achieve polite behavior
  out of others that way.  For some curious reason, many of these are
  German and display an atrocious lack of taste when they are "offended",
  as if other people have a duty not to offend them, and if they do, they
  have the "right" to attack people viciously.  Something is rotten in
  Germany.  I believe you are in position to be fairly objective about this.

| I can _understand_ why you and others react the way you do sometimes, but
| I don't think it's a wise thing to do.

  Look, I tell people _politely_ but not necessarily _kindly_ that that
  they should do something else.  95% of the time, people get the message
  and never even get into a position they need to back down from.  5% of
  the time, they get themselves into such a position, and then do _not_
  back down, but start taking _everything_ personally and feel hostility in
  everything I say, no matter what it is, and some even go so nuts they go
  on a fault-finding mission that lasts for years, just to take "revenge".
  There is clearly something wrong with such people.

| This is something I try to tell my kids as well (I'm a person who has a
| tendency to shout loud when I really dislike something, so I speak of
| experience...): Try to react as polite and calm as you can.

  I do not shout, which my cat can attest to: She spends the time I spend
  with the keyboard lying in front of me on my desk, relaxing or sleeping
  on her back -- and she hates sharp noises of all kinds.  I calmly ask
  people to go fuck themselves in real life, too, which has a much stronger
  effect on people.  Some people, however, spend a lot of time fantasizing
  about screaming and foam coming out of my mouth, such as Thomas Bushnell
  did recently, and apparently have a strong personal need to demonize
  their opponent so they can feel good about their own downright atrocious
  and even evil behavior and relieve themselves of responsibility for it.
  Nothing makes people behave worse than believing that somebody else is to
  blame for their behavior.  I consider it such an unintelligent thing to
  do that people who have stopped being responsible for their own actions
  must be psychotic or generally completely out of their mind and that
  there is no longer possible to talk to them -- one just has to wait until
  they regain their consciousness.  For some it seems to take years.

| By overreacting in a dispute, you only risk being regarded as the
| "impossible" party.

  As if anything I do could possibly change that in the minds of the bad
  guys.  If people have to reach their conclusions without thinking or
  without investigating causality and context, what do I care what they
  think?  But _still_ some people pick a fight with me?  I consider someone
  who does that to be retarded beyond recovery just there.  I mean, the
  _only_ reason these shitheads keep fighting me is that they have come to
  the conclusion that they are no longer to blame for their own behavior.
  I want such people to show the whole world how they behave when they want
  others to behave.  In short, if you cannot be polite when you ask other
  people to be polite, you _are_ an idiot.  If you cannot do what you
  suggest that other people do, such as using mail instead of news, you
  _are_ an idiot.  The curious thing with these people is that they are
  unable to stay reasonably on-topic and _also_ express their petty little
  moralistic gripes.  They even actually think that if they find a word
  which is on _their_ "do not use" list, then there _cannot_ be anything
  technical in the same article.  I want to see what kind of people are
  thusly retarded and unable to focus on their purpose of learning and
  using Common Lisp.  I also want to give people a chance to show me what
  they focus on: If I have 90% technical content to an article and 10%
  stuff that some retard finds "offensive", and he responds only to those
  10%, I know that his purpose is not compatible with this newsgroup -- his
  purpose in life is to make _other_ people behave, while he himself is
  free to do anything he goddamn pleases, including much worse insults than
  I ever use.  I find this somewhat entertaining, actually, and I guess
  that gets communicated to the morons who keep kicking and screaming.

  But since you ask so nicely, let me see if people get any less moronic
  and psychotic with less strongly-worded reactions.  I strongly doubt it.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Rahul Jain 3/18/02 11:56 AM
Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes:

> Although I agree in principle, this description is unfair if applied as
> "an hidden attack" against any of the posters in question here. Google
> can confirm that.

> Trivia: Google counts 219 occurences of "moron" in comp.lang.lisp. You
> can find a lot of important CL symbol names with a lower frequency
> than that...

Speaking of hidden attacks...

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

data hygiene [Re: Why is Scheme not a Lisp?] Paul Dietz 3/18/02 12:51 PM
Duane Rettig wrote:
 
> Oops.  I was wrong.  Plists and alists do cons the same.  I never think
> about it.  I guess I would back off of my original statement and say
> that plists are represented with fewer parens, which could count as
> an aesthetic pro.

Lookups in alists can be slightly faster on current hardware,
I think.

        Paul

Why is Scheme not a Lisp? Bruce Lewis 3/18/02 1:37 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Additionally, they get to defame the name of Lisp by making people
> think that it's as limited at Scheme. That's what I had thought from
> my prior education, before being informed by Sriram Krishnamurthi and
> c.l.l that Lisp really is very different from Scheme.

Shriram is a key member of the Scheme community, and a big proponent of
the value of generalized call/cc.  Scheme advocacy does not imply
hostility toward Common Lisp, as your example shows.

--
<brlewis@[(if (brl-related? message)    ; Bruce R. Lewis
              "users.sourceforge.net"   ; http://brl.sourceforge.net/
              "alum.mit.edu")]>

data hygiene [Re: Why is Scheme not a Lisp?] Thomas F. Burdick 3/18/02 1:41 PM
Kent M Pitman <pit...@world.std.com> writes:

> Another difference is that the "locative" (a cell to which you
> could make a datastructure modification) of (GET 'X 'FOO) is "the rest
> of the plist" from (FOO 7 BAR 9 ...) and so reveals data that is not part
> of the answer; while the locative of the analogous ASSOC call reveals no
> such unrelated data.  (FOO . 7) does not reveal a subsequent (BAR . 9).
> On the other hand, the locative result also contains information that allows
> resuming the search while for alists there is no way to resume because
> the tail is not returned.

Well, it's not as convenient to resume, anyway.  And it's less
efficient.  But you can certainly do:

  * (setf >>foo '((a . 1) (b . 2) (c . 3) (a . apple) (b . ball) (c . cat)))
  ((A . 1) (B . 2) (C . 3) (A . APPLE) (B . BALL) (C . CAT))
  * (assoc 'b >>foo)
  (B . 2)
  * (member * >>foo)
  ((B . 2) (C . 3) (A . APPLE) (B . BALL) (C . CAT))
  * (assoc 'b (rest *))
  (B . BALL)

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

Why is Scheme not a Lisp? Rahul Jain 3/18/02 1:47 PM
Bruce Lewis <brl...@yahoo.com> writes:

> Shriram is a key member of the Scheme community, and a big proponent of
> the value of generalized call/cc.  Scheme advocacy does not imply
> hostility toward Common Lisp, as your example shows.

I never claimed it did. I claimed that _specific_ people did this kind
of thing, and for no reason I can figure out. Why can't people just
accept that CL and scheme have different design goals instead of
arguing that one community has the "right" or "wrong" goals. It's
either a goal you're interested in or one you're not interested in.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Espen Vestre 3/18/02 2:13 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> > Trivia: Google counts 219 occurences of "moron" in comp.lang.lisp. You
> > can find a lot of important CL symbol names with a lower frequency
> > than that...
>
> Speaking of hidden attacks...

Yes?
--
  (espen)

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Espen Vestre 3/18/02 2:35 PM
Erik Naggum <er...@naggum.net> writes:
>   All this idiocy about Python, for instance, is like going to a cat
>   show and whine endlessly about how dogs are better than cats.

LOL :-)

>   out of others that way.  For some curious reason, many of these are
>   German and display an atrocious lack of taste when they are "offended",
>   as if other people have a duty not to offend them, and if they do, they
>   have the "right" to attack people viciously.  Something is rotten in
>   Germany.  I believe you are in position to be fairly objective about this.

What is considered as polite is strongly flavoured by your cultural
background. For instance: In most other european countries, the
default greeting behaviour ("good morning" is a very rare thing to
hear, except when there are Swedes in the neighborhood ;-)) of
norwegians is probably considered unbelievably rude.

There's no reason to draw any wide-reaching conclusions from these
differences, but they are yet another reason why one should try to
keep discourse at a polite level in an international forum like this
one.
--
  (espen)

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Rahul Jain 3/18/02 2:48 PM
Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes:

> What is considered as polite is strongly flavoured by your cultural
> background.

> one should try to keep discourse at a polite level in an


> international forum like this one.

I sense a contradiction here. There _is_ no "internationally polite"
behavior, by what you said, so how can one use it?

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme not a Lisp? Matthias Blume 3/18/02 2:38 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Matthias Blume <bl...@hanabi.research.bell-labs.com> writes:
>
> > Please, notice that there are *two* different kinds of inadvertant
> > name capture that Scheme macros avoid.  Only one of them can be
> > worked around using gensym at macro expansion time.
>
> > (I do understand that common lispers feel that the other kind does
> > not occur very often or at all in their code.  No need to point this
> > out.)
>
> I think it's more accurate to say, that if it happens, it happens out
> of intent, not accident, due to the package system. (assuming you're
> talking about lexical shadowing of bindings to symbols that are used
> in the macros.)
>
> I suppose it could happen out of accident, but that's like saying that
> someone using floating point "accidentally" created an algorithm which
> resulted in catastrophic cancellation. It's an accident caused by the
> user not knowing how to use his tools.

Right.  That's the "it's not a bug, it's a feature" line of reasoning.

--
-Matthias

data hygiene [Re: Why is Scheme not a Lisp?] Duane Rettig 3/18/02 3:00 PM
Paul Dietz <paul.f...@motorola.com> writes:

What's your theory?

--
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   duane@Franz.COM (internet)

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Espen Vestre 3/18/02 3:03 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> I sense a contradiction here. There _is_ no "internationally polite"
> behavior, by what you said, so how can one use it?

Politeness is not one-bit. Need I say more?
--
  (espen)

Why is Scheme not a Lisp? Thomas Bushnell, BSG 3/18/02 3:04 PM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> I never claimed it did. I claimed that _specific_ people did this kind
> of thing, and for no reason I can figure out. Why can't people just
> accept that CL and scheme have different design goals instead of
> arguing that one community has the "right" or "wrong" goals. It's
> either a goal you're interested in or one you're not interested in.

Well, I accept that they have different design goals, and I'm actually
interested in *both* goals.  

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/18/02 3:35 PM
* Thomas Bushnell, BSG

> But I think it's generally thought by Lispers that it's a shame that
> plists and alists have different structure, and if it were to be done
> over again, plists would have the alist structure.  So you can't
> destructure a plist easily, but except when actually dealing with plists,
> you are advised in Common Lisp to use alists instead, in general.

* Janis Dzerins


> How do you come up with this stuff?

* Thomas Bushnell, BSG


| Um, it's true.  plists and alists have unfortunately different
| representations, for historical reasons.

  And from this you conclude the "shame" part?  And this "unfortunately"
  part is so prejudicial it hurts.

| The alist representation is better (for one thing, it's just prettier,
| but also, it allows for NIL properties).

  What on earth are you talking about?

  Neither properties named nil nor properties on the symbol nil are a
  problem:

(get 'nil 'nil 42) => 42
(setf (get 'nil 'nil) t) => t
(get 'nil 'nil 42) => t

  I think you should try to realize that you do not know these things and
  stop embarrassing yourself by posting more obviously clueless falsehood.

| plists are stuck with the first way, however, because there is just way
| too much code that knows how they work.

  Are you sure you are not confusing plist and alists?  Are you confused by
  the fact that a nil in an alist is effectively ignored with any nil
  properties?

(assoc nil '(nil (nil . 1) (2 . nil))) => (nil . 1)
(rassoc nil '(nil (nil . 1) (2 . nil))) => (2)


 
| But if you want to make your own assoc list, you always use the alist
| representation and not the plist representation, with the exception of
| what you store on actual symbols' plists.

  Really?  Did you know that you can use destructuring-bind to pick up a
  bunch of values from a plist, but that you have no such handy tool with
  alists?

(properties <whatever>)
=> (:root 'n :toot 'n :foo 47 :bar 11 :zot 'yeah)

(destructuring-bind (&key foo bar zot &allow-other-keys) (properties <whatever>)
  (values foo bar zot))
=> 47
=> 11
=> 'yeah

  I use this technique quite frequently to avoid having a whole bunch of
  empty slots in classes or structures.  I trust that keyword handling in
  Common Lisp is implemented efficiently because it is such an integral
  part of the language.  In a language that lacked such integral features,
  I would be much less likely to believe that some incidental library was
  sufficiently well implemented that I could use it.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Why is Scheme not a Lisp? Erik Naggum 3/18/02 3:37 PM
* Thomas Bushnell, BSG

| Except that nobody here has been saying that Common Lisp sucks.

  Your observational skills are so deficient that whatever you say about
  what people have or have not done is completely irrelevant by now.
  Besides, you are among the clueless naysayers who deride Common Lisp for
  flaws it does not have and who do not know how to do things properly, so
  you think features you do know about make the language hard to use.

  You also sprinkle your articles liberally with negative terminoloyg, like
  you just did about plists and alists.  "Unfortunately", my ass.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Rahul Jain 3/18/02 3:31 PM
Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes:

Yes, that the percieved politeness "value" is a distance from some
arbitrary point (that is different for each person) to that vector
that defines the "underlying" politeness.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Why is Scheme (not ?) a Lisp? Bijan Parsia 3/18/02 3:50 PM
On Sun, 17 Mar 2002, Christopher Browne wrote:

> In an

failed

> attempt to throw the authorities off his trail,

Alas, they got me and I'm currently typing this from an undisclosed
location. Cold, drippy, and isolated, but *at least* there's a news feed
-- they aren't barbarians, y'know!

(Well, reserve judgement until you see the groups they let me subscribe to
:))


> Bijan Parsia
<bpa...@email.unc.edu> transmitted:
> >> and the arguments between Scheme and CL people are similar to the
> >> arguments between Roman Catholics and Protestants - they're both
> >> just more vampire-cultist christians to the outside observer,
> >> though a member of either group will argue at length about
> >> con/trans-substantiation, the status of the virgin mary, etc....
>
> > This is *really* offensive.
>
> > Interesting that you conflate all Protestants.
>
> Protestants _do_ tend to have a fair bit of common ground,

Sure, as do all Christians, etc. etc. etc.

And from some perspectives, it makes sense to make that conflation.

But perhaps I read too much into the "the" bit of "the outside observer",
or perhaps its intended that anyone who *does* bother to figure out some
of the distinctions is no longer sufficiently "outside". *Why* someone
thus far outside feels a need to comment in the midst of such a discussion
is a different issue. Likely, it's to be obnoxious in one way or another
(afaict).

> in having
> stemmed from common religious roots, in much the same way that pretty
> much all Scheme implementors and users would be reasonably expected to
> have common respect for R*RS, having Rather A Lot of Parentheses in
> their language, liking the notion of having first class functions
> around, and such.

It may be nigh incomprehensible to the outside observer, but I *suspect*
there is more variation among Protestants than among Schemes. Shocking, I
know, but, hey, Protestitism has had *hundreds* of years! Give scheme
time!

> > Really interesting that the outsiders have *all* the defining
> > power. Sorry, that's not how it usually goes. Oh, and yes, my
> > ancesters are *Iranian*, not *Persian*. Thanks ;)
>
> I'm quite sure that the distinction isn't of too much import to me,

Does it have to be?

> not only from a strict utilitarian perspective, but also since both
> those names of peoples are _English_, and thus are highly likely to be
> of much more recent provenance than whatever were the names that
> Iranian or Persian ancestors actually used.

You mean like my grandparents?

[snip]
> Getting too excited about the English words strikes me

Er..you got that it was a joke?

It is fairly complicated as one might expect that *English* speakers get
to define what terms they use to refer to peoples *in English*. And so it
is. But *I'm* an English speaker :)

> as being as
> silly as getting deeply into bizarre interpretations of the Bible
> based on the niceties of English words, when reality is that the Bible
> was certainly _not_ written in the English language.

But the more interesting example was the student who called me a Parsee,
which I am *not*, in any way. It might have helped to focus on the serious
example and not on the joke.

[snip]
> > I guess the notions of respect and tolerance and understanding are
> > just completely foreign.
>
> They're pretty "foreign" notions; with the number of "wars of
> intolerance" that have circled the globe, over the millenia, it is not
> at all clear to me that there is anywhere that they could be
> considered to be "domestic" notions...

Well, I meant "for the original poster".

Just to avoid confusion, I'm a native born US citizen whose mother (and
only) tongue is American English.

While I agree that tolerance is relatively rare, I tend to think that
*expousing* it, or taking it as *right* isn't proper.

I take it the original poster thinks I misread what he wrote. We'll see.

Cheers,
Bijan Parsia.

First-class symbols (Re: Why is Scheme not a Lisp?) Thomas F. Burdick 3/18/02 4:00 PM
Erik Naggum <er...@naggum.net> writes:

>   Sometimes, when I hear Scheme people talk, and you among them, I
>   get the impression that there are 26 people trying to argue which
>   is the Only Right Letter and they are _so_ in the need of someone
>   to say "Hey, dudes!  One word: _alphabet_".

Well, sure, that narrows the search space some, but really, do you
think they'll be able to figure out which of the 7 remaining letters
is the One Right Letter?

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

[OT] Re: Why is Scheme (not ?) a Lisp? Bijan Parsia 3/18/02 4:16 PM
On Mon, 18 Mar 2002, David Golden wrote:

> Bijan Parsia wrote:
>
> > Outsider ~= ignorance and not caring
> > about that ignorance.
> >
>
> Huh?  My argument was not that the outsider was ignorant, but that to the
> outsider the differences may be inconsequential...

Hmm. Ok, my impression was that the outsider *wasn't able to tell*.

If it causes nations to rise and fall and millions of people to die, then
it seems consequential (in an important sense).

>   i.e. Being fully aware
> of the differences (not ignorant of them) and not caring about them...

Not caring about them to the point that you make (or *can* make?) no
distinction between them? How is that being fully aware of the
differences.

I may say, "Look, anything that has a monthesitic god is just *not* going
to work for me. Thus, from this perspective, they are all the same. No
trivial variation will change my actions wrt them." but that's vastly
different than saying, "Look, Christianity and Judiasm are just the same
religion, so when I said that I don't want to be a Christian I was *also*
saying I didn't want to be a Jew."

There's some sort of error there.

> The rest of your argument rests on _your_ assumption of ignorance on
> the part of the outsider.

Perhaps. I inferred ignorance from the rest of your description. Take this
quote:

"""To even be able to argue reasonably coherently about the differences,
one must understand both Scheme and CL at a very deep level at the very
least - which I don't.
[snip]

I'd say that only members of some sort of "Lisp" community would
be able to do the argung in the first place.

[snip]

From the "outside", Scheme and CL are Lisps, and the arguments between

Scheme and CL people are similar to the arguments between Roman Catholics
and Protestants - they're both just more vampire-cultist christians to the
outside observer, though a member of either group will argue at length
about con/trans-substantiation, the status of the virgin mary, etc....

So, probably only a devoted member of the community is going to be able to
understand the issues involved,"""

I'm back at reading this as assuming the the outside observer doesn't
understand, perhaps *can't* understand, perhaps because of ennui. I agree
that many are like that, I just disagree with the bits where such folks
are somehow relevant to settling most issues, especially *inside* the
relevant communities (which *is* after all, where you posted).


> I don't think I painted the outsider as a *stupid* jerk.

Sorry, I read over your post again and I *still* come away with that
perception.

> Jerk, maybe.  It's
> possible to be fully aware of the intricacies of christianity, or lisp,

This didn't seem to be what you said in the original post. Pointers with
close readings welcome (off list preferred, though).

> and
>  _still_ recognise that roman catholic., the orthodox churches and the
> various flavours of protestant churches are all subsets of "christianity",
> or that christianity, islam and judaism are all subsets of "monotheistic
> religion",

And who denied this? Such descriptions are available to the "in
group" members too. What has this to do with definitional powers
(including the alledged superior labeling rights of the outsider)?

Interestingly, it's *true* that those Churchs are all christian and *true*
that chrisitanity, islam, and judiams are all montheistic religions and
that *almost no one*, inside *or* outside the group dispute it.

> just as one could recognise that scheme or common lisp are
> subsets of some "lisp" ideal

Well, which lisp ideal is under dispute.

>, and that the "lisp" ideal is a subset of
> "programming language concepts".

That isn't under dispute.

Why would these things be *more* available to the outsider than the
"insider"?

I take the statement: "To be a member of a Christian sect/religion is to
believe in the Trinity the way the Catholics do" to be straightforwardly
false, and most everyone agrees. That is distinct from a Catholic arguing
"The correct understanding of Christ and God includes believing in the
Trinity the way Catholics do." And outside may simply not care, which is
fine, but the *outsider* gets to determine that it's true? *Just* in
virtue of being an outsider? I hope not.

(I stay on the religious example just to keep the issues separate from the
current debate in the list, not because I think religious communities have
special status.)

If the point of your post was, "C and Java folks think that Scheme is a
Lisp", that's hardly useful to *determining* whether Scheme is a
Lisp. (Acutally, I take it that your post argued *something* like, *since*
Lisp outsiders think that Scheme is a Lisp, then Scheme is a Lisp. I'm
arguing that such an argument is a non sequitur.)

I take what you said in this post to be reasonable unobjectionable (well,
except for the parts where you interpret *me* :)), so if that's what you
meant to say, then we can stop.

Cheers,
Bijan Parsia.

[OT] Re: Why is Scheme (not ?) a Lisp? Dr.X 3/18/02 4:20 PM
oh...quit changing the subject...it makes it harder to filter out
this thread.  ;-)

Dr.X

Bijan Parsia <bpa...@email.unc.edu> wrote in message
news:Pine.A41.4.21L1.0203181851510.21092-100000@login5.isis.unc.e
du...

You know you're reading comp.lang.lisp when... Joe Marshall 3/18/02 4:31 PM

You know you're reading comp.lang.lisp when
  the religious debates are calmer than the other posts.

Anyone for politics?


"Bijan Parsia" <bpa...@email.unc.edu> wrote in message
news:Pine.A41.4.21L1.0203171357140.21798-100000@login1.isis.unc.edu...
> On 17 Mar 2002, Julian Stecklina wrote:
>
> > Bijan Parsia <bpa...@email.unc.edu> writes:
> >
> > [...]

> >
> > > > and the arguments between
> > > > Scheme and CL people are similar to the arguments between Roman
Catholics
> > > > and Protestants - they're both just more vampire-cultist christians
to the
> > > > outside observer, though a member of either group will argue at
length
> > > > about con/trans-substantiation, the status of the virgin mary,
etc....
> > >
> > > This is *really* offensive.
>
> To me.
>
> > That lies in the eye of the beholder. :) I do _not_ feel
> > offended. Even though I live in a mainly protestant area, but nobody
> > does care here either.
>
> Actually, it's not the Prot/catholic/christian bash that offended me
> :) Well, much.
>

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Espen Vestre 3/19/02 12:20 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Yes, that the percieved politeness "value" is a distance from some
> arbitrary point (that is different for each person) to that vector
> that defines the "underlying" politeness.

I never claimed that politeness is completely relativistic.
--
  (espen)

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Rahul Jain 3/19/02 12:47 AM
Espen Vestre <espen@*do-not-spam-me*.vestre.net> writes:

> I never claimed that politeness is completely relativistic.

Then you missed an important fact, and it's not worth discussing
politeness with someone who does.

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?) Espen Vestre 3/19/02 1:04 AM
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes:

> Then you missed an important fact, and it's not worth discussing
> politeness with someone who does.

And what, if I may ask, would be the point of continuing a discussion of
politeness with someone who has a nihilist (or, in CLL terms, one-bit)
view of it?

But you're probably only testing my temper...
--
  (espen)

You know you're reading comp.lang.lisp when... Andrzej Lewandowski 3/19/02 4:18 AM
On Tue, 19 Mar 2002 00:31:07 GMT, "Joe Marshall"
<prunes...@attbi.com> wrote:

>
>You know you're reading comp.lang.lisp when
>  the religious debates are calmer than the other posts.
>
>Anyone for politics?
>

Religious discussions are just OK here. Lisp is The Latin Language
of Software Engineering. Everybody is respecting it but nobody is
using it. By the way, even  Vatican is not using Latin anymore...

A.L.

P.S. By the way, I am not a troll. I have a lot of fun reading
discussions on c.l.l.

data hygiene [Re: Why is Scheme not a Lisp?] Paul Dietz 3/19/02 7:10 AM
Duane Rettig wrote:

> > Lookups in alists can be slightly faster on current hardware,
> > I think.
>
> What's your theory?

Load latency could be a bigger problem running down
the plist; you have a chain of 2N cons cells to follow.
In the alist, you need only follow a chain of N cons
cells (you also need to load the cars of these cells,
but that's off the critical path.)

        Paul

You know you're reading comp.lang.lisp when... Bruce Lewis 3/19/02 7:46 AM
"Joe Marshall" <prunes...@attbi.com> writes:

> You know you're reading comp.lang.lisp when
>   the religious debates are calmer than the other posts.
>
> Anyone for politics?

Kent tried, but nobody bit.  To get a good flame war he'll have to make
the relationship between the political and technical content more
tenuous.  As it is people get all distracted by the technical stuff.

You know you're reading comp.lang.lisp when... Julian Stecklina 3/19/02 8:28 AM
Bruce Lewis <brl...@yahoo.com> writes:


I just wanted to start discussing the American two-party-system, but
Kent made it clear that he did not want such a
discussion. So... Joschka Fischer for Bundeskanzler! No, just
kidding. ;)

Let's try to avoid Politics. Programming is strange enough.

Regards,
Julian
--
Meine Hompage: http://julian.re6.de

Um meinen oeffentlichen Schluessel zu erhalten:
To get my public key:
http://math-www.uni-paderborn.de/pgp/

data hygiene [Re: Why is Scheme not a Lisp?] Bob Bane 3/19/02 9:14 AM
Duane Rettig wrote:
>
> Oops.  I was wrong.  Plists and alists do cons the same.  I never think
> about it.  I guess I would back off of my original statement and say
> that plists are represented with fewer parens, which could count as
> an aesthetic pro.
>
If you have an implementation that can do cdr-coded lists, a plist turns
into the moral equivalent of a vector, and ends up taking a lot less
space and being faster to access than the equivalent alist.

Cdr-coding was an obvious win in the days of Lisp machines; I don't know
how it might play out with modern processors.

You know you're reading comp.lang.lisp when... Christopher Browne 3/19/02 1:03 PM
The world rejoiced as Julian Stecklina <der_j...@web.de> wrote:
> Bruce Lewis <brl...@yahoo.com> writes:
>
>> "Joe Marshall" <prunes...@attbi.com> writes:
>>
>> > You know you're reading comp.lang.lisp when
>> >   the religious debates are calmer than the other posts.
>> >
>> > Anyone for politics?
>>
>> Kent tried, but nobody bit.  To get a good flame war he'll have to
>> make the relationship between the political and technical content
>> more tenuous.  As it is people get all distracted by the technical
>> stuff.
>
> I just wanted to start discussing the American two-party-system, but
> Kent made it clear that he did not want such a discussion.
> So... Joschka Fischer for Bundeskanzler! No, just kidding. ;)
>
> Let's try to avoid Politics. Programming is strange enough.

Politics is too localized to be readily disputable in so clearly
international a forum.

I'm afraid Bundestad politics would leave me baffled as I know nothing
of the characters or of the issues.  (I do remember Norm MacDonald
repeatedly saying: "Or so the Germans would have us believe...")

I could personally opine somewhat usefully/entertainingly about both
US and Canadian politics, knowing more than merely the stereotypes of
both those lands.

To folks in Europe or Down Under, understanding of the US political
landscape is more than likely dominated by the _stereotypes_ that get
filtered through the media as opposed to the reality of the landscape.

And we haven't enough "intentionally ignorant redneck hick" types to
get into the conspiracy theory slurring of things, typically involving
people who have wild ideas about the UN, the Rothschilds, the
Tripartite Commission, and who generally use the phrase "international
bankers" as their codeword for "filthy Jews."  Happily there aren't
(m)any of those here.

All in all, I suspect we can realistically do little more than see the
_stereotypes_ of each others' political landscapes.
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/sap.html
Rule of Scarcity
"If it's not allocated by a market, then it's more expensive than
money."
-- Mark Miller

Why is Scheme not a Lisp? William D Clinger 3/19/02 2:01 PM
Nils Goesche wrote:
> And I care even less about reading arguments trying to convince
> me that I should rather use some ``eugenic'' macros or some such to
> replace my beloved Common Lisp macros.  Can't people at least use some
> name that isn't clearly intended to be insulting when talking about
> these things on comp.lang.lisp?  How about calling them ``castrated''
> macros instead?

Kohlbecker actually developed hygienic macro technology with Common
Lisp as the intended application language.  The X3J13 committee that
developed the ANSI standard for Common Lisp decided not to adopt this
technology because it was too new and Kohlbecker's original algorithm
was too inefficient.  I think this was probably the right decision,
although I personally was disappointed at the time.

To say that the name of this technology was "clearly intended to be
insulting" is at odds with historical fact.  When Kohlbecker chose
this name for his technology, he had no way of knowing that the
Common Lisp community would reject it, or that the Scheme and Dylan
communities would adopt it.

Will

Why is Scheme not a Lisp? William D Clinger 3/19/02 2:08 PM
Bruce Hoult wrote:
> I don't know what happens in Scheme, but in Dylan if a macro uses the
> canonical True value #t (or any other name, for that matter) then the
> binding used is the one current at the point that the macro is
> *defined*, not used.

That's what happens in Scheme also.  Dylan's macro system is hygienic,
like Scheme's.

Will

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/19/02 2:38 PM
* Paul Dietz

| Load latency could be a bigger problem running down the plist; you have a
| chain of 2N cons cells to follow.  In the alist, you need only follow a
| chain of N cons cells (you also need to load the cars of these cells, but
| that's off the critical path.)

  In traversing plists, you have to get the car to compare, and then two
  cdrs to move forward, but in alists, you have to get the car of the car
  to compare, and then one cdr to move forward.  I am fuzzy on how this is
  so different.  Could you explain?

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Thomas Bushnell, BSG 3/19/02 2:44 PM
Bob Bane <bb...@removeme.gst.com> writes:

> Cdr-coding was an obvious win in the days of Lisp machines; I don't know
> how it might play out with modern processors.

I've read a couple more recent papers (but alas, I can't remember
which) that mentioned off-hand that CDR-coding is not so much a win
anymore.

One reason is that memory utilization is no longer the tight issue it
used to be; another thing the mention is that CDR-coding might
actually slow down certain common pointer traversal idioms.

data hygiene [Re: Why is Scheme not a Lisp?] Rahul Jain 3/19/02 2:54 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> I've read a couple more recent papers (but alas, I can't remember
> which) that mentioned off-hand that CDR-coding is not so much a win
> anymore.

> One reason is that memory utilization is no longer the tight issue it
> used to be; another thing the mention is that CDR-coding might
> actually slow down certain common pointer traversal idioms.

Also, the addition of arrays to lisp allows for the optimization to
the compact case when needed, so it's good to optimize lists to the
case where flexibility and structure sharing is needed and let the
programmer explicitly tell you which one he/she wants instead of
trying to dynamically optimize for it. Of course in the most complex
cases, dynamic optimization might be what's best, but oh well. :)

--
-> -/                        - Rahul Jain -                        \- <-
-> -\  http://linux.rice.edu/~rahul -=-  mailto:rj...@techie.com   /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook  \- <-
-> -\  people if [they] try to walk around on their own. I really  /- <-
-> -/  wonder why XML does not." -- Erik Naggum, comp.lang.lisp    \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   (c)1996-2002, All rights reserved. Disclaimer available upon request.

data hygiene [Re: Why is Scheme not a Lisp?] Paul Dietz 3/19/02 3:25 PM
Erik Naggum wrote:

>   In traversing plists, you have to get the car to compare, and then two
>   cdrs to move forward, but in alists, you have to get the car of the car
>   to compare, and then one cdr to move forward.  I am fuzzy on how this is
>   so different.  Could you explain?

*If* the running time of your algorithm is dominated by memory
latency rather than memory bandwidth the alist search could
be up to twice as fast, since its loads are more parallelizable.
The longest sequence of dependent loads in the alist search
has length N+1, vs. 2N-1 for the plist.  This is assuming
you have a machine that can have multiple loads 'in the air'
at once.

Put another way: you can arrange the loads in the alist search
so that there's a longer distance between the load and when
the data is actually used, which might reduce pipeline stalls.

        Paul

data hygiene [Re: Why is Scheme not a Lisp?] Paul Dietz 3/19/02 3:32 PM
"Thomas Bushnell, BSG" wrote:

> I've read a couple more recent papers (but alas, I can't remember
> which) that mentioned off-hand that CDR-coding is not so much a win
> anymore.
>
> One reason is that memory utilization is no longer the tight issue it
> used to be; another thing the mention is that CDR-coding might
> actually slow down certain common pointer traversal idioms.

If you have a copying garbage collector then list cells can
tend to be made to compact into successive memory anyway.  This
could give some of the cache/VM advantages of CDR-coding, at
least.

Beyond that, you could apply compression to the pages containing
cons cells.  This could be done either by the virtual memory
system, or by dedicated hardware between the main memory the
the largest cache level.  IBM has a memory controller product that
does the latter (although it's not optimized for Lisp as far
as I know.)

        Paul

You know you're reading comp.lang.lisp when... Bruce Hoult 3/19/02 3:49 PM
In article <m38z8og...@chvatal.cbbrowne.com>,
 Christopher Browne <cbbr...@acm.org> wrote:

> To folks in Europe or Down Under, understanding of the US political
> landscape is more than likely dominated by the _stereotypes_ that get
> filtered through the media as opposed to the reality of the landscape.

Well, here Down Under the media (and I think as a result much of the
population) regard *both* US parties as being far right wing and nearly
identical.

My own perceptions I think come mostly from 15+ years online and talking
largely to people who in practice vote for what they affectionately call
the "Stupid Party", but would jump to a realistic alternative in a
second.

-- Bruce

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/19/02 3:59 PM
* Paul Dietz

| *If* the running time of your algorithm is dominated by memory latency
| rather than memory bandwidth the alist search could be up to twice as
| fast, since its loads are more parallelizable.

  Are you kidding or something?

| The longest sequence of dependent loads in the alist search has length
| N+1, vs. 2N-1 for the plist.  This is assuming you have a machine that
| can have multiple loads 'in the air' at once.

  How the hell is caar+cdr any different from car+cddr?

  How do you normally set up alists and plists?  Even after a copy-tree (or
  GC) that copies cons celle so they are allocated in the order they are
  visited, the distances are _exactly_ the same.  Just work it out.

| Put another way: you can arrange the loads in the alist search so that
| there's a longer distance between the load and when the data is actually
| used, which might reduce pipeline stalls.

  Please show me how this is done.  I think you are aggressively clueless
  by now, but I am always open to refinement and even contradiction if you
  just do something smarter.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

You know you're reading comp.lang.lisp when... Michael Parker 3/19/02 4:35 PM
Bruce Hoult wrote:
> Well, here Down Under the media (and I think as a result much of the
> population) regard *both* US parties as being far right wing and nearly
> identical.

Odd.  Here in Texas, most people I know tend to view the two parties
as left wing and nearly identical.  Unless left-wing and right-wing
have reversed meanings there?

You know you're reading comp.lang.lisp when... Bruce Hoult 3/19/02 5:22 PM
In article
<C4B52CF5AE66143C.5F1EF57E67E97267.E2101737F718610E@lp.airnews.net>,
 Michael Parker <des...@pdq.net> wrote:

Don't think so.  By NZ media standards, both US parties are
pro-business, pro-military, anti-welfare, anti-human rights and privacy
(death penalty, abortion, drugs, age of consent...).

-- Bruce

You know you're reading comp.lang.lisp when... Nils Goesche 3/19/02 5:42 PM
Bruce Hoult <br...@hoult.org> writes:

That's the impression you get from the media here in Europe, too.
Also politicians like pointing at America yelling: ``Look, how
the /really evil rightwing/ people do it!''  But after I've read
several books by American authors, all not available in Europe,
like Milton Friedman, Thomas Sowell or David Horowitz, my
impression is that the truth is quite different...

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

PGP key ID 0xC66D6E6F

data hygiene [Re: Why is Scheme not a Lisp?] Carl Shapiro 3/19/02 5:11 PM
Erik Naggum <er...@naggum.net> writes:

> * Paul Dietz


> | The longest sequence of dependent loads in the alist search has length
> | N+1, vs. 2N-1 for the plist.  This is assuming you have a machine that
> | can have multiple loads 'in the air' at once.
>
>   How the hell is caar+cdr any different from car+cddr?

There is a small amount of load parallelism in list traversal that can
be exploited when using an alist.  Before examining the car of some
element, one could prefetch the cdr.  This may increase the likelihood
of the next list element being in cache by the time you are ready for
it.  Joe Marshall's paper describing the architecture of the LMI
K-Machine mentions that its compiler would emit such instructions to
prefetch list elements when compiling mapping primitives.

With a plist one has to cdr past all elements so this opportunity
would be lost.

>   How do you normally set up alists and plists?  Even after a copy-tree (or
>   GC) that copies cons celle so they are allocated in the order they are
>   visited, the distances are _exactly_ the same.  Just work it out.

If your machine has huge cache lines, and the list elements are next
to each other, I suppose the effects of prefetching list elements may
be less pronounced.

data hygiene [Re: Why is Scheme not a Lisp?] Kent M Pitman 3/19/02 6:11 PM
Carl Shapiro <cshapi...@panix.com> writes:

> Erik Naggum <er...@naggum.net> writes:
>
> > * Paul Dietz
> > | The longest sequence of dependent loads in the alist search has length
> > | N+1, vs. 2N-1 for the plist.  This is assuming you have a machine that
> > | can have multiple loads 'in the air' at once.
> >
> >   How the hell is caar+cdr any different from car+cddr?
>
> There is a small amount of load parallelism in list traversal that can
> be exploited when using an alist.  Before examining the car of some
> element, one could prefetch the cdr.  This may increase the likelihood
> of the next list element being in cache by the time you are ready for
> it.  Joe Marshall's paper describing the architecture of the LMI
> K-Machine mentions that its compiler would emit such instructions to
> prefetch list elements when compiling mapping primitives.

I'm sure all this is probably true.

I still don't think it's a good enough reason to prefer one data structure
of another.  The whole reason we use Lisp and not C is that we value the
optimization of design time over this degree of microoptimization of
execution time.

Not that you shouldn't mention this kind of trivia, because it's quite fun
to know.  And it may even be useful in some discussions with people who are
obsessed with this kind of optimization.

But I, for one, will still be using mostly plists even though I acknowledge
the possibility in some implementations that I'll lose the occasional
prefetch assist.

Btw, in the MOO programming language, I created a concept called the
"i-list" which I found was massively more efficient there because of
idiosyncracies of the MOO byte-code interpreter.  The win wouldn't be
as big in CL, but might have some benefits. The structure looks like:

 ( sequence-of-keys . vector-of-values )

You traverse the list of keys (which may be any sequence), and when you get
to the place you want, you do a random access to grab the corresponding
value.  This allows faster access to keys without tripping over indirections
related to the values.  It's not as easy to maintain (unless you make it be
an indirect array (and that adds back the indirection that going from an
alist to a list removes), but if you pre-allocate them of the right size, it
looks faster to me.  Anyone want to do a prefetch analysis just for fun?
(I call it an i-list because the final access is indexed.)

You know you're reading comp.lang.lisp when... Daniel Pittman 3/19/02 5:57 PM

As far as I know, left-wing and right-wing tend to mean the same in
Australia as in the US. Certainly, left-wing means "reform" and
right-wing means "conservative".

More usefully, these are generally understood to mean that a "left-wing"
party tends toward socialism and a "right-wing" party toward fascism,
although generally not very far along.[1] :)


In practice, the major "left-wing" and "right-wing" parties in Australia
are both very conservative parties, focusing mostly on improving
business conditions based on the theory that a better economy means a
better life for everyone in the country, no matter what you have to
sacrifice to improve the economy.[2]

The distinguishing factor between the two is that the "left-wing" Labour
party focus on improving small business while the "right-wing"
Liberal[3] are focused on improving large, typically multinational,
business.


As far as I can tell, American politics has a greater degree of
difference between the two parties[4] but the fundamental structure is the
same -- two parties, differing mostly on what size of business to
support.

        Daniel

(Was that sufficiently inflammatory? I probably should have stuck to my
guns and not answered your post. Ah, well.)

Footnotes:
[1]  This is based on a biased sample of the people I know, or at least
     the perception that it is "generally understood" is.

[2]  This includes expendable things such as education, public health
     care, support for the unemployed and the poor and the like.

[3]  Yes, I find this name highly amusing myself, since they are the
     more conservative of the two, though not by much.

[4]  There seems to be a stronger support for social support in the, er,
     democrats. (or is it Republicans? The one that isn't in power,
     anyway.)

--
As long as a person has a notion that he is guided by immediate direction from
heaven, it makes him incorrigible and impregnable in all his misconduct.
        -- Jonathan Edwards

You know you're reading comp.lang.lisp when... Thomas Bushnell, BSG 3/19/02 6:38 PM
Daniel Pittman <dan...@rimspace.net> writes:

> As far as I can tell, American politics has a greater degree of
> difference between the two parties[4] but the fundamental structure is the
> same -- two parties, differing mostly on what size of business to
> support.

A brief study of voting theory, with some fairly sane assumptions,
will show that this is no surprise.

In the United States, all elections for members of Congress are
"winner-take-all", that is, there is an election for a single seat,
and whoever captures the most votes, by a plurality, wins that seat.
A similar rule prevails in British elections for the House of Commons,
the Canadian House of Commons, and many others.

This is to be contrasted with non-winner-take-all systems, in which
there may be several seats open for election at once, and some system
of proportional representation or transferrable vote is used.  For
example, the Board of Supervisors in San Francisco, CA and the City
Council of Cambridge, MA, both have at large members elected in such a
fashion.

In a winner-take-all system, there are very strong pressures towards a
two-party system; it's nearly automatic.  Canada is a curious
exception at present, with two prominent opposition parties, both of
which are strongly regional,

Thomas

You know you're reading comp.lang.lisp when... Erik Naggum 3/19/02 6:54 PM
* Michael Parker <des...@pdq.net>

| Odd.  Here in Texas, most people I know tend to view the two parties
| as left wing and nearly identical.  Unless left-wing and right-wing
| have reversed meanings there?

  What is all this?  Clearly both parties have very much in common.  They
  are both political parties, or members of the American political party
  family.  People from both parties should just come together and discuss
  their common ground and be friends, not fight against each other.  Their
  internal differences are unimportant compared the commonalities.  For
  instance, they are both American.  That must count for something.  Both
  parties have symbols, and both parties have some concerns for some group
  of the population that are largely symbolic.  Seen from afar, such as the
  individual voter, there is no material difference between the two, and
  people who wish to learn about the politics of one party may learn from
  the literature of the other and from congretating with people of the
  other party.  After all, the sin taxes both parties favor are the same,
  and they both display the same antics.  So, why don't you Americans adopt
  a one-party system like several European, African, and Latin American
  countries have had so much success with?  Then, peace will break out and
  real and toy Lisps shall live happily ever after.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

You know you're reading comp.lang.lisp when... Erik Naggum 3/19/02 7:13 PM
* Nils Goesche <n...@cartan.de>

| That's the impression you get from the media here in Europe, too.  Also
| politicians like pointing at America yelling: ``Look, how the /really
| evil rightwing/ people do it!''  But after I've read several books by
| American authors, all not available in Europe, like Milton Friedman,
| Thomas Sowell or David Horowitz, my impression is that the truth is quite
| different...

  Yeah, the damn liberal media are _everywhere_!

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Paul F. Dietz 3/19/02 7:49 PM
Erik Naggum wrote:

>   How the hell is caar+cdr any different from car+cddr?

The result of the caar is not needed immediately.  You can
software pipeline these side operations while you continue
to cdr down the alist.

> | Put another way: you can arrange the loads in the alist search so that
> | there's a longer distance between the load and when the data is actually
> | used, which might reduce pipeline stalls.
>
>   Please show me how this is done.  I think you are aggressively clueless
>   by now, but I am always open to refinement and even contradiction if you
>   just do something smarter.

You might do something like this:

(defun fast-assoc-eq (key lst)
  (and
   (consp lst)
   (if key
       (let (pair pair2 rest k1 k2)
         ;; The loop has been unrolled once.
         ;; Note that there is at least one load between a
         ;; use and the load on which it depends (except for
         ;;  the line marked *)
         (loop
           (setq rest (cdr lst))
           (setq pair (car lst))
           (unless (consp rest)
              (return (and (eq (car pair) key) pair)))  ; *
           (setq pair2 (car rest))
           (setq k1   (car pair))
           (setq k2   (car pair2))
           (setq lst  (cdr rest))
           (when (eq k1 key) (return pair))
           (when (eq k2 key) (return pair2))
           (unless (consp lst) (return nil))))
     ;; special case for null key -- same as above but check that
     ;; pair, pair2 are not null.
     (fast-assoc-eq-nil lst))))

The distance between some of the loads and uses could be increased
further by additional unrolling/software pipelining.

        Paul

You know you're reading comp.lang.lisp when... IPmonger 3/19/02 8:00 PM
Erik Naggum <er...@naggum.net> writes:

    Let's just say that from within the family of American Political
  Parties, the differences seem more significant.  You could say that
  each party is speaking a different dialect.  Each side would likely
  declare that their party is the only one with true symbols, the other
  party merely having rhetorical keywords.  Perhaps it's all a matter of
  packaging.

    So, can a Republican be a Democrat?  I don't know for sure, but
  certain elements of the Republican party have recently engaged in such
  speculation to a degree that is reminiscent of the anti-Trotskyite
  Communist Party in 1934.

    As an independent, I find that my time is micro-optimized by
  avoiding political discussion with people who speak a different
  "dialect" from myself - which means that I rarely speak politics with
  anyone.  I tend to stay off of both political party lists (plists) and
  association lists (alists).  

    The only exception is the stream of correspondence between my
  representatives and myself.  Sometimes it seems like the direction is
  :output only from one or the other.  The system does (provide
  two-way-communication) but doesn't (require ) it.

    Of course, as a native Texan (currently indirected through
  Pennsylvania), we often SCHEME for a minimalist government, where
  features are added only by unanimous consent.  This means that we tend
  to decry MACRO-economic issues as being unhygienic.  We sometimes have
  trouble getting consensus on what the actual standard definition of
  government is, with some claiming that the Articles of Confederation
  are the last legitimate specification, Constitutional Conventions
  not-withstanding.

    But, it really does seem to come back down to an issue of
  packaging.  After all, most Texans prefer it to seem as if we had the
  whole fully-featured universe to ourselves, even if that means we have
  to import things from "out there."  The only thing we tend to
  studiously avoid is hash....

    I cdr listed much much more, but I fear that this is no longer pun
  for (rest comp.lang.lisp).

-jon
--
------------------
Jon Allen Boone
ipmo...@delamancha.org

You know you're reading comp.lang.lisp when... Bijan Parsia 3/19/02 8:39 PM
On Tue, 19 Mar 2002, IPmonger wrote:
[snip]

>     So, can a Republican be a Democrat?  I don't know for sure, but
>   certain elements of the Republican party have recently engaged in such
>   speculation to a degree that is reminiscent of the anti-Trotskyite
>   Communist Party in 1934.
[snip]

This is the third reference (I think) to Trotskyite purges in almost as
many days on comp.lang.lisp (with *no* counterbalancing Macarthyism crys
or "Let a thousand flowers bloom (so we can crush the
blossems)" quotes). By the rule of three, I think this establishes a
corollary of Godwin's law permitting me to hunt down all you
counter-revolutionary, godless, toy-lisp wielding symbolic processors!

Hmm. Perhaps this is a proof that the participants on comp.lang.lisp *are*
bots, and have gotten caught in a wierd race condition....

Cheers,
Bijan Parsia.

You know you're reading comp.lang.lisp when... Thomas F. Burdick 3/20/02 9:48 AM
Bijan Parsia <bpa...@email.unc.edu> writes:

No, that's a Social-Democratic deviation!  You should think about what
led you astray, and confess both the fact of your mistake and we are
bots, caught in a weird race condition....

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

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/20/02 11:43 PM
* Carl Shapiro

| There is a small amount of load parallelism in list traversal that can be
| exploited when using an alist.

  I do not think there is, at least if this means that the similar facility
  _cannot_ be exploited exactly equally well when using plist.

  An exactly equal amount of load parallelism is available for plists,
  namely to prefetch one cons cell forward.  However, both alists and
  plists need to consult one _more_ cons cell per iteration.  The alist
  finds it pointed to by the car, plist by the cdr.  As I have tried to
  explain already, there can be no difference between alists and plists in
  this regard.

  There are many other interesting differences between alists and plists.
  First of all, assoc is not a cheap function.  It has :key and :test
  arguments that, if the call is not inlined, cause a rather horrible
  degradation of performance.  Second, assoc uses eql by default, whereas
  getf uses eq.  This means that every mismatch must check for the type,
  and that might involve a function call.  (For this reason, I always use
  :test #'eq when I think eql is the wrong choice (which is most of the
  time), and this also does wonders by interpreting the :test argument in a
  compiler-macro to call the proper internal function.)  Third, and a
  consequence of the two preceding, alists can represent keys that plists
  cannot have, so they clearly have different uses.  Where they do overlap,
  plists are far superior, however.

  Let me explain why in some detail, and start with a _severely_ simplified
  definition of assoc, almost a caricature, and I renamed them alist-get
  and plist-get:

(defun alist-get (alist key)
  (do ((alist alist (cdr alist))
       (cons (car alist) (car alist)))
      ((or (not alist) (and cons (eq key (car cons))))
       (cdr cons))))

(defun plist-get (plist key)
  (do ((plist plist (cddr plist)))
      ((or (not plist) (eq (car plist) key))
       (cadr plist))))

  I wanted to get a really good grip on what these were doing, so I
  macroexpanded them and tinkered a little with the expansion:

(defun alist-get-expand (alist key)
  (let (cons)
    (tagbody
     loop
      (setq cons (car alist))
      (cond ((eq alist nil) (go end))
            ((eq cons nil))
            ((eq key (car cons)) (go end)))
      (setq alist (cdr alist))
      (go loop)
     end)
    (cdr cons)))

(defun plist-get-expand (plist key)
  (tagbody
   loop
    (cond ((eq plist nil) (go end))
          ((eq key (car plist)) (go end)))
    (setq plist (cddr plist))
    (go loop)
   end))

  This is assembly in Common Lisp, but so much more readable than C.  (For
  that reason, I have used (eq x nil) instead of (not x).)  These also
  produce the smallest code I can get squeezed out for these functions in
  all CL implementations I have access to, and of those, Allegro CL has
  produced by _far_ the tigher code.  (I am _amazed_, Duane!  But if you
  had let ecx be used for temporary storage when it was not going to be
  used for argcount, you would have saved two extraneous memory accesses
  per iteration, and one, maybe two, cost-free register moves.  Although
  there will always be a level 1 cache line for this memory, there is still
  a dependency on this access that could be eliminated.)

  Now, considering these differences in the implementation, there is no
  doubt that both functions need to cdr down a list and can prefetch that
  cdr cell access.  There is no way to prefetch the car of the cell before
  it is actually needed, but the above function has been carefully written
  to allow prefetching the caar access.  However, the savings created by
  this change is easily consumed by the extra test for nil elements.  The
  distance between the first possible time the prefetch can be executed and
  the actual reference is, however, only two compares and two branches not
  taken (if carefully coded)

| Before examining the car of some element, one could prefetch the cdr.

  But this is _exactly_ the same for alists and plists.  The plist has to
  do two cdrs in succession and the alist has to two cars in succession.

| This may increase the likelihood of the next list element being in cache
| by the time you are ready for it.

  But not the caar of the alist any more than the cddr of the plist.

| Joe Marshall's paper describing the architecture of the LMI K-Machine
| mentions that its compiler would emit such instructions to prefetch list
| elements when compiling mapping primitives.

  Sure, it helps tremendously if you are _not_ going to dive into another
  cons cell.  If you are going to dive into another cons cell, it matters
  not whether it is in the car or in the cdr of the cell you are looking
  at.

  I mean, if you scan a list one element at time and do something between
  each memory reference, find, prefetch the cdr, but just because you can
  scan the list marginally more efficiently in one direction does not mean
  that the other direction is irrelevant.

| With a plist one has to cdr past all elements so this opportunity would
| be lost.

  You seem to think that getting the key of an association is _free_.  This
  is so puzzling it is truly beyond my intellectual capacity to figure out
  how you can arrive at this conclusion, which looks completely bizarre, as
  if you have completely ignored the fact that you are _not_ comparing the
  car of each cons you visit, you visit the car of the car of each cons you
  visit.

  The fact that an alist and a plist requires equally many cons cells
  _should_ have been such an important clue.

  After having spent several hours on this, including returning to the
  entertaining Intel architecture manuals (because they show such an inner
  beauty despite the incredibly boneheaded instruction set), I conclude
  that any possible savings in prefetching that cdr cell will now take 300
  million years to amortize the cost of the research.

  (This message has been composed on and off over several days, so it still
  needs a lot of editing, which I am not inclined to give it.)

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/21/02 2:10 AM
* "Paul F. Dietz" <di...@interaccess.com>

| The result of the caar is not needed immediately.  You can software
| pipeline these side operations while you continue to cdr down the alist.

  But the _exact_ same thing can be done for the property list!

  I do not think you have worked this out for property lists to see how
  similar the effect is.

  *sigh*  

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Paul F. Dietz 3/21/02 4:57 AM
Erik Naggum wrote:

>   But the _exact_ same thing can be done for the property list!
>
>   I do not think you have worked this out for property lists to see how
>   similar the effect is.

No, exactly the same thing cannot be done with plists.

In the alist, you can fit two loads between each of the main
cdr loads (loading a car, and a caar; note that with software
pipelining these will be loads from farther back in the alist.)

In the plist, there is only one 'off the critical path' car
per *two* cdrs.  There simply isn't enough extra work to fit
into the dead space after each load on the critical path.

        Paul

data hygiene [Re: Why is Scheme not a Lisp?] Ian Wild 3/21/02 5:57 AM
"Paul F. Dietz" wrote:
>
> In the alist, you can fit two loads between each of the main
> cdr loads (loading a car, and a caar; note that with software
> pipelining these will be loads from farther back in the alist.)

Load car and cdr in parallel, load caar when car is available,


 
> In the plist, there is only one 'off the critical path' car
> per *two* cdrs.  There simply isn't enough extra work to fit
> into the dead space after each load on the critical path.

Load car and cdr in parallel, load cddr when cdr is available.


Am I missing something?  These seem identical to me.

data hygiene [Re: Why is Scheme not a Lisp?] Paul Dietz 3/21/02 7:57 AM
Ian Wild wrote:

 [ alist ]

> Load car and cdr in parallel, load caar when car is available,

 [ plist ]

> Load car and cdr in parallel, load cddr when cdr is available.
>
> Am I missing something?  These seem identical to me.

The point you are missing is that the car (and caar) you
load for the alist are not for the current cell, but for
previous cells.  There's no dependency between this iteration's
cdr, car, and caar.  You can delay the car and caar because
they're not on the critical path.

In contrast, there *is* a dependency between the cdr and
the cddr for the plist, and this dependency cannot be
gotten rid of.

        Paul

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/21/02 2:36 PM
* "Paul F. Dietz"

| No, exactly the same thing cannot be done with plists.

  Nonsense.  Have you worked this out for plists?  Yes or no?

| In the plist, there is only one 'off the critical path' car
| per *two* cdrs.  There simply isn't enough extra work to fit
| into the dead space after each load on the critical path.

  Nonsense.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/21/02 2:39 PM
* Paul Dietz

| The point you are missing is that the car (and caar) you load for the
| alist are not for the current cell, but for previous cells.  There's no
| dependency between this iteration's cdr, car, and caar.  You can delay
| the car and caar because they're not on the critical path.

  Who do you think you are kidding?

| In contrast, there *is* a dependency between the cdr and the cddr for the
| plist, and this dependency cannot be gotten rid of.

  But that is just like the dependency between the car and the caar!

  Please work this out for plists, too.  You _will_ be suprrised.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Kent M Pitman 3/21/02 2:56 PM
Erik Naggum <er...@naggum.net> writes:

> * "Paul F. Dietz"
> | No, exactly the same thing cannot be done with plists.
>
>   Nonsense.  Have you worked this out for plists?  Yes or no?
>
> | In the plist, there is only one 'off the critical path' car
> | per *two* cdrs.  There simply isn't enough extra work to fit
> | into the dead space after each load on the critical path.
>
>   Nonsense.

Can't someone just write a simple test and time it and then publish
the various code sequences in question for review?  Most things in the
world are too big and too abstract for such an exercise, but this is a
rare case that is small enough and concrete enough that you could just
test it by brute force.  It might waste less time than a "did not"
"did so" "did not" "did so infinity" kind of back and forth interchange.

data hygiene [Re: Why is Scheme not a Lisp?] Paul Dietz 3/21/02 3:13 PM
Erik Naggum wrote:

> | The point you are missing is that the car (and caar) you load for the
> | alist are not for the current cell, but for previous cells.  There's no
> | dependency between this iteration's cdr, car, and caar.  You can delay
> | the car and caar because they're not on the critical path.
>
>   Who do you think you are kidding?

I am not kidding.  I admit I am failing to penetrate your
confusion.

I suggest you look up the compiler optimization called 'software
pipelining'.  What I'm suggesting it just an application of
that well-known technique, which stretches out and overlaps
iterations so as to avoid stalls.  In this case the alist
algorithm can be more effectively pipelined because it has
more work off the critical path than the plist algorithm.


> | In contrast, there *is* a dependency between the cdr and the cddr for the
> | plist, and this dependency cannot be gotten rid of.
>
>   But that is just like the dependency between the car and the caar!

They are not the same, Mr. Naggum.  The dependency between the CAR and
the CAAR is not on the critical path.  We can wait several iterations
between computing (CAR X) (for some cell X) before we compute
(CAAR X).  We *cannot* do the same thing for the CDR and the CDDR.

        Paul

Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?]) Joe Marshall 3/21/02 3:42 PM

"Kent M Pitman" <pit...@world.std.com> wrote in message
news:sfwk7s5o7gy.fsf@shell01.TheWorld.com...

>
> Can't someone just write a simple test and time it and then publish
> the various code sequences in question for review?  Most things in the
> world are too big and too abstract for such an exercise, but this is a
> rare case that is small enough and concrete enough that you could just
> test it by brute force.  It might waste less time than a "did not"
> "did so" "did not" "did so infinity" kind of back and forth interchange.

I wasted far too much time today doing just that.
On my Pentium Pro 199Mhz (if the label is to be believed)
I put in Erik's `alist-get' and `plist-get' implementation.
I tested them on an 11 element alist or plist (as appropriate)
and timed how long it took to fetch the 9th and 10th elements.
I subtracted these two to get an estimate of how long it
takes for one iteration.  (safety 0) (speed 3)

alist-get:  40ns per iteration
plist-get:  40ns per iteration

It appears that reality agrees with Erik.

This makes sense to me:  Every iteration on an alist does
2 CARs and 1 CDR, while every iteration on a plist does
2 CDRs and 1 CAR.  There is no reason to think a call to
CAR is more or less expensive than a call to CDR.
Given that this process is probably bound by the memory
bandwith, 3 memory cycles is the probably the best one
can do, no matter what order you do them it.  And since
the pentium pro can do out-of-order execution (I believe
the pro can, I know the later ones can) seems likely
that a fairly optimal execution sequence is happening
in either case.

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/21/02 4:49 PM
* Paul Dietz

| I am not kidding.  I admit I am failing to penetrate your confusion.

  Oh, I see.  You already know the one true answer, so bothering to read
  what I post is not necessary to you.

| I suggest you look up the compiler optimization called 'software
| pipelining'.

  Arrogant dipshit.

| What I'm suggesting it just an application of that well-known technique,
| which stretches out and overlaps iterations so as to avoid stalls.

  CAN YOU WORK IT OUT FOR PLISTS, TOO?  YES OR NO?

| In this case the alist algorithm can be more effectively pipelined
| because it has more work off the critical path than the plist algorithm.

  No, this is simply _wrong_.  Just get it, will you?

| They are not the same, Mr. Naggum.  The dependency between the CAR and
| the CAAR is not on the critical path.

  Really?

| We can wait several iterations between computing (CAR X) (for some cell
| X) before we compute (CAAR X).  We *cannot* do the same thing for the CDR
| and the CDDR.

  Yes, it is _exactly_ the same thing.  Why do you keep claiming this only
  for alists?  You have not worked it out for plists, so you have no clue
  what you are talking about.  What you have done for alists, can be done
  for plists.  Just try it out, and you will see how simple this really is!

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Matthias Blume 3/21/02 4:59 PM
Erik Naggum <er...@naggum.net> writes:

> * Paul Dietz
> | The point you are missing is that the car (and caar) you load for the
> | alist are not for the current cell, but for previous cells.  There's no
> | dependency between this iteration's cdr, car, and caar.  You can delay
> | the car and caar because they're not on the critical path.
>
>   Who do you think you are kidding?
>
> | In contrast, there *is* a dependency between the cdr and the cddr for the
> | plist, and this dependency cannot be gotten rid of.
>
>   But that is just like the dependency between the car and the caar!
>
>   Please work this out for plists, too.  You _will_ be suprrised.

Simple example that does NOT agree with real hardware, but which should illustrate
the _potential_ for more parallelism in the alist case:

Suppose you can "spawn" as many sub-threads as you like at any point,
but following a pointer has a fixed cost.  In the plist case, you need
at least 2n time steps to traverse n key-value pairs because the fetch
operations (mostly CDRs) are all data-dependend on their respective
predecessors.  In the alist case, one thread could "run down" the
spine of the alist in roughly n steps, spawning a new thread at every
CAR.  The subthreads then independently check to see if their
respective key is the one that we are looking for.  This latter work
can effectively overlap with the guy running down the spine, so the
total time can be less than in the plist case.

On real hardware, _if_ the key comparison is cheap (e.g., EQ), then
each of those subthreads will live only very shortly, so the amount of
effective parallelism that needs to be supported by the hardware is
bounded (and rather small).

Obviously, as Joe's tests demonstrate, getting any real advantage out
of this on a real system is hard.  It would require tight coding, hardware
that can actually do something like the above, at least in some sense,
and would probably still not matter for relatively short lists.

By the way, this is all pretty silly anyway.  If I had to implement a
dictionary data structure where the number of keys is large enough so
that the above would matter, then I would *definitely* use something
else that has better theoretical (and practical) complexity.  (If
there is some natural ordering on keys, then for example, red-black
trees come to mind.)

Matthias

Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?]) Paul F. Dietz 3/21/02 5:04 PM
Joe Marshall wrote:

> It appears that reality agrees with Erik.

If the machine is such that memory bandwidth is more
important than memory latency, then of course the point
I was making does not apply.

        Paul

data hygiene [Re: Why is Scheme not a Lisp?] Paul F. Dietz 3/21/02 5:33 PM
Erik Naggum wrote:

> | What I'm suggesting it just an application of that well-known technique,
> | which stretches out and overlaps iterations so as to avoid stalls.
>
>   CAN YOU WORK IT OUT FOR PLISTS, TOO?  YES OR NO?

Yes I can.  In fact, I've already told you the result.
For plists you can't pipeline the loads as effectively.

This is a *trivial* consequence of the structure of the
dependency graph of the loads.  Both graphs have ~3 N nodes,
but the length of the critical path in the alist search
is N vs. 2N for the plist.


> | They are not the same, Mr. Naggum.  The dependency between the CAR and
> | the CAAR is not on the critical path.
>
>   Really?

Yes, really (except for the final cell).


>   Yes, it is _exactly_ the same thing.  Why do you keep claiming this only
>   for alists?  You have not worked it out for plists, so you have no clue
>   what you are talking about.

As Mr. Pitman requested, let's see the code.  Here's a software
pipelined implementation of (assoc ... :test #'eq), concentrating
on the case of a non-null key.  You will notice that in the main
loop (not counting epilogue code), between any load and the first
use of its result you will find at least two other loads.  You
can't do as well with plist search -- there aren't as many other
loads to fit between the cdrs.

If we're on a machine in which (1) load latency dominates, and
(2) three loads can be in progress at once, then this algorithm
will take time  N+O(1) (in units of load latency).  *Any* plist
algorithm would take time 2 N in this model of computation -- you
can't start one critical path load until the previous one is
completed, and there are 2 N such loads.

(defun assoc-eq (key alist)
  (if (null key) (assoc-eq-nil alist)
    ;; Software pipelined version of assoc :test #'eq on a non-nil key
    (prog
     (k1 k2 p x1 x2 y1 y2)

     ;; Loop prologue -- fill the pipeline
     ;; I haven't optimized this prologue

     (when (null alist) (return nil))
     (setq x1 (cdr alist))
     (setq p (car alist))
     (when (atom x1) (return (and (eq (car p) key) p)))
     (setq k1 (car p))
     (setq y1 (car x1))
     (setq x1 (cdr x1))
     (when (atom x1)
       (return (cond ((eq k1 key) p)
                     ((eq (car y1) key) y1)
                     (t nil))))

     ;; End of loop prologue

     loop

     ;;
     ;; At this point, the following invariants hold: for some i,
     ;;
     ;;  (eq p (nth i alist))
     ;;  (eq k (car p))
     ;;  (eq y1 (nth (1+ i) alist))
     ;;  (eq x1 (nthcdr (+ i 2) alist))
     ;;  (consp x1)
     ;;

     (setq x2 (cdr x1)  ; critical path load
           y2 (car x1)
           k2 (car y1))
     (when (eq k1 key) (return p))
     (when (atom x2)
       ;; Fell off end of list -- flush the pipeline
       (return (cond ((eq k2 key) y1)
                     ((eq (car y2) key) y2)
                     (t nil))))
     (setq p y1)

     ;; The loop has been unrolled once so that the first
     ;; use of y2 is delayed.
     ;; The following is identical to the previous
     ;; except that ?1 & ?2 variables have been swapped
     (setq x1 (cdr x2)  ; critical path load
           y1 (car x2)
           k1 (car y2))
     (when (eq k2 key) (return p))
     (when (atom x1)
       ;; Fell off end of list -- flush the pipeline
       (return (cond ((eq k1 key) y2)
                     ((eq (car y1) key) y1)
                     (t nil))))
     (setq p y2)
     
     (go loop))))
     
(defun assoc-eq-nil (alist)
  ;; This can be implemented similarly, but we also must check
  ;; that the element of alist is not nil.
  ;; For now, this is just a placeholder.
  (assoc nil alist :test #'eq))

Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?]) Kent M Pitman 3/21/02 5:38 PM

As I've said, my understanding of this area is weak, but perhaps then
Joe would have had better luck if he were searching a circular list,
since then the memory in question might be in a cache and would not
dominate the time spent?  This, in turn, might allow you to loop out
of control more efficiently with circular alists than with circular
plists, if I understand the claim.  ... Just an idea.

Perhaps not as useless as it sounds.  The C crowd often makes sales
over the Lisp crowd when they claim that although they can't make some
of the kinds of tools we regularly do, they can at least do it
faster...  (Maybe they don't put it quite that way, though.)

Never underestimate the power of good marketing.

data hygiene [Re: Why is Scheme not a Lisp?] Erann Gat 3/21/02 7:07 PM
In article <sfwk7s5...@shell01.TheWorld.com>, Kent M Pitman
<pit...@world.std.com> wrote:

Using MCL 4.3.1:

? (setf l1 '(a 1 b 2 c 3 d 4 e 5 f 6 g 7 h 8))
(A 1 B 2 C 3 D 4 E 5 F 6 G 7 H 8)
? (setf l2 '((a . 1) (b . 2) (c . 3) (d . 4) (e . 5) (f . 6) (g . 7) (h . 8)))
((A . 1) (B . 2) (C . 3) (D . 4) (E . 5) (F . 6) (G . 7) (H . 8))
? (getf l1 'h)
8
? (assoc 'h l2)
(H . 8)
? (time (dotimes (i 1000000) (assoc 'h l2)))
;Compiler warnings :
;   Undeclared free variable L2, in an anonymous lambda form.
(DOTIMES (I 1000000) (ASSOC 'H L2)) took 192 milliseconds (0.192 seconds)
to run.
NIL
? (time (dotimes (i 1000000) (getf l1 'h)))
;Compiler warnings :
;   Undeclared free variable L1, in an anonymous lambda form.
(DOTIMES (I 1000000) (GETF L1 'H)) took 740 milliseconds (0.740 seconds) to run.
Of that, 10 milliseconds (0.010 seconds) were spent in The Cooperative
Multitasking Experience.
 200 bytes of memory allocated.
NIL
?

Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?]) Erann Gat 3/21/02 7:19 PM
In article <3C9A8338...@interaccess.com>, "Paul F. Dietz"
<di...@interaccess.com> wrote:

Right.  Was your benchmark walking over a long a/p-list or iterating
multiple times over a short one?  When doing the latter on a G4 so
everything is in cache, plists were much slower (740 ms vs 191 ms for
1000000 iterations over an 8-element a/p-list).  (Transcript was posted in
the previous thread.)

E.

data hygiene [Re: Why is Scheme not a Lisp?] Andreas Eder 3/21/02 10:05 PM
tb+u...@becket.net (Thomas Bushnell, BSG) writes:

> One reason is that memory utilization is no longer the tight issue it
> used to be; another thing the mention is that CDR-coding might
> actually slow down certain common pointer traversal idioms.

But with the ever increasing gap in speed between cpus and memory, it
might become an issue again. I'm almost sure someone will reinvent
CDR-coding, and think of it as the best thing since sliced bread.

Andreas

--
Wherever I lay my .emacs, there愀 my $HOME.

data hygiene [Re: Why is Scheme not a Lisp?] Duane Rettig 3/21/02 11:00 PM
g...@jpl.nasa.gov (Erann Gat) writes:

> Using MCL 4.3.1:
>
> ? (setf l1 '(a 1 b 2 c 3 d 4 e 5 f 6 g 7 h 8))
> (A 1 B 2 C 3 D 4 E 5 F 6 G 7 H 8)
> ? (setf l2 '((a . 1) (b . 2) (c . 3) (d . 4) (e . 5) (f . 6) (g . 7) (h . 8)))
> ((A . 1) (B . 2) (C . 3) (D . 4) (E . 5) (F . 6) (G . 7) (H . 8))
> ? (getf l1 'h)
> 8
> ? (assoc 'h l2)
> (H . 8)
> ? (time (dotimes (i 1000000) (assoc 'h l2)))
> ;Compiler warnings :
> ;   Undeclared free variable L2, in an anonymous lambda form.
> (DOTIMES (I 1000000) (ASSOC 'H L2)) took 192 milliseconds (0.192 seconds)
> to run.
> NIL
> ? (time (dotimes (i 1000000) (getf l1 'h)))
> ;Compiler warnings :
> ;   Undeclared free variable L1, in an anonymous lambda form.
> (DOTIMES (I 1000000) (GETF L1 'H)) took 740 milliseconds (0.740 seconds) to run.
> Of that, 10 milliseconds (0.010 seconds) were spent in The Cooperative
> Multitasking Experience.
>  200 bytes of memory allocated.
> NIL

We should look at this carefully, Erann.  It is possible you are
measuring the wrong thing here.  Let me suggest the possible problem:

First, I assume that MCL is compiling the forms that it is running.
If not, then that is the first place to start, since we shouldn't
want to see the interpreter running.  However, I am assuming that no
interpreter is running here, otherwise I would have expected the &key
processing in the assoc call to vastly outweigh the &optional processing
of the getf.

However, I would still recommend that you put each of these dotimes
forms into a defun and compile it (if necessary) and then disassemble
it, to see what is _really_ being run.

I suspect that assoc is being optimized, by being rewritten to call
some internal function (let's call it assoc-eql), because it is being
called with no keyword arguments.  It is even likely that there is no
function call at all, and the assoc is simply being expanded in open
code.

But the getf is likely not being optimized.  I supect this because of
the nature of the Stanford Benchmarks (i.e. the Gabriel benchmarks),
which do contain calls to assoc but which do not contain any calls to
getf.  Getf, therefore was never one that any of us vendors cared to
optimize, because it was never under microoptimization scrutiny.

If my guesses are correct, then what you have is a highly optimized
version of assoc (possibly even open-coded) and a non-optimized getf,
which at least has optional processing.

--
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   duane@Franz.COM (internet)

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/21/02 11:12 PM
* Matthias Blume

| Suppose you can "spawn" as many sub-threads as you like at any point,
| but following a pointer has a fixed cost.

  Are you trying to make me pretend that spawning a sub-thread is free and
  following pointer has costs?  This is the part I simply reject.

| In the plist case, you need at least 2n time steps to traverse n
| key-value pairs because the fetch operations (mostly CDRs) are all
| data-dependend on their respective predecessors.  In the alist case, one
| thread could "run down" the spine of the alist in roughly n steps,
| spawning a new thread at every CAR.  The subthreads then independently
| check to see if their respective key is the one that we are looking for.
| This latter work can effectively overlap with the guy running down the
| spine, so the total time can be less than in the plist case.

  I see that several people have been working this out on a mythical
  computer, not extant hardware.  I am frankly completely unimpressed with
  the arguments that have been made so far.  One does not optimize
  theoretical code for theoretical computers.

| On real hardware, _if_ the key comparison is cheap (e.g., EQ), then each
| of those subthreads will live only very shortly, so the amount of
| effective parallelism that needs to be supported by the hardware is
| bounded (and rather small).

  Well, at least they have to live long enough to grab the cons cell
  pointed to by the car and the contents o the car of that cell.  Now, it
  is all well and good to have a CPU that can pipeline anything you want,
  but we are actually trying to talk to the same _memory_, right?  And that
  is not the memory in either L1 or L2 cache, right?  How many requests can
  the _memory_ pipeline from data that are going to be very close?  I mean,
  my CPU has 32-byte cache lines, meaning it will usually not do any less
  than 32-byte fetches, but the crucial thing is to prefetch _both_ car and
  cdr of all cells visited in order to obtain maximal memory performance.
  To make this work, one would have to do massive analysis of the addresses
  that are actually fetched.  This is actually possible as long as one has
  to fetch from real memory instead of L1 or L2 caches, or even L3 caches.

  In order to make this a testable condition, there is no point in scanning
  some short list.  The list has to be at least 1 million entries in length
  for the test conditions to ensure that all data cache lines are flushed.
  To make that work, there would be some savings in cdr'ing ahead to fill
  half the L1 cache so the cons cells, which I assumme will occupy 2
  adjacent words, will be in the L1 cache when the car visits it.  However,
  in total, there will be exactly as many memory references with a plist
  and an alist, because they use exactly as many cons cells.

  I maintain that on, e.g., the IA32, which I have spent some time learning
  how to optimize the living daylight out of, you will never see any
  difference in performance between an alist and a plist.  There is no
  magic in this, just the willingness not to "suppose" one can do something
  that no processor actually does.

| Obviously, as Joe's tests demonstrate, getting any real advantage out of
| this on a real system is hard.  It would require tight coding, hardware
| that can actually do something like the above, at least in some sense,
| and would probably still not matter for relatively short lists.

  None of the compiled code I have seen has used prefetch instructions, and
  the pipeline on, e.g., IA32, is not long enough to see these actualy
  memory fetch coming.  Therefore, current tests exhibit nothing of the
  kind we would like to prove in this exercise.

  In order to measure the impact of any savings, the best approach is
  probably to have a forerunner that visits both cars and cdrs in an alist
  and the cdrs in a plist.  It should probably be running at _least_ 8 cons
  cells ahead of their use, but something like 100 will probably make more
  sense, in order to give the memory time to fill up the cache lines.  This
  also indicates that there is very significant savings to be had from
  starting the storage of any object on cache line boundaries.

  But suppose your list is short enough that all cons cells can fit in L1
  cache.  The best optimization approach is simply to call length on it to
  move all the cons cells into L1 cache, and then to make sure that they
  stay there between every time you need to scan the list.  If you manage
  to expire the cache lines between calls to either assoc or getf, there is
  no point in this exercise at all, since the next time it is needed, you
  will have to go out and prefetch it, anyway, and since both assoc and
  getf must return the first occurrence, the likelihood of prefetching
  memory that you will never use is pretty high.

| By the way, this is all pretty silly anyway.  If I had to implement a
| dictionary data structure where the number of keys is large enough so
| that the above would matter, then I would *definitely* use something else
| that has better theoretical (and practical) complexity.

  Yup.  I have been trying to argue that assoc is more expensive because it
  is more way more general and may do a _lot_ more work than getf, which
  could be as simple as my plist-get.  To get a user call to assoc be as
  tight as my alist-get requires a lot of effort in both compiler and user
  code.

  I think, however, that I have demonstrated exhaustively that there is no
  performance difference between alist and plist and that performance
  should never enter the picture when deciding which to use.  For instance,
  performance is likely to be good for get-properties and destructuring
  using keyword arguments, neither of which have a parallell for alists.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/21/02 11:22 PM
* "Paul F. Dietz"

| This is a *trivial* consequence of the structure of the dependency graph
| of the loads.  Both graphs have ~3 N nodes, but the length of the
| critical path in the alist search is N vs. 2N for the plist.

  This is just plain wrong.  Please understand that we are doing assoc, not
  member, on alists, OK?  The car of an alist is just as much on the
  critical path as the cdr of a plist.  This is frighteningly obvious if
  you spend the time to __study it rather than make up your mind and then
  spend your time to "prove" it.

| As Mr. Pitman requested, let's see the code.  Here's a software
| pipelined implementation of (assoc ... :test #'eq), concentrating
| on the case of a non-null key.

  What does "concentrating on the case of a non-null key" mean?

| You will notice that in the main loop (not counting epilogue code),
| between any load and the first use of its result you will find at least
| two other loads.  You can't do as well with plist search -- there aren't
| as many other loads to fit between the cdrs.

  I have asked you to work this out for plists, too, but you keep posting
  only code relevant to alists.  I am not interested in what you have to
  say about alists as long as you make _no_ effort to show what you can do
  similarly with plists.  Can you please understand this?

| If we're on a machine in which (1) load latency dominates, and (2) three
| loads can be in progress at once, then this algorithm will take time
| N+O(1) (in units of load latency).  *Any* plist algorithm would take time
| 2 N in this model of computation -- you can't start one critical path
| load until the previous one is completed, and there are 2 N such loads.

  *sigh*.  Yes, that is precisely what you can do.  There is no difference.

  Work it out similarly for plists.  CAN YOU DO THIS, PLEASE!?  Christ!

  Your code is extremely unlikely to have any effect, by the way.  If you
  have to grab data from external memory, you need _way_ more than two
  intervening loads.  An L1 cache hit is basically free, so the point is to
  get stuff into the L1 cache.  This does not happen any differently in
  your code than in a straight version of alist-get and plist-get that I
  posted.

  I wonder why you are so stubborn about something that is clearly wrong.

///
--
  In a fight against something, the fight has value, victory has none.
  In a fight for something, the fight is a loss, victory merely relief.

data hygiene [Re: Why is Scheme not a Lisp?] Erik Naggum 3/21/02 11:46 PM
* Duane Rettig <du...@franz.com>

| We should look at this carefully, Erann.  It is possible you are
| measuring the wrong thing here.  [...]
:
| If my guesses are correct, then what you have is a highly optimized
| version of assoc (possibly even open-coded) and a non-optimized getf,
| which at least has optional processing.

  This is why I wrote my own alist-get and plist-get and even wrote the
  tagbody out in full and tweaked it considerably.  The overhead of using
  assoc and getf with all their (hugely different) generality completely
  wipes out any savings in memory