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 wrote:
| Aubrey Jaffer wrote: | > Having a universal read/write representation for arbitrary bit | > patterms prevents including information like the procedure | > causing the NaN in its printed representation.| | I don't see this. Can you elaborate?Suppose Scheme implementation X distinguishes NaNs by the procedure producing them and makes that information part of the printed representation for NaNs: (expt +inf.0 0) ==> #<not-a-number expt> (+ -inf.0 +inf.0) ==> #<not-a-number +> (/ (* 0 -inf.0) 3) ==> #<not-a-number *> (+ 5. (/ 0.0 0.0)) ==> #<not-a-number /> If R6RS has a universal read/write representation for arbitrary bit NaN patterns, then R6RS must assign bit patterns for all possible #<not-a-number {*}> syntaxes. If some future IEEE-754 hardware returns more than one NaN code, then its assignments are very unlikely to match the R6RS codes.
To me a compromise would be to standardize a simple #<not-a-number>; implementation X can allow users to change how NaN are to be printed via parameters (in the srfi-39 sense). Btw - I agree that #<not-a-number +> is a little more helpful than #<not-a-number> during debugging, but if there is no source location information to find the actual + producing the NaN then the helpfulness is limited. -- Jens Axel Søgaard