On 6 June 2012 09:59, Simon Peyton-Jones
* generalised newtype deriving will do your job, if you can persuade the package author to expose the representation
Just exposing the representation is not enough to get GeneralizedNewtypeDeriving to work since UUIDs are not newtypes but datatypes. The only way to get it to work is to persuade the author to expose the representation _and_ turn it into a newtype. But a newtype of what? newtype UUID = UUID (Word32,Word32,Word32,Word32) is not better than the current fully unboxed representation.
* Template Haskell can do the job, but only because of a bug (arguably)
I don't think vector-th-unbox is exploiting a bug. It doesn't need to inspect the private representation of a UUID. The only thing that it needs is a type that is isomorphic to a UUID and conversion functions between them.
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.
Agreed. Regards, Bas