[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: arithmetic issues

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:

>  | From: Thomas Bushnell BSG <tb@xxxxxxxxxx>
>  | Date: Fri, 21 Oct 2005 18:22:45 -0700
>  | 
>  | Aubrey Jaffer <agj@xxxxxxxxxxxx> writes:
>  | 
>  | > I think that an implementation should be allowed to signal an
>  | > error under some conditions where an error object is encountered.
>  | > Mandating readable written representations for error objects
>  | > prevents an implementation from signaling such errors.
>  | 
>  | I think this might be confused.  Surely the mandating of a
>  | representation would mean "if you print something (rather than
>  | signalling an error) you should print it such-and-such a way."
> 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.