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. So I hope the proposer responds soon. This proposal will not get very far unless it is completely clear what is being proposed. Thanks, Yitz

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 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.

Oh yes, you're right. But I don't think it's necessary.

-- Ashley

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries

Edward Kmett writes:

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

+1 to splitting off Fixed as well. On Sun, Dec 2, 2012 at 4:55 AM, Ashley Yakeley wrote:

On 02/12/12 01:25, Herbert Valerio Riedel wrote:

...

Edward Kmett writes:

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?

+1 to both of these ideas.

-- Ashley

On Mon, Dec 3, 2012 at 4:07 PM, Edward Kmett wrote:

+1 to splitting off Fixed as well.

-1 on this count from me, and a +1 to simply exposing Data.Fixed.Fixed's constructor. -- Gregory Collins

On 07/12/12 09:15, Ian Lynagh wrote:

On Sat, Dec 01, 2012 at 09:14:28PM -0500, Edward Kmett wrote:

...

To be frank, I would just rather have access to the constructor to Fixed.

I would prefer this, in Data.Fixed.Internal[s], to the original proposal.

Is another module really necessary? Note that fromEnum and toEnum already expose the internal Integer, badly, as an Int. These are the changes I think we should make to Fixed: 1. Make the internal type generic, similar to Ratio/Rational. 2. Make access to the internal type easy and fast. Ratio has numerator/denominator/(%), but Ratio needs to canonicalise its values to lowest terms. Fixed doesn't need that, so exposing the constructor should serve. 3. Move Data.Fixed into a new package, possibly with Data.Ratio and perhaps other numerics stuff that can be moved out of base. 4. Move div', mod' and divmod' to a more sensible module and maybe rename them, or have them replace div, mod and divmod. I am somewhat motivated to 1 by calls to make certain time types generic, although that's a separate discussion with its own issues. -- Ashley

On Fri, Dec 07, 2012 at 09:49:04PM -0800, Ashley Yakeley wrote:

On 07/12/12 09:15, Ian Lynagh wrote:

...

On Sat, Dec 01, 2012 at 09:14:28PM -0500, Edward Kmett wrote:

...

To be frank, I would just rather have access to the constructor to Fixed.

I would prefer this, in Data.Fixed.Internal[s], to the original proposal.

Is another module really necessary? Note that fromEnum and toEnum already expose the internal Integer, badly, as an Int.

Exporting it from Data.Fixed would also be fine with me. Thanks Ian