-Edward

On Tue, Jun 5, 2012 at 9:35 PM, Conrad Parker <conrad@metadecks.org> wrote:

On 5 June 2012 17:24, Henning Thielemann <lemming@henning-thielemann.de> wrote:
>
> On Tue, 5 Jun 2012, Kazu Yamamoto (山本和彦) wrote:
>
>> Some functions in Data.Ratio call the error function. The following is
>> an example:
>>
>> recip (0:%_) = error "Ratio.%: zero denominator"
>>
>> We cannot catch this error as ArithException since it is ErrorCall.
>> Are there any reasons to not use ArithException?
>
>
> It is intended that you do not divide by zero, also because it is so simple
> to check it before calling the function.

Surely if that expectation (that the user not divide by zero) was
actually part of the design intention, then the check within the
function itself would be redundant.

There is already a check within the function. Perhaps changing its
behaviour to use the existing ArithException DivideByZero would be
consistent with other types?

+1 to Kazu's suggestion to throw DivideByZero.

For the implementation, if the underlying type throws DivideByZero on
division by zero anyway, perhaps all that is requried is to remove the
check.

> The best solution would certainly
> be a number type that excludes zero values, such that division by zero can
> be catched at compile time. But currently Haskell's type system may not be
> expressive enough to handle this without a lot of explicit type conversion.

Indeed, it'd be fun to implement this properly in a different
language. For now let's narrow our options down to things that work in
Haskell.

Conrad.

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries