Comments and poll on () [long message]

[Chris Haynes <chaynes@iuvax.cs.indiana.edu>]

There are (at least) four possible positions in the area of consideration:

A. #F and () may be identical, and () may be false;

B. #F and () may be identical, but () is true if they are distinct;

C. #F and () are distinct, and () may be false;

D. #F and () are distinct, and () is true;

where objects are "identical" if they are EQ?, "false" means
"interpreted as a false value", and "may be X" means "may or may not
be X in a conforming implementation".

Position A was the old status quo, but B has been agreed to by the
RNRS authors.  The change from A to B was not made in R3.95RS by an
oversite.  Thus B is the real status quo, as reflected in R3.99RS and
P1178/D3 (the most recent IEEE standard draft).  It isn't clear to me
whether anyone has argued for C. (It would make condition testing
expensive unless () were false.)  The contest seems to be between
positions B and D.

Several statements have been made to the effect that standards are
cast in stone.  They are not.  They must be revised at least every
five years, and they are supposed to evolve.  (Ironically, the current
policy for consensus in RNRS may make its evolution more conservative
than the standard.)  Existing practice must be taken into account
before changes are made; however, in the present case this may well
not be a problem.  If we go with position B now, no portable code can
rely on #F and () being identical, so it is unlikely that code
compatibility will stand in the way of a change to D when the standard
is revised.  If time further tells that few implementations are wedded
to B for reasons such as Common Lisp compatibility or branch test
efficiency (see below), a change to D a few years hence should not be
difficult.  On the other hand, it is still true that a change now is
preferable if we have a clear consensus to do so.

So far the Scheme Working Group has maintained policies of not making
binding decisions over the net and of maintaining compatibility with
R4RS.  If a position other than B were adopted in a standard draft
submitted to the MSC in March, it would be contrary to the former, and
possibly also the later policy.

However, if the results of the above poll show a clear consensus, I
believe there is justification for making an exception to these
policies for this issue.  Though a number of individuals have definite
opinions on this issue, there appears to be substantial, perhaps
universal, feeling that this issue is not worth delaying the
standardization process.  (If we miss the March 12th MSC meeting, the
standard will be delayed at least four months.)  It is also
questionable whether debate of this issue at a formal meeting would
yield any better agreement, and patience for continued discussion of
this matter in any forum is running thin.  However, there are enough
individuals that feel strongly about this issue that if it no change
is made this could result in enough negative ballots for the draft to
be rejected (at least on the first round of balloting).  Even if this
does not happen, if there is a substantial consensus on this matter,
the standard should be faithful to that consensus.

If you wish to register an opinion on this issue, respond to the
following poll:

-------------------------------------------------------------------------
I prefer:  (choose one of A, B, C, D, or none)

I strongly oppose:  (indicate all of A, B, C, and D that apply, or none).
-------------------------------------------------------------------------

Send responses to chaynes@iuvax.cs.indiana.edu by Monday, February
26th.  "Strongly oppose" means that if one of the positions you list
were adopted by the standard, you would cast a negative ballot for
that reason.  Responses of "none" will be counted as abstentions,
which will dilute the impact of other responses if they are numerous.

In using the results of this poll, the standard editors first concern
will be to avoid a position to which there is sizable opposition.
Second, if there is substantial preference for a position to which
very few are strongly opposed, that position will be adopted.  If
there is no strong opposition to position B, and no substantial
consensus favoring another position, then the status quo (B) will be
maintained.  (Put simply: if the poll is anywhere near close, the nod
goes to B.  The poll is for the editors' information; it is not a
formal vote.)


My summary of B vs D:

   Position D is attractive to many who feel it simplifies the
   language semantics.  If we stay with position B, it will not be
   possible to define a useful subset of Scheme in a reasonably
   precise way (as in a book I'm working on) without this ugly issue
   getting in the way.  This confuses readers and makes Scheme (and
   us) look bad.  Also, as has been repeatedly noted, experience
   demonstrates that punning #F and () results in subtle bugs.

   In the past, a major reason for favoring position B over D was that
   B allows Common Lisp to be built on top of Scheme without having to
   redefine a great many primitives.  I think this still carries some
   weight, as does the consideration that some hardware can test one
   value (e.g. 0) more efficiently than others, so it is nice to be
   able to use this value for both #F and ().

My response to the poll:

   I prefer: D

   I strongly oppose: none