I haven’t used Haskell but it’s baffling to me that A) there are multiple proposals for breaking changes after all these years and B) they’re spread out across multiple releases! At least get all your breaking changes done at once so people can fix things and move on instead of this constant drip of breakage. Just looks really weird from the outside. Maybe it’s not so bad if you have more context.
As a Haskell user, none of these changes are a big deal.
Ongoing: Word8#
Code will use less memory. This is probably a game changer for folks with a lot of ffi code to c, but otherwise this won’t affect most people.
Upcoming: Remove Control.Monad.Trans.List
I didn’t even know this existed. List is already a monad, so why would anybody ever import this?
Upcoming: Remove Control.Monad.Trans.Error
This module has had a big deprecation warning on it for like 3 years telling you to use ExceptT.
Upcoming: Monomorphise Data.List
Yeah, I thought it was weird these functions were polymorphic. This is a good change. Probably won’t break my code because I imported Foldable/Traversable when I wanted the polymorphic variants, but some people might have to change imports after this.
Planned: forall becomes a keyword
If you named your variables “forall” then you are in a tiny group of people affected by this.
Planned: remove return from Monad
Presumably the top level definition is still in the Prelude module, so no big deal. This only affects people who override it incorrectly and break the laws it obeys.
Planned: remove mappend from Monoid
Ditto. This only affects people who wanted to overload an optimized version, which probably isn’t common.
Planned: remove (/=) from the the Eq class
Ditto. This only affects people who override it incorrectly.
Planned: disable StarIsType by default
This disables a rarely used kind-level identifier which looks like an operator, but isn’t. Instead you use a readable identifier. That’s a good thing. It probably won’t affect much of my code.
I feel like it’s nicer when you just handle breaking changes one by one over time. Python 3 was the “break everything at once” thing, where you just get hit with a deluge of things all at once.
It kind of fits Haskell’s slogan of “avoid success at all costs”. It seems that the people behind Haskell prioritize the inherent purity of the language over stability. I actually sympathize with this way of thinking, but that is easy for me to say, as I am not using Haskell in any serious way.
I haven’t used Haskell but it’s baffling to me that A) there are multiple proposals for breaking changes after all these years and B) they’re spread out across multiple releases! At least get all your breaking changes done at once so people can fix things and move on instead of this constant drip of breakage. Just looks really weird from the outside. Maybe it’s not so bad if you have more context.
As a Haskell user, none of these changes are a big deal.
Ongoing: Word8#
Code will use less memory. This is probably a game changer for folks with a lot of ffi code to c, but otherwise this won’t affect most people.
Upcoming: Remove Control.Monad.Trans.List
I didn’t even know this existed. List is already a monad, so why would anybody ever import this?
Upcoming: Remove Control.Monad.Trans.Error
This module has had a big deprecation warning on it for like 3 years telling you to use ExceptT.
Upcoming: Monomorphise Data.List
Yeah, I thought it was weird these functions were polymorphic. This is a good change. Probably won’t break my code because I imported Foldable/Traversable when I wanted the polymorphic variants, but some people might have to change imports after this.
Planned: forall becomes a keyword
If you named your variables “forall” then you are in a tiny group of people affected by this.
Planned: remove return from Monad
Presumably the top level definition is still in the Prelude module, so no big deal. This only affects people who override it incorrectly and break the laws it obeys.
Planned: remove mappend from Monoid
Ditto. This only affects people who wanted to overload an optimized version, which probably isn’t common.
Planned: remove (/=) from the the Eq class
Ditto. This only affects people who override it incorrectly.
Planned: disable StarIsType by default
This disables a rarely used kind-level identifier which looks like an operator, but isn’t. Instead you use a readable identifier. That’s a good thing. It probably won’t affect much of my code.
This.
I get more breaking changes from
template-haskellthan from anywhere else in The Language orbase.I feel like it’s nicer when you just handle breaking changes one by one over time. Python 3 was the “break everything at once” thing, where you just get hit with a deluge of things all at once.
It kind of fits Haskell’s slogan of “avoid success at all costs”. It seems that the people behind Haskell prioritize the inherent purity of the language over stability. I actually sympathize with this way of thinking, but that is easy for me to say, as I am not using Haskell in any serious way.
One of Haskell’s claims to fame is its ease of refactoring so this is really just showboating.