[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed modifications to RRRS
>> 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.