Re: Draft of R.R. Report

[Chris Haynes <cth%indiana.csnet@csnet-relay.arpa>]

We are quite pleased with the report.  Its synthesis is particularly
remarkable given the considerable diversity of opinion expressed on the
net.  Asside from a few bugs and editorial suggestions communicated
directly to Will (the most significant of which was that we agreed
CALL-WITH-CURRENT-CONTINUATION was essential), our only remaining
difficulties with the proposal are reflected in the following opinions.


Given (1) the failure to specify under what circumstance an escape
procedure invocation will result in closing a port opened with
CALL-WITH-INPUT-FILE or CALL-WITH-OUTPUT-FILE, and (2) the optional
nature of the explicit open and close operations, the result is that
portable code can not be written for applications in which ports must
be closed (often the case with todays operating systems) and escape
procedures must be used (as in a coroutine application).  The simplest
solution is to make the open and close operations essential and the
call-with operations optional.  (In general, if an essential feature
can not be fully specified, it should always be possible to program
around the uncertainty.) If there is some reason why the open and close
operations can not be essential (which shouuld be spelled out in a
rationale statement), then the call-with functions should close files
*only* when they return to the continuation of their invocation.  It
would then be possible to define the open and close operations using
call-with functions and devious application of escape procedures.

READ-CHAR-READY? is more descriptive than LISTEN?.  The failure to
specify what it returns at end of file is most unfortunate.  We
shouldn't waffle just because Common Lisp got it wrong.

If you need to READ with assurance that you won't block, you have to
write your own reader using READ-CHAR-READY?  and READ-CHAR?.  How
about adding READ-READY?, which returns true iff an entire parsable
object can be read without blocking.  (A system that includes READ-ATOM
should also include READ-ATOM-READY?.)

An alternative to this predicate proliferation is to allow all read
functions to return a distinguished object to indicate blocked input,
as they may return a distinguished object to indicate end-of-file.
Then all we need is a single predicate for this object, say HUNG?.

The inclusion of the same numeric order predicates with and without a
"?" looks terrible--as if we couldn't make up our mind, which is what
standardization is all about.  And both forms are essential!  We were
among of those who insisted on the simpler (no ?) forms because that is
what we were accustomed to.  But we'd rather switch than fight if the
result is such conspicuous failure to standardize.  At the very least,
only one form should be essential.  Would anyone else be willing to
switch?

#!TRUE, #!FALSE and #!NULL should not be constants.  They are
sufficiently ugly in programs that an extra quote mark in front is
hardly worse.  If they are required more than occasionally they should
be bound to variables anyway.  Why complicate the spartan syntax of
Scheme with such things?  

#!NULL is unnecessary, for we already have a prefectly good way of
printing and reading the empty list, ().  #!NULL is also misnamed:
traditionally NULL is a predicate and NIL is the empty list.

RECURSE (introduced in Chez Scheme and added to Scheme 84) is much
better than "named let" or ITERATE.  If we can not agree, it would
be better if neither RECURSE nor named let were mentioned in the report;
but if the standard says some implementations permit named let, it
should say others permit RECURSE.

DEFINE!  and DEFREC!  should go away.  (Yes, We were among those who
wanted them originally, but they aren't worth it.) We're not fond of
DEFINE either and wish it could go the same way, or at least be
optional.

NUMBER? is redundant, since all all numbers are complex in the
proposal.  If NUMBER? is included to allow for future generalization
(quaternions?) or other reasons, then the rationale should be stated.

WHEN is better than no one arm conditional.  Having no one arm
conditional is better than having IF's alternative optional.  UNLESS we
are better off without.

The interaction of OBJECT-HASH and OBJECT-UNHASH with garbage
collection should be specified.  If we can't decide, the whole section
should be deleted.

A unary constructor is so fundamental that it is worth standardizing.
It might be called BOX, REF or CELL.  BOX probably would create the
least confusion.  Of course, we would also need associated selection,
mutation and predicate functions.


Chris
Dan