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.
On Sat, 18 Jun 2005, William D Clinger wrote: >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. Good point. >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. I agree with this, by the way: I'd much rather see +inf.0 and -inf.0 than 1/0 and -1/0. To me the connotations are different: +inf.0 means "numeric overflow:" 1/0 means "illegal operation." Or, mathematically, +inf.0 seems to mean "we can't tell how big this is, and it may be infinite" and 1/0 means "this is, exactly and absolutely, a first-order infinity." I find +inf.0 and -inf.0 seem to me to express the ideas that are more in line with the way they are used in computer programs. Besides, they are already used by more implementations than 1/0 and -1/0. >4. So far as I can tell, the R5RS does not require > every number to have an external representation. :-/ I agree with you, but this is one of the things that I think ought to be fixed about RNRS. In other words, I call "bug, not feature." > 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. Hmm, that would work. 2^51 fixnums, 2^21 one-code characters, #t, #f, the empty-list, the EOF object, 2^10 or so error objects including several used as NaNs, etc, and you've still got 2^52 codes left over for pointers to non-immediate values, plus almost that many codes still unused for whatever purpose. Plus, there's no indirection or masking required for floats, which makes float operations fast. > 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. This appeal to standardization efforts would work better if the promulgators of such "standards" had been more diligent about contacting the authors of other implementations and letting them know that there was a standard, even an informal one, in place. As matters stand, I think +inf.0 and -inf.0 have to stand on their merits, and the fact that there are several implementations that already use them. At any rate, R6RS isn't going to be taking as small a detail as a name from the SRFI's. If anything, it will be looking at the concept of including an infinity, period. If it needs a name, it will be looking to implementations, not SRFI's. And that's as should be, I think. SRFI's don't contribute directly to R6RS: implementations adopting SRFI's and users creating code that takes advantage of them do. And that's as it should be, I think. Bear