Tom Lord <lord@emf.emf.net> wrote:
+---------------
| Some people ask "what is truth".  In the Scheme world, we sometimes
| ask "what is falsehood?"
+---------------

No, we also ask "what is truth?" here, and the Standard [IEEE or R5RS]
answer is "Anything that is not the distinguished object #f is true."

+---------------
| In some older implementations of Scheme, the values `()' and `#f'
| are the same value
+---------------

Yes, well, that changed, di'n it now?

+---------------
| Although the standard changed, I think it is a nearly objective truth
| that having just one value, "nil", is the better idea.
+---------------

Obviously the writers of the standard saw a different objective truth.
(Which means it's really not all that "objective", don' it?)

Tom, it's a total troll to argue the nill/null/false issue in
comp.lang.scheme at this point in history. There are serious
mathematical & pedagogical reasons for keeping them distinct,
which the Scheme community (or at least, the IEEE & RnRS writers)
eventually felt outweighed any minor speed hacks one gets from
merging them.

If you really, really prefer () == #f == nil, why not just use
Common Lisp, where they *do* agree with you? Besides, in Common
Lisp (car nil) --> nil, which is awfully darned convenient sometimes,
e.g., (cadr (assoc x y)).

[Though that can also be confusing occasionally, too. Did
(cadr (assoc x y)) return NIL because X wasn't in the assoc
list Y or because X *was* in Y but had a null association?]

The reason your troll isn't going to go anywhere is not that
at one time it mightn't have been worth discussing (it was,
and it *was* discussed, at great length, furiously), but that
now it's too late.

A large amount of Scheme code has already been written by
various people [disclaimer: one of them is me] which *depends*
on (not (equal? '() #f)). You see, if you can depend on it,
there are some *different* neato speed hacks you can use,
useful in their own right. And at this point, no-one who has
gone down that path is going to want to change their code...

Let Scheme be R5RS Scheme; let Common Lisp be X3J13 ANSI Common Lisp.
Oh, yes, and let all other Lisps past and future be themselves, too.
Keeping all of those others distinct is important[1].


-Rob

[1] Which is why I I don't go along entirely with certain folks in
    comp.lang.lisp who say that the term "Lisp" (used without other
    qualification) should automatically mean X3J13 ANSI Common Lisp,
    *only*. Their main point seems to be that most of the negativity
    the general public has picked up about "Lisp" is outdated or
    was never true in general (e.g., "Lisp is interpreted"), and
    by insisting that "Lisp == ANSI Common Lisp" they can overcome
    that negativity.

    Hmmm... Maybe they *do* have a point. After all, I argue above
    that Scheme today is defined by R5RS. If you want to talk about
    some "other" Scheme, you need to qualify it (e.g., R4RS Scheme).
    So why not admit that Lisp today is defined by ANSI Common Lisp,
    and that if you want to talk about some "other" Lisp, you need to
    qualify it (e.g., Elisp [in Emacs] or ISLisp [ISO Standard] or EuLisp).

-----
Rob Warnock, 30-3-510		<rpw3@sgi.com>
SGI Network Engineering		<http://reality.sgi.com/rpw3/> [R.I.P.]
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA

[Note: aaanalyst@sgi.com and zedwatch@sgi.com aren't for humans ]