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@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries