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