Re: Data.Ratio and exceptions

I have to admit I rather prefer the notion of throwing a DivideByZero in this case as well, especially since a lot of things that would otherwise by Double/Float round trip through Rational temporarily during conversion. -Edward On Tue, Jun 5, 2012 at 9:35 PM, Conrad Parker wrote:

On 5 June 2012 17:24, Henning Thielemann 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