Re: #f/() tedium

[Thomas Bushnell, BSG]

Tom Lord <address@hidden> writes:

> It bugs me when people site R5RS as a reason to do _anything_ to their
> scheme impl., and this is a timely time to mention it.

Except that it's already been done.  Nobody is trying to figure out
whether Guile should have #f != ().  

The only question is whether we should *reverse* that decision... out
of what?  A desire not to be compatible with R5RS?  

> Some aspects of RnRS, such as the I/O procedures, are clearly so
> academic as to be nearly worthless in practice.   In that light,
> examine the #f/() distinction.

The I/O procedures are actually useful in practice.  At least, I use
them in practice, in the same kinds of contexts I would use the
corresponding getc/putc functions from C.  

But sure, they are a bare skeleton, and of no great interest in
themselves.  And yet, it would be a serious mistake to ignore them on
that ground.  Any decent Scheme system can implement them easily, and
should.  Of course, that's no reason not to also implement a good set
of comprehensive I/O routines.  

> Against this, I suppose, are the SRFIs.  I haven't surveyed them to
> see how heavily they rely on #f != ().  I did find that Olin's list
> library was an easy port.  It used to be (still is?) a design
> principle of slib to be agnostic on the issue.

Suppose we were designing a language anew.

What possible reason is there for making the space of boolean values
have anything to do with the space of proper lists?  

It seems to me that conventional practice of Lisp is the only reason
for that, and the argument from conventional practice allowed the
names "car" and "cdr" and "cons" into Scheme, with a wink and a smile,
and used to allow the possibility of #f = (), but no longer does.

The argument from conventional practice has some merit, but not when
the convention has now changed.  And I can see no reasons whatsoever
aside from "that's what Lisp does" for maintaining what seems to me to
be a bit of non-orthogonal inanity.  

That is, if you can explain why integer 0 should not be the empty
list, or perhaps (integer->character 0), or why not even #t! aside
from the argument "that's what Lisp does", then I'm all ears.

> And, as tb and I seem to have agreed to disagree off list (hope I'm
> not misrepresenting you too badly, tb), 

No, I think I was very clear.

As long as you continue to bring up the "issue" on the list, I will
answer you on the list.  If you find it so damn tedious (as your
subject indicates) then why do you bring it up like clockwork?

Thomas