Did anything happen to Euclidean geometry because of this re-evaluation?

  Or did the development of non-Euclidean geometries prove useful in ways
  that did not impact the remainder of Euclid's The Elements _at_all_?  Was
  it not one of the amazingly interesting features of non-Euclidean
  geometry that it did _not_ contradict or have a stupid quarrel with the
  rest of his work?

  So why are you still here when you should be in comp.lang.dylan extolling
  the features of non-<whatever> Lisps?  Who do you think cares?  Invite
  Lisp people to your own very low-traffic forum to discuss this with you,
  rather than annoy people with your repetitive nonsense, OK?  Or are you,
  as I now strongly suspect, only posting in comp.lang.lisp because you
  think Lisp people should be "converted" to Dylan because nobody else are?

  By the way, what you call "axiom" is called "postulate" in Euclid because
  of the distinction that Aristotle drew between the two concepts.  But I
  suppose you do not recognize Euclid's The Elements as authoritative on
  what Euclid said, either.  "It is so because Euclid said so" seems to be
  an invalid argument to you, but I am afraid that I have no "logical"
  answer that I expect will sate your desire for pathological nonsense.

How could criticism of Lisp in general and CL in particular be possibly
considered criminal? That is ridiculous. Criticism and discussion is hardly the
violation of any "law".

The only possible crime that could occur in the context of CL is to implement a
language that does not conform to the standard and then call it Common
Lisp. There are no other "laws" that could be violated.

When debating the merits of a language, however, anything goes, especially in a
usenet group.

Ideally, smart people who disagree about important issues offer criticisms.
Rebuttals are returned. In the ensuing debate the various tradeoffs are
realized and understood, and everyone is that much wiser, even if their
positions are not necessarily changed.

Andreas's real crime here seems to be 1) that he is into Dylan, 2) thinks it's
in the Lisp family, and 3) has the audacity to criticize your favourite
language.

Where *else* can he discuss Lisp's shortcomings in a meaningful manner? The
people who can most intelligently correct the error of his ways hang out here.

People have already explained that

  1) There is already a large community who think it's a feature, not
     what you condescendingly call a "design rule violation"

  2) A lot of these people are very smart

  3) They've already given you examples of the idioms which are natural
     in CL to "differentiate between valid and invalid results".

So what remains?  It still looks like, to me, that it's a different way
of doing things than you're used to, so you immediately conclude it's bad.

One thing you'll learn, if you persevere with CL, is that some of the
brightest minds ever to touch a keyboard have contributed to its design,
directly or indirectly (i.e. via historical accidents).

I've learned that, when I read CLtL2, if I don't understand something,
or think I disagree with something, I need to look harder, because it
is almost certainly _I_ who is missing something.

I suggest you adopt that attitude for a couple of years, write lots of
code, and _THEN_ come tell this newsgroup why nil == () is bad in
real day-to-day CL usage, AND what you propose is better.

Who knows?  You just _might_ be a genius, come up with a great innovation,
and get the language changed.

Are you saying that you're brighter than Moon?

--
Janis Dzerins

