blog/century-of-the-fruitbat/

[utterances-bot]

Dragging Haskell Kicking and Screaming into the Century of the Fruitbat :: Reasonably Polymorphic

https://reasonablypolymorphic.com/blog/century-of-the-fruitbat/

[nomeata]

Interestingly, at least I have defined (/=) in an instance. Did I have a good reason? No, but the class has the method, and instantiating it was faster than thinking whether the default would work for me. Which is precisely the kind of distraction I hope we can spare future developers with.

Anyways, thanks a lot for this supportive analysis!

[runeksvendsen]

There are more than just two choices here. There's a middle road where we recognize that removing (/=) from Eq is indeed a sensible change, but instead we start by marking it as deprecated, and only after a certain grace period we remove it.

All major companies have deprecation policies, because they know that how often breaking changes are introduced is important to their clients. I want more people to use Haskell, because it's the best programming language I know. Therefore I think it makes sense to adopt a deprecation policy. In the end, we will arrive at the same goal: a more sensible Prelude. It will just take a bit longer.

[nomeata]

Potentially worth it. But I think at the moment GHC does not support deprecating instantiating a method without deprecating it's use. So that would add complexity to GHC - doable, but again extra cost.

Or we deprecate it without a compiler warning, only in the docs and via channels like this one? In a way, we have done that: the CLCs intention to remove the method has been announced, and everyone affected can, if they want, do the change now, and then not notice at all when the change lands.

[jegi]

That's only analogous provided that the change doesn't land for a while (the grace period). Will that be the case?

[nomeata]

Given that we first need to improve GHC's handling of RULES for single method classes (which, incidentally, is collateral improvement from this work), I don't expect this change to land too soon.

[bhurt]

I've been thinking about this post for a while, and I'm not sure releases with lots of breaking changes are a good idea. You can easily end up like Python 3 or Java 5- new versions that a large fraction of the community simply don't adopted because of the large numbers of breaking changes. The community then bifurcates. This isn't an argument against breaking changes, it's an argument against wrapping lots of little breaking changes up into a single release, instead of stringing them out over several releases.