NaN's Paul Schlie (29 Oct 2005 15:50 UTC)
Re: NaN's Marcin 'Qrczak' Kowalczyk (29 Oct 2005 16:39 UTC)
Re: NaN's Paul Schlie (29 Oct 2005 18:22 UTC)
Re: NaN's Marcin 'Qrczak' Kowalczyk (29 Oct 2005 19:14 UTC)
Re: NaN's Paul Schlie (29 Oct 2005 22:49 UTC)
Error objects in general bear (29 Oct 2005 19:46 UTC)
Re: Error objects in general Marcin 'Qrczak' Kowalczyk (29 Oct 2005 20:22 UTC)
Re: Error objects in general bear (30 Oct 2005 05:57 UTC)
Re: Error objects in general Marcin 'Qrczak' Kowalczyk (30 Oct 2005 14:17 UTC)
Re: Error objects in general Alan Watson (29 Oct 2005 21:26 UTC)
Re: Error objects in general bear (30 Oct 2005 05:40 UTC)
Re: Error objects in general Taylor Campbell (30 Oct 2005 05:45 UTC)
Re: Error objects in general bear (30 Oct 2005 06:08 UTC)
Re: Error objects in general Taylor Campbell (30 Oct 2005 16:49 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 05:54 UTC)
Re: Error objects in general bear (30 Oct 2005 06:07 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 06:46 UTC)
Re: Error objects in general Paul Schlie (30 Oct 2005 12:39 UTC)
Re: Error objects in general Paul Schlie (30 Oct 2005 13:04 UTC)
Re: Error objects in general John.Cowan (30 Oct 2005 16:30 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 20:29 UTC)
Re: Error objects in general Alan Watson (30 Oct 2005 13:17 UTC)

NaN's Paul Schlie 29 Oct 2005 15:50 UTC

Upon further thought, it's not clear that specifying a NaN error-object
is necessary or desirable; as in all cases it would appear preferable to
signal a recoverable exception, upon which a default most-likely-useful
value based on the context of the calculation is returned, or optional
alternative action (potentially inclusive of a halting error) may be
invoked if specified. Thereby alleviating any explicit need for a
non-numerical error object itself.

Where then default most-likely-useful numeral results may be specified if
desired, or left implementation specific (whereby then an implementation
may choose to explicitly represent a NaN error-object it so chooses,
however not mandated to do so by the standard).

Where then, an error-object may be independently specified as a proposed
srfi independently, where by then such an object (such as <void> for the
sake of argument), may be returned in lieu of an otherwise valid object as
a result of any calculation, numeral or otherwise, as may be desired in lieu
of a recoverable exception handler returning an otherwise more useful value.

As just a thought.