Also, Steele, for example, designed Scheme first and then CL.  Was CL a
rejection of Scheme for him?  Was his later work with C++ a rejection of CL?
Was his later work with Java a rejection of C++?  I suspect some of the
answers here are "yes" and some "no", but I wouldn't know without asking him.
I point it out to say that the single-bit of information represented in
the yes/no answer to the question "used to work with X now works for Y?"
is not the same as the single-bit of information represented in the statement
"has rejected all aspects of X for Y".  I quote (or is it paraphrase, since
I'm not sure I have an exact wording that I think is best)
Pitman's Two-Bit Rule: when representing two bits of information,
use two bits to do it.

Further, as I have pointed out many times before, there is no "good/bad"
distinction in the abstract.  Good and bad are dictated by context.  When
you make a new language, you make a new ecology.  What is good and bad
in that new ecology is what makes sense there in context.

That's the reason that the apparent kludge of ()/#f being the same works in
CL.  Tons of other decisions are of similar kind.  NIL's are padded out for
return values where not supplied.  NIL can be car/cdr'd.  We use type
"designators" all over where other languages would use raw types only.
There is a certain design consistency here that is underappreciated, and that
I hoped to highlight in the spec when I invented the designator concept
where previously there had been only "a lot of special cases".  Just because
people are bad at articulating it doesn't mean they are stupid.  

And saying
 (when foo ...)
is not the same as saying
 (when (not (null foo)) ...)
at the intention level.  It carries a subtlely different connotation for
some of us.  The former, to me, asks "if there is a foo" and the latter asks
"if there foo is not empty".  These are represented the same in CL, but I
prefer the expressional sense of the former.  In my mind, when a list goes to
empty, I like to think of it as not existing.  I don't think of it as existing
but empty.  It works out programmatically nicely to have the two be the same.
It's fine for people to think otherwise, but it's not fine for them to pretend
that the language doesn't intend to support my way of thinking.

If you really want a language with no ability to pun on types, I
really do suggest Scheme.  Not just because it makes this decision
differently (or "right", if you prefer to say that) but because its
community will reinforce in you the notion that this is the only
possible legitimate point of view, and give you a generally warm sense
of fuzzy that you have come home.  Its leaders will also make it a
priority to ruthlessly seek out lurking places where anyone is punning
for convenience and to callously shun such people, and that will
probably make you feel good about your leaders and the community they
have created.  And that's WHY we have separate political parties, er,
languages.  Because people want different things.  In this political party,
we tolerate diverse points of view.  You can write (not (null x))
and I can write x.  We both know what each other means.  And our code
interacts.  If you don't like that, and prefer to interact with people
who agree with you that only one point of view is possible, then this is
not the language for you.  It will not just frustrate you on this point.
It will frustrate you on a whole host of issues where the design style
has been of similar character.

I'll refrain from judging this.

Andreas

--
Janis Dzerins

We want to be able to use the *same* subtle connotation for data types
other than lists without somehow bringing in an implicit assumption that
a list is a valid value where you want to convey the idea that something
is either a string or doesn't exist, or is either a number or doesn't
exist, or is either a hash table or doesn't exist.

It is an invalid debating tactic and I totally reject implications based
upon it.

Whether particular things are good or bad should be decided on the basis
of logic, not on the basis of argument from authority.  Of course that
becomes difficult when you explicitly reject logic, as Erik just did.  I
don't know what that leaves, other than tradition and accident.

Implementation doesn't need to be easy, just possible.

Indeed, the whole point of an implementation is to centralize hard things
so that they are done only once.  Easy things don't need centralization.

I am one of the "authors" (such as we are) of the Revised Report on
Scheme.  I've participated in the meetings.  The "freedom" is not left
there for implementors, as far as I've ever been able to tell.  The
Scheme designers rarely discussed implementation beyond "is it
possible".  The freedom is there because the designers, as a group at
least, though there are individual exceptions and I like to claim I'm
one of them, have a phobia about the spec being too long, regardless
of whether that makes the spec "more useful".  As to "more useful", we
once had a discussion in the design committee in which some people
hinted that if the spec were more useful, the issue of usefulness
might cause control of the language to be taken from the committee and
put in the hands of users, who had a vested stake in the outcome.
That is, that the usefulness of something causes design principles to
be sacrificed and is the road to disaster.  Further, the committee
has, when it has spoken at all, which isn't much recently, expressed
considerably more interest in the issue of book compatibility than
implementation compatibility.  To put that in the bluntest of terms,
individuals on the committee have sometimes even gone so far as to say
that their focus has been on preserving the right of people who
disagree about how to write Scheme textbooks to assert what they like
without trampling one another.

I think CLTL was a similar stage of language evolution to Scheme.  It
was an attempt to make the words span the gap between differing
implementations, hoping that by leaving enough things unspecified, you
could make a lot of disparate behaviors conforming.  The CL community,
at any rate, decided this was not acceptable, and demanded that things
be made more compatible, that things left unspecified be made possible
to test for, etc.  We could have left things like evaluation order, or
the order of certain class precedence lists in classes created by
DEFCLASS, unspecified.  But that would have just hurt users in the
name of "implementation flexibility".

Language design is not about pleasing implementors.  (Just as "raising
kids" is not about "pleasing parents".)  There is a primary task to be
accomplished which drives, or ought to drive, the goodness of the
result.  Users of a language are not, or ought not be, secondary to
the process.  They are why we have languages.

Whatever one thinks of the NIL/false pun, one can hardly accuse it of
being there for "implementor convenience".  It was put there because some
users wanted it.  Some of us wish there were more such, not fewer such.
I really like the way it works in MOO, with "", #(), and errors being false,
too.  I definitely regard that the language would be poorer for my needs
if we moved away from such overlap instead of toward it.  

  From Steve Strassmann
  Date: 1992-06-25
  Subject: RE: MCL Framework & Directions
  [...]

  MCL and Dylan are two very different products, and are expected to fill
  the different needs of two very different communities. [...]
  [...]

  Dylan, however, is not aimed at the Lisp market. It's aimed at the
  current market for static languages. We would definitely consider Dylan
  a failure if it only stole support from the lisp community and had no
  impact on the rest of the world. We think there are compelling reasons
  for a static programmer to seriously consider switching to Dylan, and
  we'll do everything we can to get them to do so!

[Note the last line.]

abe

I think in a way a designer is a potential implementor, so he's often
in the same position.

[lots of stuff I completely agree to snipped]

Andreas

ASSOC, FIND and friends are annoying, as (agreeing with Paul Graham)
it is somewhat annoying to have separate abstractions for table
lookups.

This is somewhat strange and an oversight in view of the fact that
GETHASH does the right thing.  It accepts a default and returns two
values.

Cheers

But in answer to your question, no, the (FALSE-OR type) thing moves
in the wrong direction.  It IS a useful technology for places where it
was not possible to find a degenerate element within the set.

For example, had () and NIL and #f been all separate to start, I could
imagine arguing to make () false, just as I have noted that I'd be
happy if "" was false and #() was false.  However, I can't imagine
that a priori, I'd argue that (intern "NIL") should result in a false
value.  Absent history, I can't make a huge case that any given symbol
should be false.  So in a world where those were split, and where I
had no memory of this world, I think I'd argue that (FALSE-OR SYMBOL)
was the right way to talk about the union of boolean false and the
symbols, since the choice of any one symbol as a degenerate case
(absent a historical basis, as with Lisp) would be unfair in
Internationalization terms, if nothing else.  And certainly if I were
telling you to merge a faluse value with some random number seed, I
wouldn't try to figure out what a degenerate seed was so that I could
argue it should be false.  I'd just say (FALSE-OR RANDOM-STATE).

But there are places where there are natural nulls, and lists and
arrays (including, of course, strings) are among them.  I don't feel a
need for an extra type in a great many situations.  This is evident in
the number of applications that do (PUSH X (GETHASH A B)) where they
don't check to see if (GETHASH A B) returns NIL, NIL or NIL, T because
it doesn't matter to them.  Good language design is not done by
randomly changing a feature but by doing feature changes in
coordinated sets. So if we could declare a hash table of integers,
there might be cases where people usefully did (INCF (GETHASH A B))
without having to initialize (GETHASH A B) because they would know
that (GETHASH A B) would return 0, NIL when there was no element or 0,
T when an element had been set to 0.

Also, in languages where you have more than one false, you can choose
to do (EQ value 'particular-false-value) and to treat the other values
differently.  So you might want the type (AND (MEMBER NIL) type)
even though (FALSE-OR type) might mean the same thing.  It wouldn't
capture the intent I'm looking for.  

  It is a metaphor, intended to show a particular attitude that has an
  exact parallel in the real world.  Grow a clue, now.

| Andreas's real crime here seems to be 1) that he is into Dylan, 2) thinks
| it's in the Lisp family, and 3) has the audacity to criticize your
| favourite language.

  Nonsense.  He speaks of what he does not know.  He also criticizes with
  no intention of resolving anything.  Common Lisp is not being designed at
  this time, and these things are so fundamental that there is no way his
  criticism can possibly stop, because they are not going to change.  There
  is no way this person is going to cease his complaints, because he will
  never be satisfied.  Why do you defend such people and activities?

| Where *else* can he discuss Lisp's shortcomings in a meaningful manner?
| The people who can most intelligently correct the error of his ways hang
| out here.

  No, the error of his ways is that he thinks that a newcomer to town
  should be _respected_ for disagreeing with the prevailing customs for no
  better reason than that they are different where he came from.  This is
  fantastically stupid in real life, too, and has a name: "an obnoxious
  tourist".  There is no confusion or error that anybody else can fix.

  But they designed a new language and set up a new community for it!  They
  did _not_ hang around in the Common Lisp community and whine about it.

| Are you saying that you're brighter than Moon?

  Please think about what you are _actually_ saying.

  _I_ assume that Guy L. Steele is a very smart _professional_ and is not
  married to any of the languages on which he has worked.  Actually, I do
  not expect a _personal_ attachment from any seriously good Common Lisp
  programmer.  There are personal _values_, but they can and should be
  approached professionally, because one cannot always get what one wants,
  and it is incredibly stupid to whine for decades about something you did
  not get that was personal to you.

  The distinction between personal and professional seems to be lost on
  some people.  They tend to get into problems when they are required to be
  professional and detach personally.

| That applies in both directions, though you wouldn't know it to read
| many of the replies to myself and Andreas here.

  Of course you are the judge of this, because you have already made up
  your mind and you also get personal about it, so you are prevented from
  seeing the _professionalism_ in the replies you get.

| And Andreas and I have much the same subtly different connotation.  The
| only real difference is that we think that perpetuating the old "the
| list is the fundamental datastructure in Lisps" myth is doing the Lisp
| community (of which we are a part) a disservice.

  Why have you decided to find converts in comp.lang.lisp?  This looks more
  and more like a personal mission.  Invite those who want to discuss this
  stupid shit with you to comp.lang.dylan.  It does not look like anybody
  would disturb anyone.

| We want to be able to use the *same* subtle connotation for data types
| other than lists without somehow bringing in an implicit assumption that
| a list is a valid value where you want to convey the idea that something
| is either a string or doesn't exist, or is either a number or doesn't
| exist, or is either a hash table or doesn't exist.

  Why do you want to do this in Common Lisp when you have your perfect
  little toy language Dylan that gets it right?  Is this how you idiots
  think that people will choose Dylan?  Insult the best language on earth,
  take criticism personally, be obnoxiously obtuse and do not get the
  point, then give them Dylan in shining armor as the answer.  Good luck.

| Scheme is way too limiting.  We've got far more in common with CL than
| we have with Scheme.  Scheme isn't even an option any more than Jensen &
| Wirth Pascal is an option.

  Why do you have this desire to have things in common with other people?
  That looks like personal insecurity to me.  Is not Dylan enough for you?
  Do you need to reach out and find people to disagree strongly with just
  to feel you have something in "common" with them that you do not focus
  on?  If you have so much in common with somebody, why spend your time
  carping about differences?

  None of this makes any _sense_.  I believe you are just trolls from a
  community that has no future and then you attack the closest competitor
  you think you can annoy into supporting you.

| Funnily enough I know this.  The point of my making this remark is that
| this is *exactly* the tactic that has been used against myself for some
| time, and is now being used against Andreas in, for example, Alain's
| message.

  You still have not figured out that there is a difference between people
  who made up their mind to be outsiders and those who have not.  Please do.

| Whether particular things are good or bad should be decided on the basis
| of logic, not on the basis of argument from authority.

  What kind of idiot _are_ you?  Geez, do you even _believe_ this crap?
  Good and bad _are_ arguments from authority, you annoying little shit.
  If you think logic helps, consider this: The premises on which you base
  your "logic" eventually turn into arguments from authority, no matter
  where you start.  Why is this?  Good and bad do not exist in nature.
  There is no absolute test for goodness or badness out there that is
  independent of people.  Do you think there is, Bruce Hoult?  Do you think
  if you research long enough, you will find elemental particles of good
  and bad that can form the basis of a logic that all people can agree on?

  Good and bad are the results of people who want to live together.  This
  means they _have_ an authority higher than themselves which they accept.
  It can be some funny deity or it can be the fuzzy "community" or it can
  be a set of law and lots of strange things, but people happen to agree on
  what good and bad should be considered in _reference_ to.  A standard of
  ethics, in the non-technical meaning of "standard" _is_ an authority.
  Those who reject it are considered _bad_guys_ in that community.  We have
  a standard for a language that we accept and those who keep quibbling
  over it and when there is no possible way it could ever stop, because
  there is no possible way to change what they keep carping about for no
  good reason are _bad_guys_ to this community.

| Of course that  becomes difficult when you explicitly reject logic, as
| Erik just did.  I  don't know what that leaves, other than tradition and
| accident.

  I just rejected logic?  I reject logic as the proper means to resolve
  ethical problems.  Does that mean I reject _logic_?  You really _are_
  quite insane.  If someone says I should use classical mechanics to learn
  to drive a car, and I think this is inappropriate even though there are
  many elements of mechanics (including the pun) in driving cars, do I
  reject classical mechanics?  Or do I reject its _application_?

  For someone who thinks logic is so great a univeral problem-solver, you
  sure have a funny way of arriving at _your_ conclusions.

This discussion made me wonder about the status of ASSOC and FIND, and
what would mean to "change the standard".

CLHS reports:

find item sequence &key from-end test test-not start end key => element
assoc item alist &key key test test-not => entry
gethash key hash-table &optional default => value, present-p

Do you think it would be too much of a change to request the
vendors/implementors to change the behavior of the implementation in
such a way that

find item sequence &key from-end test test-not start end key default => element, present-p
assoc item alist &key key test test-not default => entry, present-p

(Of course a better writeup is necessary).

Also, what could be an "agreed upon and simple" machinery such that
all the implementations could check for this "extension"?

Cheers

He is only talking for Christ's sake. Debunk him or ignore him.

  I think a new package named COMMON-LISP-2002, say, which implements the
  new symbols and semantics, would be the way to go.

  The metaphor does not concern _what_ one disregards, considers oneself
  above, disrespects, etc, but _that_ one knows better than the community
  and that if there is ever some disagreement, the community is wrong for
  making its choices.

| "Obnoxious tourist" would be much more accurate, and while despicable, is
| not a crime in any part of the world that I know of.

  Ok, so you have a personal hangup about "criminal" and only think it
  concerns "crime", and not the personal attitude towards authority.  I
  shall make a small note of this, and that you refuse to get the point.
  Fine with me.