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
···@jpl.nasa.gov
···@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 -=- ············@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.
Rahul Jain <·····@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
* ·········@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.
In the last exciting episode, Erik Naggum <····@naggum.net> wrote::
> * ·········@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 ····················@" "454aa"))
http://www3.sympatico.ca/cbbrowne/sgml.html
"Christopher Browne" <········@acm.org> wrote in message
···················@salesman.cbbrowne.com...
> In the last exciting episode, Erik Naggum <····@naggum.net> wrote::
> > * ·········@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
* Christopher Browne <········@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.
Erik Naggum <····@naggum.net> wrote:
>* Christopher Browne <········@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 article <················@naggum.net>, Erik Naggum wrote:
> * ·········@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
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:
> * ·········@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.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> ···@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/
···@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.
In article <····················@eglaptop.jpl.nasa.gov>,
Erann Gat <···@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, ······@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.
Barry Margolin <······@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 <···@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
Lieven Marchand <···@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
In article <················@paloalto-snr2.gtei.net>,
Barry Margolin <······@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
····@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 -=- ············@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.
Rahul Jain <·····@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.
In article <··············@photino.sid.rice.edu>,
Rahul Jain <·····@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
····@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 -=- ············@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.
Rahul Jain <·····@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
····@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?
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
>····@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
In article <············@news.gte.com>, Dorai Sitaram <····@gte.com> wrote:
>In article <···············@shell01.TheWorld.com>,
>Kent M Pitman <······@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
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <············@news.gte.com>, Dorai Sitaram <····@gte.com> wrote:
> >In article <···············@shell01.TheWorld.com>,
> >Kent M Pitman <······@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.
Kent M Pitman <······@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
Doug Quale <······@charter.net> writes:
> Kent M Pitman <······@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.
Kent M Pitman <······@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?
·········@becket.net (Thomas Bushnell, BSG) writes:
> Kent M Pitman <······@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. 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".
Kent M Pitman <······@world.std.com> writes:
> ·········@becket.net (Thomas Bushnell, BSG) writes:
>
> > Kent M Pitman <······@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
In an attempt to throw the authorities off his trail, ·········@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 ··········@" "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/>
* 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.
·········@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Kent M Pitman <······@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.
Kent M Pitman <······@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Kent M Pitman <······@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?
I don't think so.
Regs, Pierre.
--
Pierre R. Mai <····@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
Kent M Pitman <······@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
Doug Quale <······@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 -=- ············@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.
Doug Quale <······@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.
Carl Shapiro <·············@panix.com> writes:
> Doug Quale <······@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.)
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
Doug Quale <······@charter.net> writes:
> Carl Shapiro <·············@panix.com> writes:
>
> > Doug Quale <······@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 "E.
(NLAMBDA (X Y) (LIST X Y)) == (LAMBDA ("E X Y) (LIST X Y))
NLAMBDA had no way to express &EVAL, which would undo the "E 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
Doug Quale <······@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.)
Kent M Pitman <······@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.
* 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.
Kent M Pitman <······@world.std.com> writes:
> Doug Quale <······@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.
> 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.
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
* 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.
Doug Quale <······@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.
The world rejoiced as Kent M Pitman <······@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/>
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
······@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.
Kent M Pitman <······@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
·········@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 -=- ············@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.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> ·········@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@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 -=- ············@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.
Rahul Jain <·····@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
>
> > ·········@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 ·····@Franz.COM (internet)
Duane Rettig <·····@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?
·········@becket.net (Thomas Bushnell, BSG) writes:
> Duane Rettig <·····@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 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>,
Duane Rettig <·····@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
In article <··············@photino.sid.rice.edu>,
Rahul Jain <·····@sid-1129.sid.rice.edu> wrote:
>·········@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
·········@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.
Kent M Pitman <······@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
* 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.
Erik Naggum <····@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
* 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.
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> ... the lack of first-class symbols ...
Scheme has first-class symbols. See R5RS section 6.3.3
E.
Kent M Pitman <······@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.
--
<·······@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
* 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.
Erik Naggum <····@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.
--
<·······@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
* 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.
·········@becket.net (Thomas Bushnell, BSG) writes:
> Kent M Pitman <······@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.
Kent M Pitman <······@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.
·········@becket.net (Thomas Bushnell, BSG) writes:
> Kent M Pitman <······@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.
·········@becket.net (Thomas Bushnell, BSG) writes:
> Erik Naggum <····@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.
Kent M Pitman <······@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.)
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
······@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 -=- ············@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.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> ······@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
>
> > ······@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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
·········@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 -=- ············@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.
* 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.
······@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.
--
<·······@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
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
* 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.
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
* 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.
Erik Naggum: [crap beyond contempt elided]
> ... 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.
where is that evidence? give a reference to significant research.
oz
* ozan s yigit <··@blue.cs.yorku.ca>
| where is that evidence? give a reference to significant research.
Yup, another revengeful moron. We just cannot do without them, can we?
What is _wrong_ with you guys? Why do you have such a huge problem just
living your own lives that you have to run after people you hate to taunt
them with completely idiotic passive-aggressive and so hostile rhetorical
"question" like these? Get a _life_, ozan s yigit! And just _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.
Naggum (?):
? ... 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.
> | where is that evidence? give a reference to significant research.
? [crap elided] We just cannot do without them, can we?
no you cannot, especially if you choose to spew hateful rhetoric about
intellectual honesty and learning. this is a real question about a curious
claim. what evidence, what research? go look it up, post a reference for
that "much evidence" when you are done with your spluttering.
oz
---
the factual burden of a science varies inversely with its degree
of maturity. -- Peter Medawar
* ozan s yigit
| [crap beyond contempt elided]
* ozan s yigit
| [crap elided]
Learn to behave, get a life, and stop believing that you can order people
around. Please take your time. I may want to answer your questions when
you manage to present yourself as a human being, but it is not likely.
In any case, please cease and desist with your abusive behavior.
///
--
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.
Erik Naggum:
? ... 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.
so, are you going to just drool and splutter as is your custom, or post
something worth reading to support this curious "people are not _naturally_
"higher-order thinkers"" claim? here, i'll even include something possibly
relevant to get you started.
oz
---
obref: Merlin Donald, "Origins of the Modern Mind" Harvard, 1991.
* ozan s yigit <··@blue.cs.yorku.ca>
| so, are you going to just drool and splutter as is your custom [...]
Learn to behave. Cease and desist with your abusive behavior. I need to
know that you are a human being who can think to avoid wasting my time on
answering anything you ask for. So far, you have given very strong clues
that you are only a hateful moron who plays games with idiotic questions.
If you do not wish to present yourself as a thinking human being, that is
your problem, not mine. Now, the reason I do not pretend that you are a
human being, which I have done with several other people in the past who
have not behaved, is that you chose to be just as abusive as you are here
in private communication, which is a _very_ strong indicator that this is
personal to you and that you are both mentally unstable and either unable
to modify your behavior to reach your goals or destructive. So _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.
Erik Naggum: [more abusive crap elided]
go get your pills, and answer the simple question. what evidence are you
talking about, and what are the references? continuing indications are, you
have no clue, nor enough intellectual honesty to admit that such is the case.
oz
* ··@cs.yorku.ca (ozan s. yigit)
| Erik Naggum: [more abusive crap elided]
I politely ask you to behave. You are doing all the abuse around here.
| go get your pills, and answer the simple question.
Well, I do not elide your abusive behavior because I do not like people
who lie about what other people do and provide no evidence of it.
| what evidence are you talking about, and what are the references?
| continuing indications are, you have no clue, nor enough intellectual
| honesty to admit that such is the case.
You are asked to behave before you have any hope of getting an answer,
and this has been made clear to you. It is really that simple.
Just cease and desist with your abusive behavior, ozan s. yigit.
///
--
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.
Erik Naggum :
?* ··@cs.yorku.ca (ozan s. yigit)
? | Erik Naggum: [more abusive crap elided]
?
? I politely ask you to behave.
as opposed to you, who evidently cannot possibly be told how to behave.
i am not interested in your fake politeness.
? You are doing all the abuse around here.
this is a lie. retract it.
? | go get your pills, and answer the simple question.
?
? Well, I do not elide your abusive behavior because I do not like people
? who lie about what other people do and provide no evidence of it.
don't you have asprin or tylenol at home? i sure do. i sure need it after
what is turning into a surreal and nasty experience trying to get a reference
or two about a curious claim.
? | what evidence are you talking about, and what are the references?
? | continuing indications are, you have no clue, nor enough intellectual
? | honesty to admit that such is the case.
? You are asked to behave before you have any hope of getting an answer,
? and this has been made clear to you. It is really that simple.
you are held to the same standards you hold others to. since when your
ignorance become a point of view? provide some reasonable evidence that
you know what you are talking about or just say you don't know. it is
really that simple.
oz
---
Det bedste er ikke for godt.
* ··@cs.yorku.ca (ozan s. yigit)
| as opposed to you, who evidently cannot possibly be told how to behave.
| i am not interested in your fake politeness.
Oh, so when I am polite, it is fake. This is great. You are so funny.
| ? You are doing all the abuse around here.
|
| this is a lie. retract it.
No, it is the barenaked truth, ozan s. yigit. Just stop your abuse.
| don't you have asprin or tylenol at home? i sure do.
No, my head does not hurt when I use it.
| i sure need it after what is turning into a surreal and nasty experience
| trying to get a reference or two about a curious claim.
Nasty? You are simply asked to behave, yet you flood the newsgroup with
abusive and hostile messages. Well, perhaps you feel your own pain.
I have already told you: just behave well and give me evidence that you
are thinking human beging who has a constructive purpose with your
"questions", and I might considering answering your questions, but as I
have also said, it is not very likely, since you are such a despicable
person. It should be very simple to just behave well, unless, of course,
you are so hateful that you cannot even fake good behavior. I think you
are, you see, so I primarily want you to self-destruct.
| you are held to the same standards you hold others to.
You know my standards? Above, you just called my standards fake. If you
had at least some integrity, you would have realized that you apply what
you think are my standards, and at least have _some_ allowance for having
misunderstood or made a mistake in that process, but you are _so_ certain
of yourself and your view that nobody, least of all me, can be allowed to
attempt to change your mind. When you see a change in behavior, you even
think it is "fake". You call statements of fact about your own behavior
"a lie". Such is bound to give headaches. Psychosis can hurt so much.
Just behave well, ozan s. yigit. And consider this: If you cannot do it
on demand, why do you expect anyone else to be able to do it? When they
do change their behavior, it drives you nuts. What does this tell about
you and your purpose in posting to this newsgroup?
///
--
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.
erik naggum: apologize for your dishonest and hostile statements on
this newsgroup and retract. grow some intellectual backbone and admit
when you have no clue about something.
oz
* ozan s yigit <··@blue.cs.yorku.ca>
| erik naggum: apologize for your dishonest and hostile statements on
| this newsgroup and retract. grow some intellectual backbone and admit
| when you have no clue about something.
You think you can give these orders, yet you cannot even behave well on
order when it would have gotten you want tyou want? You are such a funny
guy.
Show me what an honest apology looks like, and I will emulate it. Since
you believe my good behavior is "fake", I have no reason to think you are
even capable of an honest apology yourself, nor that you would belive one
if you got it. You have approached me privately and publicly with a very
hostile attitude and show absolutely no _ability_ to change your behavior
or to be constructive about anything. _Why_ should I accomodate your
very hostile and very, very stupid requests? _You_ have misbehaved
towards _me_, ozan s yigit, while you have been asked to stop and to
behave better in return, nothing else. If you attack people out of the
blue in order to have them apologize for something they have not done to
you, while you are free to attack people, you are clinically insane and
should be locked up. People who have this kind of mission from God to
make other people behave in ways they cannot are dangerous. That was
pretty obvious from your first article and your first mail message. I
just enjoy point out how screwed up some people are, particularly your
kind. No, go take your pills and learn to behave. You have bad enough
problems controlling yourself, so do not even _try_ to control others
before you have acquired self-control. An honest apology for your
attacks and your attitude problem would be very welcome, however.
///
--
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.
so, to summarize:
naggum posts (amongst a storm of maledicta) a curious claim.
? ... 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.
i simply ask:
where is that evidence? give a reference to significant research.
after more maledicta and dishonest deconstruction, not one piece of usable
information relevant to this claim (which i strongly disagree with) nor an
apology for any of this disgusting behaviour. there is nothing more to
be said.
logorrhea is its own petard.
*plonk*
oz
---
genus est mortis male vivere -- ovid
* ozan s yigit <··@blue.cs.yorku.ca>
| i simply ask:
Need I remind you of all the abusive behavior you have accompanied your
"request" with, and which is the sole reason that I refuse to grant you
any shred of respect for your question? You are destructive person, ozan
s yigit, and you are so self-righteous that you do not see your hatred,
which is even self-fueling. I do not grant self-righteous people who
spend so much energy attacking me any leeway at all, and certainly do not
do as they ask. You have refused to behave better, and still do, so I
guess you are incurably destructive and hateful. This is important to
know about you.
| after more maledicta and dishonest deconstruction,
Where? I have only asked you to behave before you get any answers.
| not one piece of usable information relevant to this claim
You might get it if you behaved properly instead of being such a horribly
destructive person.
| (which i strongly disagree with)
What you disagree with is completely irrelevant. If you had a contrary
opinion or had knewn of facts to the contrary, you could have provided
some useful counter-information of your own and inspired a discussion,
yet all you do is attack someone you disagree with. This must mean that
you are so much more interested in attacking me than in shedding light on
any subject at all that I have been entirely justified in denying you any
respite from my request that you start thinking. That you now take my
unwillingness to do your stupid bidding as evidence of ill will is such
an important property of your own personality that I find it strange that
you choose to share it with us, but that is your choice.
| nor an apology for any of this disgusting behaviour.
Which disgusting behavior? I have asked you to behave. If you think
there has been hostility in my request, you are quite wrong, yet you
regard being treated politely as "fake", indicating to us all that you
are so hateful that facts alone can never alter your opinion of anything.
This is another thing I would have kept to myself if I should suffer from
it, but you choose to share it.
And, is asking you to behave so disgusting to you? You damend, stomping
your feet like a spoiled child, that I "apologize" for something, yet you
refuse to apologize for your vicious attacks against someone while you
believe you can demand an apology for something that has not even been
done to you? What _is_ your problem? You seriously need help to get
over your emotional problems.
| there is nothing more to be said.
Yes, I sincerely hope that you will shut up for the rest of your life.
This concludes yet another demonstration of how a nutjob on a mission
from his self-righteous conscience-by-proxy is unable to grasp the
simplest thing about cause and effect and is so tremendously hung up in
his own emotions that he cannot deal with what he could have observed.
Good riddance, ozan s yigit! Next time, open polite and intelligent.
///
--
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.
Erik Naggum <····@naggum.net> writes:
> Need I remind you of all the abusive behavior you have accompanied your
> "request" with, and which is the sole reason that I refuse to grant you
> any shred of respect for your question?
This rings very hollow.
* Thomas Bushnell, BSG
| This rings very hollow.
Oh, Christ, get _over_ yourself! Grow up, little mind.
///
--
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.
Erik Naggum <····@naggum.net> writes:
> * Thomas Bushnell, BSG
> | This rings very hollow.
>
> Oh, Christ, get _over_ yourself! Grow up, little mind.
You protest that ozan s yigit has accompanied his request with
"abusive behavior". And yet you actually *do* exhibit abusive (and
cowardly) behavior every chance you get.
Rings a little hollow to hear you complain about someone else's
allegedly abusive behavior.
Oh, if you want to disprove the "cowardly" label, just put your
accusations in writing and send them to my department. That would be
the courage of your convictions in action.
Thomas
* Thomas Bushnell, BSG
| You protest that ozan s yigit has accompanied his request with "abusive
| behavior". And yet you actually *do* exhibit abusive (and cowardly)
| behavior every chance you get.
Please quit projecting yourself onto me.
| Rings a little hollow to hear you complain about someone else's allegedly
| abusive behavior.
Of course _you_ think it does. You, like ozan s yigit, have been
incredibly abusive and blame me for your behavior. You simply cannot
understand your own role and can _not_ quit your abuse behavior, but
quite unlike me, you step into all sorts of discussions with _purely_
off-topic crap about other people. CAN YOU QUIT THAT MORONIC SHIT?
| Oh, if you want to disprove the "cowardly" label, just put your
| accusations in writing and send them to my department.
Thomas Bushnell, you are the coward here. You have declined to answer my
request for the the name and address of those you want me to inform of
their role as the evidence of your ability to think. Fess up or shut up!
| That would be the courage of your convictions in action.
Your department (why did it change from your advisor?) really has nothing
to do with your retarded and abusive behavior, but _you_ involve them in
it, and that is the only thing I intend to inform them of. However, I
would like to do this as officially as possible, so I need the name of
the people who have guaranteed that you can think. If you just keep
repeating this moronic line and continue to decline to provide the names
and addresses of the people you want to involve, the label "coward" will
stick to you for a very long time.
What you keep doing here is so ridiculous that it is itself reason to
inform the people _you_ want to implicate, but _you_ have to inform us
all of who those people are. However, I consider your failure to grasp
that your posting here on a newsgroup does not constitute violation of
any rules, but your implication of your university, department, graduate
program, or individual people, _does_. I want you to name those people
if you are so concerned about not being labeled a coward. You are simply
an abusive idiot for playing this stupid trick, but I would prefer if you
were not such a chickenshit that you keep this going by inviting what you
do not have the guts to complete. _Name_ the people and provide their
address to this forum, or shut 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.
Erik Naggum <····@naggum.net> writes:
> * Thomas Bushnell, BSG
> | You protest that ozan s yigit has accompanied his request with "abusive
> | behavior". And yet you actually *do* exhibit abusive (and cowardly)
> | behavior every chance you get.
>
> Please quit projecting yourself onto me.
So calling me an idiot, a moron, intellectual dishonest, a
chicken-shit, and you think that's not abusive? What counts as
abusive?
* Thomas Bushnell, BSG
| What counts as abusive?
Repetitive hostile "questions" like yours which continue to have
absolutely _nothing_ to do with this forum, but only with your need to
harrass me, along with the other whining morons here. Quit it, 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.
Erik Naggum <····@naggum.net> writes:
> * Thomas Bushnell, BSG
> | What counts as abusive?
>
> Repetitive hostile "questions" like yours which continue to have
> absolutely _nothing_ to do with this forum, but only with your need to
> harrass me, along with the other whining morons here. Quit it, OK?
Yeah, you are the injured party. Poor Erik, getting all this
harassment. It's so unfair, since you are the very soul of propriety,
kindness, and decorum.
Thomas
* Thomas Bushnell, BSG
| Yeah, you are the injured party.
Yes, in fact. Just because you feel injured, too, does not give you the
"right" to go after and hurt others on purpose, and that is precisely
what you do.
If _you_ were injured, you would seek a way to cause less injury, not
cause more of it. Thus, you are not injured, but you are hateful and
vengeful. I have tried to make you stop, but you keep going with more
and more evil. People observe this and draw their solid conclusions.
But I am actually happy to see you self-destruct. I just wish it would
happen a _lot_ fastesr.
| Poor Erik, getting all this harassment. It's so unfair, since you are
| the very soul of propriety, kindness, and decorum.
Was that the University of California at Irvine _Kindergarten_ graduate
program?
It is getting pretty obvious that you are _thoroughly_ evil, Thomas
Bushnell, and that you defend your evil by attacking someone that you
think is "bad" and therefore not "deserving" of good behavior. What if
you were wrong? What if _you_ are the bad guy and _you_ get what you
deserve? People like you never ask that question, because you think all
you need is good intention. But where does the road lead that is paved
with good intentions? They are waiting for you.
Why are you nutjobs so unable to behave such that people might _want_ to
treat you better or even nicely? What happend to the other cheeK? What
is your ethics worth if you use it to hurt people you hate? Is this the
whole Middle East in some kind of miniature?
Cease and desist, Thomas Bushnell. Fight your deamons privately.
///
--
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.
I would not respond, but for this quote:
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> People observe this and draw their solid conclusions.
Yup. But I'm not entirely sure the conclusions they (at least me) draw
correspond to your expectations.
Before continuing, let me say that I've really enjoued (and hopefully
learned from) the ongoing technical discussions that have lately been in
this group. Both you and Tom have contributed things that have given me
lots to think about, as I have a lot to learn. I appreciate it and thank
you both.
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
>* Thomas Bushnell, BSG
>| Yeah, you are the injured party.
>
> Yes, in fact. Just because you feel injured, too, does not give you the
> "right" to go after and hurt others on purpose, and that is precisely
> what you do.
The thing that's so ironic about this is that this is _exactly_ what it
looks like you have a long history of doing yourself. Hell, it goes back
11 years, to this post from 1991:
>You little fuckhead. If all you can argue against are where people
>are posting from, you're even more of a sniveling little ratface than
>I imagined. Get a clue, moron.
http://groups.google.com/groups?hl=en&selm=ENAG.91Jun30015621%40gyda.ifi.uio.no
If that's not trying to go after and hurt somebody on purpose, what is?
How do you logically justify not following your own advice?
> If _you_ were injured, you would seek a way to cause less injury, not
> cause more of it. Thus, you are not injured, but you are hateful and
> vengeful.
Indeed. I wholly agree with this. Once again, do you really?
Going back to something you apparantly mailed someone in 2000:
>I'm overjoyed that I actually hurt your feelings. I wish I could hurt
>your feelings so much you would commit suicide.
http://groups.google.com/groups?oi=djq&ic=1&selm=an_591283931
How is that not hateful and vengeful? I understand you were 'provoked'
in that incident by a private mail, but isn't that your central thesis:
that "if you were injured, you would seek a way to cause less injury"?
> It is getting pretty obvious that you are _thoroughly_ evil, Thomas
> Bushnell, and that you defend your evil by attacking someone that you
> think is "bad" and therefore not "deserving" of good behavior. What if
> you were wrong? What if _you_ are the bad guy and _you_ get what you
> deserve? People like you never ask that question, because you think all
> you need is good intention.
Please, read this yourself.
> What happend to the other cheeK?
Again, why does that not apply to you? You seem to have (I don't know for
sure) this expectation that you can verbally pound somebody into turning
the other cheek. If this is truly your intent, here's some advice: calling
people morons, fuckfaces, psychotics, evildoers, and idiots, does _not_ do
what you intend. You've spoken some of the fact that people seem to be
out to get you. Speaking as the third party you referred to in your
post, you seem to be out to get _them_. Even worse, you're hiding behind
philosophies (Turn the other cheek) you don't seem to be willing to apply
to yourself.
It's really sad that it comes to this, particularly in this group, as it's
bad publicity for a programming language that really deserves all the
good breaks it can get.
Again, thanks for the positive posts you both make. Like I said, I've
learned a lot. After your off topic statement about the perception of 3rd
parties, I figured I'd go even more off topic and post my 3rd party
perception. I apologize to the newsgroup, in general, for the off topic
post.
-Mike
--
http://www.mschaef.com
* ·······@io.com (MSCHAEF.COM)
| Again, why does that not apply to you?
I do not pretend to be concerned with "good behavior".
| You seem to have (I don't know for sure) this expectation that you can
| verbally pound somebody into turning the other cheek.
Only those who attack me because they want me to behave better. I thus
demonstrate that what they try does not work on them, either.
| Speaking as the third party you referred to in your post, you seem to be
| out to get _them_.
I criticize _and correct_ people's mistakes. Some nutjobs go ballistic
and turn everything into a personal vendetta at this point. If you are
the kind who cannot read criticism of your actions without taking it
personally, you will not see any difference. If you are the kind who
cannot understand things in context, no amount of clarification will ever
change your mind about what you think you see. But go back through this
thread and see when Thomas Bushnell decides to attack me.
Nice of you to speak for all third parties, though.
///
--
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.
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
>* ·······@io.com (MSCHAEF.COM)
>| Speaking as the third party you referred to in your post, you seem to be
>| out to get _them_.
>
> Nice of you to speak for all third parties, though.
I agree my intention was unclear in the text you quoted. Later on in the
message, I say the following. The emphasis (underscores) is new to this
quote, but even in the original post, the wording (my specific usage of
the singular 'my' and plural 'parties') was meant to indicate that I
wasn't intending to speak for anyone other than myself.
>>After your off topic statement about the perception of 3rd
>>parties, I figured I'd go even more off topic and post _my_ 3rd party
>>perception.
> I criticize _and correct_ people's mistakes.
Fair enough. Most of the technical corrections you (and others) make,
particularly in the recent Unicode discussions, are among the more
educational posts in the forum, for me, at least.
Other than that, it's the posts that aggressively criticize the people
behind the posts that got me to make my first post in this thread. I know
that Usenet isn't supposed to be some kind of newbie-friendly love-fest,
but posts calling people morons and psychotic? My personal gut instinct,
if you decide to respond to me in that manner, would be to respond in
kind, "turn the other cheek" be damned. It's pretty easy to see how that
could spiral into something pretty terrible, even if the underlying
intention is to demonstrate the ineffectiveness of that form of
discussion.
Personal issues aside, the image it presents for Lisp is pretty horrible,
when presented in a public forum. As a Lisp newbie, seeing posts damning
people as moronic, psychotic idiots isn't exactly an attraction to the
forum or the language. It obviously isn't stopping me posting, since I
like the language, but it would certainly make me think twice about
suggesting this group as reading material to a tentative manager
(or any individual, for that matter) wanting to know more about the
language.
> But go back through this
> thread and see when Thomas Bushnell decides to attack me.
Was this the initial post you're talking about?
http://groups.google.com/groups?q=g:thl299120000d&hl=en&selm=87pu26cpq3.fsf%40becket.becket.net
You guys were antagonistic to each other before that, in other threads.
I don't really think I'm contributing enough to justify more posts along
these lines either. :-( In the process of rereading some of this thread
and others, I re-read a few messages from Kent Pitman, including this one
from which I quote:
> This is not a forum in which one can coerce the behavior of another.
> It is foolish on all sides to try. Anyone, however well meaning
> (including myself here), who even tries is contributing to the
> problem."
http://groups.google.com/groups?hl=en&selm=sfw3d7btwvd.fsf%40world.std.com
That said, I think I'll just shut up, now. :-)
-Mike
--
http://www.mschaef.com
* ·······@io.com (MSCHAEF.COM)
| Fair enough. Most of the technical corrections you (and others) make,
| particularly in the recent Unicode discussions, are among the more
| educational posts in the forum, for me, at least.
This provides a certain balance to your view, but not sufficiently so.
| Other than that, it's the posts that aggressively criticize the people
| behind the posts that got me to make my first post in this thread.
Please take a closer look at what I respond to and precisely what it is
that I criticize. Some people refuse to do this because they have
already made up their mind due to the "word count syndrome", but this is
a peculiarity of the judgmental character that gets into trouble in the
first place.
| I know that Usenet isn't supposed to be some kind of newbie-friendly
| love-fest, but posts calling people morons and psychotic?
USENET is not text, it is context.
| My personal gut instinct, if you decide to respond to me in that manner,
| would be to respond in kind, "turn the other cheek" be damned.
Then you _really_ need to look at how these things start.
| Personal issues aside, the image it presents for Lisp is pretty horrible,
| when presented in a public forum. As a Lisp newbie, seeing posts damning
| people as moronic, psychotic idiots isn't exactly an attraction to the
| forum or the language.
If you are the kind of person who has no regard for context and are
therefore unable to deal with pain in context, I fail to see how any
public forum or, indeed, reality, could possibly lead to anything but
severe depression and shizophrenic withdrawal. Some people (my empirical
evidence indicates about 5%) go nuts when they are exposed to unexpected
pain (like thinking it is "unfair" or that the universe somehow owes them
less pain) and the rest cope with it just fine or even learn faster from
slightly unwelcome experiences than being cuddled simply because they
switch to learning mode when reality does something unexpected instead of
judgment mode to teach reality a lesson. When the world is just as
expected, generally no cognitive processes are involved. Coping with
cognitive dissonance is perhaps the most basic of an intelligent person's
set of mental skills. Failure to do so means that a person is much more
interested in preserving his current perception of the world than to
maintain a productively useful perception of the world.
| It obviously isn't stopping me posting, since I like the language, but it
| would certainly make me think twice about suggesting this group as
| reading material to a tentative manager (or any individual, for that
| matter) wanting to know more about the language.
I think a person who is unable to read news is dangerous anywhere on
USENET. comp.lang.lisp is not the exception some of you guys want to
make it out to be. All newsgroups have to deal with trolls and idiots.
Overall, we have far fewer of them, and even if trolls and idiots are not
known to be bright, most of them figure out that there is a connection
between what they do and how they are treated. The few morons who just
have to oppose every "authority" they encouter are a problem everywhere,
but when they suffer from delusions of moral superiority and think they
can do worse things than somebody else and still remain innocent victims,
they become truly evil. This, however, is a localized phenomeon, and if
you can figure out how to read threads, you will notice that a long
exchnage between two people is very unlikely to be useful for a newbie,
regardless of who they are talking about or how.
| Was this the initial post you're talking about?
No.
| You guys were antagonistic to each other before that, in other threads.
Thomas does not understand that he gets a new chance to behave well. To
him, like most other idiots in most newsgroups, things are personal and
he has a deep-seated personal need to be vindicated and not come out the
bad guy. This alone makes him a bad guy, because if you cannot be the
bad guy, somebody else has to be, and it leads to such useless things as
only one party regarded as "injured". This is extremely unproductive.
///
--
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.
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
>* ·······@io.com (MSCHAEF.COM)
>| Fair enough. Most of the technical corrections you (and others) make,
>| particularly in the recent Unicode discussions, are among the more
>| educational posts in the forum, for me, at least.
>
> This provides a certain balance to your view, but not sufficiently so.
I've tried to be balanced in the posts I've made. I apologize if you don't
think it's sufficient.
>| I know that Usenet isn't supposed to be some kind of newbie-friendly
>| love-fest, but posts calling people morons and psychotic?
>
> USENET is not text, it is context.
Agreed. Despite my differing opinion, I _have_ tried to understand more of
the context in which it was said. To make that context easily available
from my own posts, I've posted links to Google so that others reading them
might read them to make their own judgement.
As far as my own understanding of context and Usenet, maybe it's my lack
of understanding of your use of language. It's trivially easy to find
posts on google in which you write of ripping people's throats [1, 2]
out, people that need to be committed or are fit to die. Maybe it's
hyperbole, but that's much more severe hyperbole than I'm accustomed to
seeing in a number of years online. Even in cases like this, where
Brouillet so deliberately provoked you.
1] http://groups.google.com/groups?hl=en&selm=B865DDF1.3C32%25verec%40mac.com
2] http://groups.google.com/groups?hl=en&selm=3219915763159706%40naggum.net
>| My personal gut instinct, if you decide to respond to me in that manner,
>| would be to respond in kind, "turn the other cheek" be damned.
>
> Then you _really_ need to look at how these things start.
I did _not_ say that I _would_ respond in that manner. I just said it
would be my gut instinct. I'd like to think I'd catch it before it
escaped. :-)
At any rate, I appreciate your responses to my posts. If I'm going to
avoid becoming any more hypocritical than I already am, I should probably
stop my contributions to this thread.
-Mike
--
http://www.mschaef.com
* ·······@io.com (MSCHAEF.COM)
| I've tried to be balanced in the posts I've made. I apologize if you don't
| think it's sufficient.
I think you blame me for Thomas Bushnell's behavior, and question only my
role, not his. This is not particularly smart.
| Agreed. Despite my differing opinion, I _have_ tried to understand more
| of the context in which it was said. To make that context easily
| available from my own posts, I've posted links to Google so that others
| reading them might read them to make their own judgement.
Google is not news. Despite the usefulness of this tool, a Google search
tells me that somebody generally fails to understand that news is dynamic
-- it is interaction -- things on USENET are generally only _responses_.
| As far as my own understanding of context and Usenet, maybe it's my lack
| of understanding of your use of language. It's trivially easy to find
| posts on google in which you write of ripping people's throats [1, 2]
| out, people that need to be committed or are fit to die.
But what have I responded to? How much abuse should _I_ take? Why do
you blame the victim? Why am I _not_ the victim of the abuse of Thomas
Bushnell? This is your lack of balance, and it colors your entire
approach to your reasoning.
| I did _not_ say that I _would_ respond in that manner. I just said it
| would be my gut instinct. I'd like to think I'd catch it before it
| escaped. :-)
Look, perhaps you are wrong? Perhaps I am the one who _responds_ to
abuse from morons who cannot take criticism professionally? Just go back
and look at things with that _possible_ perspective. Perhaps what we
have here is a general consensus that it is OK to respond with rabidly
insane hostilities towards _me_ if I point out a technical mistake
someone has made, and that somebody has the intelligence and prejudicial
disposition of a racist, and therefore believes he is mistreated because
of said consensus instead of reading the actual article? Perhaps evil
morons like Thomas Bushnell are _only_ after making me a villain so he
can escape judgment of his character, which I have exposed?
Also, let me know what you think about such phenomena as S Campion/ Adam
Tissa/Israel Ray Thomas. What do you think makes these lunatics tick?
| At any rate, I appreciate your responses to my posts. If I'm going to
| avoid becoming any more hypocritical than I already am, I should probably
| stop my contributions to this thread.
I fail to see the hypocrisy.
///
--
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.
Erik Naggum <····@naggum.net> writes:
> Look, perhaps you are wrong? Perhaps I am the one who _responds_ to
> abuse from morons who cannot take criticism professionally? Just go back
> and look at things with that _possible_ perspective.
Well, your first attack on me was to call me an "idiot" and a "snotty
bastard", in Message-ID: <················@naggum.net>.
This was in reply to my saying "And since the popular operating
systems *do* have those memory protection features, it's not
possible for a creep to get in and destroy a system, right?"
Thomas
* Thomas Bushnell, BSG
| This was in reply to my saying "And since the popular operating
| systems *do* have those memory protection features, it's not
| possible for a creep to get in and destroy a system, right?"
This is why I keep telling you guys that news is context, not text.
Anyone who reads that innocuous-looking question by itself does not see
that in context it is a supreme example of your dishonest practices of
passive aggressiveness and asking people fantastically stupid rhetorical
questions. Your halo does not shine, any more.
///
--
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.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
>* ·······@io.com (MSCHAEF.COM)
>| I've tried to be balanced in the posts I've made. I apologize if you don't
>| think it's sufficient.
>
> I think you blame me for Thomas Bushnell's behavior, and question only my
> role, not his. This is not particularly smart.
Well, you're right. Part of the thing that was so eye catching about
your posts was the force of the langage, not to mention the length, or the
fact you were trying to advocate a better standard of conduct. I haven't
seen many people put as much effort into such things. I've seen people
as persistant, but never that... 'energetic'.
> Google is not news. Despite the usefulness of this tool, a Google search
> tells me that somebody generally fails to understand that news is dynamic
> -- it is interaction -- things on USENET are generally only _responses_.
Google does at least allow the entire thread to be read.
> But what have I responded to? How much abuse should _I_ take? Why do
> you blame the victim? Why am I _not_ the victim of the abuse of Thomas
> Bushnell?
Okay, I'll agree with this. It does seem mutual, and there is another
side to it. But to what extent should you or anybody else dish out
abuse to avoid receiving it? What if it is counterproductive to the
extent that it incites other people to respond?
> Look, perhaps you are wrong? Perhaps I am the one who _responds_ to
> abuse from morons who cannot take criticism professionally?
Again, it's the force with which you respond that got me thinking about
this at all. I wholeheartedly agree with the need for professionalism,
but some of the things you've written here (and others, too) would get
people fired or arrested if spoken aloud in any of the professional
environments I've been in. Am I just totally misunderstanding your
definition of professionalism? Or are you saying it doesn't matter,
in the context of the thread?
> Just go back and look at things with that _possible_ perspective.
That's partly why I'm reconsidering my point of view. There have been a
number of occasions that I've been reading posts of yours that seem
pretty damned extreme on the surface. Generally, you've been provoked
pretty harshly. I don't know how I'd react if someone posted a thread on
silencing me down. It's actually pretty amazing you have the patience to
stick around here at all.
> Also, let me know what you think about such phenomena as S Campion/ Adam
> Tissa/Israel Ray Thomas. What do you think makes these lunatics tick?
I have no idea, I wish I did.
-Mike
--
http://www.mschaef.com
* ·······@io.com (MSCHAEF.COM)
| I wholeheartedly agree with the need for professionalism, but some of the
| things you've written here (and others, too) would get people fired or
| arrested if spoken aloud in any of the professional environments I've
| been in.
In isolation, sure. But in context? No danger at all.
| Am I just totally misunderstanding your definition of professionalism?
Probably not.
| Or are you saying it doesn't matter, in the context of the thread?
Basically, yes, but not the whole thread: in the context of the specific
interaction at that point.
| That's partly why I'm reconsidering my point of view. There have been a
| number of occasions that I've been reading posts of yours that seem
| pretty damned extreme on the surface.
Reasonable people already have or manage to grow a clue long before it
gets to that intensity, and figure out that it says: "Do not reply".
| Generally, you've been provoked pretty harshly.
It seems to take a considerably amount of both effort and objectivity to
see that, and I appreciate that you do. I have hoped to communicate that
it is a really bad idea to attack me. Some people just do not get it.
| I don't know how I'd react if someone posted a thread on silencing me
| down. It's actually pretty amazing you have the patience to stick around
| here at all.
Well, my patience is probably one of my least explored potentials.
///
--
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.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
Erik Naggum <····@naggum.net> wrote:
> I do not pretend to be concerned with "good behavior".
But you do.
You abuse others and when they finally decide to give you a small
taste of your own medicine, you complain and whinge and moan about
their behaviour.
·········@becket.net (Thomas Bushnell, BSG) wrote:
>Erik Naggum <····@naggum.net> writes:
>
>> * Thomas Bushnell, BSG
>> | What counts as abusive?
>>
>> Repetitive hostile "questions" like yours which continue to have
>> absolutely _nothing_ to do with this forum, but only with your need to
>> harrass me, along with the other whining morons here. Quit it, OK?
>
>Yeah, you are the injured party. Poor Erik, getting all this
>harassment. It's so unfair, since you are the very soul of propriety,
>kindness, and decorum.
Erik was never properly potty trained.
That is why he eliminates faecal material orally.
* Adam Tissa <·······················@yahoo.com>
| Erik was never properly potty trained.
|
| That is why he eliminates faecal material orally.
Please quit projecting yourself onto me.
///
--
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.
Erik Naggum <····@naggum.net> writes:
[drivel]
I assumed you were able to use basic information tools to locate the
information you need. I'll give you a head start. You want the
Department of Philosophy at UC Irvine.
I accuse you of being a coward with your accusations, rather like a
garden variety neighborhood bully.
So I expect you to put into your letter that you think I am an idiotic
moron, intellectually dishonest, etc. Oh, and CC me the letter, of
course. If you have the courage of your convictions, you'll be
willing to see them stood up to more public scrutiny, right?
Thomas
* Thomas Bushnell, BSG
| I assumed you were able to use basic information tools to locate the
| information you need. I'll give you a head start. You want the
| Department of Philosophy at UC Irvine.
I want you to provide the name and address of the people you want to
implicate. If you are too much of a coward to name them, you are only
doing more of your immensely stupid and abusive tactics.
| I accuse you of being a coward with your accusations, rather like a
| garden variety neighborhood bully.
So is this worse or better than accusing Kent Pitman of hypocrisy?
Why do you not _learn_?
Why are you so retarded that you challenge the neighborhood bully all the
time when you are the only party that suffers?
| So I expect you to put into your letter that you think I am an idiotic
| moron, intellectually dishonest, etc.
What I will do is inform your superiors of your need to use them as a
shield and guarantors of your ability to think. I just need their names
and addresses, because you have started this challenge. Asking me to
figure out which people _you_ want to implicate is simply idiotic.
| Oh, and CC me the letter, of course. If you have the courage of your
| convictions, you'll be willing to see them stood up to more public
| scrutiny, right?
I have the courage of my convictions, idiot, but your "department" or
advisor or whatever do not have any bearing on your behavior here until
_you_ implicate them, and you have.
The more you keep this idiotic charade up and the more you implicate
them, the more your department needs to hear about you. Otherwise, there
is no need to implicate them at all.
You remain a brainless idiot, Thomas Bushnell. Have you _no_ friends who
can tell you how stupid you are behaving? Or worse, do you have some
"friends" who enjoy that you make a spectacle of yourself?
///
--
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.
Erik Naggum <····@naggum.net> writes:
> * Thomas Bushnell, BSG
> | I assumed you were able to use basic information tools to locate the
> | information you need. I'll give you a head start. You want the
> | Department of Philosophy at UC Irvine.
>
> I want you to provide the name and address of the people you want to
> implicate. If you are too much of a coward to name them, you are only
> doing more of your immensely stupid and abusive tactics.
Implicate them? No, I want to implicate *you* in libel, that's all.
> Why are you so retarded that you challenge the neighborhood bully all the
> time when you are the only party that suffers?
I'm not suffering--like I told you before, I'm enjoying it. Which is
the thing that *really* got you pissed.
> What I will do is inform your superiors of your need to use them as a
> shield and guarantors of your ability to think. I just need their names
> and addresses, because you have started this challenge. Asking me to
> figure out which people _you_ want to implicate is simply idiotic.
Huh? Of course I didn't say that...I said that if you want to blather
about my inability to think and my defective moral character, you
should do it in print, where you can be held fiscally liable for your
slanders.
> You remain a brainless idiot, Thomas Bushnell. Have you _no_ friends who
> can tell you how stupid you are behaving? Or worse, do you have some
> "friends" who enjoy that you make a spectacle of yourself?
Actually, one person sent me email and said you didn't really mean
what you say when you call people idiots, morons and the like. He
also said you were always right--*always*--on this newsgroup.
Other than that one fan of yours, several people have sent me email
saying they appreciated what I said.
Not that this proves anything, but I do wonder (and lament for) the
pleasant Erik Naggum that used to be around. Maybe he'll come back,
though a look through groups.google.com for your name shows that he
has been gone for a long time.
Thomas
* Thomas Bushnell, BSG
| Implicate them? No, I want to implicate *you* in libel, that's all.
Well, that seems to imply that it is _not_ libel to call you an evil and
non-thinking idiot here because I have grounds for that, including your
own effort to prove that you are clinically insane. "Libel" is not
dependent on medium, however, you illteraite moron. so if you had a case,
you would already have made it. You do not have a case, and you know it,
so you are grasping for straws, but you are just too goddamn stupid to
figure out that _you_ have figured out.
I appreciate your admission of guilt by publishing the need to trasnport
this to an "innocent" forum in order to become the "victim" you are not,
but think you are. Instead you prove that I am in my _right_ to label
you a moron. You are just so ridiculously _childish_.
| I'm not suffering--like I told you before, I'm enjoying it.
So you _enjoy_ taunting and hurting people? Just how quickly do you want
to go to Hell? Do you not hear the Pearly Gates clam shut when you post?
People who _enjoy_ hurting others on purpose are sociopaths. I merely
enjoy that you progress ever faster towards self-destruction -- and I do
not have do anything at all. _You_ are doing all the attacking, now.
That is something I take some pride in, actually. You are self-propelled
in your evil, just like every other evil bastard who has visited us.
Such destructiveness is seriously pathological.
| Which is the thing that *really* got you pissed.
You wish. No, I kind of regard your hypocrisy with curiosity. I wonder
what Thomas Busnhell imploding in his own evil will sound like. I would
_really_ like to be there when you have a flash of insight into your own
personality.
| Huh? Of course I didn't say that...I said that if you want to blather
| about my inability to think and my defective moral character, you should
| do it in print, where you can be held fiscally liable for your slanders.
I marvel at the magnitude your insanity. You obviously do not regard
this forum as sufficiently important to take seriously, which is _why_
you keep attacking me, too. Your lack of ability to accept responsiblity
for your own actions has produced all this evil. When you eventually
grasp that you _were_ responsible for all you have done, it should be
quite a spectacle.
However, if you would please take this forum seriously and stop using it
to vent your hatred for people who have figured you out, that would
really be highly appreciated. Not that you can do this, of course. You
have gone too far on the evil path to turn back without a _momentous_
backlash at your own personality. This is what I appreciate about seeing
morons self-destruct.
| Actually, one person sent me email and said you didn't really mean what
| you say when you call people idiots, morons and the like.
I speak about their behavior. Some people figure out that they are able
to change their behavior and thus change the outcome of the criticism.
You are not smart enough to figure out. Or just too evil to figure out
that criticism is directed at specific actions, so _you_ believe it is
personal and react in what _you_ think is "in kind", but you really are
responsible for your own evil. There is nobody to blame, and some day
you will understand this. Please note: I do not forgive people like you,
I do not accept apologies from your kind. You _are_ bad to the core,
Thomas Bushnell, and you keep proving it,
| He also said you were always right--*always*--on this newsgroup.
That you something is merely a counter-indication.
| Other than that one fan of yours, several people have sent me email
| saying they appreciated what I said.
Of course they do! People like you always work in gangs. But if you
think you can be forgiven for what you have done, please think again.
| Not that this proves anything, but I do wonder (and lament for) the
| pleasant Erik Naggum that used to be around.
WHy do you then keep your hostilities going? Just behave well, and I
have no need to respond to _your_ attacks. But this just tells me that
you are out of control -- your evil has taken control over you. _You_
would be seriously hurt if you were nice to me, which is why you have to
keep this going. All those _cheering_ friends of yours would turn on you
if you did not continue attacking me. In fact, the more you continue,
the harder it is for you to stop. It is the opposite with me. I have no
reason to attack you _apart from_ your actions. No actions, no response.
You, onthe other hand, are on a mission from God to hurt me. That is the
crucial difference between us. My signature _should_ have told you
something. Yet it does not. You must be _phenomenally_ stupid.
| Maybe he'll come back, though a look through groups.google.com for your
| name shows that he has been gone for a long time.
You google to find out about me? How long do you think it will take any
other person to find _your_ articles? Who _cares_ what you can come up
with in the "he made me do it" category of excuses when they read what
you have written? I actually look forward to the day when you get hurt
by what you have done, and figure that you wearing a fucking _halo_ does
not make you less evil.
But don't you have some repenting to do? Someone told me that you were a
monk or apprentice or something in some Christian religious order, and
that this "BCG" thing is a mark of your moral elevation in your order or
whatever. Perhaps those who think you are a good person need to have
_their_ views revised before the advisors at the kindergarten graduate
program? Do the people you "help" in that food bank know that you
_enjoy_ hurting people? Do you hide your hoof and the pointy tail?
///
--
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.
In article <··············@becket.becket.net>, Thomas Bushnell, BSG wrote:
> Erik Naggum <····@naggum.net> writes:
>
>> Why are you so retarded that you challenge the neighborhood bully all the
>> time when you are the only party that suffers?
>
> I'm not suffering--like I told you before, I'm enjoying it. Which is
> the thing that *really* got you pissed.
No; it only proves that you are nothing but an ordinary troll.
>> What I will do is inform your superiors of your need to use them as a
>> shield and guarantors of your ability to think. I just need their names
>> and addresses, because you have started this challenge. Asking me to
>> figure out which people _you_ want to implicate is simply idiotic.
>
> Huh? Of course I didn't say that...I said that if you want to blather
> about my inability to think and my defective moral character, you
> should do it in print, where you can be held fiscally liable for your
> slanders.
Don't know about the US, but in Germany you certainly won't win a
trial against someone who called you an idiot or anything else on
Usenet. I would be very surprised if that were different in the
US.
>> You remain a brainless idiot, Thomas Bushnell. Have you _no_ friends who
>> can tell you how stupid you are behaving? Or worse, do you have some
>> "friends" who enjoy that you make a spectacle of yourself?
>
> Actually, one person sent me email and said you didn't really mean
> what you say when you call people idiots, morons and the like. He
> also said you were always right--*always*--on this newsgroup.
If you are referring to me as that ``one person'', then thanks for
reminding me that I should keep copies of mails I send to the
likes of you. All I am wondering about is if you really didn't
understand what I wrote or just chose to misunderstand it on purpose.
I also note that you forgot to mention that it was you who contacted
me by Email, not the other way around. From what I've heard, you
generally like writing harrassing Emails to everybody you disagree
with, too.
Ironically, all this is more confirmation for what I was telling you:
If I, myself, had been smart enough to listen to people with more
experience than myself, I would have known that trying to explain
something to you and expecting you to learn anything from it is a
total waste of time. I will remember that in the future.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Nils Goesche <······@cartan.de> writes:
> Don't know about the US, but in Germany you certainly won't win a
> trial against someone who called you an idiot or anything else on
> Usenet. I would be very surprised if that were different in the
> US.
Erik just said the opposite. He said that Usenet is covered by the
libel statutes. Well, I think Erik is wrong here, at least, I know
some things that *are* covered under libelous defamation, and so does
Erik, so he blusters and avoids actually doing anything that might
actually force him to defend his lies and defamations.
* Thomas Bushnell, BSG
| Erik just said the opposite. He said that Usenet is covered by the libel
| statutes. Well, I think Erik is wrong here, at least, I know some things
| that *are* covered under libelous defamation, and so does Erik, so he
| blusters and avoids actually doing anything that might actually force him
| to defend his lies and defamations.
Where are the names of the people you want to implicate? You keep making
these idle and empty threats, yet refuse to do anything yourself that
would show us _your_ courage of conviction. What was that concern of
yours about "hypocrisy", again? Please provide the names of the people
you want to implicate in this and who would constitute the proper target
audience for what _you_ believe would be libelous defamation. Quit
playing your stupid chickenshit games, Thomas Bushnell, _especially_ if
you make such a ruckus about how other people refuse to play with 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.
Nils Goesche <······@cartan.de> writes:
> Don't know about the US, but in Germany you certainly won't win a
> trial against someone who called you an idiot or anything else on
> Usenet. I would be very surprised if that were different in the
> US.
Right. It's not Usenet per se, it's calling someone an idiot. Unless
I'm passing myself off as a psychologist, and I'm claiming to have
diagnosed someone as severely mentally retarded, you don't have a
case; even then, it would be hard to win. All of this happening on
Usenet, as opposed to in a journal, just makes it even harder to show
that the "libelous" party thought that people would believe his
opinions as fact, not opinion. Glad I'm not in Britain / love me some
1st Amendment.
[ Mmmm, I'm drinking Freedom of Speech coffee right now. Seriously.
What, you think I'm kidding? Look at my e-mail address! ]
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Erik Naggum <····@naggum.net> wrote:
>* ozan s yigit <··@blue.cs.yorku.ca>
>| i simply ask:
>
> Need I remind you of all the abusive behavior you have accompanied your
> "request" with, and which is the sole reason that I refuse to grant you
> any shred of respect for your question? You are destructive person, ozan
> s yigit, and you are so self-righteous that you do not see your hatred,
> which is even self-fueling.
Forgot your medicine today ?
ozan s yigit <··@blue.cs.yorku.ca> wrote:
>erik naggum: apologize for your dishonest and hostile statements on
>this newsgroup and retract. grow some intellectual backbone and admit
>when you have no clue about something.
>
>oz
You'll be waiting till the cows come home.
Erik never apologises.
Especially when he is wrong.
Erik, cease and desist with your abusive, dishonest behaviour.
you single-handedly turned this group into a cesspool. it deserved
better.
? ... 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.
it is clear you have no idea what you are talking about. this has been
a waste of my time; i have readily more references at hand than you are
likely to be able to provide in a year, so don't bother. feel free to
have the last word.
oz
---
ozan s yigit <··@blue.cs.yorku.ca> writes:
> Erik Naggum: [crap beyond contempt elided]
>
>
> > ... 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.
>
> where is that evidence? give a reference to significant research.
Hrm, if you teach philosophy to first year undergraduates for a little
while, it quickly becomes obvious that "higher-order" thought,
abstractions on abstractions, do not come easily to many people.
I don't know whether that means that they don't come naturally to
anyone (I can't remember ever having trouble with them, but maybe I've
just forgotten), but at least to lots, they don.t
Thomas
·········@becket.net (Thomas Bushnell, BSG) writes:
> Hrm, if you teach philosophy to first year undergraduates for a little
> while, it quickly becomes obvious that "higher-order" thought,
> abstractions on abstractions, do not come easily to many people.
it seems that way, certainly with phil undergrads :) but i believe that
is more conditioning and suppression and /not/ what is natural. i thought
of punting this to minsky, but i suspect he'll have a good chuckle and
probably respond with one word: "humour." in any case, no material i'm
familiar with in the area of cognition and philosophy of mind discusses
the curious view that "higher-order thinking" [we can argue about what
that means] is not natural.
[so anyone who has references to relevant research should chime in]
oz
--
rigor is mortifying to most. - oz
* 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
···@jpl.nasa.gov (Erann Gat) writes:
> In article <················@naggum.net>, Erik Naggum <····@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). 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...)
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <················@naggum.net>, Erik Naggum
<····@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.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@eglaptop.jpl.nasa.gov...
> > > In article <················@naggum.net>, Erik Naggum
> <····@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.
From: Thomas Bushnell, BSG
Subject: Re: First-class symbols (Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87lmcrmzp3.fsf@becket.becket.net>
"Joe Marshall" <·············@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> "Joe Marshall" <·············@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 -=- ············@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.
"Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
···················@photino.sid.rice.edu...
> ·········@becket.net (Thomas Bushnell, BSG) writes:
>
> > "Joe Marshall" <·············@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
"Joe Marshall" <·············@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 -=- ············@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.
"Rahul Jain" <·····@sid-1129.sid.rice.edu> wrote in message
···················@photino.sid.rice.edu...
> "Joe Marshall" <·············@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!)
From: Erik Naggum
Subject: Re: First-class symbols (Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225347578362126@naggum.net>
* 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.
Erik Naggum <····@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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Naggum
Subject: Re: First-class symbols (Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225221516192724@naggum.net>
* 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.
In article <················@naggum.net>, Erik Naggum <····@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.
···@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 -=- ············@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.
From: Erik Naggum
Subject: Re: First-class symbols (Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225266991598821@naggum.net>
* 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.
In article <················@naggum.net>, Erik Naggum <····@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.
From: Erik Naggum
Subject: Re: First-class symbols (Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225301548722039@naggum.net>
* 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.
From: Nils Goesche
Subject: Re: First-class symbols (Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87pu241b3r.fsf@darkstar.cartan>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <················@naggum.net>, Erik Naggum <····@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
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.
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.
In an attempt to throw the authorities off his trail, Bijan Parsia <·······@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?
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
<·······@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.
Bijan Parsia <·······@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/
On 17 Mar 2002, Julian Stecklina wrote:
> Bijan Parsia <·······@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.
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.
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.
oh...quit changing the subject...it makes it harder to filter out
this thread. ;-)
Dr.X
Bijan Parsia <·······@email.unc.edu> wrote in message
···············································@login5.isis.unc.e
du...
> 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.
>
>
You know you're reading comp.lang.lisp when
the religious debates are calmer than the other posts.
Anyone for politics?
"Bijan Parsia" <·······@email.unc.edu> wrote in message
···············································@login1.isis.unc.edu...
> On 17 Mar 2002, Julian Stecklina wrote:
>
> > Bijan Parsia <·······@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.
>
On Tue, 19 Mar 2002 00:31:07 GMT, "Joe Marshall"
<·············@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.
Andrzej Lewandowski <·············@attglobal.net> wrote in message news:<··································@4ax.com>...
> By the way, even Vatican is not using Latin anymore...
Actually, they do. For example the Latin edition
of the new Catechism (Editio Typica, Imprimi Potest
Cardinal Joseph Ratzinger) was introduced in 1997.
"Joe Marshall" <·············@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.
Bruce Lewis <·······@yahoo.com> writes:
> "Joe Marshall" <·············@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.
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/
The world rejoiced as Julian Stecklina <··········@web.de> wrote:
> Bruce Lewis <·······@yahoo.com> writes:
>
>> "Joe Marshall" <·············@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 ··········@" "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
In article <··············@chvatal.cbbrowne.com>,
Christopher Browne <········@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
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?
From: Erik Naggum
Subject: Re: You know you're reading comp.lang.lisp when...
Date:
Message-ID: <3225581663883498@naggum.net>
* Michael Parker <·······@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.
Erik Naggum <····@naggum.net> writes:
> * Michael Parker <·······@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.
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
········@delamancha.org
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.
Bijan Parsia <·······@email.unc.edu> writes:
> 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....
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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On Tue, 19 Mar 2002, Michael Parker wrote:
> 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?
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
From: Thomas Bushnell, BSG
Subject: Re: You know you're reading comp.lang.lisp when...
Date:
Message-ID: <87sn6w9d5n.fsf@becket.becket.net>
Daniel Pittman <······@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
In article
<··················································@lp.airnews.net>,
Michael Parker <·······@pdq.net> wrote:
> 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?
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
From: Nils Goesche
Subject: Re: You know you're reading comp.lang.lisp when...
Date:
Message-ID: <877ko8817b.fsf@darkstar.cartan>
Bruce Hoult <·····@hoult.org> writes:
> In article
> <··················································@lp.airnews.net>,
> Michael Parker <·······@pdq.net> wrote:
>
> > 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?
>
> 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...).
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
From: Erik Naggum
Subject: Re: You know you're reading comp.lang.lisp when...
Date:
Message-ID: <3225582817150095@naggum.net>
* Nils Goesche <···@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.
Bruce Hoult <·····@hoult.org> 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...).
By Australian standards too.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> ···@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
······@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.
Centuries ago, Nostradamus foresaw when Kent M Pitman <······@world.std.com> would write:
> ······@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.
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
······@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 -=- ············@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.
Rahul Jain <·····@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.
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@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.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@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.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> ·········@becket.net (Thomas Bushnell, BSG) writes:
>
> > Rahul Jain <·····@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
·········@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 -=- ············@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.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> ·········@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> > ·········@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 -=- ············@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.
Rahul Jain <·····@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.
* 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
Tim Bradshaw <···@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
"Tim Bradshaw" <···@cley.com> wrote in message
····················@cley.com...
> * 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.
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.
"Joe Marshall" <·············@attbi.com> writes:
> "Tim Bradshaw" <···@cley.com> wrote in message
> ····················@cley.com...
> > * 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.
>
> 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.
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.)
Matthias Blume <·····@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 -=- ············@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.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> Matthias Blume <·····@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
* 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.
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
······@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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
······@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 <····@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
Christopher Browne <········@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".
Kent M Pitman <······@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
·········@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 -=- ············@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.
Rahul Jain <·····@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@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 -=- ············@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.
Rahul Jain <·····@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@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 -=- ············@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.
Rahul Jain <·····@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@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 -=- ············@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.
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>"))
Paul Foley <·······@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
* 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.
* Paul Foley <·······@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.
Paul Foley <·······@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.
Kent M Pitman <······@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...
Kent M Pitman <······@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!
In article <··············@photino.sid.rice.edu>,
Rahul Jain <·····@sid-1129.sid.rice.edu> wrote:
> ·········@becket.net (Thomas Bushnell, BSG) writes:
>
> > Rahul Jain <·····@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
Bruce Hoult <·····@hoult.org> writes:
> In article <··············@photino.sid.rice.edu>,
> Rahul Jain <·····@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 -=- ············@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.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> Bruce Hoult <·····@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!
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
* 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.
Erik Naggum <····@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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Erik Naggum <····@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.
On 16 Mar 2002 23:30:51 -0800, Thomas Bushnell, BSG wrote:
> Rahul Jain <·····@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>"))
Paul Foley <·······@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.
* 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
Tim Bradshaw <···@cley.com> writes:
> * 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.
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...
······@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...
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
* 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.
Erik Naggum <····@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.
In article <··············@becket.becket.net>, Thomas Bushnell, BSG wrote:
> Erik Naggum <····@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.
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
Nils Goesche <······@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.
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
* 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.
·········@becket.net (Thomas Bushnell, BSG) writes:
> Nils Goesche <······@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..]
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@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...
Matthias Blume <·····@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.
Kent M Pitman <······@world.std.com> writes:
> Matthias Blume <·····@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.
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.)
···@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.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@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.
"Doug Quale" <······@charter.net> wrote in message
···················@charter.net...
> Kent M Pitman <······@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")
Kent M Pitman <······@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.
--
<·······@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@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
* 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.
In article <················@naggum.net>, Erik Naggum <····@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
Rahul Jain <·····@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.
--
<·······@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
Bruce Lewis <·······@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 -=- ············@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.
Rahul Jain <·····@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.
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <················@paloalto-snr2.gtei.net>,
> Barry Margolin <······@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?
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 <·····@red-bean.com>
http://www.red-bean.com/~craig
Ask me about Common Lisp Enterprise Eggplants at Red Bean!
In article <··············@piracy.red-bean.com>,
Craig Brozefsky <·····@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, ······@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.
In article <············@news.gte.com>, Dorai Sitaram <····@gte.com> wrote:
>In article <················@paloalto-snr2.gtei.net>,
>Barry Margolin <······@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?
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, ······@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.
On Tue, 12 Mar 2002 21:16:13 GMT, Barry Margolin <······@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
···@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.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@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.
* 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.
In article <················@naggum.net>, Erik Naggum <····@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.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@eglaptop.jpl.nasa.gov...
> In article <················@naggum.net>, Erik Naggum <····@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
In article <·······················@news20.bellglobal.com>,
"Geoffrey Summerhayes" <·············@hotmail.com> wrote:
> "Erann Gat" <···@jpl.nasa.gov> wrote in message
> ·························@eglaptop.jpl.nasa.gov...
> > In article <················@naggum.net>, Erik Naggum <····@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
* 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.
In article <················@naggum.net>, Erik Naggum <····@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.
···@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.
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.
In article
<··········································@login9.isis.unc.edu>, Bijan
Parsia <·······@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.
Centuries ago, Nostradamus foresaw when ···@jpl.nasa.gov (Erann Gat) would write:
> In article
> <··········································@login9.isis.unc.edu>, Bijan
> Parsia <·······@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.
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/>
In article <····················@eglaptop.jpl.nasa.gov>,
···@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
Erik Naggum <····@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 ····················@" "454aa"))
http://www3.sympatico.ca/cbbrowne/sgml.html
>
>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
···@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 <···@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
"Lieven Marchand" <···@wyrd.be> wrote in message
···················@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.
The world rejoiced as Lieven Marchand <···@wyrd.be> wrote:
> ···@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 ····················@" "454aa"))
http://www3.sympatico.ca/cbbrowne/lisp.html
On 13 Mar 2002 15:30:36 -0500, Christopher Browne <········@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/]
···@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.
* 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.
Erik Naggum <····@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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
* 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.
From: Christopher C. Stacy
Subject: Re: Why is Scheme not a Lisp?
Date:
Message-ID: <uhenlyqtt.fsf@theworld.com>
>>>>> 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.
In article <····················@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.
In article <·············@rabbit.ddts.net>,
Larry Clapp <·····@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
Bruce Hoult <·····@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
* 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.
In article <··············@becket.becket.net>,
·········@becket.net (Thomas Bushnell, BSG) wrote:
> Bruce Hoult <·····@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
From: Christopher C. Stacy
Subject: Re: Why is Scheme not a Lisp?
Date:
Message-ID: <un0xdyrf8.fsf@theworld.com>
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.
······@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 -=- ············@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.
Rahul Jain <·····@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
On 12 Mar 2002 23:30:23 -0600, Rahul Jain
<·····@sid-1129.sid.rice.edu> wrote:
>······@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.
On Tue, 12 Mar 2002 12:00:23 -0800, ···@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.
)
······@interaccess.com (Thaddeus L Olczyk) writes:
> On Tue, 12 Mar 2002 12:00:23 -0800, ···@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.
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.
From: Erann Gat
Subject: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <gat-1303021036490001@eglaptop.jpl.nasa.gov>
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.
From: Erik Naggum
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225042418121611@naggum.net>
* 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.
From: Erann Gat
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <gat-1303021435250001@eglaptop.jpl.nasa.gov>
In article <················@naggum.net>, Erik Naggum <····@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.
From: Paul Wallich
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <pw-1303021824470001@192.168.1.100>
In article <····················@eglaptop.jpl.nasa.gov>, ···@jpl.nasa.gov
(Erann Gat) wrote:
>In article <················@naggum.net>, Erik Naggum <····@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.
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
From: Erik Naggum
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225051863129355@naggum.net>
* 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.
From: Erann Gat
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <gat-1403020946060001@192.168.1.50>
In article <················@naggum.net>, Erik Naggum <····@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.
From: Erik Naggum
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225138049947945@naggum.net>
* 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.
From: Kent M Pitman
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <sfw3cz24s8l.fsf@shell01.TheWorld.com>
Erik Naggum <····@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.
From: Erann Gat
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <gat-1403021628240001@eglaptop.jpl.nasa.gov>
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@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.
From: Christopher Browne
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <m33cz265ko.fsf@salesman.cbbrowne.com>
Kent M Pitman <······@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/>
From: Peter Lewerin
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3C95AF5F.6090308@swipnet.se>
>>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.
From: Erik Naggum
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225146489372030@naggum.net>
* 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.
From: Kent M Pitman
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <sfwzo1c2cuz.fsf@shell01.TheWorld.com>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <················@naggum.net>, Erik Naggum <····@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.
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.
From: Doug Quale
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87k7sfc38l.fsf@charter.net>
Kent M Pitman <······@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
From: Rahul Jain
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87zo1bzkvy.fsf@photino.sid.rice.edu>
Doug Quale <······@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 -=- ············@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.
From: Duane Rettig
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <4r8mnn9lt.fsf@beta.franz.com>
Doug Quale <······@charter.net> writes:
> Kent M Pitman <······@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.
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 ·····@Franz.COM (internet)
From: Doug Quale
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87g033byfy.fsf@charter.net>
Duane Rettig <·····@franz.com> writes:
> Doug Quale <······@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?
From: Duane Rettig
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <4n0xbn4qn.fsf@beta.franz.com>
Doug Quale <······@charter.net> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > Doug Quale <······@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?
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 ·····@Franz.COM (internet)
On Thu, 14 Mar 2002, Duane Rettig wrote:
> Doug Quale <······@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.
From: Doug Quale
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87bsdrbwnu.fsf@charter.net>
Bijan Parsia <·······@email.unc.edu> writes:
> > Doug Quale <······@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
From: Pierre R. Mai
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <878z8vjnie.fsf@orion.bln.pmsf.de>
Doug Quale <······@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 <····@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
On 14 Mar 2002, Pierre R. Mai wrote:
> Doug Quale <······@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.
From: Christopher C. Stacy
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <u1yen4wna.fsf@theworld.com>
>>>>> On 13 Mar 2002 20:06:18 -0600, Doug Quale ("Doug") writes:
Doug> Kent M Pitman <······@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.
From: Martti Halminen
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3C913E3A.A368F0ED@kolumbus.fi>
"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.
--
From: Erik Naggum
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225147207934879@naggum.net>
* 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.
From: Kent M Pitman
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <sfwwuwflbvl.fsf@shell01.TheWorld.com>
Doug Quale <······@charter.net> writes:
> Kent M Pitman <······@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.
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...
From: Pierre R. Mai
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <874rjjjn1x.fsf@orion.bln.pmsf.de>
Kent M Pitman <······@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 <····@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
From: Joe Marshall
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3jWj8.22218$44.5104854@typhoon.ne.ipsvc.net>
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@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.
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.)
>
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.
From: Rahul Jain
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87vgbyz9jo.fsf@photino.sid.rice.edu>
Bijan Parsia <·······@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 -=- ············@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.
In article <··············@photino.sid.rice.edu>,
Rahul Jain <·····@sid-1129.sid.rice.edu> wrote:
> Bijan Parsia <·······@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
From: Rahul Jain
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87u1rixmm7.fsf@photino.sid.rice.edu>
Bruce Hoult <·····@hoult.org> writes:
> In article <··············@photino.sid.rice.edu>,
> Rahul Jain <·····@sid-1129.sid.rice.edu> wrote:
> > Bijan Parsia <·······@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 -=- ············@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.
In article <··············@photino.sid.rice.edu>,
Rahul Jain <·····@sid-1129.sid.rice.edu> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > In article <··············@photino.sid.rice.edu>,
> > Rahul Jain <·····@sid-1129.sid.rice.edu> wrote:
> > > Bijan Parsia <·······@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
From: Rahul Jain
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <877koexin3.fsf@photino.sid.rice.edu>
Bruce Hoult <·····@hoult.org> writes:
> In article <··············@photino.sid.rice.edu>,
> Rahul Jain <·····@sid-1129.sid.rice.edu> wrote:
> > Bruce Hoult <·····@hoult.org> writes:
> > > In article <··············@photino.sid.rice.edu>,
> > > Rahul Jain <·····@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 -=- ············@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.
In article <··············@photino.sid.rice.edu>,
Rahul Jain <·····@sid-1129.sid.rice.edu> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > In article <··············@photino.sid.rice.edu>,
> > Rahul Jain <·····@sid-1129.sid.rice.edu> wrote:
> > > Bruce Hoult <·····@hoult.org> writes:
> > > > In article <··············@photino.sid.rice.edu>,
> > > > Rahul Jain <·····@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
From: Rahul Jain
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <871yelwojj.fsf@photino.sid.rice.edu>
Bruce Hoult <·····@hoult.org> writes:
> In article <··············@photino.sid.rice.edu>,
> Rahul Jain <·····@sid-1129.sid.rice.edu> wrote:
> > Bruce Hoult <·····@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 -=- ············@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.
From: Dorai Sitaram
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <a6qgie$iau$1@news.gte.com>
In article <····························@posting.google.com>,
Paul Graham <····@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.
From: Ian Wild
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3C90CDAD.E359290D@cfmu.eurocontrol.be>
Dorai Sitaram wrote:
>
> In article <····························@posting.google.com>,
> Paul Graham <····@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.
From: Dorai Sitaram
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <a6qk45$ic0$1@news.gte.com>
In article <·················@cfmu.eurocontrol.be>,
Ian Wild <········@eurocontrol.int> wrote:
>Dorai Sitaram wrote:
>>
>> In article <····························@posting.google.com>,
>> Paul Graham <····@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?
--d
From: Christopher Browne
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <m38z8u3p75.fsf@salesman.cbbrowne.com>
In the last exciting episode, ····@goldshoe.gte.com (Dorai Sitaram) wrote::
> In article <·················@cfmu.eurocontrol.be>,
> Ian Wild <········@eurocontrol.int> wrote:
> >Dorai Sitaram wrote:
> >>
> >> In article <····························@posting.google.com>,
> >> Paul Graham <····@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/>
From: Erik Naggum
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <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.
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.
From: Pierpaolo BERNARDI
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3Dzk8.68282$_u5.1956244@news1.tin.it>
"Erik Naggum" <····@naggum.net> ha scritto nel messaggio
·····················@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.
From: Erik Naggum
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225268547127061@naggum.net>
* "Pierpaolo BERNARDI" <··················@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.
From: Pierpaolo BERNARDI
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <TyVk8.74522$Ns4.3008055@news2.tin.it>
"Erik Naggum" <····@naggum.net> ha scritto nel messaggio
·····················@naggum.net...
> * "Pierpaolo BERNARDI" <··················@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.
From: Ian Wild
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3C91BE29.8872F36C@cfmu.eurocontrol.be>
Dorai Sitaram wrote:
>
> In article <·················@cfmu.eurocontrol.be>,
> Ian Wild <········@eurocontrol.int> wrote:
> >Dorai Sitaram wrote:
> >>
> >> In article <····························@posting.google.com>,
> >> Paul Graham <····@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.)
From: Dorai Sitaram
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <a6stfq$jp1$1@news.gte.com>
In article <·················@cfmu.eurocontrol.be>,
Ian Wild <········@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
From: Lieven Marchand
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <m3elil4vgw.fsf@localhost.localdomain>
····@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 <···@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
From: Christopher C. Stacy
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <uy9gtlenz.fsf@theworld.com>
>>>>> On 15 Mar 2002 13:38:02 GMT, Dorai Sitaram ("Dorai") writes:
Dorai> In article <·················@cfmu.eurocontrol.be>,
Dorai> Ian Wild <········@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.
From: Dorai Sitaram
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <a6trm8$kb6$1@news.gte.com>
In article <·············@theworld.com>,
Christopher C. Stacy <······@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
From: Pierre R. Mai
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87k7sfkt0b.fsf@orion.bln.pmsf.de>
····@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 <····@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
From: Kent M Pitman
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <sfwy9gvc9zw.fsf@shell01.TheWorld.com>
"Pierre R. Mai" <····@acm.org> writes:
> ····@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.
From: Kent M Pitman
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <sfwu1rj3tpx.fsf@shell01.TheWorld.com>
I <······@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
From: Dorai Sitaram
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <a6qve6$igi$1@news.gte.com>
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@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
From: Rahul Jain
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87r8mmz97n.fsf@photino.sid.rice.edu>
····@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 -=- ············@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.
From: Christopher Browne
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <m3n0xa4bf7.fsf@salesman.cbbrowne.com>
Centuries ago, Nostradamus foresaw when Rahul Jain <·····@sid-1129.sid.rice.edu> would write:
> ····@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/>
From: Rahul Jain
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87663yz1nq.fsf@photino.sid.rice.edu>
Christopher Browne <········@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 -=- ············@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.
From: Thomas Bushnell, BSG
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87elimb4zw.fsf@becket.becket.net>
Rahul Jain <·····@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
From: Rahul Jain
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87g032xizv.fsf@photino.sid.rice.edu>
·········@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 -=- ············@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.
From: Kent M Pitman
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <sfwk7sdewe2.fsf@shell01.TheWorld.com>
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@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?
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.
From: Erik Naggum
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225237165705716@naggum.net>
* 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.
From: Kent M Pitman
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <sfwelik4xgq.fsf@shell01.TheWorld.com>
Erik Naggum <····@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.
From: Erik Naggum
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225166605272218@naggum.net>
* 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.
From: Rahul Jain
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87ofhqxmhx.fsf@photino.sid.rice.edu>
Erik Naggum <····@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 -=- ············@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.
From: Erik Naggum
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225183094172538@naggum.net>
* Rahul Jain <·····@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.
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Rahul Jain <·····@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
From: Rahul Jain
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87wuwdv9t2.fsf@photino.sid.rice.edu>
Bruce Hoult <·····@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 -=- ············@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.
From: Erik Naggum
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225269051878053@naggum.net>
* 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.
From: Bruce Lewis
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <nm9pu25bz87.fsf@magic-pi-ball.mit.edu>
Rahul Jain <·····@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.
--
<·······@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
From: IPmonger
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <m3ofhnluqj.fsf@validus.delamancha.org>
Bruce Lewis <·······@yahoo.com> writes:
> Rahul Jain <·····@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
········@delamancha.org
From: Thaddeus L Olczyk
Subject: Re: What should S-expression based languages be called? (was: Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3c995780.134302437@nntp.interaccess.com>
Kent M Pitman <······@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
* Doug Quale <······@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.
Erik Naggum <····@naggum.net> writes:
> * Doug Quale <······@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
Doug Quale <······@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 -=- ············@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.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> Doug Quale <······@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
Doug Quale <······@charter.net> writes:
> Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> > Doug Quale <······@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 -=- ············@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.
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> Doug Quale <······@charter.net> writes:
>
> > Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> > > Doug Quale <······@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
* 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 <······@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.
* Doug Quale <······@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.
Doug Quale <······@charter.net> writes:
> Erik Naggum <····@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.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
> ······@interaccess.com (Thaddeus L Olczyk) writes:
>
> > On Tue, 12 Mar 2002 12:00:23 -0800, ···@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
"Thaddeus L Olczyk" <······@interaccess.com> wrote in message
······················@nntp.interaccess.com...
> On Tue, 12 Mar 2002 12:00:23 -0800, ···@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.
> )
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
(······@cox.net)
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@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
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" <········@cadvision.com> wrote in message news:<············@news3.cadvision.com>...
> "Erann Gat" <···@jpl.nasa.gov> wrote in message
> ·························@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
····@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.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> ····@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.
····@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
In article <····························@posting.google.com>,
Paul Graham <····@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
····@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.
·········@becket.net (Thomas Bushnell, BSG) writes:
> ····@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.
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...
* 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.
Erik Naggum <····@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.
* 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.
Erik Naggum <····@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.
* 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.
On Fri, 15 Mar 2002 06:40:31 GMT,
Erik Naggum <····@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.
From: Erik Naggum
Subject: Re: Discussions, was Re: Why is Scheme not a Lisp?
Date:
Message-ID: <3225185371593086@naggum.net>
* 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.
Erik Naggum <····@naggum.net> wrote:
>* 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.
Perhaps he was hoping to shame you into silence, Eric.
From: Rolf Mach
Subject: Re: Discussions, was Re: Why is Scheme not a Lisp?
Date:
Message-ID: <3C91FBDD.9316385@xanalys.com>
Stefan,
I completely agree.
Sincerely
Rolf Mach
Stefan Schmiedl wrote:
> On Fri, 15 Mar 2002 06:40:31 GMT,
> Erik Naggum <····@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.
--
__________________________________________________________________________________________
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
·····@xanalys.com
__________________________________________________________________________________________
Watson - PowerCase - Quenza - LispWorks
From: Erik Naggum
Subject: Re: Discussions, was Re: Why is Scheme not a Lisp?
Date:
Message-ID: <3225237886273382@naggum.net>
* Rolf Mach <·····@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
| ·····@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.
From: Espen Vestre
Subject: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <kwofhm5joa.fsf_-_@merced.netfonds.no>
Erik Naggum <····@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
From: Erik Naggum
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225443058159866@naggum.net>
* 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.
From: Espen Vestre
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <kw663u3u1x.fsf@merced.netfonds.no>
Erik Naggum <····@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)
From: Nils Goesche
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <a756bu$ih542$1@ID-125440.news.dfncis.de>
In article <··············@merced.netfonds.no>, Espen Vestre wrote:
> Erik Naggum <····@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
From: Espen Vestre
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <m1r8mh64p9.fsf@macduck.vestre.net>
Nils Goesche <······@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)
From: Rahul Jain
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87663ty7il.fsf@photino.sid.rice.edu>
Espen Vestre <·····@*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 -=- ············@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.
From: Espen Vestre
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <m1u1rdtth6.fsf@macduck.vestre.net>
Rahul Jain <·····@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)
From: Erik Naggum
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225470179877386@naggum.net>
* 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.
From: Espen Vestre
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <m1pu21tsh1.fsf@macduck.vestre.net>
Erik Naggum <····@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)
From: Rahul Jain
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87d6y1wkzd.fsf@photino.sid.rice.edu>
Espen Vestre <·····@*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 -=- ············@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.
From: Espen Vestre
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <m17ko932d5.fsf@macduck.vestre.net>
Rahul Jain <·····@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)
From: Rahul Jain
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <874rjdwj0m.fsf@photino.sid.rice.edu>
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Rahul Jain <·····@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?
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 -=- ············@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.
From: Espen Vestre
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <kwsn6xarzr.fsf@merced.netfonds.no>
Rahul Jain <·····@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)
From: Rahul Jain
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <87vgbtlzav.fsf@photino.sid.rice.edu>
Espen Vestre <·····@*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 -=- ············@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.
From: Espen Vestre
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <kwzo159bd0.fsf@merced.netfonds.no>
Rahul Jain <·····@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)
Erik Naggum <····@naggum.net> wrote:
> 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.
Does it help to post idiotically rude posts ? No.
Should they learn from this and avoid doing it in the future? Yes.
Has Eric Naggum done the same idiotically rude 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.
"S Campion" <···················@hotmail.com> wrote in message
·······································@4ax.com...
>
> Does it help to post idiotically rude posts ? No.
> Should they learn from this and avoid doing it in the future? Yes.
Does a flood of <AOL>Me, too!</AOL> responses to
4 day old messages count? Yes.
*PLONK*
From: Marc Spitzer
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <slrna9n5te.2fmr.marc@oscar.eng.cv.net>
In article <··································@4ax.com>, S Campion wrote:
> Erik Naggum <····@naggum.net> wrote:
>
>> 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.
>
> Does it help to post idiotically rude posts ? No.
> Should they learn from this and avoid doing it in the future? Yes.
> Has Eric Naggum done the same idiotically rude 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.
>
Just because it appears to be idiotic to you does not mean you are
right. Now on to the "_politeness_" bug of yours, are you saying that
Erik should be punished/shuned because he uses "the 7 words you can't
type on CLL"?(stolen from george carlen)
marc
S Campion <···················@hotmail.com> wrote:
>Erik Naggum <····@naggum.net> wrote:
>
>> 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.
>
>Does it help to post idiotically rude posts ? No.
>Should they learn from this and avoid doing it in the future? Yes.
>Has Eric Naggum done the same idiotically rude 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.
??
What is the point in provoking Eric ?
All you will do is subject yourself ( and this group ) to another of
his endless tirades.
Either killfile him ( like some did ) or leave the group ( like many
others did ). There are several " Eric free" languages around. Scheme,
OCaml and Mozart are one of many choices.
Leave Eric to record ( and expedite ) the last death throes of Lisp.
>What is the point in provoking Eric ?
>All you will do is subject yourself ( and this group ) to another of
>his endless tirades.
>
>Either killfile him ( like some did ) or leave the group ( like many
>others did ). There are several " Eric free" languages around. Scheme,
>OCaml and Mozart are one of many choices.
>
>Leave Eric to record ( and expedite ) the last death throes of Lisp.
BTW, does anyone know who Eric's current employer is ?
I would like to email them a sample of the abuse that he posts here.
* Adam Tissa <·······················@yahoo.com>
| BTW, does anyone know who Eric's current employer is ?
| I would like to email them a sample of the abuse that he posts here.
Why do you take part in such obvious hate campaigns? Are you such an
easy mark that you do not even recognize that you have been had? Do not
feed the trolls. Watch the newsgroups header to see that "S Campion" is
violating a large number of newsgroups with his attacks, and so are you.
Followups are set to comp.lang.lisp, only, where we are more used to your
kind than the innocent newsgroups to which this was cross-posted.
I do not post in the name of any employers. However, please let me know
who yours is, so I can show your employer (1) that you consider it your
employer's business what you do on the Net, and (2) what you do on the
Net. This would be fair, would it not? So be careful what you wish for.
What would your employer do with you if he got a complaint from someone?
Would he not ask what your role is? A crank who just calls to complain
about other people who has done nothing to that person is dismissed out
of hand. You have attacked me, so I have a case against you, but you
have no case against me at all. You see, in my culture, the employer
does not own his employees and has no say over what they do as long as
they do not represent the employer in any way. In your culture, I must
assume that the employer has the power to require obedience to standards
of conduct even off duty, lest they be fired. I must also assume that
you consider it just punishment for not having attacked you in any way
that somebody get into trouble with such an owner of their life. I
regret to inform you that my culture is not like this at all -- in my
culture, an accusation like you want to make is much more likely to be
considered good evidence of _your_ behavioral problems.
Now, I have never said anything harsh or critical or even unwelcome to
you, in fact, I have never even _seen_ your name until now. Yet you find
it the most prudent approach to attack me out of the blue, piggybacking
off another very hostile attack out of the blue. You choose to post not
one, but _four_ very hostile messages, and more are undoubtedly coming.
Despite the lack of personal involvement, you feel such personal anger
that you have set aside all ethical concerns, if any, and let it rage
uncontrollably. This is very interesting. You see, normally, people get
into heated exchanges over a particular topic they care very much about
-- emotion is a result of passion _for_ something, and they may start
small and escalate, but they never start off with an all-out flame like
yours with a passion _against_ someone. You see, normally, exchanges
vary in temperature but stay pretty focused on the topic at hand, but
yours is an unfettered hostility that has no constructive purpose or
contents at all. What, precisely, is it that you think I do wrong that
you do not do much worse yourself and consider perfectly OK? I mean, I
never ask for anyone's employer -- if they flaunt it in a 23-line
signature, say, or they explicitly speak for their company, sure, I
implicate the employer, but otherwise not. This is pretty basic.
But who is this "Adam Tissa"? I have _no_ idea and I have no desire to
learn to know ths person, but I know something about him: He is a person
who attacks people who have _not_ provoked him in any way and he does not
even defend anyone or even anything he cares about, he is a person who
wants only _other_ people to behave better while _he_ shall be free to
hurt people as he pleases, and on top of this he is a person cannot
control his anger. I already know more than I ever wanted to know about
Adam Tissa. However, this is a fairly classical "enraged bystander", one
who actually thinks he can remain a bystander while he hurls attacks at
other people. Adam, news is not a sitcom and your comments are not idle
comments that you hurl at your TV. You are _part_ of the problem, now.
Please realize this and temper yourself.
Finally, if you would like others to behave well, start with yourself.
If you have a technical point relevant to comp.lang.lisp, just make it.
If you are a troll, be prepared to be hated everywhere you go. If you
cannot behave and have nothing to say, please do it privately.
My apologies to the irrelevant newsgroups to which S Campion and Adam
Tissa made it relevant for me to post a rebuttal. Follows have been
directed to comp.lang.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.
"Adam Tissa" <·······················@yahoo.com> wrote in message
·······································@4ax.com...
> >What is the point in provoking Eric ?
> >All you will do is subject yourself ( and this group ) to another of
> >his endless tirades.
> >
> >Either killfile him ( like some did ) or leave the group ( like many
> >others did ). There are several " Eric free" languages around. Scheme,
> >OCaml and Mozart are one of many choices.
> >
> >Leave Eric to record ( and expedite ) the last death throes of Lisp.
>
>
> BTW, does anyone know who Eric's current employer is ?
> I would like to email them a sample of the abuse that he posts here.
You could always follow your own advice:
> Either killfile him ( like some did ) or leave the group ( like many
> others did ). There are several "Eric free" languages around. Scheme,
> OCaml and Mozart are one of many choices.
If you think Eric is provocative you should take a good look
at yourself.
Eric has a special style, and if can't cope that is your problem.
--
Thomas.
Approaching singularity.
"Thomas Stegen" <··········@hotmail.com> writes:
> Eric has a special style, and if can't cope that is your problem.
What about Erik's (note the spelling, please) inability to cope with
many other styles?
"Thomas Bushnell, BSG" <·········@becket.net> wrote in message
···················@becket.becket.net...
> "Thomas Stegen" <··········@hotmail.com> writes:
>
> > Eric has a special style, and if can't cope that is your problem.
>
> What about Erik's (note the spelling, please) inability to cope with
> many other styles?
>
From what I have seen (I haven't been here for long), it seems to
me that it usually starts when Erik critizises some technology
and someone takes it personally and a vicious cycle starts.
Well, I am not here to discuss Erik, so I think I'll leave it at
that. And please note that I set follow-ups only to cll.
Apologies for the spelling mistake Erik. (I knew that, just managed
to hit the wrong key which is on the other side of the keyboard...
duh)
--
Thomas.
Approaching singularity.
Racism
The Democrats have kept African Americans shackled to poverty by keeping
African Americans shackled to poverty programs.
Race and Racism seems to be the hardest thing to talk about in this country.
And it is not ironic that all we ever do is talk about it. Does anyone
truly disagree that the best way to put an end to an idea is to assign it to
a committee? And the Clintons established a national dialogue on race. Big
deal.
Since the dawn of the modern Civil Rights movement, the one that began with
television, we have witnessed the greatest political slight of hand that has
ever been perpetrated against a race of people. Adolph Hitler was up front
about his activities. The Soviet Union lied through their propaganda
machines and did what they wanted to do anyway. But the Democrats have
established a house of smoke and mirrors.
When the war on poverty began, the Republicans called for workfare programs.
Programs that would keep Blacks participating in the economy. The Democrats
redefined that as an attack on entitlements, an attack on civil rights, and
got middle of the road white people to join the liberals in marginalizing
the Black community.
It is not sufficient to say that a Republican, Abe Lincoln, freed the
slaves. Nor is it sufficient to point out that the Army had to be called
upon to protect federal marshals escorting four Black children to school in
a system run by a party whose Governor declared his commitment to injustice.
We have to look at what has been done to impede the efforts of Blacks in
their attempt at full enfranchisement.
The Problems
Busing: Every morning, Democrats bus Black children into White schools.
Every afternoon, Democrats bus Black children back into Black neighborhoods.
Housing: Fair housing was ignored in favor of public housing. And public
housing always meant ghetto housing. With welfare instead of workfare,
high-rise public housing, and busing, the Democrats have kept African
Americans apart from the rest of America. (And suburban housing plans have
always been high density housing. Which, as always, is a course to
stigmatize not to help African Americans.)
Education: The Democrats have made education a matter of empowerment and
dignity, self-esteem building, and cultural pride. In short, rather than
spend money on the education of Black children, they have diverted it
everywhere else. Your child may be proud he can read a book. But, have you
ever heard of a child being able to read a book because he is proud of who
he is? For years Black children were tracked into low expectation classes.
Whites were tracked into gifted and able programs. Then, one day, someone
discovered that Black children in classes for troublesome children were
there because they were actually gifted children and they were disruptive
because they were bored. What happened? Rather than move the Black
children into the classes for gifted children where they belonged, liberals
declared tracking and classes for gifted children to be elitist. So, gifted
Black children were, again, cheated. Only now do the headlines read:
Reverend Jesse Jackson Sends Ministers to Wall Street. Which lead us to...
Investment: Economic self-determinationism has been replaced with
propaganda and socialism. Distressed areas are not slated for development.
They are defined, again, as empowerment and dignity zones, and non-profit,
social service agencies are located there. This to give jobs to unemployed
Blacks. Non-profit means Black people don't make any money. Social service
means help dealing with the conditions as they are. Not (as Bobby Kennedy's
words promised) as they could be. Or should be.
The Solutions
The best focus is to generate "investments for profit" in the Black
Community. This can be defined as any place (remember the internet) where
one, two, or more African Americans, individually or with others, work at an
activity to generate income and or profit for themselves and for others. It
may include but is not limited to the inner cities.
Investment in the Black Community (for a profit) will result in Black
ownership. It is the profits from these businesses that will help these
businesses grow. But we must think beyond small businesses to large
businesses and to corporations. And we must include the internet.
To some, open housing means affordable housing. To others it means helping
Black people afford houses. To Democrats it seems to mean building ghetto
housing that Blacks can afford. With subsidized interest rates, instead of
subsidized housing, Blacks who are now in low and moderate income families
could afford one-family homes. Their children could walk to integrated
schools, and the quality of life will improve. There will no longer be a
need to bus a Black child into a school if he or she lives close enough to
walk. This solves the busing, the housing, and the education issue.
What's the catch?
When African Americans own their own businesses, or own a stake in corporate
America when African Americans make profits and expand their financial and
economic power, they will invest their profits, they will buy things, they
will own things. The most important being the ownership of their own means
of economic well being. Once that happens, Black people will no longer vote
for the Democrats who want to tax it away from them. Without busing,
housing, and education as an "issue" the Democrats will find their
"plantation mentality" a relic of their political history. The Democrats
will no longer get a free ride from the African American community.
"Thomas Bushnell, BSG" <·········@becket.net> wrote in message
···················@becket.becket.net...
> "Thomas Stegen" <··········@hotmail.com> writes:
>
> > Eric has a special style, and if can't cope that is your problem.
>
> What about Erik's (note the spelling, please) inability to cope with
> many other styles?
>
"Wayne Johnson" <······@hers.com> writes:
> Racism
>
>
>
> The Democrats have kept African Americans shackled to poverty by keeping
> African Americans shackled to poverty programs.
>
> Race and Racism seems to be the hardest thing to talk about in this country.
[...]
Didn't know these are US-only newsgroups... sorry for posting here.
Regards,
Julian
--
Meine Hompage: http://julian.re6.de
Ich suche eine PCMCIA v1.x type I/II/III Netzwerkkarte.
Ich biete als Tauschobjekt eine v2 100MBit Karte in OVP.
On 31 Mar 2002 21:42:52 +0200, Julian Stecklina <··········@web.de>
wrote:
>"Wayne Johnson" <······@hers.com> writes:
This is a forgery, from some nut-case racist.
Wayne "Pay no attention to it" Johnson
************************************************
"They've got us surrounded again, the poor bastards."
- Lt. Col. Creighton Abrams, 4th Armored Division, U.S. Army,
preparing for the counteroffensive at the Battle of Bastogne, 1944
>BTW, does anyone know who Eric's current employer is ?
>I would like to email them a sample of the abuse that he posts here.
He calls himself Naggum Software.
What we need is the names of his major clients.
Adam Tissa <·······················@yahoo.com> wrote:
>>BTW, does anyone know who Eric's current employer is ?
>>I would like to email them a sample of the abuse that he posts here.
>He calls himself Naggum Software.
>What we need is the names of his major clients.
I vaguely remember that he claimed to be working for a newspaper
publisher in Norway.
I think that they would be very, very interested to read some of Mr
Naggum's pathologically abusive statements about individuals and
companies.
I have seen posts by him abusing Franz Lisp and Xanalys.
>What is the point in provoking Eric ?
>All you will do is subject yourself ( and this group ) to another of
>his endless tirades.
>
>Either killfile him ( like some did ) or leave the group ( like many
>others did ). There are several " Eric free" languages around. Scheme,
>OCaml and Mozart are one of many choices.
>
>Leave Eric to record ( and expedite ) the last death throes of Lisp.
BTW, does anyone know who Eric's current employer is ?
I would like to email them a sample of the abuse that he posts here.
Adam Tissa wrote:
> S Campion <···················@hotmail.com> wrote:
[...]
Well, well, well. Fascinating.
1. From "S Campion"'s article headers:
| From: S Campion <···················@hotmail.com>
2. From "Adam Tissa"'s article headers:
| From: Adam Tissa <·······················@yahoo.com>
I notice in Adam S Campion-Tissa's list of newsgroups
a bunch of Christian ones. Perhaps Mr S. Adam Tissa-Campion
considers themselves a Christian. I'll remind him of
Luke 12:2-3, and Mark 5:9. Oh, and maybe Matthew 7:1-2.
Followups directed to alt.flame, as they deserve.
--
Gareth McCaughan ················@pobox.com
.sig under construc
Erik Naggum <····@naggum.net> wrote in message news:<················@naggum.net>...
> * Espen Vestre
> | That their representative is a man who prefers politeness is hardly
> | a reason to avoid them...
>
> Sure, he prefers politeness, but mostly by requiring others to behave.
And you are too immature and egocentric to behave ?
From: Erik Naggum
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225871173031057@naggum.net>
* ···········@yahoo.com (···········@yahoo.com)
| And you are too immature and egocentric to behave ?
No, that would be you. I am not like you, and I can say that because you
have chosen to introduce yourself to me the way you have. Please do not
insult people by extrapolating from yourself -- it gets you into trouble.
I tend to get very irritated by stupid people like yourself, especially
when they are both so conceited and so ill-behaving that they post such
moronic rhetorical questions and do not realize that they have just told
the whole world they are too immature and egocentric to behave. However,
good thinking to post from yahoo.com, the next best thing to anonymous
and a virtual haven for bad people. Still, one must judge people on a
case by case basis -- most people behave differently when they deal with
retarded pricks and intelligent people. If you just assume that somebody
is a prick and approach them with that assumption, the other person does
not need to assume anything about you -- he _knows_.
I do not recall having said anything at all towards you, ever, yet you
think it is appropriate to attack me on this our first encounter. I find
this quite interesting in people. Politeness in my book is when you
always approach people as individuals and with as clean a slate as
possible, and engage in a discussion with them based on how you react to
eachother in a particular context, not based on prejudice or hatred, like
you do, and like several other people who claim that they are concerned
that only other people behave well do.
I actually believe that people who choose to attack other people for no
reason other than their _own_ feelings towards them, especially on their
very first encounter, are clinically insane and should be locked up.
Therefore, when such a person chooses to talk about _other_ people's
behavior, I not only know that they are dangerous and violent from their
lack of ability to control their anger and approach people as individuals
that may react differently to them than to others, I have reason to
suspect that they are psychotic and see things and so out of touch with
reality in general that they cannot be expected to read and understand
_anything_ that the subject of their strong and irrational hatred have to
say in their defense. Therefore, replying to such people as yourself is
an exercise in diplomacy towards all the people with whom you have chosen
to share your accusation. However, it is characteristic of your kind of
people not to tolerate a defense, but to operate in "one truth" mode.
You would understand my position if you had the wherewithal to understand
your _own_ role and behavior and had been far less concerned with that of
others, but you seem to have the same appreciation for hypocrisy as all
the others who spend their time _not_ contributing to a forum, _not doing
anything to change the tone they do not like, _not_ understanding that
behavior like yours is the root cause of the hostility and irritation,
and moreover, is self-fulfilling and self-propelling. If you think this
is smart behavior on your part, consider moving to the Middle East. I
hear some recently vacated caves without Internet access have low rent.
The reason people like you are so concerned with other people's behavior
is that the only way you can be treated nicely is if other people do not
treat you as you deserve -- all good and/or intelligent people give each
other a second chance, but bad and/or stupid people never do -- they
think they know "enough" about other people to make up their mind. So
instead of responding to what people _write_ in any given article, they
do just what you do: they respond to their image of another person, made
up in their own personality and their own image. The need to have people
"like" them is so strong that they attack anyone who does not give the
impression of liking bad and/or stupid people, lest it be widespread. It
is therefore understandable that bad and/or stupid people always behave
badly when they attack others for not being nice to a fellow bad and/or
stupid person -- they identity with any vermin who is treated as he
deserves. The clue to get out of this situation is simply not to
identify with vermin. Try to face people on a case by case basis, and
people will treat you well if you deserve it. It really is that simple,
but your kind will probably never figure out what your role is and that
you can change it. That is why your only hope is that other people are
nice to you. Now, go away and ba a bad and/or stupid person elsewhere.
///
--
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.
On Sat, 23 Mar 2002 11:19:22 GMT, Erik Naggum <····@naggum.net>
wrote:
>* ···········@yahoo.com (···········@yahoo.com)
>| And you are too immature and egocentric to behave ?
>
> No, that would be you. I am not like you, and I can say that because you
> have chosen to introduce yourself to me the way you have. Please do not
> insult people by extrapolating from yourself -- it gets you into trouble.
> I tend to get very irritated by stupid people like yourself, especially
> when they are both so conceited and so ill-behaving that they post such
> moronic rhetorical questions
Rhetorical question from me: what all this has in common with Lisp
or Scheme?
A.L.
From: Erik Naggum
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <3225997961410822@naggum.net>
* Andrzej Lewandowski <·············@attglobal.net>
| Rhetorical question from me: what all this has in common with Lisp
| or Scheme?
Barely more than your rhetorical question.
Meta-discussions never have anything to do with the purpose of the
newsgroup, and meta^x-discussions less the higher the value of x.
///
--
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.
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
>Erik Naggum <····@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...
True.
Indeed the fact that a certain very rude man (E.N ) dislikes them is
probably a good reason to buy from them.
From: Nils Goesche
Subject: Re: Xanalys Germany (was Re: Discussions, was Re: Why is Scheme not a Lisp?)
Date:
Message-ID: <a7fni0$l750c$1@ID-125440.news.dfncis.de>
In article <··································@4ax.com>, S Campion wrote:
[spam]
Abuse reports should probably go to ·····@hotmail.com and
··········@cwo.com.au.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Erik Naggum <····@naggum.net> wrote:
> Stefan, this is what happens when you post such messages. Jerks
> _always_ come crawling out of the woodwork when someone posts
No Eric, you are already here.
From: Erik Naggum
Subject: Re: Discussions, was Re: Why is Scheme not a Lisp?
Date:
Message-ID: <3225804766285922@naggum.net>
* Erik Naggum
> Stefan, this is what happens when you post such messages. Jerks
> _always_ come crawling out of the woodwork when someone posts
* S Campion <···················@hotmail.com>
| No Eric, you are already here.
Amazingly, you could not figure out that you are precisely the kind that
crawls out of the woodwork that I was talking about. Congratulations.
///
--
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.
·@xss.de (Stefan Schmiedl) wrote:
>On Fri, 15 Mar 2002 06:40:31 GMT,
>Erik Naggum <····@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.
Very true.
Hi Stefan Schmiedl,
have you ever studied anthropology?
many eon ago, when i first heared the word and looked it up, i being
the Dilbert type of guy (i.e. engineers & chemists & phycists etc.),
thought it's a dorky subject.
But these days i have revelations. I see that there are tons of dorky
engineers who knew nothing of the subject, yet fervently strut out
their opinions and views from law to politics. (look at the OpenSource
sham)
I would advice you programing geeks, spare a science fiction, spare a
language debate, and read a couple of _text books_ on anthropology,
sociology, law, economics, history, and political science. Then, you
will realize your tech brain knew nothing about humanity and society.
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
> From: Stefan Schmiedl (·@xss.de)
> Subject: Discussions, was Re: Why is Scheme not a Lisp?
> Newsgroups: comp.lang.lisp
> Date: 2002-03-15 04:08:16 PST
···@xahlee.org (Xah Lee) wrote:
>I would advice you programing geeks, spare a science fiction, spare a
>language debate, and read a couple of _text books_ on anthropology,
>sociology, law, economics, history, and political science. Then, you
>will realize your tech brain knew nothing about humanity and society.
The Li Ao you refer to, is he the one who is standing for the
presidential elections in Taiwan ?
http://th.gio.gov.tw/p2000/li1.htm
Erik Naggum <····@naggum.net> wrote:
>* 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.)
>
>///
S Campion <···················@hotmail.com> wrote:
> > (I made that all one paragraph so people who read only the first should
> > not get away with skipping all the juicy bits.)
...the effect of which is that not even the people who usually read the
first paragraph read *any of it*, but for the two line addition above!
Denis
On 14 Mar 2002 00:42:50 -0800, ····@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/]
In article <····························@4ax.com>,
Paolo Amoroso <·······@mclink.it> wrote:
> On 14 Mar 2002 00:42:50 -0800, ····@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
In article <···························@copper.ipg.tsnz.net>, Bruce Hoult wrote:
> In article <····························@4ax.com>,
> Paolo Amoroso <·······@mclink.it> wrote:
>
>> On 14 Mar 2002 00:42:50 -0800, ····@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
Regards,
--
Nils Goesche PGP key ID 0x42B32FC9
"The sooner all the animals are dead, the sooner we'll find
their money." -- Ed Bluestone
Centuries ago, Nostradamus foresaw when Nils Goesche <······@cartan.de> would write:
> In article <···························@copper.ipg.tsnz.net>, Bruce Hoult wrote:
> > In article <····························@4ax.com>,
> > Paolo Amoroso <·······@mclink.it> wrote:
> >
> >> On 14 Mar 2002 00:42:50 -0800, ····@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 ···········@" "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/>
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. :-)
Matthias Blume <········@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 <···@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
Lieven Marchand <···@wyrd.be> writes:
> Matthias Blume <········@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
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''.
Doug Quale <······@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 -=- ············@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.
Rahul Jain <·····@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
Doug Quale <······@charter.net> writes:
> Rahul Jain <·····@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 -=- ············@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.
Rahul Jain wrote:
> Doug Quale <······@charter.net> writes:
> > Rahul Jain <·····@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
······@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 -=- ············@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.
Rahul Jain <·····@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.
From: Thomas Bushnell, BSG
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <87d6y5heq2.fsf@becket.becket.net>
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
·········@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 -=- ············@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.
From: Thomas Bushnell, BSG
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <87u1rfn07o.fsf@becket.becket.net>
Rahul Jain <·····@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@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 -=- ············@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.
From: Thomas Bushnell, BSG
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <871yej1v0h.fsf@becket.becket.net>
Rahul Jain <·····@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@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 -=- ············@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.
From: Thomas Bushnell, BSG
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <87henf4hbk.fsf@becket.becket.net>
Rahul Jain <·····@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Rahul Jain <·····@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 -=- ············@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.
From: Thomas Bushnell, BSG
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <87vgbuwxa9.fsf@becket.becket.net>
Rahul Jain <·····@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
·········@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 -=- ············@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.
From: Thomas Bushnell, BSG
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <87r8miwv9c.fsf@becket.becket.net>
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> ·········@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
From: Janis Dzerins
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <87sn6ybycz.fsf@asaka.latnet.lv>
·········@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.
From: Thomas Bushnell, BSG
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <877ko9ai6x.fsf@becket.becket.net>
Janis Dzerins <·····@latnet.lv> writes:
> ·········@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
From: Duane Rettig
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <48z8pwxvg.fsf@beta.franz.com>
·········@becket.net (Thomas Bushnell, BSG) writes:
> Janis Dzerins <·····@latnet.lv> writes:
>
> > ·········@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 ·····@Franz.COM (internet)
From: Duane Rettig
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <44rjdwwpr.fsf@beta.franz.com>
Duane Rettig <·····@franz.com> writes:
> ·········@becket.net (Thomas Bushnell, BSG) writes:
>
> > Janis Dzerins <·····@latnet.lv> writes:
> >
> > > ·········@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 ·····@Franz.COM (internet)
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
From: Duane Rettig
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <4y9gpv88s.fsf@beta.franz.com>
Paul Dietz <············@motorola.com> writes:
> 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.
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 ·····@Franz.COM (internet)
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
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225566321428508@naggum.net>
* 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.
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
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225571208798099@naggum.net>
* 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.
Erik Naggum <····@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.
Carl Shapiro <·············@panix.com> writes:
> Erik Naggum <····@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.)
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225685440358243@naggum.net>
* 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.
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
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225694232096978@naggum.net>
* "Paul F. Dietz" <·····@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.
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
"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.
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
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225739210766179@naggum.net>
* 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.
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
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225746969252089@naggum.net>
* 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.
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))
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225770541321057@naggum.net>
* "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.
Erik Naggum wrote:
> | 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.
Mr. Naggum, no, it is not just plain wrong. *You* are just plain
wrong. *Study* that algorithm I posted. Build the dependency
graph of the loads. You will see that the maximum path length
in the alist graph is N+O(1) vs. 2N+O(1) for the plist.
> | 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?
NIL is a special case, since an alist can contain NILs as well
as conses. The test (eq (car pair) key) would incorrectly succeed
on such elements if key were nil. The algorithm therefore handles
the null key case separately, and I did not optimize that case.
> | *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.
I've presented a trivial proof that you cannot (it's right in front
of you there.)
How about you show me an algorithm that does plist search in better
than 2N+O(1) load latency?
> I wonder why you are so stubborn about something that is clearly wrong.
Funny, I was wondering the same thing.
Paul
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225858821399981@naggum.net>
* "Paul F. Dietz"
| Mr. Naggum, no, it is not just plain wrong. *You* are just plain wrong.
| *Study* that algorithm I posted. Build the dependency graph of the
| loads. You will see that the maximum path length in the alist graph is
| N+O(1) vs. 2N+O(1) for the plist.
Mr. Dietz, you are anti-productive. There is more to this than the
"maximum path length". Nobody has _ever_ disputed these claims, but you
continue to neglect the _additional_ costs: things like cache lines and
the register requirements of your algorithm. What you offer us is a
_complication_ that has absolutely no value at the level you offer it --
it has significant value in understanding _some_ issues, but when you
refuse to listen to the measurable facts, something is just plain wrong.
Optimization is about making things execute more efficiently, faster in
this case. When your code runs significantly slower then mine (93 ns vs
71 ns on my machine), there is something _wrong_ in your premises to
optimization. Is this so hard to understand and accept? A 28% increase
in the time spended on scanning an alist is not optimization in my book.
| I've presented a trivial proof that you cannot (it's right in front of
| you there.)
What is right in front of me is not just proofs, but also measurements.
Since you diss my measurements, I must assume that you are either unable
to deal with the real world or have a personal problem, since you could
very easily _repeat_ these measurements in a straight-forward scientific
way, yet you cling to your proofs. I find this _extremely_ annoying.
We are, or at least I am, discussing optimization on a real machine with
real registers and real memory. It is very useful to be able to talk
about some abstract machine with abstract registers and abstract memory,
but optimization of real machines obey many _additional_ constraints. A
proof that considers only one set of constraints and completely ignores
all others is not useful when discussing which will run faster on actual
hardware. And let us not forget that some of these optimizations give
you a lower cost of some things at the expense of higher costs of other
things. Optimizing access into an alist many thousands of key-value
pairs long is precisely the kind of stupid thing that people who learn
that Lisp is for List Processing would do. Real programmers would find
that not only is there no benefit to your more complex algorithm, it has
far higher costs than savings.
If I have "mistaken" this discussion for being some academic exercise in
theoretical "optimization" apart from implementation, please let me know.
I have sort of based my entire line of reasoning on the kinds of design
choices people were inclined to make because "alists are faster than
plists". Theoretical optimization with a large number of registers is
fine -- as long as it actually runs faster, too. A _potential_ to run
faster given a more perfect universe does not impress me when I want raw
speed.
| How about you show me an algorithm that does plist search in better than
| 2N+O(1) load latency?
So you want others to compete with you on your home ground and refuse
adamantly to consider any other premises. How interesting.
I have tried to make you realize that I have discussed actual hardware.
There has been absolutely no secrecy around what I have been doing, but I
have continually found that you want to discuss something else that does
not yield better results. I am profoundly sorry to see that you are
completely oblivious to hardware and think a _more_ optimal algorithm can
reasonably be expected to run _slower_ than a less optimal algorithm. I
consider an algorithm to be faster when it _is_ faster, as _measured_.
| Funny, I was wondering the same thing.
Yeah, another case of the mirror game is brewing. Sheesh, some people.
But obviously we have different purposes: You want to "prove" algorithmic
optimization on an abstract machine with an infinite number of registers
and constant memory access costs. I actually want to obtain the fastest
implementation of a algorithm on a given machine (repeated for more
machines as necessary), including its variable memory costs due to
multi-level caching, its register shortage, etc, and I consider more
complex algorithms that run slower to be going in the wrong direction.
It is time to realize that "optimization" is both a mathematical and an
engineering discipline. I had sort of hoped you could have figured out
what _I_ have been demonstrating, when you are so bloody eager to shoe me
stuff that does not answer any question anybody had asked before you came
along. So, you have given us a nice proof that does not matter, code
that runs slower than my _far_ simpler code (which even checks for nil in
the alist, which you skimped on!), and you still huff and puff. What
makes you tick? I am frankly seriously annoyed by people who refuse to
listen to simple, repeatable, measurable facts and prefer their theories.
///
--
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.
Erik Naggum <····@naggum.net> writes:
> But obviously we have different purposes: You want to "prove" algorithmic
> optimization on an abstract machine with an infinite number of registers
> and constant memory access costs.
No, that was not his purpose. Paul showed an algorithmic optimization
for a machine that can have 3 loads independently in flight (so that
they do not have to wait for each other). Nothing about infinite
registers and other such nonsense. They are not needed.
Now, there *are* machines where multiple loads (but not infinitely
many) can be independently in flight. There are literally thousands
of people in the world doing research of how to efficiently program
for such machines.
> It is time to realize that "optimization" is both a mathematical and an
> engineering discipline. I had sort of hoped you could have figured out
> what _I_ have been demonstrating,
In the beginning you were, IIRC, demonstrating that you need the same
number of CARs and CDRs in either case -- which (while certainly
correct) showed that you didn't even understand at that time what Paul
was talking about. (Well, at least you were hiding it well... :-)
> when you are so bloody eager to shoe me
> stuff that does not answer any question anybody had asked before you came
> along. So, you have given us a nice proof that does not matter, code
> that runs slower than my _far_ simpler code (which even checks for nil in
> the alist, which you skimped on!), and you still huff and puff. What
> makes you tick? I am frankly seriously annoyed by people who refuse to
> listen to simple, repeatable, measurable facts and prefer their theories.
Paul was saying that there are machines where this can be an
advantage. You say "on my machine it doesn't". Fine, neither of you
has contradicted the other. A counterexample is does not disprove an
existentially quantified statement. Had Paul said "this will always
make a difference", he would have been wrong. But he didn't.
In any case, let's talk about something more useful. How about: Which
implementation of bubblesort runs fastest?
Matthias
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225880811573244@naggum.net>
* Matthias Blume
| No, that was not his purpose. Paul showed an algorithmic optimization
| for a machine that can have 3 loads independently in flight (so that
| they do not have to wait for each other). Nothing about infinite
| registers and other such nonsense. They are not needed.
I have spent some time with the documentation for my processor, and it
has four-way concurrent access to the level 2 cache, request-response
access to syste memory, and instantaneous level 1 cache access. As near
as I can tell, my simple alist-get function exercises the kinds of
optimizations that Paul has described and the branch prediction is done
the right way with Allegro CL's code, so there should be no pipeline
flushes at all. As near as I can tell, the code I have written in
alist-get-expand, as compiled by Allegro CL cannot be improved upon.
Now, I have tried to optimize Paul's code similarly, but it is in dire
need of registers in order to keep from accessing the level 1 cache to
swap registers with memory. Paul's code is 27% slower than my simple
alist-get-expand.
| Now, there *are* machines where multiple loads (but not infinitely many)
| can be independently in flight. There are literally thousands of people
| in the world doing research of how to efficiently program for such
| machines.
Very nice. If Paul is one of them, his code should have run faster than
mine. It does not.
| In the beginning you were, IIRC, demonstrating that you need the same
| number of CARs and CDRs in either case -- which (while certainly correct)
| showed that you didn't even understand at that time what Paul was talking
| about. (Well, at least you were hiding it well... :-)
I have tried to argue that the same number of memory accesses are needed.
Paul did a much better job of explaining his case after it became clear
that he was not actually interested in optimizing his code, but instead
optimizing the algorithm. The result is slower execution. I remain
resoundingly unimpressed.
| Paul was saying that there are machines where this can be an advantage.
| You say "on my machine it doesn't".
No, I have asked for information on which machines it does apply since I
cannot find any such machine. Please pay attention if you want to accuse
people of ill will and stupidity, will you? Otherwise, you are the
offender.
| Fine, neither of you has contradicted the other. A counterexample is
| does not disprove an existentially quantified statement. Had Paul said
| "this will always make a difference", he would have been wrong. But he
| didn't.
What he has indeed said is that his code should run faster, yet has not
shown that it actually does on any extant hardware. However, it appears
that the benefits that he talks about are handled at the hardware level
in my processor and that his software pipelining works _against_ the
hardware because of the register shortage. In other words, it works
better to do this in software on CPUs that lack hardware support for
pipelining, and that it has no effect at all on machines with enough
registers. If there are no processors that can do 3 concurrent memory
accesses that do _not_ do sufficient pipeline entirely on their own, this
is useful, but if modern processors all do this on their own, there is
simply no point in doing software pipelining, and the effect should be
noticeable regardless.
In particular, there should be _no_ difference in execution time between
scanning a list of a million elements (to get rid of the cache) and
scanning the cars of a list of a million conses, i.e., heavily optimized
member and assoc should run just as quickly on the same list. I would
like to see timings on at least one processor where this is the case.
| In any case, let's talk about something more useful. How about: Which
| implementation of bubblesort runs fastest?
I am actually happy that you are so bemused that this beats daytime TV.
///
--
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.
> Now, I have tried to optimize Paul's code similarly, but it is in dire
> need of registers in order to keep from accessing the level 1 cache to
> swap registers with memory. Paul's code is 27% slower than my simple
> alist-get-expand.
When reading this it occurred to me that there may be people out there
who actually need maximum speed on assoc-lists.
If there are, have you been experimenting with heuristic access
methods? Ron Rivest has analyzed two of them (MTF and TRANS) in [1].
I have made two little functions that may or may not help. They do
finds on lists using move-to-front and transpose heuristics. Both of
them modify element ordering in the list they are working with.
Note: I have never actually used them, beware bugs.
[1] R. Rivest. On self-organizing sequential search heuristics.
Communications of the ACM, 19, 2:63--67, February 1976.
<code>
;;; Matching element is moved to the front of the list.
(defun list-find-mtf (item list &optional (test #'eql) (key #'identity))
(loop for current-cons = list then (cdr current-cons)
for k = (funcall key (car current-cons))
until (null current-cons)
when (funcall test k item) do
(rotatef (car current-cons) (car list))
(return (car list))))
;;; Matching element is transposed with previous element.
(defun list-find-trans (item list &optional (test #'eql) (key #'identity))
(if (funcall test (funcall key (car list)) item)
(car list) ;; item in the head of the list
(loop for current-cons = list then (cdr current-cons)
and prev-cons = nil then current-cons
for k = (funcall key (car current-cons))
until (null current-cons)
when (funcall test k item)
do (unless (null prev-cons)
(rotatef (car prev-cons) (car current-cons)))
(return (car prev-cons)))))
-- Kimmo, http://www.iki.fi/kt/
((lambda (integer)
(coerce (loop for i upfrom 0 by 8 below (integer-length integer)
collect (code-char (ldb (byte 8 i) integer))) 'string))
100291759904362517251920937783274743691485481194069255743433035)
········@cc.helsinki.fi (Kimmo T Takkunen) writes:
> When reading this it occurred to me that there may be people out there
> who actually need maximum speed on assoc-lists.
>
> If there are, have you been experimenting with heuristic access
> methods? Ron Rivest has analyzed two of them (MTF and TRANS) in [1].
Why not use a tree-based approach for larger set-sizes? That's why
they were developed, after all. If you don't have a total ordering for
the key set you can try ordering based on hashes of the
keys. Something like a hash-B-tree or a hash-splay-tree.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@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.
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225924796503700@naggum.net>
* Kimmo T Takkunen
| When reading this it occurred to me that there may be people out there
| who actually need maximum speed on assoc-lists.
Well, that is one possible way to see it, but I see it more as an
exercise in showing that choosing alists or plists because one has better
theoretical performance than the other is all bunk, because in practice
it does not appear to matter. Not one person out there has found test
results that clearly contradict my findings, which tells me that (1)
modern processors do not appreciate software that does the same kind of
optimization they try to do, (2) to make the access times matter, you
need to ensure that you fight the cache and have long memory latency, and
(3) even when you do, memory organization matters more than the
algorithm. In other words, mine is an elaborate argument to ask people
not to bother optimizing these things because (1) if the hardware can do
it, just let it do it, and (2) before any of this matters significantly,
you would profit from switching to something other than alists and plist.
I have some problems figuring out why some people think that just because
you set up a fairly elaborate counter-argument, you actually argue in
favor of the _opposite_ of what you demonstrate to be false. E.g., when
I found that alists and plists were just as fast in normal usage and I
saw equal execution times, my attempt at an explanation was that the
number of memory references were the same, and that memory latency was
not at issue, some think I failed to get the other point that provably
had a _negative_ impact on performance. I find this so amazingly useless
that I wonder how people think. So, in summary, no, I do not argue for
maximum speed of alists (or plists), I reject the notion that the maximum
path length argument matters one hoot to actual performance of actual
code running on actual machines, because it measurably does not. And if
you cannot imagine the glee that some people would take in "proving me
wrong", I can, so when nobody steps forward to do it, we can be very
certain that the measurements I have made are generally applicable, so
the argument remains quite simple: do not use "performance" as an excuse
to choose alists over plists when other concerns should weigh more.
| I have made two little functions that may or may not help. They do finds
| on lists using move-to-front and transpose heuristics. Both of them
| modify element ordering in the list they are working with.
Thanks, this is useful, but I think I would prefer one that kept track of
the number of times a key has been visited and maintained a list sorted
on that number. This could be done in a training session or at runtime.
For instance, many astonishingly stupid C-based programmers have built
"command tables" with strings as keys and perform a strncasecmp call for
every string in the list until they have a match, which is dumb enough in
itself, but then also fail to sort the "command table" in the order of
the most likely high use. These are the same people who would no doubt
call Lisp slow if they did the exact same thing in Lisp, but still think
that C is fast.
///
--
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.
Matthias Blume <········@shimizu-blume.com> writes:
> Erik Naggum <····@naggum.net> writes:
>
> > I am actually happy that you are so bemused that this beats daytime TV.
>
> To tell the truth, it doesn't.
I personally don't rank order them. I spend time here but I also
enjoy watching The Young and The Restless. Each has its recurrent themes,
its heros and villains, and its complex philosophical problems...
I guess you could say my day is just filled with programming of various
sorts. ;)
From: Duane Rettig
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <4wuw5dpns.fsf@beta.franz.com>
"Paul F. Dietz" <·····@interaccess.com> writes:
> 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.
OK, I see it now (although I think that the alist time is N+2).
The 2N load latency for the plist was the critical piece that I
was missing. I even had to draw myself a picture in order to
see it well. Perhaps it will help others to see my picture also.
What is critical is that the machine has the ability to do three
memory references at once.
Note that the picture has the same number of cons cells in each
list type, so you would think that parallel loads could be
done one both equally efficiently. However, given tN where N is
the ordinal of a best-case memory cycle, the best we would be able
to do go all the way through the 4-element plist (with a failure to
find anything) is the time it takes to get to key3 (k3) which occurs
at t7 (or 8 cycles). The alist could get k3 by t5 (or 6 cycles).
Note also that the alist is using all three loads at once, whereas
the plist is only doing two loads max at any one time. This
explains the experimental data that I and others got (although I
never posted any of my data). If the machine can only handle two
loads at once, there will be no difference in timings, because one
of the three tN loads for the alist will always be stalled.
t0 t1 t2 t3
----- ----- ----- -----
| | |->| | |->| | |->| | |
----- ----- ----- -----
| | | |
v t1 v t2 v t3 v t4
----- ----- ----- -----
|k0|v0| |k1|v1| |k2|v2| |k3|v3|
----- ----- ----- -----
t2 t3 t4 t5
plist:
t0 t1 t2 t3
----- ----- ----- -----
|k0| |->|v0| |->|k1| |->|v1| |-> ...
----- ----- ----- -----
t1 t2 t3 t4
t4 t5 t6 t7
----- ----- ----- -----
|k2| |->|v2| |->|k3| |->|v3| |
----- ----- ----- -----
t5 t6 t7 t8
Thanks for the great brain exercise, Paul.
--
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 ·····@Franz.COM (internet)
Duane Rettig wrote:
> What is critical is that the machine has the ability to do three
> memory references at once.
The algorithm I gave assumes that, but you can also design
an assoc algorithm under the assumption that only 2 loads
can be done at once that takes time 1.5 N + O(1). This is
left as an exercise for the reader. :)
> Thanks for the great brain exercise, Paul.
My pleasure, Duane. The practical importance is questionable,
but it is fun to think about.
More practically, I think this suggests that there might be impact
from load latency in lisp programs and that it could be worthwhile
for a lisp compiler to be smart about scheduling loads (maybe
a latency-aware peephole optimizer?)
Paul
From: Duane Rettig
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <47ko4ee0j.fsf@beta.franz.com>
"Paul F. Dietz" <·····@interaccess.com> writes:
> Duane Rettig wrote:
>
> > What is critical is that the machine has the ability to do three
> > memory references at once.
>
> The algorithm I gave assumes that, but you can also design
> an assoc algorithm under the assumption that only 2 loads
> can be done at once that takes time 1.5 N + O(1). This is
> left as an exercise for the reader. :)
I won't take you up on that one. However, I will note that
such an algorithm would require a minimum alist/plist length
in order to overcome the two-memory-load constant overhead
that the alist has for the final key.
Also worth noting is that if the first key is what was found,
there is no difference in the load latency; your theoretical
difference is based on _no_ keys being found at all. This
potentially reduces the practical speedup between the two
approaches, and how much the speedup is reduced depends on
the percentage of times a key is expected to be found when
an assoc or getf is performed. If the probability of finding
the key approaches 1, then the advantage of alists over plists
decreases. If the probability approaches 0, then we might
tend to switch to yet a different mapping technique which
provides a faster rejection of the key than searching through
a list.
--
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 ·····@Franz.COM (internet)
From: Paul Dietz
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3C9B6AE4.7BDA597@motorola.com>
Duane Rettig wrote:
> your theoretical
> difference is based on _no_ keys being found at all.
Or that the key is 'far' down the list (N then being
the position of the key in the key sequence.)
Paul
From: Duane Rettig
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <4bsdgeeq4.fsf@beta.franz.com>
"Paul F. Dietz" <·····@interaccess.com> writes:
> Duane Rettig wrote:
> > Thanks for the great brain exercise, Paul.
>
> My pleasure, Duane. The practical importance is questionable,
> but it is fun to think about.
Absolutely.
> More practically, I think this suggests that there might be impact
> from load latency in lisp programs and that it could be worthwhile
> for a lisp compiler to be smart about scheduling loads (maybe
> a latency-aware peephole optimizer?)
Far be it from me to turn down an optmization, but in fact the
disconnect between theory and measurement indicates to me that
this particuular theory operates close to the noise, and that
there are other optimizations that will get us much better
results than organizing the load latency, and these optimizations
should be done first. Optimizing GETF comes to mind; either via
rewrites or open-coding.
--
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 ·····@Franz.COM (internet)
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225783034450486@naggum.net>
* Duane Rettig
| What is critical is that the machine has the ability to do three memory
| references at once.
That is indeed a critical piece of information. I have reasoned based on
explicit prefetch instructions because the pipeline is not long enough to
_sustain_ three outstanding requests, especially considering the
destructive effect of taken branches on the pipeline, and considering the
amount of time it takes to fetch from external memory compared to the
on-chip L1 cache, which will hold the entire cons cell in the same cache
line, unles allocation is really screwed up. Unrolling loops has the
significant disadvantage that execution needs more memory references.
I have severe problems seeing how you can possibly achieve code with
three outstanding requests at all times. Not to mention the severe
shortage of registers on IA32. Are there any CPUs that can _actually_
achieve this? If none, it is an interesting exercise in How Things
Should Be, but not in optimizing code for real processors. Sadly, I am
far more interested in actual CPUs than imaginary ones, but since
acquiring a working knowledge of a processor family is pretty much
depth-first, I have only working knowledge of one current architecture,
and I am probably not up to speed on what IA32 can do, either. From what
I can find in the documentation, however, I am unable to write the code
for this architecture that will _actually_ achieve more than two
concurrent accesses to implement assoc (or my simplified alist-get) even
though the CPU is supposed to be able to handle four.
There are two obvious reasons for this: (1) memory accesses that end up
with a L1 cache hit are not worth optimizing further, and (2) if you have
grabbed one of the car and the cdr of a cons cell, the other access is
free. If you have to hit the L2 cache or worse, have to request it from
real memory, you still get a 64-bit unit back from the memory subsystem.
In other words, if you keep moving two cdrs ahead in a plist, the car is
there for free in a plist, whereas the alist must access both car and cdr
of the given cell. Yes, there is savings to be had in pipelining this,
but it has no practical edge over that in plists, because we are not
optimizing just the processor pipeline, we have to request the memory and
have something that takes some time to get, before this matters.
I sort of regret having to be incredibly concrete and low-level, but that
is where these things actually happen. It is very convenient to optimize
some abstract access model, but it has to be implemented and actually be
possible to generate instructions for it such that it actually matters.
I have yet to see that be true.
I guess what I keep saying is that optimizing for a real processor is not
some theoretical task that can ignore the actual processor.
You alluded to measurements that indicated a material difference, Duane,
and I would just love to see that and the code that produced it on
various processors.
///
--
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.
From: Duane Rettig
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <4g02sef3j.fsf@beta.franz.com>
Erik Naggum <····@naggum.net> writes:
> You alluded to measurements that indicated a material difference, Duane,
> and I would just love to see that and the code that produced it on
> various processors.
No, my reference to timing data was to times which did _not_ produce
a difference. I have not searched very hard, but have not yet found
the machine which produced a real difference. The timings were not
exact, but any differences were in the random noise area, actually
going in either direction (in one test, the getf loop was "faster").
This indicated to me that there was not enough iterations of the loop
to bring the resolution of the difference out of the range of the
noise.
I've done this many times before. Benchmarking is a black art,
and I still find that it is not understandable. I'll make a change
which I absolutely _know_ will give me speedups, and it slows down
instead. I've found that this kind of nonlinearity occurs most often
on sparcs, so I do not do benchmarking on sparcs anymore. [And this
is after taking register-window quantizations into consideration]
However, I do find that the exercises are worthwhile, not only to
hone my understanding about what optimizations are more important
than others, but also to understand the underlying workings of the
machines on which the code is running. And in the long run, it
does result in faster code.
--
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 ·····@Franz.COM (internet)
Erik Naggum <····@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
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225769957792533@naggum.net>
* 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.
Erik Naggum <····@naggum.net> writes:
> * 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.
Remember, we were in a make-pretend world. I said that.
(On real hardware, one would (of course!) not actually spawn a new thread. The parallel
work can be scheduled statically for a CPU with significant instruction-level
parallelism.)
> 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.
AFAIK, such hardware *does* exist. (But I am not an expert.)
> And that
> is not the memory in either L1 or L2 cache, right?
How do you know? Actually, the higher the load latency, the higher the potental
benefits.
> How many requests can
> the _memory_ pipeline from data that are going to be very close?
Well, that depends. On many machines it might well be that memory access will force
sequentiality.
> 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.
My guess is that benefits (albeit perhaps tiny ones) could be measured with lists
much shorter than 1 million entries.
> 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.
That may very well be. But one should not extrapolate from one crappy
architecture to all architectures.
> I think, however, that I have demonstrated exhaustively that there is no
> performance difference between alist and plist
... on one particular kind of hardware ..
> and that performance
> should never enter the picture when deciding which to use.
Actually, it should. The moment I'd think about performance,
I'd decide to use neither. :-)
Matthias
Paul Dietz wrote:
>
> 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.
(ian ponders for some hours)
So you're saying, for X being "here", the memory pattern of a-list
can go like:
(psetf car-x (car x)
cdr-x (cdr x))
(loop
(psetf caar-x (car car-x)
car-x (car cdr-x)
cdr-x (cdr cdr-x)))
> 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 of p-list can't be better than:
(psetf car-x (car x)
cdr-x (cdr x))
(setf cddr-x (cdr cdr-x))
(loop
(psetf car-x (car cddr-x)
cdr-x (cdr cddr-x))
(setf cddr-x (cdr cdr-x)))
Yes - you're right - I'd missed that extra bit of parallelism.
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225739029050571@naggum.net>
* "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.
Erik Naggum <····@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.
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> Erik Naggum <····@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.
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
?
From: Duane Rettig
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <41yedf67z.fsf@beta.franz.com>
···@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 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
> 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.
Yes, it does.
[Snip]
These are good points nonetheless. Here's the disassembly. I'll leave it
as an excercise for the reader to figure out which is which :-)
? (disassemble 'foo)
(TWNEI NARGS 0)
(MFLR LOC-PC)
(BLA .SPSAVECONTEXTVSP)
(LWZ NARGS 331 RNIL)
(TWGTI NARGS 0)
(LWZ ARG_Z 'L1 FN)
(LWZ ARG_Y 2 ARG_Z)
(TWEQI ARG_Y 51)
(LWZ ARG_Z 'H FN)
(SET-NARGS 2)
(LWZ TEMP3 'GETF FN)
(BLA .SPRESTORECONTEXT)
(MTLR LOC-PC)
(BA .SPJMPSYM)
? (disassemble 'baz)
(TWNEI NARGS 0)
(MFLR LOC-PC)
(BLA .SPSAVECONTEXTVSP)
(LWZ NARGS 331 RNIL)
(TWGTI NARGS 0)
(LWZ ARG_Y 'L2 FN)
(LWZ ARG_Z 2 ARG_Y)
(TWEQI ARG_Z 51)
(LWZ ARG_Y 'H FN)
(BLA .SPRESTORECONTEXT)
(MTLR LOC-PC)
(BA .SPBUILTIN-ASSQ)
? (time (dotimes (i 1000000) (foo)))
(DOTIMES (I 1000000) (FOO)) took 782 milliseconds (0.782 seconds) to run.
Of that, 11 milliseconds (0.011 seconds) were spent in The Cooperative
Multitasking Experience.
40 bytes of memory allocated.
NIL
? (time (dotimes (i 1000000) (baz)))
(DOTIMES (I 1000000) (BAZ)) took 241 milliseconds (0.241 seconds) to run.
NIL
?
E.
From: Duane Rettig
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <4sn6tdlln.fsf@beta.franz.com>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <·············@beta.franz.com>, Duane Rettig <·····@franz.com> wrote:
>
> > 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.
>
> Yes, it does.
>
> [Snip]
>
> These are good points nonetheless. Here's the disassembly. I'll leave it
> as an excercise for the reader to figure out which is which :-)
Looks like I guess'd good, heh?
> ? (disassemble 'foo)
[ ... ]
> (LWZ TEMP3 'GETF FN) <----------------
> (BLA .SPRESTORECONTEXT)
> (MTLR LOC-PC)
> (BA .SPJMPSYM)
> ? (disassemble 'baz)
[ ... ]
> (BA .SPBUILTIN-ASSQ) <----------------
> ? (time (dotimes (i 1000000) (foo)))
It's interesting, though, that the builting assoc function being
called is named *assq, which historically might imply :test #'eq
instead of the default :test #'eql. If you have supplied the list
to it as a constant alist, it could have implied that :test #'eq
was good enough, since all of the keys are symbols. I'm surprised,
though, that it didn't just unroll the loop inline. But perhaps it
would have if you had compiled with higher speed/safety ratio.
> (DOTIMES (I 1000000) (FOO)) took 782 milliseconds (0.782 seconds) to run.
> Of that, 11 milliseconds (0.011 seconds) were spent in The Cooperative
> Multitasking Experience.
> 40 bytes of memory allocated.
> NIL
> ? (time (dotimes (i 1000000) (baz)))
> (DOTIMES (I 1000000) (BAZ)) took 241 milliseconds (0.241 seconds) to run.
> NIL
So it seems like your test isn't checking against the potential speed
of assoc vs getf, but only the current default speed of the implementation,
probably due to optimizations for the Gabriel Benchmarks.
--
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 ·····@Franz.COM (internet)
Duane Rettig wrote:
> It's interesting, though, that the builting assoc function being
> called is named *assq, which historically might imply :test #'eq
> instead of the default :test #'eql. If you have supplied the list
> to it as a constant alist, it could have implied that :test #'eq
> was good enough, since all of the keys are symbols.
The key he was searching for was a symbol, so :test #'eq was
acceptable regardless of the keys in the alist.
Paul
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225784077592910@naggum.net>
* Duane Rettig
| It's interesting, though, that the builting assoc function being
| called is named *assq, which historically might imply :test #'eq
| instead of the default :test #'eql.
But (eql <whatever> <symbol>) is identical to (eq <whatever> <symbol>),
so there is no point in using assoc with eql when you know that you
search for something for which eql and eq are identical. I note that
Allegro CL in all versions I have cared to look at, collapse eql to eq
when the type of one of the operands is not of type number or character.
| If you have supplied the list to it as a constant alist, it could have
| implied that :test #'eq was good enough, since all of the keys are
| symbols. I'm surprised, though, that it didn't just unroll the loop
| inline. But perhaps it would have if you had compiled with higher
| speed/safety ratio.
Lispworks generally does not inline even car or cdr as I have seen it,
either, while Allegro CL makes them a single instruction. (Good job!)
| So it seems like your test isn't checking against the potential speed of
| assoc vs getf, but only the current default speed of the implementation,
| probably due to optimizations for the Gabriel Benchmarks.
It is instructive to see the cost of benchmarks affect program design by
almost "misrepresenting" the case for a particular design choice.
///
--
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.
From: Duane Rettig
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <43cysed6y.fsf@beta.franz.com>
Erik Naggum <····@naggum.net> writes:
> * Duane Rettig
> | It's interesting, though, that the builting assoc function being
> | called is named *assq, which historically might imply :test #'eq
> | instead of the default :test #'eql.
>
> But (eql <whatever> <symbol>) is identical to (eq <whatever> <symbol>),
> so there is no point in using assoc with eql when you know that you
> search for something for which eql and eq are identical. I note that
> Allegro CL in all versions I have cared to look at, collapse eql to eq
> when the type of one of the operands is not of type number or character.
Right. My surprise was why MCL would bother to note that all of the
key elements in a constant alist were symbols, but not opencode the assoc
into a loop.
A more likely scenario is that assq actually means (assoc ... test #'eql)
in this implementation. Since assq is a purely pre-CL name, and since
EQL is (I think) a CL-inspired concept, I would not be too surprised to
see a mapping of assq onto the EQL test, rather than to the EQ test.
The acid test would be to create an alist with bignum keys, and see
what code is generated (and whether it is correct, of course).
> | If you have supplied the list to it as a constant alist, it could have
> | implied that :test #'eq was good enough, since all of the keys are
> | symbols. I'm surprised, though, that it didn't just unroll the loop
> | inline. But perhaps it would have if you had compiled with higher
> | speed/safety ratio.
>
> Lispworks generally does not inline even car or cdr as I have seen it,
> either, while Allegro CL makes them a single instruction. (Good job!)
Thanks. Of sourse, this is not true on x86 under safe compilation, due
to the unfortunate fact that alignment traps are not taken, forcing us
to test for cons-ness in safe situations. For such cases, we call
5-instruction code segments "qcar" and "qcdr" to perform the necessary test
and do the load. A shame...
> | So it seems like your test isn't checking against the potential speed of
> | assoc vs getf, but only the current default speed of the implementation,
> | probably due to optimizations for the Gabriel Benchmarks.
>
> It is instructive to see the cost of benchmarks affect program design by
> almost "misrepresenting" the case for a particular design choice.
In some cases, it can in fact be harmful. If you want to climb a mountain,
one strategy might be to just climb upward. So up you go, higher and higher,
making good progress, until you get to the top of a hill. At that point,
you can see the mountain off in the distance, but now you have to actually
go _down_ in order to eventually go as high as possible and to thus get to
the mountaintop.
--
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 ·····@Franz.COM (internet)
Erik Naggum <····@naggum.net> writes:
> Lispworks generally does not inline even car or cdr as I have seen it,
> either, while Allegro CL makes them a single instruction. (Good job!)
Allegro CL is indeed in general better at optimizing than Lispworks,
and especially at giving the programmer the tools to direct
optimizations like :explain declarations, but this is a bit harsh.
At all but the highest safety setting, car is inlined.
CL-USER 21 > (defun foo (x)
(declare (optimize (safety 2)))
(car x))
FOO
CL-USER 22 > (compile 'foo)
FOO
NIL
NIL
CL-USER 23 > (disassemble 'foo)
204FFDBA:
0: 3B25BC150020 cmp esp, [200015BC] ; T
6: 7617 jbe L2
8: 80FD01 cmpb ch, 1
11: 7512 jne L2
13: 55 push ebp
14: 89E5 move ebp, esp
16: 89C7 move edi, eax
18: 89F8 move eax, edi
20: 83F810 cmp eax, 10
23: 7403 je L1
25: 8B40FF move eax, [eax-1]
L1: 28: FD std
29: C9 leave
30: C3 ret
L2: 31: E8DC33B4FF call 200431BA ; #<function 200431BA>
36: 90 nop
37: 90 nop
NIL
--
Lieven Marchand <···@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
Erik Naggum <····@naggum.net> writes:
> Lispworks generally does not inline even car or cdr as I have seen it,
> either, while Allegro CL makes them a single instruction. (Good job!)
In case anyone is left with the wrong impression, LW does too (that
was MCL Erann Gat was using, anyway).
--
Pekka P. Pirinen
GOOD ADVICE: Something old men give young men when they can no
longer give them a bad example. - Gideon Wurdz
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3226060945512680@naggum.net>
* Erik Naggum
> Lispworks generally does not inline even car or cdr as I have seen it,
> either, while Allegro CL makes them a single instruction. (Good job!)
* Pekka P. Pirinen
| In case anyone is left with the wrong impression, LW does too (that
| was MCL Erann Gat was using, anyway).
One does not need "impressions". Just grab a trial edition, compile some
test code with the appropriate declarations and disassemble. I was
fairly disappointed. Even CMUCL did better. Others may come to other
conclusions with different 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.
Erik Naggum <····@naggum.net> writes:
> * Erik Naggum
> > Lispworks generally does not inline even car or cdr as I have seen it,
> > either, while Allegro CL makes them a single instruction. (Good job!)
>
> * Pekka P. Pirinen
> | In case anyone is left with the wrong impression, LW does too (that
> | was MCL Erann Gat was using, anyway).
>
> One does not need "impressions". Just grab a trial edition, compile some
> test code with the appropriate declarations and disassemble. I was
> fairly disappointed. Even CMUCL did better. Others may come to other
> conclusions with different code.
I don't really read modern assembly code, alas, so I can't comment with
authority, but just so we're all on the same page, the following is from
LispWorks 4.2 Enteprise on a PC ... I certainly see some inlining here
if you set the SAFETY setting to 2, and even more if you set it to 0.
The problem is probably less that it's not doing an optimization and more
that both the default optimize settings vary among implementations, and also
that the _meanings_ of the optimize settings are not standard...
I'm a little leary of using trial editions as proof of what a commercial
implementation is capable of, btw.
CL-USER 31 > (disassemble #'(lambda (x) (declare (optimize (safety 3))) (car x)))
205F42DA:
0: 3B25BC150020 cmp esp, [200015BC] ; T
6: 760E jbe L1
8: 80FD01 cmpb ch, 1
11: 7509 jne L1
13: 55 push ebp
14: 89E5 move ebp, esp
16: C9 leave
17: E932443600 jmp 20958722 ; #<function SEQ::CAR-1ARG 20958722>
L1: 22: E8351DA5FF call 2004602A ; #<function 2004602A>
27: 90 nop
28: 90 nop
29: 90 nop
NIL
CL-USER 32 > (disassemble #'(lambda (x) (declare (optimize (safety 2))) (car x)))
20603512:
0: 3B25BC150020 cmp esp, [200015BC] ; T
6: 7613 jbe L2
8: 80FD01 cmpb ch, 1
11: 750E jne L2
13: 55 push ebp
14: 89E5 move ebp, esp
16: 83F810 cmp eax, 10
19: 7403 je L1
21: 8B40FF move eax, [eax-1]
L1: 24: FD std
25: C9 leave
26: C3 ret
L2: 27: E8F82AA4FF call 2004602A ; #<function 2004602A>
32: 90 nop
33: 90 nop
NIL
CL-USER 33 > (disassemble #'(lambda (x) (declare (optimize (safety 1))) (car x)))
20611232:
0: 3B25BC150020 cmp esp, [200015BC] ; T
6: 760E jbe L2
8: 55 push ebp
9: 89E5 move ebp, esp
11: 83F810 cmp eax, 10
14: 7403 je L1
16: 8B40FF move eax, [eax-1]
L1: 19: FD std
20: C9 leave
21: C3 ret
L2: 22: E8DD4DA3FF call 2004602A ; #<function 2004602A>
27: 90 nop
28: 90 nop
29: 90 nop
NIL
CL-USER 34 > (disassemble #'(lambda (x) (declare (optimize (safety 0))) (car x)))
205EDC32:
0: 55 push ebp
1: 89E5 move ebp, esp
3: 83F810 cmp eax, 10
6: 7403 je L1
8: 8B40FF move eax, [eax-1]
L1: 11: FD std
12: C9 leave
13: C3 ret
NIL
Greetings, Kent.
On Mon, 25 Mar 2002 17:03:13 GMT,
Kent M Pitman <······@world.std.com> wrote:
>
> I don't really read modern assembly code, alas, so I can't comment with
> authority, but just so we're all on the same page, the following is from
> LispWorks 4.2 Enteprise on a PC ... I certainly see some inlining here
> if you set the SAFETY setting to 2, and even more if you set it to 0.
Windows or Linux?
I pasted your examples into LW 4.2 on Linux running on a K7 and got
the same results, only the addresses of the jmp and call were different.
Now I am really curious, why the constant 200015BC in the first
cmp is the same in both cases...
Kent:
>
>
> CL-USER 31 > (disassemble #'(lambda (x) (declare (optimize (safety 3))) (car x)))
> 205F42DA:
> 0: 3B25BC150020 cmp esp, [200015BC] ; T
> 6: 760E jbe L1
> 8: 80FD01 cmpb ch, 1
> 11: 7509 jne L1
> 13: 55 push ebp
> 14: 89E5 move ebp, esp
> 16: C9 leave
> 17: E932443600 jmp 20958722 ; #<function SEQ::CAR-1ARG 20958722>
> L1: 22: E8351DA5FF call 2004602A ; #<function 2004602A>
> 27: 90 nop
> 28: 90 nop
> 29: 90 nop
> NIL
>
me:
> CL-USER 1 > (disassemble #'(lambda (x) (declare (optimize (safety 2))) (car x)))
> ; Loading fasl file /usr/lib/LispWorks/lib/4-2-0-0/modules/util/disass.ufsl
> ; Loading fasl file /usr/lib/LispWorks/lib/4-2-0-0/modules/memory/findptr.ufsl
> 206582AA:
> 0: 3B25BC150020 cmp esp, [200015BC] ; T
> 6: 760E jbe L1
> 8: 80FD01 cmpb ch, 1
> 11: 7509 jne L1
> 13: 55 push ebp
> 14: 89E5 move ebp, esp
> 16: C9 leave
> 17: E952CB4F00 jmp 20B54E12 ; #<function SEQ::CAR-1ARG 20B54E12>
> L1: 22: E8FDDA9EFF call 20045DC2 ; #<function 20045DC2>
> 27: 90 nop
> 28: 90 nop
> 29: 90 nop
> NIL
s.
--
Stefan Schmiedl
Approximity GmbH http://www.approximity.com
Research & Development ·············@approximity.com
Loreleystr. 5, 94315 Straubing, Germany
Tel. (0 94 21) 74 01 06, Fax (0 94 21) 74 01 21
shhhh ... I can't hear my code!
·@xss.de (Stefan Schmiedl) writes:
> Now I am really curious, why the constant 200015BC in the first
> cmp is the same in both cases...
> > 0: 3B25BC150020 cmp esp, [200015BC] ; T
The "; T" usually means that the literal constant there represents the
value of T. Since most Lisp implementations locate their heaps in the
same place in memory for the same architecture/OS, they can hardcode
those constants directly.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@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.
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3226090781415284@naggum.net>
* Kent M Pitman <······@world.std.com>
| The problem is probably less that it's not doing an optimization and more
| that both the default optimize settings vary among implementations, and
| also that the _meanings_ of the optimize settings are not standard...
The code I compiled looked like this:
(in-package :cl-user)
(declaim (optimize (safety 0) (speed 3)))
(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))
The declaim caused all other implementations to compile to the fastest
inline code they could. LispWorks still makes calls to cddr-1arg.
| I'm a little leary of using trial editions as proof of what a commercial
| implementation is capable of, btw.
Well, I think that if anyone purposefully crippled the compiler in the
trial edition, they would seriously have hurt their possibility of
getting new customers.
///
--
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.
·@xss.de (Stefan Schmiedl) writes:
> Greetings, Kent.
>
> On Mon, 25 Mar 2002 17:03:13 GMT,
> Kent M Pitman <······@world.std.com> wrote:
> >
> > I don't really read modern assembly code, alas, so I can't comment with
> > authority, but just so we're all on the same page, the following is from
> > LispWorks 4.2 Enteprise on a PC ... I certainly see some inlining here
> > if you set the SAFETY setting to 2, and even more if you set it to 0.
>
> Windows or Linux?
Windows
> I pasted your examples into LW 4.2 on Linux running on a K7 and got
> the same results, only the addresses of the jmp and call were different.
>
> Now I am really curious, why the constant 200015BC in the first
> cmp is the same in both cases...
Perhaps one is fixed early in the system build and doesn't follow the
conditional inclusion of system-dependent code the presence or absence
of which implicitly changes the magnitude of subsequent addresses?
I dunno. Just a guess... It's way below the level of abstraction at
which I usually prefer to hang around.
> Kent:
> >
> >
> > CL-USER 31 > (disassemble #'(lambda (x) (declare (optimize (safety 3))) (car x)))
> > 205F42DA:
> > 0: 3B25BC150020 cmp esp, [200015BC] ; T
> > 6: 760E jbe L1
> > 8: 80FD01 cmpb ch, 1
> > 11: 7509 jne L1
> > 13: 55 push ebp
> > 14: 89E5 move ebp, esp
> > 16: C9 leave
> > 17: E932443600 jmp 20958722 ; #<function SEQ::CAR-1ARG 20958722>
> > L1: 22: E8351DA5FF call 2004602A ; #<function 2004602A>
> > 27: 90 nop
> > 28: 90 nop
> > 29: 90 nop
> > NIL
> >
>
> me:
> > CL-USER 1 > (disassemble #'(lambda (x) (declare (optimize (safety 2))) (car x)))
> > ; Loading fasl file /usr/lib/LispWorks/lib/4-2-0-0/modules/util/disass.ufsl
> > ; Loading fasl file /usr/lib/LispWorks/lib/4-2-0-0/modules/memory/findptr.ufsl
> > 206582AA:
> > 0: 3B25BC150020 cmp esp, [200015BC] ; T
> > 6: 760E jbe L1
> > 8: 80FD01 cmpb ch, 1
> > 11: 7509 jne L1
> > 13: 55 push ebp
> > 14: 89E5 move ebp, esp
> > 16: C9 leave
> > 17: E952CB4F00 jmp 20B54E12 ; #<function SEQ::CAR-1ARG 20B54E12>
> > L1: 22: E8FDDA9EFF call 20045DC2 ; #<function 20045DC2>
> > 27: 90 nop
> > 28: 90 nop
> > 29: 90 nop
> > NIL
Duane Rettig <·····@franz.com> writes:
> I'm surprised, though, that it didn't just unroll the loop inline.
> But perhaps it would have if you had compiled with higher
> speed/safety ratio.
Since the Power(PC) series is an out of order execution architecture,
would loop unrolling really make that much of a difference? ISTR that
on the POWER3, gcc -O2 and gcc -O3 were nearly identical for all the
benchmarks I had available. But that's a POWER3, not a G3 or G4. :)
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@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.
From: Duane Rettig
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <4ofhgcru8.fsf@beta.franz.com>
Rahul Jain <·····@sid-1129.sid.rice.edu> writes:
> Duane Rettig <·····@franz.com> writes:
>
> > I'm surprised, though, that it didn't just unroll the loop inline.
> > But perhaps it would have if you had compiled with higher
> > speed/safety ratio.
>
> Since the Power(PC) series is an out of order execution architecture,
> would loop unrolling really make that much of a difference? ISTR that
> on the POWER3, gcc -O2 and gcc -O3 were nearly identical for all the
> benchmarks I had available. But that's a POWER3, not a G3 or G4. :)
My emphasis was intended to be on the inlining of the assq, not necessarily
the unrolling. As it is in the provided disassembled code, there is
a function call that could have been eliminated.
--
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 ·····@Franz.COM (internet)
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225771981784501@naggum.net>
* Duane Rettig <·····@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 access unless the lists are _really_
long, as in: _way_ beyond the threshold at which to switch to hashtables.
///
--
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.
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225772799804783@naggum.net>
* Erann Gat
> 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
* Duane Rettig
| We should look at this carefully, Erann. It is possible you are
| measuring the wrong thing here.
Not only that, but the "Cooperative Multitasking Experience" seems like a
fairly suspicious thing to include in such a test. One would hope that
at least a sufficient number of samples to produce statistically
significant results would have been included. (I seem to recall a lot of
noise about statistical significance.) The above really says nothing --
for all we know, the system could have been swapping like mad, and that
would be system time instead of user time, but such is not distinguished.
A suffiently large sample would have removed such unintended 'spikes"
from the data set.
///
--
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.
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
> Not only that, but the "Cooperative Multitasking Experience" seems like a
> fairly suspicious thing to include in such a test. One would hope that
> at least a sufficient number of samples to produce statistically
> significant results would have been included. (I seem to recall a lot of
> noise about statistical significance.) The above really says nothing --
> for all we know, the system could have been swapping like mad, and that
> would be system time instead of user time, but such is not distinguished.
> A suffiently large sample would have removed such unintended 'spikes"
> from the data set.
I ran it a couple of times and the results seemed pretty consistent, but
your point is well taken.
It turns out Duane was right and what I was really measuring was the
difference in implementation efficiency between the built-in getf and
assoc (which became blatantly obvious when I disassembled *those*.
Duh!). When I wrote my own the difference was much smaller, but
interestingly still there:
(DOTIMES (I 1000000) (MY-GETF L1 'H)) took 581 milliseconds (0.581
seconds) to run.
(DOTIMES (I 1000000) (MY-ASSOC 'H L2)) took 612 milliseconds (0.612
seconds) to run.
This is a small difference, but very consistent. I'm running with
interrupts off, and a dozen runs produced timing differences of no more
than +/- 1 ms.
Whether this difference is due to the effect that Paul is describing or
simply due to a compiler quirk is unclear. I obviously need more practice
reading disassembly listings.
E.
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225807274641011@naggum.net>
* Erann Gat
| It turns out Duane was right and what I was really measuring was the
| difference in implementation efficiency between the built-in getf and
| assoc (which became blatantly obvious when I disassembled *those*.
| Duh!). When I wrote my own the difference was much smaller, but
| interestingly still there:
To make this a useful basis of comparison, you should post the code, too.
I posted my code for alist-get and plist-get with optimized versions with
hand-tweaked expanded tagbodies.
| Whether this difference is due to the effect that Paul is describing or
| simply due to a compiler quirk is unclear. I obviously need more
| practice reading disassembly listings.
You will _never_ have the potential of stalling if you have so short
lists that they are all in level 1 cache. Optimizing the access pattern
of what is basically 16K of registers on the IA32, for instance, is a
major waste of time. I have found it useful to use lists of 1 million
key-value pairs for testing. to ensure that no caching can possibly
intervene and the cost of memory latency is predominant, which means you
can repeat the function 100 times without deterioration of maasurements.
///
--
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.
From: Duane Rettig
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <4wuw4cy9v.fsf@beta.franz.com>
···@jpl.nasa.gov (Erann Gat) writes:
> In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
>
> > Not only that, but the "Cooperative Multitasking Experience" seems like a
> > fairly suspicious thing to include in such a test. One would hope that
> > at least a sufficient number of samples to produce statistically
> > significant results would have been included. (I seem to recall a lot of
> > noise about statistical significance.) The above really says nothing --
> > for all we know, the system could have been swapping like mad, and that
> > would be system time instead of user time, but such is not distinguished.
> > A suffiently large sample would have removed such unintended 'spikes"
> > from the data set.
>
> I ran it a couple of times and the results seemed pretty consistent, but
> your point is well taken.
>
> It turns out Duane was right and what I was really measuring was the
> difference in implementation efficiency between the built-in getf and
> assoc (which became blatantly obvious when I disassembled *those*.
> Duh!). When I wrote my own the difference was much smaller, but
> interestingly still there:
>
> (DOTIMES (I 1000000) (MY-GETF L1 'H)) took 581 milliseconds (0.581
> seconds) to run.
> (DOTIMES (I 1000000) (MY-ASSOC 'H L2)) took 612 milliseconds (0.612
> seconds) to run.
>
> This is a small difference, but very consistent. I'm running with
> interrupts off, and a dozen runs produced timing differences of no more
> than +/- 1 ms.
>
> Whether this difference is due to the effect that Paul is describing or
> simply due to a compiler quirk is unclear. I obviously need more practice
> reading disassembly listings.
Interestingly, this is actually the opposite of Paul's effect, which is
that assoc should be faster. I posted elsewhere about mitigating effects
of the theory, incluuding whether or not you are actually looking for a key
which is contained in the list or not. I suspect that you are looking for
a key which is present, and that your numbers might change if you look
for a non-present key instead.
Also, you didn't post your actual hand-coding, so we can't comment on
possible explanations for the results you see.
--
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 ·····@Franz.COM (internet)
"Kent M Pitman" <······@world.std.com> wrote in message
····················@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.
From: Paul F. Dietz
Subject: Re: Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?])
Date:
Message-ID: <3C9A8338.DCD81DAC@interaccess.com>
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
From: Erann Gat
Subject: Re: Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?])
Date:
Message-ID: <gat-2103021919460001@192.168.1.50>
In article <·················@interaccess.com>, "Paul F. Dietz"
<·····@interaccess.com> wrote:
> 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.
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.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@192.168.1.50...
> 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.)
The original figures I posted were for iterating down to the
9th and 10th items of an 11 element a/p-list.
I spent a little bit of time making a longer list, but I've found
that the time spent is *extremely* hard to measure to any
accuracy whatsoever. I think I'll waste some more time today
attempting to measure it.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@192.168.1.50...
> 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.)
Here are some more numbers.
In these tests, the alist or plist was 1001 key/value pairs.
The symbol a was the 500th key, the symbol b was the 1000th key.
The lists were `tenured' and a `full gc' was performed before
each test.
A `lookup test' involved turning off interrupts, performing
1000 lookups of the key (to `precondition' everything), then
recording the start time, performing 100000 lookups of
the key, recording the end time, then dividing the time
difference by 100000.
Each `algorithm test' would perform thirty five lookup tests
for the symbol b, then thirty five lookup tests for the
symbol a. The first ten of each of these sets was discarded.
The best time from the remaning twenty-five was selected.
The best time to lookup symbol a was subtracted from the
best time to lookup symbol b giving the amount of time to
traverse from key a to key b. This result was divided
by 500 to give an estimate of how long it takes to get
from one key to the next.
The results varied by a few percent.
alist-get: 72ns per iteration
plist-get: 54ns per iteration
alist-get-expand: 43ns per iteration
plist-get-expand: 52ns per iteration
Conclusions?
1. Alists *might* be a tad faster than plists, but
then again, the improvement is very close to the
error margin.
2. The test is unrealistic in that it is against
alists and plists at least an order of magnitude
larger than those typically used.
3. To recoup the time I spent analyzing this, I
would have to perform 4 trillion alist lookups
in situations where plist lookups would have
been used.
4. I have too much time on my hands.
You may discuss this amongst yourselves.
From: Christopher Browne
Subject: Re: Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?])
Date:
Message-ID: <m3vgboig9f.fsf@chvatal.cbbrowne.com>
Centuries ago, Nostradamus foresaw when "Joe Marshall" <·············@attbi.com> would write:
> 3. To recoup the time I spent analyzing this, I
> would have to perform 4 trillion alist lookups
> in situations where plist lookups would have
> been used.
That certainly fits in quite nicely with the essay _Optimization: Your
Worst Enemy_ <http://www.pgh.net/~newcomer/optimization.htm>.
On the one hand, if the discussion has led to 'entertainment' and to
people better understanding their systems, that's not a particularly
bad thing.
What is really fortunate is that the result of this _isn't_ that of
someone commending adding in an operation that would risk systems
getting less reliable (new code might be broken) whilst being highly
unlikely to be recouped in improved performance.
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/lsf.html
When sign makers go on strike, is anything written on their signs?
From: Thomas F. Burdick
Subject: Re: Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?])
Date:
Message-ID: <xcvg02swe0p.fsf@conquest.OCF.Berkeley.EDU>
Christopher Browne <········@acm.org> writes:
> Centuries ago, Nostradamus foresaw when "Joe Marshall" <·············@attbi.com> would write:
> > 3. To recoup the time I spent analyzing this, I
> > would have to perform 4 trillion alist lookups
> > in situations where plist lookups would have
> > been used.
>
> That certainly fits in quite nicely with the essay _Optimization: Your
> Worst Enemy_ <http://www.pgh.net/~newcomer/optimization.htm>.
>
> On the one hand, if the discussion has led to 'entertainment' and to
> people better understanding their systems, that's not a particularly
> bad thing.
>
> What is really fortunate is that the result of this _isn't_ that of
> someone commending adding in an operation that would risk systems
> getting less reliable (new code might be broken) whilst being highly
> unlikely to be recouped in improved performance.
Right, so long as everyone involved knows that silly
micro-optimization is just a hobby enjoyed by many programmers, it's
all good: no one's time was wasted, because they were doing it for
fun, not work; and no one's work code was jeapordized because, again,
this was fun, not work.
I wish I'd had enough time to engage this thread, because this is
exactly the sort of nonsense I find fun. I was also happy to find
that I'm not the only one who finds SPARCs utterly impossible to
benchmark on.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Raymond Toy
Subject: Re: Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?])
Date:
Message-ID: <4nlmckqq3q.fsf@rtp.ericsson.se>
>>>>> "Thomas" == Thomas F Burdick <···@conquest.OCF.Berkeley.EDU> writes:
Thomas> I wish I'd had enough time to engage this thread, because this is
Thomas> exactly the sort of nonsense I find fun. I was also happy to find
Thomas> that I'm not the only one who finds SPARCs utterly impossible to
Thomas> benchmark on.
What makes Sparcs so bad? I use Sparcs all the time, but I don't
normally need this kind of extra fine timing info.
Ray
From: Thomas F. Burdick
Subject: Re: Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?])
Date:
Message-ID: <xcv663jro3e.fsf@apocalypse.OCF.Berkeley.EDU>
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "Thomas" == Thomas F Burdick <···@conquest.OCF.Berkeley.EDU> writes:
>
> Thomas> I wish I'd had enough time to engage this thread, because this is
> Thomas> exactly the sort of nonsense I find fun. I was also happy to find
> Thomas> that I'm not the only one who finds SPARCs utterly impossible to
> Thomas> benchmark on.
>
> What makes Sparcs so bad? I use Sparcs all the time, but I don't
> normally need this kind of extra fine timing info.
Oh, I love SPARCs, but I just have a hell of a time constructing
benchmarks for them. I'm not sure what the cause is, but I've noticed
that if I micro-optimize the assembly language produced by, say, GCC
-- in a way that I'm 95% sure should make it faster -- I can't always
construct benchmarks that show a speed up. Sometimes I see a slow
down. When I put the hand-optimized code back into the application I
pulled it out of, the application will speed up. I just figured there
was something wrong with my brain wrt SPARC benchmarking (which could
still be true), but I was sort of comforted to see that Duane has a
similar problem. This doesn't happen to me on IA-32 (I really hope my
brain hasn't been wired for that horror of an architecture!).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Rahul Jain
Subject: Re: Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?])
Date:
Message-ID: <87d6xr2d35.fsf@photino.sid.rice.edu>
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Oh, I love SPARCs, but I just have a hell of a time constructing
> benchmarks for them. I'm not sure what the cause is, but I've noticed
> that if I micro-optimize the assembly language produced by, say, GCC
> -- in a way that I'm 95% sure should make it faster -- I can't always
> construct benchmarks that show a speed up. Sometimes I see a slow
> down. When I put the hand-optimized code back into the application I
> pulled it out of, the application will speed up.
Maybe this has to do with cache effects. Since there's no reordering
in SPARC, it should be horribly sensitive to cache misses (which,
incidentally, is what Intel seems to be most concerned about with the
IA-64, explaining their elaborate and awesome cache design for the
McKinley). Cache behavior should change pretty significantly between
microbenchmarks and real-world code, so I wouldn't be too surprised if
that were the case.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@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.
Thomas F. Burdick answered Raymond Toy thusly:
> > What makes Sparcs so bad? I use Sparcs all the time, but I don't
> > normally need this kind of extra fine timing info.
>
> Oh, I love SPARCs, but I just have a hell of a time constructing
> benchmarks for them. I'm not sure what the cause is, but I've noticed
> that if I micro-optimize the assembly language produced by, say, GCC
> -- in a way that I'm 95% sure should make it faster -- I can't always
> construct benchmarks that show a speed up....
SPARCs are very sensitive to instruction alignment. I don't know
whether the alignments that matter have to do with the instruction
buffer, instruction cache, or branch target, or (probably) all
three, but I have noticed that inserting nop instructions in front
of a tight loop can make it run as much as 2.5 times as fast (or
as slow).
As a compiler writer, I used this alist/plist example as a micro-
benchmark to see how much effort I should put into instruction
scheduling for the SPARC. I wrote two versions of the linear
search for both alists and plists. The first version is a trivial
translation of Erann Gat's code into Scheme. The second versions
were pipelined by hand. When compiled to unsafe code by Twobit,
both of the simple versions execute 10 SPARC instructions per
iteration, both pipelined versions execute 12, and all versions
execute 3 loads per iteration.
I timed all four versions on each of two benchmarks. The first
benchmark (1000000x1000) performs one million fruitless searches
of a list with 1000 entries (i.e. 2000 elements in the plist),
which presumably fits within the primary data cache. The second
benchmark (1000x1000000) performs 1000 fruitless searches of a
list with one million entries, which presumably does not fit
within any data cache. I ran these benchmarks on a SunBlade 100
with no other users; I think it clocks at about 400 MHz. The
results, in seconds (i.e. nanoseconds per entry searched):
1000000x1000 1000x1000000
alist 36.2 137.3
alist (bummed) 26.3 133.3
plist 16.7 74.4
plist (bummed) 12.8 72.6
These timings are the average of three runs, with no more than
0.2% deviation from the mean for 1000000x1000, and with no more
than 3.3% deviation for 1000x1000000.
Now, to give you an idea of how sensitive the SPARC is to
instruction ordering, here are the timings on that same machine
for a different but equally good Scheme compiler:
1000000x1000 1000x1000000
alist 19.6 79.8
alist (bummed) 21.6 70.4
plist 29.0 77.3
plist (bummed) 23.0 72.7
I won't post the Scheme or SPARC code here, but for the next
few weeks you can view them at
http://www.ccs.neu.edu/home/will/Twobit/assoc.sch.txt
http://www.ccs.neu.edu/home/will/Twobit/assoc.sparc.txt
Will
From: Kent M Pitman
Subject: Re: Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?])
Date:
Message-ID: <sfwy9glbcv0.fsf@shell01.TheWorld.com>
"Paul F. Dietz" <·····@interaccess.com> writes:
> 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.
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.
From: Peter Lewerin
Subject: Re: Alists faster than plists? (was: data hygiene [was: Why is Scheme not a Lisp?])
Date:
Message-ID: <3C9B1714.7070706@swipnet.se>
> It appears that reality agrees with Erik.
I nominate this the canonical reluctant statement of c.l.l.
;-)
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.
From: Thomas Bushnell, BSG
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <87it7sch3r.fsf@becket.becket.net>
Bob Bane <·····@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.
·········@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 -=- ············@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.
"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
From: Andreas Eder
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <m3lmcl2l36.fsf@elgin.eder.de>
·········@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�s my $HOME.
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225483324695497@naggum.net>
* 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.
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225350191898070@naggum.net>
* 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.
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>"))
From: Thomas Bushnell, BSG
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <87it7v2k0n.fsf@becket.becket.net>
Paul Foley <·······@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
In article <··············@mycroft.actrix.gen.nz>,
Paul Foley <·······@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
·········@becket.net (Thomas Bushnell, BSG) writes:
> Janis Dzerins <·····@latnet.lv> writes:
>
> > ·········@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.
From: Thomas Bushnell, BSG
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <87y9gp7mwq.fsf@becket.becket.net>
Kent M Pitman <······@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.
Kent M Pitman <······@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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225349798667164@naggum.net>
* 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.
Erik Naggum [on scheme macros]
> 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".
where does it say that?
oz
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3226396942345543@naggum.net>
* ··@cs.yorku.ca (ozan s. yigit)
| where does it say that?
Let me know when you start to think, again.
///
--
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.
Erik Naggum:
> | where does it say that?
> Let me know when you start to think, again.
answer the question. if you need references to help you figure out what
you are talking about, i can give you pointers.
oz
·········@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).
From: Thomas Bushnell, BSG
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <873cyyetsg.fsf@becket.becket.net>
Kent M Pitman <······@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
·········@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 -=- ············@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.
·········@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.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@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
·········@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 <···@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
From: Thomas Bushnell, BSG
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <87pu23n02r.fsf@becket.becket.net>
Lieven Marchand <···@wyrd.be> writes:
> ·········@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
From: Erik Naggum
Subject: Re: data hygiene [Re: Why is Scheme not a Lisp?]
Date:
Message-ID: <3225240324630811@naggum.net>
* 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.
Kent M Pitman <······@world.std.com> writes:
> Rahul Jain <·····@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 -=- ············@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.
Kent M Pitman <······@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?
--
<·······@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>
Bruce Lewis <·······@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 -=- ············@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.
Bruce Lewis <·······@yahoo.com> writes:
> Kent M Pitman <······@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.
Rahul Jain <·····@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!
* Doug Quale <······@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.
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.