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!

-------------- 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