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

wren ng thornton wren at
Mon Sep 24 01:02:49 CEST 2012

On 9/23/12 11:31 AM, Ben Millwood wrote:
> 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.

That's true, however you can have the entire contents of the module be 
hidden by CPP. This is how many of the STM data structures are handled.

(Thus, the client-side error isn't trying to import the module, but 
rather is trying to import any definitions from the module. But that's 
still preferable since it isolates the issues into a single module 
rather than having it mixed up with the shared definitions.)

Live well,

More information about the Libraries mailing list