Proposal: Adding generics-based rnf-helper to `deepseq`
Herbert Valerio Riedel
hvr at gnu.org
Mon Sep 24 15:22:26 CEST 2012
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
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