michael at snoyman.com
Tue Nov 29 11:18:41 CET 2011
On Tue, Nov 29, 2011 at 12:11 PM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Am Dienstag, den 29.11.2011, 10:36 +0200 schrieb Michael Snoyman:
>> On Tue, Nov 29, 2011 at 10:29 AM, Joachim Breitner
>> <mail at joachim-breitner.de> 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
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
More information about the Haskell-Cafe