| Date: Thu, 27 Oct 2005 13:00:02 -0700
 | From: Alan Watson <xxxxxx@astrosmo.unam.mx>
 | ...
 |
 | I do think your suggestion of context is a good one, provided it is
 | optional and does not interfere with bit patterns. It can be
 | accomodated by:
 |
 | (a) "write" writes NaNs with a bit pattern and a possible context
 | (for example, #<NaN #x12345ef expt>). If the implementation does
 | not support context or if the NaN is not associated with any
 | context, "write" omits it (for example, #<NaN #x12345ef>).
 |
 | (b) "display" writes NaNs without a bit pattern but with a possible
 | context (for example, #<NaN expt>). If the implementation does not
 | support context or if the NaN is not associated with any context,
 | "display" omits it (for example, #<NaN>).
 |
 | (c) If a bit pattern is present, "read" produces a NaN with the
 | same bit patterm. This maintains read/write equivalence.
 |
 | (d) If no bit pattern is present, but a context is present, and if
 | the implementation supports contexts, then "read" produces a NaN
 | with the same context. This may be a different bit pattern as the
 | reading and writing implementations may encode the context
 | differently.
 |
 | (e) If neither a bit pattern nor a context is present, "read"
 | produces a contextless NaN.
 |
 | Basically, write/read would preserve bit patterns and display/read
 | would attempt to preserve context.  What do you think?

It looks a reasonable system for read/write invariance.

I think there is a practical problem with "designer-NaNs" in that,
unlike all other IEEE-754 number objects, they cannot be constructed
by IEEE-754 floating-point operations alone.

For example, SLIB/bytenumb.scm has R5RS code which converts between
numbers and byte representations of IEEE-754 numbers.
<http://savannah.gnu.org/cgi-bin/viewcvs/slib/slib/bytenumb.scm?rev=HEAD&content-type=text/vnd.viewcvs-markup>
In an SRFI-70 compliant implementation with bignums and flonums, all
single or double float numerical values are converted uniquely.  But
only one NaN value is converted because IEEE-754 operations provide no
way to distinguish NaNs.

Mandating more than one portable NaN value will necessitate
non-IEEE-754 mangling of flonums.  The ultimate extension of this idea
is the NaN-based pointer regimes mentioned in SRFI-70 discussions:
<http://srfi.schemers.org/srfi-70/mail-archive/msg00079.html>

 | > One could use NaNs for all sorts of purposes.  I think they are
 | > most useful when they flag impossible and unplanned-for numerical
 | > errors.

IEEE-754:1985 section 6.2:
 ...
 Quiet NaNs should, by means left to the implementor's discretion,
 afford retrospective diagnostic information inherited from invalid or
 unavailable data and results.

 | That's a valid opinion, but I do not share it.  I use them quite
 | usefully to flag possible and planned-for events for which there is
 | no other good answer.

Such reasonable disagreement is why R6RS should *not* specify a read
or write syntax for NaNs.  Implementations should be free to have
read/write syntax for NaNs or not.