Aubrey Jaffer <xxxxxx@alum.mit.edu> writes:

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

Consider three possibilities of a pair of programs which communicate
floating point data between them in text form:

1. Program A handles the possibility of numerically bad data.
   Then NaN will not appear in the data to be written, no issue.

2. Program B handles the possibility of numerically bad data.
   You are breaking this scenario.

3. Neither program handles the possibility of numerically bad data.
   This pair of programs is buggy and introducing errors during
   reading will not make them work.

                          *       *       *

Lisp and Scheme programs use write and read for Serialization. In the
following cases Scheme read doesn't return the same data that was written:

- Procedures, ports, promises, environments. Serializing them is in
  general unimplementable, there are conceptual obstacles.

- Sharing of stateful objects is not preserved, cycles break the
  printer. Lisp optionally handles that but Scheme does not. This is
  costly for the implementation, Scheme tends to be minimalistic,
  and sharing would only work within a single datum anyway.

- The eof object. It's because read returns it to indicate that there
  were no more data to read.

That's all. All other standard data are printable and readable,
including all numbers. Non-standard data either falls into the first
category, or it's not clear how to derive the format automatically,
or the implemenation was lazy.

There is no reason to break the standard way of serialization for NaN.

--
   __("<         Marcin Kowalczyk
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/