This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
Aubrey Jaffer <agj@xxxxxxxxxxxx> 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
\__/ qrczak@xxxxxxxxxx
^^ http://qrnik.knm.org.pl/~qrczak/