R3.99RS issues (long message)

[will@cs.uoregon.edu]

No less than 12 issues, by my count, have been debated here since I lost
contact with the net.  I'll be responding to some of them separately.  For
the others, this message summarizes my perception of the consensus or lack
thereof for purposes of the R4RS.

William Clinger

--------------------------------------------------------------------------------
Timing of the R3.99RS, R4RS.

Mike Shaff:
    I am definitely in favor of moving forward on issues and getting the
    report out to the public, however the latest version of the report that
    I have (via zurich) still seems to have some areas that I thought were to
    be part of the document (per L&FP such things as macros, name
    regularization, etc were to be 'rubber stamped' by the group).  Is there
    to be another beta release *before* the submission to P1178?  If not, what
    happened to those and other favorites?

There will not be a beta release before submitting R3.99RS to P1178 because
there isn't time if P1178 is to circulate a draft IEEE standard before its
next meeting.  Matters for which we have not reached consensus will have
to wait for the R5RS.  There were only two things that the Snowbird meeting
"rubber stamped" in advance: clarification of the numeric procedures, and
macros.  On the matter of regularization, it was agreed that Morry Katz would
develop a proposal for consideration over the net, but the Snowbird meeting
did not commit itself to accepting such a proposal.

With regard to the numeric procedures, we appear to have reached consensus
on everything except MIN and MAX; at worst I can leave MIN and MAX out of
the R4RS, but I expect we will do better than that.  The macro committee
has thus far failed to agree on a proposal.  The plan is for the R4RS (but
not the R3.99RS) will have an appendix that describes (at least) two
incompatible macro proposals and the issues that have prevented them from
being resolved; this should be the only substantial difference between the
R3.99RS and the R4RS.  We do not have consensus on wholesale regularization,
but some regularization is occurring anyway (see below).

Pavel Curtis:
    I'd rather that we did not cut off debate on R4RS at the end of this
    month.  It seems to me that there are several reasonably important
    issues currently on the table that could make it into R4RS in the very
    near future (e.g., uniform definition semantics, fluid binding, and
    regularization of procedures).  I would hate to see R4RS come out so
    little changed from the previous report; in a sense, what's the point?

The point is that there should be a version of the RnRS that corresponds to
the P1178 draft.  The P1178 committee has committed itself to follow the RnRS,
not to lead it.  The changes that Pavel mentions are upwardly compatible with
what will be in the R4RS, so there's no reason to delay the R4RS on their
account.

--------------------------------------------------------------------------------
Flushing ELSE.

Morry Katz:
    ....I therefore advocate that we remove ELSE from the list of syntactic
    keywords and replace ELSE by #T in the COND examples in RNRS....

This proposal has not attracted support, and is about to die for lack of a
second.

--------------------------------------------------------------------------------
Fluid variables or cells.

There seems to be agreement in principle but little consensus on details.
I think this is a good topic for R5RS but not for R4RS.

--------------------------------------------------------------------------------
FORCE and DELAY.

Mike Shaff:
    Force and delay are currently in totally separate sections of R3.95RS
    which can lead readers to hours of fun and enjoyment.  Perhaps the
    Delayed Evaluation section (4.2.5) can be made a subsection of Control
    Features (6.9) and expanded to include force.

Sections 4.2.5 and 6.9 refer to each other explicitly.  I can see how this
might cause a minute or two of page-flipping, but I think only a very
creative reader could derive hours of fun and enjoyment from it.

--------------------------------------------------------------------------------
Add CONTINUATION?

This issue has been withdrawn.  In the message withdrawing this issue, Morry
Katz said:

    I believe that PROCEDURE? is a serious misnomer.  The function should
    really be called APPLICABLE?.

All applicable objects described in R4RS are procedures, and vice versa, so
PROCEDURE? is no more a misnomer than APPLICABLE?.  The name has been
debated twice in the last five years, and PROCEDURE? has won out both times.

--------------------------------------------------------------------------------
EQV? on numbers.

Jim Miller:
    I thought that 
       (and (number? x) (number? y) (= x y)) implied
       (eqv? x y).
    By my reading of R3.95RS this isn't true (consider x=3 and y=3.0),
    although I believe
       (and (number? x) (number? y) (eqv? x y)) implies
       (= x y)
    Have I got this right?

Yes.  In fact, my reading is that
    (and (number? x) (number? y) (eqv? x y))
is equivalent to
    (and (number? x) (number? y) (eqv? (exact? x) (exact? y)) (= x y)).

Pavel Curtis:
    I would be unhappy with any statement that distinguished between the
    behavior of, for example, the car cell of a pair and the contents of a
    lexical variable...

The discussion at the recent P1178 meeting addressed both, though this
may not have been reflected by the minutes.

In my separate message on MAX and MIN, I argue that the requirement that
EQV?-ness be preserved should not be strengthened to a requirement that
EQ?-ness be preserved.  I will expand that argument if people want me to.

--------------------------------------------------------------------------------
Add bitwise logical operation on exact integers (bitvectors, whatever).

This sounds like an excellent proposal for the yellow pages, and later for
inclusion in R5RS.

--------------------------------------------------------------------------------
Require left-to-right evaluation of internal definitions.

Pavel Curtis:
    Given your retraction of this objection and John's and my unanswered
    refutations of your first one, may we assume that you now support the
    proposal to unify definition semantics?  If not, could you say more?

I remember that you sent some messages denying my first objection, but I
don't recall any refutations of it.

I still prefer that the order of evaluation of internal definitions be left
unspecified, for the same reason that the order of evaluation of arguments
in a procedure call is unspecified.  In both cases the context is such that
the order of evaluation ordinarily would not matter even if it were
specified.  By leaving the order of evaluation unspecified, we save the
reader of a correct program from having always to consider the remote
possibility that the order is significant.

The obvious "disadvantage" of leaving the order unspecified is that people
who want to use side effects cannot use a tacit sequencing implicit to the
internal definitions or arguments, but must use an explicit BEGIN instead.
I maintain that this is actually the great advantage of leaving the order
unspecified.

The real disadvantage of leaving the order of evaluation unspecified is that
it becomes easier to write incorrect code.  In my opinion this has not been
an important problem.

An aesthetic disadvantage in the case of internal definitions is that the
order of evaluation *is* specified for top-level definitions.  I maintain
that this inconsistency results from our current compromise with file-based
program structures and separate compilation---matters that aren't even
mentioned in the Report, but influence it regardless.  I too would like to
remove this inconsistency, but would prefer to fix it by removing the
implicit sequencing of top-level definitions.  I hope this will be possible
in a future module facility or other extension for programming-in-the-large.

For all that, I repeat my earlier statement that I am not strongly opposed
to requiring that internal definitions be evaluated from left to right.
I am merely opposed.  I will certainly implement this change if the authors
want me to.

--------------------------------------------------------------------------------
Why aren't more procedures required to return exact integers more often?

Alan Bawden:
    Actually, I'd be more interested to know what -isn't- on the list.  I'll
    bet SQRT isn't there because people think that SQRT of an exact 4 should be
    allowed to return something inexact rather than an exact 2.  Am I right?
    I suspect that if I understood more about this "list" I would argue that
    -all- numeric functions belonged on it (including SQRT).

Bill Rozas:
    Correct.  I suppose it's a matter of practicality -- nobody wanted to
    commit to implement `sqrt' to handle this case specially, presumably
    because such behavior isn't too interesting.  To take it further, I
    suppose it wouldn't hurt to add the transcendental functions to the
    list....The only good reason why `/' and `sqrt' should not be in the
    list is efficiency and implementation complexity.  Maybe that's not
    good enough....

    I suspect that there's no argument for keeping the transcendental
    functions out of the list since my intuition tells me that there is no
    case where integer arguments provide an integer result; if there is
    such a case, it's probably pretty obscure...A similar argument holds
    for `make-polar' and `angle'....

Here's the cases I could think of that would require special treatment:
(exp 0), (log 1), (sin 0), (cos 0), (tan 0), (asin 0), (acos 1), (atan 0),
(atan 0 n), (make-rectangular n 0), (make-polar n 0), (angle n),
(magnitude n); where n is an exact but not necessarily non-negative
integer.

    Summary: the only procedures that seem to matter are `/' and `sqrt',
    and the argument in favor of excluding them is pragmatic.

Scheme would be simpler if we could just say that with the exception
of EXACT->INEXACT, all procedures in section 6.5 that return a numeric
result will return an exact integer result provided all their arguments
are exact integers and the mathematically expected result is representable
as an exact integer within the implementation.

I think the argument in favor of simplicity outweighs the pragmatic
argument, partly because the pragmatic argument is weak.  It isn't very
hard to handle the special cases, and it's unlikely that SQRT needs to be
particularly fast on exact integers.  I propose that we make this change
in R5RS.

Peace, Will