[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

proposing changes to RRRS



Here is a list of changes I (Will Clinger) would like to see made in the
RRRS.  Only three changes have enough substance to be controversial.
Page numbers refer to MIT AI Memo 848, August 1985.


Non-controversial changes

----------------------------------------------------------------
Pages 7, 12, 48, and 54:  The context free grammar omits characters and
vectors as constants, and is therefore inconsistent with the language
describing the quote special form and the notations for characters and
vectors.  This should be fixed.  Note, however, that the # notations
for characters and vectors are optional.

----------------------------------------------------------------
Page 7:  Backquote doesn't fit into the context free grammar.  A correct
treatment of backquote syntax may be more trouble than it's worth in an
informal document, however.

----------------------------------------------------------------
Page 7:  Variables are referred to as objects, but they're not.

----------------------------------------------------------------
Page 22:  It says that "pairs (and therefore lists)" count as true.
It should say "pairs (and therefore nonempty lists)", or else just "pairs".

----------------------------------------------------------------
Page 25:  eqv? should work on characters also.

----------------------------------------------------------------
Page 30:  People have requested that the last argument to append
not be required to be a proper list.

----------------------------------------------------------------
Page 43:  The grammar is ambiguous as to whether (for example) #x1e4
represents decimal 10000 or decimal 484.  Following Common Lisp, let's
say that "interpretation as a digit is preferred to interpretation as"
an exponent.

----------------------------------------------------------------
Page 43:  There are no rules about the exactness or precision to be
used on input if none is specified.  I think that's just fine until
we get more experience with the RRRS number system, but a sentence
to that effect would be helpful.

----------------------------------------------------------------
Page 49:  The character set should not have to be infinite, so the
order isomorphisms should be between the set of characters and a
*subset* of the integers.

----------------------------------------------------------------


Controversial changes

----------------------------------------------------------------
Page 17:  I'd still like to see named-lambda removed from the language
definition.  Any implementation capable of handling
(named-lambda (var ...) ...) specially should be capable of handling
(rec var (lambda (...) ...)) specially.

----------------------------------------------------------------
Page 19:  In talking about do, RRRS says that "the results of the step
expressions are stored in the bindings of the vars".  I would rather change
the semantics so that the step expressions are evaluated, the vars are
bound to fresh locations, and the results of the step expressions are
stored into those locations.

The current semantics is compatible with Common Lisp, but the proposed
semantics is better not only because it has no side effects but also because
it is likely to run faster when compiled by a sophisticated compiler.  I
don't think many people will notice the difference, and the few who are
sophisticated enough to notice will probably prefer the proposed semantics.

The proposed semantics is the one that has been used in Scheme up until
the RRRS.  MacScheme and T3 still use it in violation of RRRS; others
may also.  The change was due to my thoughtless acceptance of the Common
Lisp semantics.

----------------------------------------------------------------
Pages 24-25:  We have agreed that eq? is a low-level notion of object
identity.  I would like to adopt Jonathan's proposal that eqv? be
defined independently of eq?.  I believe the main effect of this is
that the result of eqv? when given procedures as arguments would
not be specified.