Unboxed Vectors of newtype'd values

[Simon Peyton-Jones]

| > So Andres has explained how to do what Johan asks.  Does that mean
| > that Bas’s problem is solved?
| 
| My problem can't be solved with GeneralizedNewtypeDeriving since a UUID
| is not a newtype but an abstract data type defined in another
| package[1].
| 
| However, the template-haskell from the vector-th-unbox package which
| Reiner mentioned does the job perfectly:
| 
| derivingUnbox "UUID"
|     [d| instance Unbox' UUID (Word32, Word32, Word32, Word32) |]
|     [| \ uuid -> UUID.toWords uuid|]
|     [| \ (a,b,c,d) -> UUID.fromWords a b c d |]

Ah, well, that is another matter.

GeneralisedNewtypeDeriving respects the abstraction boundaries imposed by the package author.  I think Template Haskell does not.  It probably should; see [1].

So it seems that 
 * generalised newtype deriving will do your job, if you
   can persuade the package author to expose the representation
 * Template Haskell can do the job, but only because of a bug (arguably)

So this is really a library design question, not a language design one.  If a package author makes a type abstract, he's saying that he does not want you to look at the representation; and yet you must if you want to unbox it. So you must negotiate with the package author.  I don't see how the language can (a) respect abstractions and (b) let you retrospectively unbox abstract types.


[1] http://stackoverflow.com/questions/10857030/whats-so-bad-about-template-haskell