add Storable a => Storable (Ratio a) and Storable a => Storable (Complex a) to base

[Edward Kmett]

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 at 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 at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141103/2d9401fc/attachment.html>