Unboxed Vectors of newtype'd values

[Bas van Dijk]

On 6 June 2012 09:59, Simon Peyton-Jones <simonpj at microsoft.com> wrote:
>  * 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