Edward Kmett
To be frank, I would just rather have access to the constructor to Fixed.
It honestly strikes me as silly to have to pay for a division and/or multiplication every time I want to access one.
There in an ideological distinction being maintained here about the one true usage pattern that has forced me to reimplement Data.Fixed in my own code to avoid the overhead. =(
Fwiw, I've sometimes wanted to have 'Int' based fixed-precision arithmetic, and the current Data.Fixed allows only for "big-num" based fixed-precision types. Just a thought: Why does Data.Fixed have to be in 'base' anyway if the interface doesn't seem to be agreed upon by everyone? Can't we split it off into a separate package where it can more easily evolve into a richer API? I've done a quick head-count over the ~4600 packages on hackage w.r.t. which import Data.Fixed, and I found the 45 packages below which directly import it. So splitting Data.Fixed from 'base' would affect only about 1% of packages... Chart-0.16 collada-output-0.6 complex-generic-0.1.1 configurator-0.2.0.1 deepseq-1.3.0.1 DisTract-0.2.5 ebeats-0.1.0 esotericbot-0.0.6 fixed-point-0.5.0.1 gearbox-1.0.0.1 Geodetic-0.4 gluturtle-0.0.56 gps-1.1 GPX-0.7.0 has-0.5.0.1 haskell-platform-test-2010.2.0.0 HDBC-2.3.1.1 hsc3-0.12 husk-scheme-3.6 lambdabot-4.2.3.3 network-bitcoin-1.0.1 Noise-1.0.5 penny-lib-0.4.0.0 postgresql-simple-0.2.4.1 propane-0.1 QuickCheck-2.5.1.1 quickcheck-instances-0.3.1 random-extras-0.19 random-fu-0.2.3.1 remote-0.1.1 repr-0.4.1.3 RNAwolf-0.4.0.0 rsagl-0.6.0.1 rsagl-math-0.6.0.1 safecopy-0.7.1 sindre-0.4 tamarin-prover-0.8.2.1 time-1.4.0.1 time-http-0.5 time-lens-0.3 timeparsers-0.3.2 time-w3c-0.1.0.1 webdriver-0.4 wxturtle-0.0.1 xturtle-0.1.11 cheers, hvr