Unboxed Vectors of newtype'd values

[Simon Peyton-Jones]

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?

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

I do remember a dinner conversation in Tokyo where I couldn't figure out how to implement what you wanted, but I've forgotten the details.  Maybe it's worth a wiki page to explain -- or maybe not if its un-implementable.

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

Simon

| -----Original Message-----
| From: Johan Tibell [mailto:johan.tibell at gmail.com]
| Sent: 04 June 2012 20:58
| To: Bas van Dijk
| Cc: Simon Peyton-Jones; Bryan O'Sullivan; Jake McArthur;
| libraries at haskell.org
| Subject: Re: Unboxed Vectors of newtype'd values
| 
| My desire probably doesn't overlap much with what others have described
| in this thread, apologies. I *think* they want generalized newtype
| deriving to work for Unbox instances.
| 
| I want to be able to write definition like this (pseudo code):
| 
|   data UnpackedList a = forall a. Unbox a => Cons {-# UNPACK #-} !a
| (UnpackedList a) | Nil
| 
| and have GHC generate appropriate data type definitions at call sites.
| In other words, I want polymorphic unpacking to work as long as the
| unpacked field is unboxable (i.e. is member of some Unobx type class.)
| 
| I believe I've described this desire to you before. Unfortunately it
| seems like a really hard problem.
| 
| -- Johan