| From: William D Clinger <xxxxxx@verizon.net>
 | Date: Sat, 18 Jun 2005 09:55:17 +0200
 |
 | 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.
 |
 | 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.

SRFI-70 mandates no connection between IEEE-754 NaN and 0/0.  In fact,
(= 0/0 0/0) ==> #t, while NaN != NaN in IEEE-754 arithmetic (in C).
Furthermore, SRFI-70 0/0 is a single number (which is not complex).
And 0/0 is optional in SRFI-70.

So SRFI-70 is no threat to using 2^53 NaNs for any purpose.

 | 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.

One of the notations being floated is #i1/0 and #i-1/0 (and #i0/0).
This notation looks inexact; and requires no rule complications.
Does that assuage your concerns?

 | 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.

 | 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".

On June 28, 2003 I posted to xxxxxx@zurich.ai.mit.edu a survey
<http://swiss.csail.mit.edu/~jaffer/III/RAWI> of infinity behaviors
and notations in Kawa-1.7, SCM-5d8, Guile-1.3.4, Bigloo-2.5c,
glibc-2.2, Elk-3.0, Gambit-3.0, Mz-Scheme-202, MIT-Scheme-7.8, and
Scheme-48-0.57.  At that time, there was no notation common to more
than one Scheme implementation.  That it is "not terribly
controversial" could only be arrived at by ignoring most
Scheme implementations.

Being an author of SCM, and having posted an article on this topic to
xxxxxx@zurich.ai.mit.edu, I am mystified by a standardization
process which not only doesn't include interested implementors, it
doesn't even notify them "several years" after the fact!  Am I wasting
my time tendering SRFIs in hopes of participating in the development
of R6RS?

As for the relative merits of notations, 1/0 is very evocative for
infinity.  While "finit" is a Latin root, "infinit" is a Middle
English derivation.  Thus "inf" will be not be nearly as evocative for
most people.  Numerical data written by Scheme programs will be seen
by people who have never read a Scheme Report.  Seeing 1/0 or -1/0,
many will intuit that the calculation reached an exceptional value.

"Nan" as a numerical notation is obscure, even to English speakers.
It is an acronym for not-a-number, which isn't the case for SRFI-70
#i0/0; (number? #i0/0) ==> #t.

There is still time for R6RS to improve upon the casually adopted
"standard" of +inf.0.

 | 4.  So far as I can tell, the R5RS does not require
 | every number to have an external representation.

You are correct.  The type restriction implied by the `z' argument is
that only complex numbers need have external representations.

6.2.6 Numerical input and output:

 -- procedure: number->string z
 -- procedure: number->string z radix
     ... The procedure `number->string'
     takes a number and a radix and returns as a string an external
     representation of the given number in the given radix such that

     (let ((number NUMBER)
           (radix RADIX))
       (eqv? number
             (string->number (number->string number
                                             radix)
                             radix)))

     is true.  It is an error if no possible result makes this
     expression true.

1.3.3 Entry format:

  It is an error for an operation to be presented with an argument
  that it is not specified to handle.

Thus (number->string 0/0) is an error.

The equivalence of number notations between string->number,
number->string, literal constants, and read, and write was shown in
<http://srfi.schemers.org/srfi-70/mail-archive/msg00061.html>