#13498: More storable instances? -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Storable, | Foreign, Ptr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by wyager):
the encoding would be quite arbitrary
How is this an argument against adding the encodings? If they function correctly, why does it matter that they aren't "fixed" in some sense?
Why are the tags 8 bit wide, and why are the tag values 0 and 1?
Because it makes sense and works. Why, for a {{{Ratio}}}, is the numerator stored before the denominator? Presumably for the same reason. The choice of representation doesn't really matter a whole lot; the point of this feature request isn't to bikeshed over the exact implementation, but to establish if there's some fundamental stumbling block with this approach.
then there is the issue of alignment
I *think* my `lcm` trick solves this for sum types. For product types, there are some obvious approaches.
If you need serialization, you can use `Data.Binary`.
Besides `Data.Binary` being vastly slower than `Storable`, the primary use case here is `Data.Vector.Storable` and `Data.Array.Storable`. You can't write an `Unbox` instance for `Maybe a`, but you can (as I've done here) write a `Storable` instance. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13498#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler