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