Re: [dylan] float-invalid proposal

Dustin Voss <[email protected]> Sun, 05 Jan 2014 12:16:14 -0800
Newsgroups gmane.comp.lang.dylan.gwydion.devel
Message-ID <[email protected]>
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