Unboxed Vectors of newtype'd values

Johan Tibell johan.tibell at gmail.com
Tue Jun 5 18:32:24 CEST 2012


On Tue, Jun 5, 2012 at 12:06 AM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> I'm sorry I'm still struggling.  In your example below you bind 'a' twice, once with the "data UnpackedList a" and once with the "forall a".  Did you intend an existential?

I didn't intend the existential. I haven't made any real progress on
my unpacking problem since we last talked so lets let it rest for now.
I'll try to find some time to write down a wiki page so we at least
know where we got stuck last time. Perhaps someone reading it will
have an aha moment that will let us move forward.

> Also I don't know what you mean by "generate appropriate type definitions at call sites".

If I write:

    module A

    data UnpackedList a = Unbox a => Cons {-# UNPACK #-} !a
(UnpackedList a) | Nil
    { -# INLINABLE_DATA UnpackedList #-}  -- Like INLINABLE, but for data types

    module B

    f :: UnpackedList Int -> ...

I'd like GHC to generate

    data UnpackedListInt = ConsInt {-# UNPACK #-} !Int UnpackedListInt | NilInt

and a specialized version of f, using that type, in B. It's a bit like
the call-site specialization afforded by the INLINABLE pragma, but
applied also to data type definitions.

You might protest and say that I could just just use type families,
but they don't work well if my type has more than one type parameter
(e.g. Map), as I need to write O(n^2) instances:

instance Map Int Int where
    type Map = MapIntInt ...{-# UNPACK #-} !Int {-# UNPACK #-} !Int...

instance Map Int Char where
    type Map = MapIntChar ...

instance Map Int (Int, Int) where
   type Map = MapIntIntInt ...

That's 50,625 instances to just cover the basic types (e.g. Int, Word,
etc) and pairs. The reason you'd want call-site generation of data
types (ala C++ templates) is that a real program would only use no
more than 100 (for a big program) of the potentially infinite number
of combinations.

> Anyway thanks for distinguishing the two threads.  If you can clarify the generalised newtype deriving problem too that would be great.

I'll leave it to others. I'm not quite sure what the issue is.

-- Johan



More information about the Libraries mailing list