| Date: Mon, 24 Oct 2005 15:53:55 -0500
 | From: Alan Watson <xxxxxx@astrosmo.unam.mx>
 |
 | Aubrey Jaffer wrote:
 | > 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.
 |
 | All hardware should recognize all NaNs.  Therefore, allowing NaNs
 | to be generated with aribitrary bit patterns is not a problem.
 | However, different hardware need not generate the same NaNs for
 | identical operands.

Having a universal read/write representation for arbitrary bit
patterms prevents including information like the procedure causing the
NaN in its printed representation.

 | However, I still think we need a read syntax.  Suppose program A
 | calculates a value and writes it to a file and program B reads the
 | value from the file and uses it.  Is is not useful for program A to
 | be able to communicate to program B that it got a NaN?

To evaluate this scenario, we must compare it with the alternatives.
In mission critical software, signaling an error instead of returning
NaNs is unacceptable.  Even if the error is caught, the computation is
curtailed, requiring higher levels of exception awareness which are
difficult to plan and test.

If program A writes out its state, it would be useful to see that NaNs
were computed.  It gives operators a chance to capture the use case
which provoked the error.  If the program state is very valuable, then
it can be repaired manually.

But if program B reads its initial state from the file, its reading of
NaNs puts errors into its state which can propagate and corrupt it.

This is not an entirely hypothetical scenario.  My database-backed
HTTP servers write out their (Scheme) databases after changes; and
read them in on reboot.

 | This would suggest we need a write syntax and a read syntax for
 | NaNs.

I disagree.