Abstracting over things that can be unpacked
Simon Peyton-Jones
simonpj at microsoft.com
Tue Mar 6 23:40:12 CET 2012
First idea: instead of rejecting unpack pragmas on polymorphic fields, have them require a class constraint on the field types. Example:
data UnboxPair a b = (Unbox a, Unbox b) => UP {-# UNPACK #-} !a {-# UNPACK #-} !b
The Unbox type class would be similar in spirit to the class with the same name in the vector package, but be implemented internally by GHC. To a first approximation instances would only exist for fields that unpack to non-pointer types (e.g. Int.)
Johan I don't understand how this would work. What methods does the class Unbox have? What is the final representation of a UP constructor? How many words? Pointers or non-pointers?
At the moment each constructor has a fixed layout.
I'm really not sure what you have in mind here. More detail needed!
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120306/3580fc88/attachment.htm>
More information about the Glasgow-haskell-users
mailing list