I expect that this will not be easy to implement, because it requires interaction with things like the garbage collector. For example, UnboxPair will need a different info table for different a and b.

It might be possible to essentially specialize UnboxPair for each different a and b for which it is used, but that gets tricky with generic code.

I believe use-site code generation is the way to go. This is what C++ does (at compile time) and C# (at runtime, using the JIT) does.

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

Second idea: Introduce a new pragma, that has similar effect on
representations as DPH's [::] vector type. This new pragma does deep
unpacking, allowing for more types to be instances of the Unbox type.

Could this be handled by just having/deriving an Unbox instance for (a,b)? I imagine the Unbox type class would have to contain essentially the same things as Storable, maybe something like

type UnboxedRepr :: Int -> #
class Unbox a where
type Repr a :: # -- gives size and alignment
unbox :: a -> Repr a
box :: Repr a -> a

A problem with an instance (Unboxed a, Unboxed b) => Unboxed (a,b) is that it allows arbitrarily large unboxed values to be created at runtime. That doesn't work when you use specialization to create the needed info tables.

As I mentioned further up in the email, I think this needs to be done at compile time. However, I'm not sure type classes are the right mechanism, as they don't guarantee that the polymorphism is resolved at compile time. Perhaps type families, in some form, is the right solution.

-- Johan