On Tue, Nov 29, 2011 at 10:29 AM, Joachim Breitner wrote:

Hi,

Am Dienstag, den 29.11.2011, 07:43 +0200 schrieb Michael Snoyman:

...

Since the release of deepseq 1.2, we've had a bit of a problem: when using the newest versions of packages on Hackage, there is no NFData instance available for the containers types. When GHC 7.4 comes out with its newer version of containers, this will be addressed, but we'll still have problems for users of older GHC releases.

I'd like to suggest a solution: a new package called containers-deepseq. Using conditional compilation, it will provide an orphans NFData instance for all containers types when deepseq >= 1.2 and containers < 0.5. Packages (e.g., aeson) would then depend on containers-deepseq and simply import the module whenever they rely on the NFData instances. When GHC 7.4 comes out, the package will essentially be a no-op.

Does this make sense?

from a distro point of view: Please void this if possible; every additional package causes us work. (Although we’d likely just not upgrade containers before 7.4.1 and patch out the dependency in the cabal file when we switch to 7.4.1.)

Why can’t you put the instances in containers, guarded by some #ifs? I don’t see the point of a separate package for these 15 lines of code.

Because containers cannot be updated: you're stuck with whatever version comes with GHC. Michael

On Tue, Nov 29, 2011 at 12:11 PM, Joachim Breitner wrote:

Hi,

Am Dienstag, den 29.11.2011, 10:36 +0200 schrieb Michael Snoyman:

...

On Tue, Nov 29, 2011 at 10:29 AM, Joachim Breitner wrote:

...

Am Dienstag, den 29.11.2011, 07:43 +0200 schrieb Michael Snoyman:

...

Since the release of deepseq 1.2, we've had a bit of a problem: when using the newest versions of packages on Hackage, there is no NFData instance available for the containers types. When GHC 7.4 comes out with its newer version of containers, this will be addressed, but we'll still have problems for users of older GHC releases.

I'd like to suggest a solution: a new package called containers-deepseq. Using conditional compilation, it will provide an orphans NFData instance for all containers types when deepseq >= 1.2 and containers < 0.5. Packages (e.g., aeson) would then depend on containers-deepseq and simply import the module whenever they rely on the NFData instances. When GHC 7.4 comes out, the package will essentially be a no-op.

Does this make sense?

from a distro point of view: Please void this if possible; every additional package causes us work. (Although we’d likely just not upgrade containers before 7.4.1 and patch out the dependency in the cabal file when we switch to 7.4.1.)

Why can’t you put the instances in containers, guarded by some #ifs? I don’t see the point of a separate package for these 15 lines of code.

Because containers cannot be updated: you're stuck with whatever version comes with GHC.

ah, I remember. Trying the same trick in deepseq is also not nice, because it would require a cabal-conditional dependency on containers, which would surely cause other problems.

How about depending on  (deepseq < 1.2 && containers < 0.5) || (deepseq >= 1.2 && containers >= 0.5) in a package that uses the NFData instances? Then cabal would figure out the right version of deepseq to use, based on the version of containers available (or at least I hope so).

Still not a perfect solution, since now you can *only* use deepseq 1.2 if you have the newer containers. My proposal allows you to use deepseq with any version of containers, and therefore any version of GHC. Otherwise, we end up with a "split Hackage" issue where different packages work with different versions of deepseq, and we have dependency hell. By the way, this is the part of situation that cabal-src is coming to solve, and it *is* solved... except that the result is a lot of re-compiling. Michael