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.<div>
<br></div><div>-Edward<br><br><div class="gmail_quote">On Tue, Jun 5, 2012 at 9:35 PM, Conrad Parker <span dir="ltr">&lt;<a href="mailto:conrad@metadecks.org" target="_blank">conrad@metadecks.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 5 June 2012 17:24, Henning Thielemann &lt;<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>&gt; wrote:<br>

&gt;<br>
&gt; On Tue, 5 Jun 2012, Kazu Yamamoto (山本和彦) wrote:<br>
&gt;<br>
&gt;&gt; Some functions in Data.Ratio call the error function. The following is<br>
&gt;&gt; an example:<br>
&gt;&gt;<br>
&gt;&gt;   recip (0:%_)        = error &quot;Ratio.%: zero denominator&quot;<br>
&gt;&gt;<br>
&gt;&gt; We cannot catch this error as ArithException since it is ErrorCall.<br>
&gt;&gt; Are there any reasons to not use ArithException?<br>
&gt;<br>
&gt;<br>
&gt; It is intended that you do not divide by zero, also because it is so simple<br>
&gt; to check it before calling the function.<br>
<br>
</div>Surely if that expectation (that the user not divide by zero) was<br>
actually part of the design intention, then the check within the<br>
function itself would be redundant.<br>
<br>
There is already a check within the function. Perhaps changing its<br>
behaviour to use the existing ArithException DivideByZero would be<br>
consistent with other types?<br>
<br>
+1 to Kazu&#39;s suggestion to throw DivideByZero.<br>
<br>
For the implementation, if the underlying type throws DivideByZero on<br>
division by zero anyway, perhaps all that is requried is to remove the<br>
check.<br>
<div class="im"><br>
&gt; The best solution would certainly<br>
&gt; be a number type that excludes zero values, such that division by zero can<br>
&gt; be catched at compile time. But currently Haskell&#39;s type system may not be<br>
&gt; expressive enough to handle this without a lot of explicit type conversion.<br>
<br>
</div>Indeed, it&#39;d be fun to implement this properly in a different<br>
language. For now let&#39;s narrow our options down to things that work in<br>
Haskell.<br>
<span class="HOEnZb"><font color="#888888"><br>
Conrad.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>