I think any such instance would have to enforce the invariants of the type and load via (%), which does mean it'd need the Integral constraint.

Loading and storing with Storable can already change some of the bits in all sorts of types. 

Nothing says that every bit configuration with a given size is a legal inhabitant of the type we store. Consider Storable Float and Storable Double: We silently change between quiet and signaling NaNs.

We've actually run into this in the wild at work, because a naive test we wrote was to round trip Ermine code by loading and serializing it and comparing the result bitwise, but loading and storing Floats/Doubles changed them.

Similarly if you had a padded struct nothing says we'd peek the bits in the gaps between fields.

So Storable (Ratio a) changing some bits if you round trip in and out isn't unusual at all and in that light, I'm generally in favor of having it for completeness.

That said I'd also support a longer term and much broader discussion about if we want Ratio a to exist at all. 

It doesn't support any of the usecases one would classically want out of a ring of fractions, and basically exists solely as a dangerous representation that blows up easily, and as a source of pain for users.

-Edward

On Mon, Nov 3, 2014 at 12:27 PM, Reid Barton <rwbarton@gmail.com> wrote:
For Storable (Ratio a), when peeking a (Ratio a) value, should the instance reduce it to lowest terms or not?

If not, then you can construct an unreduced (Ratio a) value, which AFAIK isn't otherwise possible with the Ratio API.

If so, then you need an (Integral a) constraint as well as (Storable a). Furthermore, peeking a value and poking it back may change the bytes stored at the Ptr, which is unusual behavior for a Storable instance.

Neither behavior seems generally useful to all programs, so I'm -1 on adding any instance for Storable (Ratio a).

+1 for Storable (Complex a) though.

Regards,
Reid Barton

On Mon, Nov 3, 2014 at 11:07 AM, Carter Schonwald <carter.schonwald@gmail.com> wrote:
Getting those two into base for 7.10 would be quite nice. 

I think this will mostly impact folks who maintain numerical computing libraries, such as myself, and even then, I think this would be a change well worth having!

discussion period 1 week  (because I'd like to get it OK'd with plenty of time before the merge window for 7.10 finally closes)

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries