Data.Ratio and exceptions

[Edward Kmett]

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 <conrad at metadecks.org> wrote:

> On 5 June 2012 17:24, Henning Thielemann <lemming at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120605/1b050f6c/attachment.htm>