Unboxed Vectors of newtype'd values

Reiner Pope reiner.pope at gmail.com
Thu May 31 18:17:47 CEST 2012


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 at 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 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.
>>
>> Roman
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120531/f9763f2c/attachment.htm>


More information about the Libraries mailing list