Below are comments and questions I have on SRFI 70 Numerics with Infinities,
following roughly in the order of the SRFI document. Let me preface my
comments by saying I do not have the relevant expertise to make judgments on
the quality of the technical contributions of this SRFI.  However, there are
several non-technical issues that arise in the document.  Most notably 1) this
SRFI claims to be about one thing, but is in reality is concerned with with
something(s) quite different, 2) it lacks a clear scope and includes several
seemingly unrelated changes to R5RS, and 3) does not meet the structural
requirements of the SRFI process document since it is lacking in rationale.

The following is stated in the opening of the abstract:

    When Scheme was an experimental and research language, the Scheme
    reports were written sparsely to provide a framework which allowed
    unusual implementations. With many experiments having been tried and
    hopefully having gained knowledge from them, and with a growing user
    base wanting portability for their programs, this SRFI attempts to
    tighten the specifications for Scheme's numeric subsystems.

Given this opening, I would expect that this SRFI is concerned with
writing portable programs, specifically with respect to numerical
computations, and even more specifically with respect to numerical
computations involving infinities (whatever that means---I assume this
will be covered later in the document).

(As an aside, I don't see why the experimental or research-oriented
nature of the language is relevant here, neither do I see why it is
something to be abandoned, or how it interferes with portability.)

My expectation is that the rest of the abstract will outline what
"numerics with infinities" are, motivate why they are needed---presumably
by demonstrating their effectiveness at making programs portable among
Scheme implementations---and briefly argue that the particular approach to
numerics with infinities taken in this SRFI is the appropriate solution and
should be widely adopted among Scheme implementations.

However the next paragraph concerns division by zero:

    Checks for division by zero (and their absence) remain one of the
    most common programming errors. In numerical code the conscientious
    programmer must deeply nest conditionals to assure that checks for
    zero preceed [sic] each division.

    With infinities added to the number system we find that division by
    zero "works". It lets initialization of variables precede bounds
    checks and gives flexibility in placement of those checks. Limit and
    corner cases need not crash programs.

I don't see what this has to do with the paragraph above.  Is this
supposed to be the motivation for "numerics with infinities" (which is
still undefined at this point)?  If so, what is the relation to
portability?  If the absence of a division by zero check is a
programming error, how does silently ignoring it lead to portable
programs?  The sentence "Limit and corner cases need not crash programs"
seems to imply "they need not (but may) crash programs".  If the
behavior may or may not be specified, what is portable?  Or do you mean
the stronger claim, "Limit and corner cases /must/ not crash programs"?  What
specific cases are you referring to?

The document then lists 10 items enumerating changes made to the Numbers
section of R5RS.  2 are concerned with infinity.

- include inexact real positive and negative infinities,
- add `limit' procedure calculating one-sided finite and infinite limits.

The remaining 8 items seem unrelated, and out of scope, for a SRFI on
infinities.

The issues section remains largely unresolved, although everything in
the section should be handled before finalization and the section should
not appear in the final document.

The first issue deals with the appropriateness of including the limit
procedure, thus one of the two items dealing with the topic of this SRFI
is still under dispute as to whether it belongs in the specification.

If limit should be included in the SRFI, there must be a case for limit
extending the portability of Scheme programs.

The next issue asks the question of whether (/ 0.0 0.0)
- "is an error" (in R5RS speak, and thus can mean anything), or
- returns 0/0. or signals an error.

I don't see how either choice extends portability.

The next choice concerns the predicate identifying infinity.  This seems
on topic and within the scope of the SRFI.  The next two issues are not,
and should be removed from consideration.
- "Should odd? and even? be restricted to exact integer arguments?"
- "Should there be exact-only versions of expt and sqrt?"

The next issue concerns the external representation of infinities and
indeterminate numbers.  The abstract does not mention that the syntax of
numbers is going to be extended.  The syntax of infinities is arguably
within the scope of this SRFI (which I consider to be more correctly
concerned with computing with, not writing, infinities).  The syntax of
indeterminate number seems surely out of scope.  What does an
indeterminate number, much less it's syntax, have to do with "numerics
with infinities" (still undefined).  If this SRFI extends the syntax of
numerical constants, the relevant section 7.1.1 Lexical structure must
be revised to reflect these changes.

The section titled rationale follows, but the section does not contain a
rationale for the SRFI.  This section must explain why the proposal
should be incorporated as a standard feature in Scheme implementations.
However, no such explanation is given.  This SRFI replaces or competes
with R5RS, thus the rationale must explain why the present proposal is a
substantial improvement over R5RS.  However, no such explanation is
given.  As such the document does not meet the structural requirements
of the SRFI Process document, and should have been rejected by the
editors rather than accepted as a draft.

Rather than the requisite detailed rationale, the section includes an
descriptions and discussions on each of the specific changes made in
Section 6 of R5RS.  It addresses the What rather the Why of the
proposal.  The description material is more appropriately in the
specification section, using some typographical convention to offset it
from the revised R5RS text.  The discussion material is more
appropriately placed in a Discussion section, such as in SRFI 1.

What might be considered a definition of infinity first appears
in the fifth subsection of the Rationale section.

Much, perhaps most, of this SRFI has to do with the distinction between
exact and inexact numbers, and not with the subject of the title.
Little is said that relates infinities to the distinction between exact
and inexact numbers.  None is said that relates either subject to the
issue of portability.  Indeed, the word portability is not used in the
document outside of the opening paragraph of the document.

    library procedure: floor->exact x
    library procedure: ceiling->exact x
    library procedure: truncate->exact x
    library procedure: round->exact x

     These procedures are the compositions of `inexact->exact' with
    `floor', `ceiling', `truncate', and `round'.

These have portable definitions---they can't extend portability.
Further, these seem to be a poor choice of names.  The name x->y
traditionally names a function taking values of type x to type y, such
as string->list.  But the convention breaks here; what's a value of type
floor?

limit seems out of place in relation to the rest of the section in R5RS.

The procedures exact->inexact and inexact->exact are implementation
dependent.  How does their idempotency lead to portability?  What does their
idempotency have to do with numerics with infinities?  What is the rationale
for this change?

How does an optional non-real infinity 0/0. lead to portability?

How are "small improvements to the text" of R5RS within the scope of this
document?

David