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