Re: Zeroes and infinities

[David Hough 754R work <754r@xxxxxxxxxxx>]

> 0) There is an abstract model, consistent set of conventions, call it
> what you will, so that all failures are detectable without more than
> rare false positives.  For some consistent meaning of "failures".

754 deals with exceptions, which might or might not be failures.
There is considerable agreement about what the exceptions are, 
but less so about which of them
are failures, and thus what the proper default responses should be.

> The one exception, which can only be a political objection, is to not
> include the LIA-1 mandatory mode "Terminate with message".  It is, after
> all, the oldest and most widespread exception handling mode of all ....

754R does provide in annex E:

 "Languages should define, and require implementations to provide, these 
non-resumable modes:

 -      transfer attached to a block: transfers control; no return possible. 
transfer is a language-specific idiom for non-resumable control transfer; 
conventional languages should offer several transfer idioms such as 
   -    goto label: label might be local or global according to the semantics 
of the language.
   -    break: abandon the block controlled by this exception handling and go 
to the next block.
   -    throw exceptionName: causes an exceptionName not to be handled locally, 
but rather signaled to the next handling in scope, perhaps the function that 
invoked the current subprogram, according to the semantics of that language. 
The invoker might handle exceptionName by default or by alternate handling such 
as signaling exceptionName to the next higher invoking subprogram."

and in annex G:

 "Debuggers should be able to detect and pause to the debugger when a 
prespecified exception is signaled within a particular subprogram, or within 
specified undebugged subprograms that it calls."


That's about the best that can be done in general.   Because 
in general, "Terminate with message" doesn't tell what to terminate
nor what the message should be nor to whom it should be directed.
Those are real issues in embedded systems running a single control loop.
I read yesterday a claim that the majority of the cars on the road have PowerPC
processors... presumably running nonstop 754 arithmetic. 

And even in traditional batch processing environments, "Terminate with message"
is seldom welcome as a default response for underflow or inexact.


In the original 754 context, if there is only going to be one 
exception handling response on which a programmer can rely on all platforms, it
had to be "nonstop default result and raise flag".

The legitimate complaint is that 754 required no portable way to get any
other handling when needed.