guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

#f/() tedium


From: Tom Lord
Subject: #f/() tedium
Date: Thu, 5 Sep 2002 00:25:19 -0700 (PDT)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]