Re: Proposal: Remove Semigroup and Monoid instances for Data.Map, Data.IntMap, Data.HashMap

avoiding these subtle bugs requires at least a full GHC release cycle

Now that GHC is on a 6 month release cycle this seems preferable to waiting 3-5 years. On Tue, Feb 13, 2018 at 2:52 PM, David Feuer wrote:

It would let us have some cake. Users would be able to test against 0.9, in theory. But they'd have to do it intentionally. And Stack-based projects would probably need some shenanigans to deal with a version of containers that doesn't come with GHC. So I really think that avoiding these subtle bugs requires at least a full GHC release cycle.

On Feb 13, 2018 5:48 PM, "Herbert Valerio Riedel" wrote:

Hi,

On 2018-02-13 at 17:41:25 -0500, David Feuer wrote:

...

We may not have to be *quite* as long-winded as I initially suggested, but I don't think your way is sufficiently long-winded. The advantage of removing the instances first and then adding them back is that the version(s) without the instances will make compilation of every single package that uses them fail. The way you suggest, if someone has a package using containers or unordered-containers, they don't even have a simple way to find out whether they need to make changes. On the opposite side, Chris Wong's suggestion would let us be very explicit, with a type error that warns users that the instance is missing *because it is changing* and that no code using the instance will work for both 0.* and 1.* versions.

Alright, then let's do a little Gedankenexperiment; what if you release a containers-0.9.0.0 (which drops the instances) and a containers-1.0.0.0 (which 'adds back' the desired new instances) on the same day!

...wouldn't this allow us to have the cake and eat it too? ;-)

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries