[Haskell-cafe] ANN: generic-deepseq 188.8.131.52
José Pedro Magalhães
jpm at cs.uu.nl
Mon Feb 20 08:06:39 CET 2012
2012/2/19 Bas van Dijk <v.dijk.bas at gmail.com>
> I do think it's better to integrate this into the deepseq package (and
> thus removing the default implementation of rnf). Otherwise we end up
> with two ways of evaluating values to normal form.
I agree with this, and I guess many people are already using the deepseq
package (simply because it was there first), so it would be better to
integrate the generic code with that package. As for the backwards
compatibility loss, it is indeed a pity that you are forced to choose
between a generic default and a "normal" default, but I don't see any easy
way to change that, and the current behaviour is simple and predictable. So
I do not propose we change that. In this case I agree with Bas, and propose
removing the "normal" default for `rnf`.
> One last issue: Say I have a type like: "data T = C !Int"
> Currently GHC Generics can't express the strictness annotation. This
> means that your deepseq will unnecessarily evaluate the Int (since it
> will always be evaluated already). It would be nice if the strictness
> information could be added to the K1 type. (José, would it be hard to
> add this to GHC.Generics?)
I don't think so; I think the right place to put it is as a method of the
Selector class, though.
But, I'm wondering, for your example, wouldn't/couldn't GHC optimize away
`seq` calls to strict arguments?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe