Paul Schlie <xxxxxx@comcast.net> writes:

> 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,

IEEE-754 already specifies that (the "invalid" exception). But it's
important to be able to proceed without establishing an explicit
handler too, in which case NaN is returned.

Since the presence of invalid operations in inexact arithmetic depends
on rounding errors for unfortunate input, and not merely on bugs in
the program, it should not be fatal by default. It's hard to predict
at which stage it will happen before it happens, thus it's important
to be able to set it up such that it produces a value which behaves
like a number (doesn't cause further errors in numeric processing),
so it can be checked at convenient places instead of after each
operation.

> 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).

If it's not mandated, then I can't rely on that. It increases the
amount of unportable code relying on a useful feature which is present
everywhere in practice but not formally standard, and decreases the
usefulness of 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.

The point in NaN is that it passes through arithmetic without errors,
so checking for it can be postponed. It makes no sense to replace it
with something which is not a valid argument of arithmetic.

For operations which don't uniformly work on inexact numbers such
object is much less useful. For non-numbers the behavior is generally
predictable and bad arguments imply a bug in the program rather than
unfortunate data.

Why so many people want to "fix" aspects of IEEE which are not broken?

--
   __("<         Marcin Kowalczyk
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/