reading NaNs

[Aubrey Jaffer <agj@xxxxxxxxxxxx>]

 | Date: Mon, 24 Oct 2005 03:25:09 -0500
 | From: Alan Watson <a.watson@xxxxxxxxxxxxxxxx>
 | 
 | NaNs are atoms -- they have no context or stucture, just a single
 | value.

In an implementation which boxes flonums, NaNs aren't a single value;
EQ? and EQV? are *not* guaranteed to return #t given two NaNs.

 [Read-sytnax for singular objects is useful because it allows those
 objects to be put in CASE clauses.  But this works only for objects
 which match under EQV?.]

 | With the understandable exception of the eof object (and as has
 | been noted, this is exception is not universal), Lisps and Schemes
 | tranditionally provide read syntax for atoms.

Closures and continuations are atomic; R5RS provides no way to
deconstruct them.  Yet every implementation I have encountered has a
write syntax without a corresponding read syntax for them.

 | So, tradition suggests that we should have a read syntax for NaNs.

Are you suggesting a single NaN or multiple distinct NaNs?

To support existing IEEE-754 hardware, R6RS must not mandate multiple
distinct NaNs.  But specifying a singular NaN prevents implementations
from fully supporting IEEE-754 in the future.

Thus R6RS should declare that NaNs are numerical error-objects [or
condition-objects, whatever], and leave the rest to implementations.

We worked through this issue in SRFI-70.  I think SRFI-70's treatment
is Schemely, compatible with IEEE-754, and doesn't unnecessarily
constrain implementations:

  The notation 0/0 is used within this report to designate a numerical
  error-object.  A numerical function may return such an object when
  no other number (including real infinities) is the correct value.
  An implementation may report a violation of an implementation
  restriction in any calculation for which the result would be 0/0.