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@gmail.com] | Sent: 04 June 2012 20:58 | To: Bas van Dijk | Cc: Simon Peyton-Jones; Bryan O'Sullivan; Jake McArthur; | libraries@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