[Haskell-cafe] Making new Unboxed Algebraic Types? (A Repa Problem)

Hans Georg Schaathun georg+haskell at schaathun.net
Mon Jun 30 18:55:02 UTC 2014


could someone offer som advice on handling composite types with
the Repa library?  I can see a /long/ way around my problem, but
I wonder what is the /best/ way ...

The problem is that I am trying to parallellise a probabilistic
algorithm using Repa.  To handle pseudo-randomness in parallel,
I couple each data element with a generator state, in a tuple.
The generator state is of type TFGen (tf-random package) or
StdGen¹ (random package), neither of which is an Unbox instance.
Hence, I have been using boxed repa arrays.

The code does not execute in parallel, and if I understand correctly
this is because of the Boxed type.  There is a workaround², but that
requires an NFData instance.

To make a NFData instance and work through the code to support it
should be as simple as it is tedious, but it would still leave the
other drawbacks of a boxed type.  (In particular, I do sequential
fold because the Repa fold function did not support boxed types.)

I could of course rewrite the published libraries to use tuples instead
of algebraic types, and benefit from the pre-made Unbox instances, but
sounds messy and error-prone (as well as boring).  If I have to I have

Is there a quick and robust way to make Unbox instances from composite
datatypes?  Or any other advice on how to approach the matter?
Both random ideas, references, and concrete solutions are welcome.

[The other element of the tuple is an vector of unboxed constituent
type.  I am not sure how that's going to work, but I'll cross that
bridge when I get there.  For the time being it is the generator that
stops type checking.]


¹ Yes, I know that StdGen is statistically unsound.
² http://stackoverflow.com/questions/16097418/parallel-repa-code-doesnt-create-sparks

:-- Hans Georg

More information about the Haskell-Cafe mailing list