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


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.

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.