Abstracting over things that can be unpacked

[Johan Tibell]

On Sat, Mar 3, 2012 at 8:06 AM, Twan van Laarhoven <twanvl at gmail.com> wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120304/6096c084/attachment.htm>