Releasing containers -- before GHC 7.8?

Carter Schonwald carter.schonwald at
Tue Jan 14 20:40:41 UTC 2014

ok, thats a good point

On Tue, Jan 14, 2014 at 3:15 PM, Reid Barton <rwbarton at> wrote:

> On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton <rrnewton at> wrote:
>> On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <roma at>wrote:
>>> * Ryan Newton <rrnewton at> [2014-01-14 11:41:48-0500]
>>> > Replacing containers seems like a real pain for end users
>>> Is it a real pain? Why?
>> One thing I ran into is that cabal sandboxes want consistent
>> dependencies.  And when users get to this point where they need to grab our
>> latest containers, they've got a bunch of core/haskell platform packages
>> that depend on the old containers.
>> I didn't mean that there was anything difficult about containers itself,
>> just that almost everything else depends on it.
> In addition to the general pain of updating packages at the base of the
> dependency hierarchy, there is also the fact that the template-haskell
> package depends on containers. As far as I know upgrading template-haskell
> is impossible, or at least a Very Bad Idea, so any library that wants to
> use an updated version of containers can't use template-haskell, or even be
> linked into an application that uses template-haskell directly or through
> another library.
> As far as I am concerned as a GHC user, versions of containers that aren't
> the one that came with my GHC might as well not exist. For example if I see
> that a package has a constraint "containers >= 0.10", I just assume I
> cannot use the library with GHC 7.4. Thus I'm strongly in favor of
> synchronizing containers releases with releases of GHC.
> Regards,
> Reid Barton
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list