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?
On 30/05/2012, at 05:27, Ben Gamari wrote: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.
> 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.
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