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
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