<br><div><span class="gmail_quote">On 6/20/07, <b class="gmail_sendername">Henning Thielemann</b> <<a href="mailto:lemming@henning-thielemann.de">lemming@henning-thielemann.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Do you have some examples, where such a data type is really superior to<br>strong typing? There are examples like computing the average, where a<br>natural number must be converted to a different type:<br> average xs = sum xs / fromIntegral (length xs)
<br> but this one can easily replaced by<br> average xs = sum xs / genericLength xs<br><br> Thus, before you spend much time on making Haskell closer to Perl, how<br>about collecting such examples, work out ways how to solve them elegantly
<br>in the presence of strong typing and set up a wiki page explaining how to<br>work with strongly typed numbers? I think, this topic really belongs to<br> <a href="http://www.haskell.org/haskellwiki/Category:FAQ">http://www.haskell.org/haskellwiki/Category:FAQ
</a><br> Strongly typed numbers are there for good reason: There is not one type<br>that can emulate the others. Floating point numbers are imprecise, a/b*b=a<br>does not hold in general. Rationals are precise but pi and sqrt 2 are not
<br>rational. People have designed languages again and again which ignore<br>this, and they failed. See e.g. MatLab which emulates an integer (and even<br>a boolean value) by a complex valued 1x1 matrix.<br></blockquote></div>
<br>That's a good idea too, perhaps I will do that. This would be a good thing to have on the wiki since it's clearly an issue that people learning Haskell struggle with (I certainly did). I also want to make clear, though, that I certainly appreciate the reasons for strongly typed numbers. I am not trying to make Haskell closer to Perl in general (God forbid!), or in any way advocate for doing away with strongly typed numbers, but only to create a library for working more conveniently with numeric types in small programs where the typing is not as important. To give a couple quick examples, based on what I have already implemented:
<br><br>*EasyNum> 1 / 3<br>0.3333333333333333<br>*EasyNum> 1 / 3 :: EasyNum<br>1/3<br>*EasyNum> 1 / floor pi<br><br><interactive>:1:4:<br> Ambiguous type variable `t' in the constraints:<br> `Integral t' arising from use of `floor' at <interactive>:1:4-11
<br> `Fractional t' arising from use of `/' at <interactive>:1:0-11<br> Probable fix: add a type signature that fixes these type variable(s)<br>*EasyNum> 1 / floor pi :: EasyNum<br>1/3<br><br>I would have also put in the example of 1 / pi :: EasyNum and show it printing out a double value instead of the rational it prints with 1 / 3, except I haven't yet implemented the instance of Floating. =)
<br><br>-Brent<br>