Proposed modifications to R3RS

[David Bartley <bartley@mips.csc.ti.com>]

> From: Morris Katz <MKATZ@A.ISI.EDU>
> Subject: Proposed modifications to R3RS
> [...]
> 1)  The DO construct should be eliminated from the language as it
>     is easily implemented using named-let's or letrec's.

DO is inessential and so is perhaps a good candidate for excision from
the IEEE standard, but it is probably too commonly used for most of us
to want to remove support for it from our existing or planned
implementations.  Thus it should remain in the informal standard to
ensure we all do it the same way.  (For example, someone may make it
re-ASSIGN rather than re-BIND the variables at each iteration if they
didn't know better.  That could introduce subtle portability bugs.)

> 2)  The CASE statement should be eliminated for the same reasons
>     as DO.  How many of you have ever used a CASE?  Would it
>     really have been less clear had you used a COND?  This should
>     be a library function if it is going to exist at all.

CASE is also inessential syntax.  I use CASE a lot, and find it to be
much more clear than COND when I use it.  CASE makes it clear that I
am dispatching on a value; I have to inspect all of the clauses of a
COND to see if they all fit the same pattern otherwise.  Since CASE is
syntax and not a function, we would need macros before we could demote
it to a library.

> 3)  I believe that AND is overspecified [...]

I see both sides of this one.  As an implementor, I hate for these
things to be overspecified.  In fact, I have some logic in my compiler
to look for chances to simplify the true value returned by AND and its
kin.  However, AND has such a long history that the dusty deck (and
dusty brain) factor can't be ignored.

> 4)  LAST-PAIR should be eliminated as it is gratuitous at best.

Definitely.

See, I tried to be agreeable!

Regards,
David Bartley