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

Herbert Valerio Riedel hvr at
Mon Sep 24 15:22:26 CEST 2012

Ben Millwood <haskell at> writes:

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

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.

More information about the Libraries mailing list