Proposed modifications to R3RS

[Jonathan A Rees <JAR@AI.AI.MIT.EDU>]

    Date: Tue 24 May 88 13:13:21-EDT
    From: Morris Katz <MKATZ at A.ISI.EDU>

    a)  Syntactic sugar should only be added to the language if its
        usefulness far outweighs the complexity it introduces.

It's difficult to make objective arguments on this rounds, because
different people have uses for different things.

    b)  Overspecification should be avoided as it artificially
        prohibits reasonable implementations.

Underspecification effectively amounts to giving an axiomatic semantics
(proof system) for the language, as opposed to a denotational one (a
model).  The problem with underspecification is that one can have a
program that works fine in one implementation and fails in another, so
the only way to produce portable code is by reasoning about it, and
testing doesn't help you a bit.  While I agree that some
underspecifications are important, I believe you can go too far in
underspecifying things that really don't make much difference, requiring
reasoning in situations where testing ought to be sufficient.

Underspecifications makes the language harder to learn and use, since an
implementation cannot teach them very well.  One must be aware of all
underspecifications all the time.  I think they should be minimized, not
maximized.

    1)  The DO construct should be eliminated from the language as it
        is easily implemented using named-let's or letrec's.  

At first I thought I didn't make much use of it, but empirical evidence
shows that I think it's important to keep it.  I just checked one large
recently-written system of mine, and I wrote 47 out of 88 loops using
DO.

I can't believe this question is being raised again.  You would do us a
favpor by looking through the archives (in AI: LSPMAI; RRRS MAILnn) to
see how this issue was dealt with before.  It was also argued at the
1984 meeting, as I remember.

    2)  The CASE statement should be eliminated for the same reasons
        as DO.  How many of you have ever used a CASE?  
I use it all the time.
        Would it really have been less clear had you used a COND?
Yes.

    3)  I believe that AND is overspecified ...

It has been proposed to eventually eliminate the possibility of multiple
false values.  That would fix your complaint about AND.  Until that
time, AND should be symmetric with OR.  Thus in your arguments I would
prefer you use OR as your example rather than AND.  It seems somewhat
unprincipled that you start out by saying you think AND is
underspecified and say only as an afterthought that you think OR is.

I think that rather than take the half-way measure you propose, you
should instead be in favor of making it an error for the predicate of an
IF to be a non-boolean.  This would get you some of the results you
want for OR and AND, and it would get you many other beneficial
transformations as well.

By the way, it's clear that OR (and AND) must necessarily return the
value of the last form if previous forms evaluate to false (true);
otherwise you will lose tail recursion.  (Unless you imagine one
sophisticated continuation garbage collector.)

    4)  LAST-PAIR should be eliminated as it is gratuitous at best.
        After all, its tail-recursive implementation appears directly
        below it in R3RS.  Personally, I can see no performance
        reason for keeping it, which would be the only possible
        justification.  

OK, let's flush LENGTH, APPEND, REVERSE, ASSOC, CHAR=?, VECTOR->LIST,
and all other easily-definable procedures as well.  EQUAL? isn't so hard
to write either.  There is no performance advantage to having these.