Re: [dylan] float-invalid proposal

That’s fine. I thought about it, and I’m not really sure what’s going on anyway. Like, how NaN fits in, and stuff.


On Jan 10, 2014, at 7:32 PM, Bruce Mitchener <[email protected]> wrote:

> Your suggestions are a separate proposal and unrelated to handling a new FP error condition.
> 
> I've also had to revert my changes as there are some issues with them.  The compiler can hit an invalid FP error during compilation sometimes (not sure why) and when it does, MPS asserts in lockli.c when allocating the error instance.
> 
>  - Bruce
> 
> 
> 
> On Fri, Jan 10, 2014 at 11:51 PM, Dustin Voss <[email protected]> wrote:
> 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
> 
> 
> _______________________________________________
> hackers mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/hackers

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