#f/() tedium

#f/() tedium

[Tom Lord]

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.

As recent threads on comp.lang.scheme illustrate, a lot of what's
interesting about Scheme is that it is a (conceptual) _vector_ (not a
significant _point_) in language design space.

RnRS is interesting (in my opinion) because it demonstrates what can
be accomplished with a combination of minimalism, "lispism", and care
for the underlying math.   

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.

If you look at scheme as a language in want of a CPAN (as one
c.l.s. poster put it) -- I think you'll make compromises that are
....well..., in the words of Wavy Gravy -- "not specifically good".
But it's your trip.

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.

And, as tb and I seem to have agreed to disagree off list (hope I'm
not misrepresenting you too badly, tb), there are no clear pithy
arguments or empirical evidence one way or the other.  My current best
"argument" is something like: try writing really tight Emacs lisp code
for a while, with this issue in mind.  That's probably simpler than
trying to find some space aliens to ask.


the gods must be crazy, and guile is a monkey with a coke bottle up a tree...
-t



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: #f/() tedium

[Thomas Bushnell, BSG]

Tom Lord <lord@regexps.com> 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


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel