Unboxed Vectors of newtype'd values

[Daniel Peebles]

It seems like the most elegant long-term solution here is to make
GeneralizedNewtypeDeriving more cunning. Is there some fundamental reason
it can't work with the type families involved?

But in the short term, I agree and TH is probably best.

-Dan

On Wed, May 30, 2012 at 3:41 PM, Roman Leshchinskiy <rl at cse.unsw.edu.au>wrote:

> On 30/05/2012, at 05:27, Ben Gamari wrote:
>
> > Sadly, these two features don't interact particularly well. While the
> > Data.Vector.Unbox documentation claims that "Implementing unboxed
> > vectors for new data types can be very easy", it then goes on to list an
> > abridged version of the Complex instance---dozens of lines of
> > code. While this code certainly isn't difficult to write, it is time
> > consuming, error-prone, and, above else, utterly mind deadeningly dull
> > (making it quite uncharacteristic for Haskell). So dull that I generally
> > avoid newtypes at all cost in code that might need to use unboxed
> > vectors. This boilerplate is largely due to Vector's use of type
> > families as this precludes the use of (the otherwise quite cunning)
> > GeneralizedNewtypeDeriving to automatically derive the necessary
> > instances.
>
>
> I completely agree that the current situation is less than ideal but don't
> really have a good solution. Frankly, the easiest way of defining Unbox
> instances for newtypes is probably a preprocessor macro. I use a lot of
> those in vector to reduce boilerplate and they work well. I'll provide one
> for newtypes in the next release.
>
> As you say, TH is another possibility but one I'm rather wary of.
>
> Roman
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120531/8567dec5/attachment.htm>