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