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