Unboxed Vectors of newtype'd values
pumpkingod at gmail.com
Thu May 31 07:03:46 CEST 2012
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.
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.
> Libraries mailing list
> Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries