Re: [dylan] float-invalid proposal

On Mon, Jan 6, 2014 at 3:16 AM, 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.
>
>
The DRM doesn't specify the error or the error hierarchy involved for a
division by zero, just that an error is signaled.

An invalid floating point exception happens for things like 0/0, Infinity -
Infinity, and so on.  These aren't much different from a division by zero.
 I don't think it should have some other parent, these should all be
<arithmetic-error>.

In Haskell (for example), these all have the same parent (FloatException).

I think there's room for improving floating point control, like allowing
setting the rounding mode, in some other extensions, but adding the
float-invalid stuff that prom did is pretty straight forward (and doesn't
really involve modifying the DRM since the DRM doesn't comment much on this
subject).

 - Bruce

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