> To clarify my statement: I did not imply that R6RS aims at making
> Scheme harder to implement. For me, I see R6RS as a vehicle for
> serving the *users* of Scheme first and foremost. If serving the
> users leads to (as a consequence) raising the bar for implementors
> and forcing them to implement features that they would rather not
> bother with (full numeric tower, useful I/O, unicode, hash tables,
> records, libraries, exceptions, ...), then so be it. As a master
> Scheme implementor once said: There is no pity for the implementor.
While these are noble sentiments, reality contradicts them in many cases:
1. People who work with circular lists know what they're doing and don't
need baby sitting. I doubt they want (length) to check for circularity by
default. If anything, they would probably have to bypass the babysitting
by implementing a (length-unsafe) procedure to speed up things.
It's not like you can create circular lists casually. It takes determined
effort.
2. I'm a user of some niche Schemes. They work just fine with R5RS. If
they won't support R6RS, while the major implementations do, I lose,
because I won't be able to port common libraries to the niche
implementations.
You will say, switch to a major implementation. But for many niches,
there's just one implementation. Either you use it or you program in
another language.
So raising the bar for implementations hurts users.
3. Wasn't Common Lisp the one where you got everything-and-the-kitchen
sink? That argument about hash tables, records etc. used to come from the
Lisp camp.
Best,
Dan Muresan
http://alumnus.caltech.edu/~muresan
Received on Mon Oct 02 2006 - 07:34:23 UTC