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

[Herbert Valerio Riedel]

Ben Millwood <haskell at benmachine.co.uk> writes:

> On Sun, Sep 23, 2012 at 7:13 AM, wren ng thornton <wren at freegeek.org> 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.