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

[Simon Marlow]

On 24/09/2012 14:22, Herbert Valerio Riedel wrote:
> 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.

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