Should we have a Storable a => Storable (Ratio a) ?

[Carter Schonwald]

Hey Core Lib folks,

Recently, as part of a Libraries proposal to add Storable a =>  Storable (Complex a )  to Base, at Edwardk's behest I included suggesting Storable a => Storable (Ratio a)

While the Complex-Storable had pretty energetic support (heck, http://hackage.haskell.org/package/storable-complex has been a standardized orphan for EONS), the Ratio-Storable bit got a bit of contention

The arguments against Storable Ratios boiled down to arguments that Ratio types using Fixed / Finite range integral types like Word or Int etc can have pretty gnarly over/underflow issues, and thus perhaps We should ONLY have Ratio for things like Natural and Integer (which are better behaved in many respects). 

That is, arguments against Storable a => Storable (Ratio a) boil down to argument against Ratio a for base types that have a bounded range of integral values, rather than against the Storable instance 

I dont think rethinking parts of the numeric prelude we have in Base is in scope for 7.10, and if future evolution of base were to make such a storable instance out of date, well, it'd be easy to drop it later, while avoiding needless orphans in the mean time (granted, storable-complex was a widely used orphan and  but I dont think ratio-storable was ever a thing).

I think i've (approximately) summarized the gist of the Associated Libraries list thread plus my own thoughts on top.

thoughts?

-Carter

[Edward Kmett]

I'm personally fairly neutral on the Ratio thing tending towards mildly in favor:

On one hand, I think it probably should be there because it strikes me as rather silly to just randomly omit it, and the only option someone who _did_ want it would have would be to go write it themselves.

On the other hand:

1.) It encourages use of a dangerous type, (Ratio Int) and the like do bad things after surprisingly few multiplications of reasonably scaled arguments. 

2.) It would need to have an Integral constraint as well, lest loading/storing be able to generate a Ratio in unreduced form.

3.) It isn't a terribly pressing need. I've never seen anyone decry its lack.

On the other other hand:

#1 is an argument I don't give much weight to, because it strikes me that this instance isn't the right place to make this stand.

For #2 we already do some normalization on loads/stores for other types, so this isn't as alien as it seems at first.

#3 I have no answer to, other than that sort of reasoning tends to build code that doesn't work together by creating random barriers to use.

-Edward

--
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eric Mertens]

--

You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

I'm opposed to Storable instances that don't correspond directly to some specific C type. I don't like the use of Storable where it is just being used as an arbitrary way to serialize to a pointer. I don't want it to be another class like Binary, but rather to have it specifically about marshaling data and the C FFI.

As far as whether or not Ratio should be parameterized or not, I think that belongs in a different discussion and is not currently relevant. If we "fix" that type later we can fix the instance. Storable is not the place to punish people for using the "wrong" type parameter.

[Carter Schonwald]

Hrm, I'm not sure if thats quite true (at least any more)
To whit, Yuras has a WIP proposal to extend the Haskell C FFI to be able to give a first class treatment of applicabe Haskell data types / record types  (products not sums) https://ghc.haskell.org/trac/ghc/wiki/CStructures in a way that guarantees C ABI compliance with the analogous C Structs.  https://phabricator.haskell.org/D252 is the WIP code for the CMM layer 

I think that gives a reasonable formalized bar by which Base provided storable instances need to meet, and I think we hit that quality bar fo for a Storable instance of Ratio a (as well as for Complex-Storable)