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.
I have four things to say. 1. Defining a distinct external syntax for every NaN, or providing some other means for programs to create specific NaNs, would interfere with a representation that is likely to be of great importance on 64-bit machines. 2. The proposed 1/0 and -1/0 syntax for infinities has two related problems: it looks like these things are exact, and allowing this syntax will require a more complicated rule for deciding whether a numeric literal is exact or inexact. 3. The +inf.0 and -inf.0 syntax is already used by several implementations, which agreed to standardize upon it several years ago, before the SRFI process began. Th +inf.0 and -inf.0 syntaxes (and +nan.0) also appear within The Revised R6RS Status Report of October 2004, which is online at www.schemers.org. 4. So far as I can tell, the R5RS does not require every number to have an external representation. With regard to the first point, one of the most attractive 64-bit representations is to represent all non-NaN inexact reals in IEEE double precision format, and to represent all other Scheme values as NaNs. This works because there are about 2^53 NaNs, which is about 2^53 more NaNs than are needed to represent the results of floating point computation. Using these excess NaNs to encode all of Scheme's non-flonum values is practical, and results in very efficient floating point calculation. I would oppose any proposed external syntax for NaNs that might interfere with the representation of Scheme values as NaNs. With regard to 2 and 3, I think SRFIs and other standardization processes should attempt to build on past standardization; otherwise we'll just be going around in circles. The proposed 1/0 and -1/0 syntax is contrary to the R5RS rule for determining whether an external representation names an exact or inexact number. It is also contrary to the informal standard that several major implementations have already agreed upon and have used for several years. Finally, it is contrary to the syntax being considered by the R6RS editors. Their progress report of October 2004 listed +inf.0 and -inf.0 among the things that are "probably not terribly controversial". Will