This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
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 amongScheme 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 meanthe 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 implementationdependent. 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?