Re: [dylan] float-invalid proposal

To clarify, this looks like prom’s change without my suggestions of a recovery protocol or inheriting from <serious-condition> instead of <error>.

(I believe that when the DRM talks about “signaling an error” in plain type, it does not necessarily require the implementation to call error() or signal an <error>; I believe it simply means signaling a condition that corresponds to something erroneous about the program.)


On Jan 10, 2014, at 3:44 AM, Bruce Mitchener <[email protected]> wrote:

> For reference, this is done for HARP on all platforms that HARP supports:
> 
>   https://github.com/dylan-lang/opendylan/pull/642
> 
>  - Bruce
> 
> 
> On Mon, Jan 6, 2014 at 9:28 AM, Bruce Mitchener <[email protected]> wrote:
> 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

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