Re: Proposal: Adding generics-based rnf-helper to `deepseq`

Ben Millwood writes:

On Sun, Sep 23, 2012 at 7:13 AM, wren ng thornton wrote:

...

I'm agnostic on the issue of including genericRnf rather than keeping the packages separate; but if it is included, I definitely think it ought to be put in a separate module. Having the API of a module depend on CPP/flags/... is a terrible maintenance issue--- for client code, I mean. But just having a module be absent/present makes the divide clear, and makes it a lot easier to work with.

I believe that Cabal is expressly designed so that exposed-modules cannot change based on configuration of things. Can anyone suggest a clear disadvantage for having the generics stuff remain in a separate package? It seems like the least problematic solution to me so far.

Fair enough, I've just uploaded a companion package providing the "Control.DeepSeq.Generics" module, see http://hackage.haskell.org/package/deepseq-generics-0.1.0.0 for documentation & usage examples So, regardless of whether `genericRnf` will be merged into `deepseq` at some point or not, `deepseq-generics` now provides Generics-based `rnf` support for older GHCs starting with version 7.4.1. I hope this will be useful to someone. Btw, I hacked up a test-suite for testing whether `genericRnf` works as expected. Suggestions/ideas on how to improve the current test-suite would be welcomed.