Re: [dylan] float-invalid proposal

One other point:

If the condition handler returns a value, that value would be used for the result of the entire runtime function. If there is a function A that, say, performs several division operations B₁–B₉, and operation B₃ turns out to be division-by-zero, the handler’s returned value is used for the value of function A, not B₃.

To make that work, A would have to enclose its body in a block…exception…end statement, and that statement’s exception clause would have to signal the condition. (It would have to do that anyway to properly describe the condition.)


On Jan 5, 2014, at 12:16 PM, Dustin Voss <[email protected]> wrote:

> The DRM already says that “/” can signal an error for division by zero, so we don’t need to alter the language spec by adding <arithmetic-domain-error>. That said, I think it would be fine to elevate this particular condition above all the others in the DRM where it just says “blah-blah-blah signals an error.”
> 
> If we proceed, I suggest the following:
> 
> <arithmetic-domain-error> inherits from <serious-condition>, not <error>. I think it is more akin to a network problem (given as an example of <serious-condition>) than to a <type-error> (an example of an <error>).
> It should have a recovery protocol:
> A condition handler can return a value. The runtime will use that returned value as a substitute result for the failed operation.
> The runtime will not establish a <restart> handler.
> 
> On Jan 5, 2014, at 1:48 AM, Bruce Mitchener <[email protected]> wrote:
> 
>> I'm looking through some changes that prom had been working on for handling floating point errors in the C runtime and I see that he had a change to add:
>> 
>> +define sealed class <arithmetic-domain-error> (<arithmetic-error>)
>> +  inherited slot condition-format-string = "Arithmetic domain error";
>> +end class <arithmetic-domain-error>;
>> +
>> +define sealed domain make (singleton(<arithmetic-domain-error>));
>> +define sealed domain initialize (<arithmetic-domain-error>);
>> 
>> And:
>> 
>> +define function float-invalid ()
>> +  error(make(<arithmetic-domain-error>))
>> +end function float-invalid;
>> 
>> (and the corresponding exports from the dylan library / module)
>> 
>> His commit comment was:
>> 
>>     Add runtime support for float-invalid exceptions
>> 
>>     This exception is thrown by libm functions, so it should
>>     be translated to conditions just like the other ones.
>> 
>>     This should be properly thought through and documented
>>     as a language extension.
>> 
>> I'd like to suggest that we think this through and do this.
>> 
>> Any thoughts, objections, statements of approval, etc?
>> 
>>  - Bruce
>> 
>> _______________________________________________
>> hackers mailing list
>> [email protected]
>> https://lists.opendylan.org/mailman/listinfo/hackers
> 
> _______________________________________________
> hackers mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/hackers

_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers