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

>  | From: Thomas Bushnell BSG <xxxxxx@becket.net>
>  | Date: Sat, 22 Oct 2005 17:47:25 -0700
>  |
>  | Aubrey Jaffer <xxxxxx@alum.mit.edu> writes:
>  | > ...
>  | > That still prevents an implementation from displaying information
>  | > about what type of NaN was returned.  Such information could be
>  | > helpful to find the call which generated the NaN.
>  |
>  | Huh?  How does it prevent such?  We *could* mandate a readable
>  | written representation for NaNs without manding that printing a NaN
>  | should produce that representation, since it would still be allowed
>  | to signal an error.  (And then, once it is signalled, it could
>  | print *anything it wants*.)
>  |
>  | Moreover, nothing prevents the mandated written representation from
>  | optionally including implementation defined contents, if that
>  | should be useful.
>
> When different NaNs are returned depending on the circumstances
> creating them, I would like my implementation to display them like
> this:
>
>   #<not-a-number expt>

Sure, that seems fine.  We could mandate that as the readable written
representation!