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

On 24/09/2012 14:22, Herbert Valerio Riedel wrote:

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.

So, just to make sure I've followed, the conclusion is that we don't want to modify the deepseq package because that would take it outside Haskell 98, and we don't want to have a conditional API (quite rightly). There's no disadvantage to having the generic functionality in a separate package, right? Cheers, Simon