Unboxed Vectors of newtype'd values

Simon Peyton-Jones simonpj at microsoft.com
Tue Jun 5 09:06:34 CEST 2012

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.


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

More information about the Libraries mailing list