In case anyone missed it, Liyang HU wrote a TH deriver for Unbox instances[1]. 

Also, I have tried using GHC's new generic deriving[2] to derive instances - this is almost possible, but is blocked by a GHC issue[3]. IMHO generic deriving would be the best solution (once it works), because it works for product types as well as newtypes, and requires no extra GHC assistance or TH.

[1] http://hackage.haskell.org/packages/archive/vector-th-unbox/0.1.0.0/doc/html/Data-Vector-Unboxed-Deriving.html
[2] http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/generic-programming.html
[3] http://hackage.haskell.org/trac/ghc/ticket/5936

Cheers,
Reiner

On 30 May 2012 22:03, Daniel Peebles <pumpkingod@gmail.com> wrote:
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


_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries