Henning Thielemann writes:

As far as I know, deepseq is currently plain Haskell 98. This would no longer be true with a dependency on generics. Thus I would prefer to keep deepseq and generic-deepseq separated.

that's right (although one could make that an optional feature of the `deepseq` package, depending on the availability of the generics-feature, so that `deepseq` could still build with a pure H98 compiler) moreover, there's one important difference though between the implementation I included in the email and the original `generic-deepseq` package: The `generic-deepseq` package uses a completely separate `DeepSeq` type-class (the `generic-deepseq` package doesn't even depend on the `deepseq` package), whereas the code I posted is able to make use of existing `NFData` class instances.

Henning Thielemann writes:

On Fri, 21 Sep 2012, Herbert Valerio Riedel wrote:

...

Henning Thielemann writes:

...

As far as I know, deepseq is currently plain Haskell 98. This would no longer be true with a dependency on generics. Thus I would prefer to keep deepseq and generic-deepseq separated.

that's right (although one could make that an optional feature of the `deepseq` package, depending on the availability of the generics-feature, so that `deepseq` could still build with a pure H98 compiler)

And how would one write packages that depend on deepseq, that can be compiled easily on both, say, GHC and JHC?

afaics, if you choose (which is an explicit decision) to make use of `genericRnf`, you already have to provide `Generic` instances in your client code, thus your code already is beyond Haskell98 as it uses the Generics GHC extension. If you don't make use of the `genericRnf` then there's no harm, as your code would work with a `deepseq` package compiled in "H98 compatibility mode"... or am I overlooking something?

José Pedro Magalhães writes:

On Fri, Sep 21, 2012 at 10:58 AM, Herbert Valerio Riedel wrote:

...

Henning Thielemann writes:

...

On Fri, 21 Sep 2012, Herbert Valerio Riedel wrote: ... a `deepseq` package compiled in "H98 compatibility mode"... or am I overlooking something?

Are you suggesting CPP?

Either that (this is how the `cereal` package does it for instance) or by a pure CABAL solution, which switches between two internal .hs files based on `impl(ghc >= 7.2)`, or maybe a CABAL-flag-based approach... so this is just an implementation detail[1] which can be decided once it is clear, whether adding `genericRnf` is a good idea at all [1]: another impleemtation detail would be, whether to make `genericRnf` visible directly in `Control.DeepSeq` or in a separate module such as `Control.DeepSeq.Generics`

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.

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.

Simon Marlow writes: [...]

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?

Yeah, that sums it up about right (the way I perceived the discussion) Originally, it seemed a bit overkill to me to create a separate package containing just a few lines of codes also, I thought that the current default (pure H98/H2010) implementation for rnf provided by the NFData type-class, which is | class NFData a where | rnf :: a -> () | rnf a = a `seq` () could be changed to make use of the DefaultSignature extension at some point in the future (which'd defintely leave the H98/H2010 featureset and/or lead to a conditional API), for which having the `genericsRnf` helper accessible to the `deepseq` package would be a requirement However, the convenience of being able to write | instance NFData Foo instead of the more verbose | instance NFData Foo where rnf = genericsRnf isn't such a big deal either... it would have just been a nice use-case for the DefaultSignature extension IMHO :-) cheers, hvr