Re: Proposed modifications to RRRS

[Morris Katz <MKATZ@A.ISI.EDU>]

>> 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.

When one actually wants AND and OR to return the values currently specified
instead of just being boolean predicates, there is a simple and efficient
implementation in terms of the AND and OR semantics I advocate.  However, the
reverse is not true.  One could wrap all all uses of AND and OR as predicates 
in a function which canonicalized the return values to #t and #f, but this
would be neither efficient nor esthetically pleasing.  Furthermore, this 
would add yet one more special case for the efficient compiler to worry about.
Lastly, I must repeat that I just don't buy the argument that language 
designers must repeat the mistakes of the past in order to maintain 
compatibility.  Bad ideas should be purged from or memories, not reenforced.

>> 1) and 2) Do and CASE

My original proposal advocated standardizing macros and then relegating
these features to library status.  I stand by this recommendation.  To me the 
distinction between essential and inessential is a bad one because those
attempting to write portable code can only depend on essential features, 
anyway.  This means that inessential features are effectively not part of the 
language and a really just commonly used portions of a library.  I therefore 
make the previously discussed suggestion again:

5)  Lets remove the distinction between essential and inessential features and
in each case decide that the feature either is or is not part of the language.
-------