+1 to splitting off Fixed as well.<br><br><div class="gmail_quote">On Sun, Dec 2, 2012 at 4:55 AM, Ashley Yakeley <span dir="ltr"><<a href="mailto:ashley@semantic.org" target="_blank">ashley@semantic.org</a>></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 02/12/12 01:25, Herbert Valerio Riedel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Edward Kmett <<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>> writes:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To be frank, I would just rather have access to the constructor to Fixed.<br>
<br>
It honestly strikes me as silly to have to pay for a division and/or<br>
multiplication every time I want to access one.<br>
<br>
There in an ideological distinction being maintained here about the one<br>
true usage pattern that has forced me to reimplement Data.Fixed in my own<br>
code to avoid the overhead. =(<br>
</blockquote>
Fwiw, I've sometimes wanted to have 'Int' based fixed-precision<br>
arithmetic, and the current Data.Fixed allows only for "big-num" based<br>
fixed-precision types.<br>
<br>
Just a thought: Why does Data.Fixed have to be in 'base' anyway if the<br>
interface doesn't seem to be agreed upon by everyone? Can't we split it<br>
off into a separate package where it can more easily evolve into a<br>
richer API?<br>
</blockquote>
<br></div>
+1 to both of these ideas.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- Ashley<br>
</font></span></blockquote></div><br>