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. =(
You can bury it in an Internal module or something and load it with caveats about how it is a bad idea to use and how you reserve the right to change it some day, but without it Data.Fixed remains almost useless to me.
The Binary instance can trivially be implemented on top of that, as we shoudn't be encoding type (precision) information in the Binary data stream.
-Edward
On Sat, Dec 1, 2012 at 5:54 PM, Ashley Yakeley
<ashley@semantic.org> wrote:
On 01/12/12 12:11, Yitzchak Gale wrote:
Jeff Shaw wrote:
In my work I've run into an annoyance: Data.Fixed.Fixed does not
have a
Binary instance in the binary package.
Ashley Yakeley wrote:
Just to be clear, this is a modification of binary, not Data.Fixed
in base, is that correct?
Hmm, I had understood just the opposite:
that the proposal was to add fromFixed/toFixed
to Data.Fixed, motivated by the difficulty of things
like writing a Binary instance.