[ghc-steering-committee] Stability

[Arnaud Spiwack]

As I was saying in my previous email (I'm making a second email to avoid
confusion between the serious process question and the more casual musing),
I'd noticed that a lot of the migration issues are due to the base library
changing. Maybe the CLC can have stronger stability policies but the truth
is: it's pretty hard. The details of Haskell makes so many things backward
incompatible:

- It's incompatible to add a new instance for a type (somewhat mitigated by
complaining about orphan instances, but orphan instances aren't always
avoidable)
- It's incompatible to add a member to a type class without a default
implementation
- It's incompatible to remove a member from a type class, even if the
member is replaced by a simple function of the same name (see e.g.
https://github.com/haskell/core-libraries-committee/issues/3 ) in
- It's incompatible to add a function to a module because it may conflict
with a function of the same name in another imported module (this isn't a
theoretical concern:
https://mail.haskell.org/pipermail/haskell-cafe/2023-October/136389.html )

There may be things that Haskell-the-language can do to help
Haskell-the-ecosystem cope with some of these problems. So there may still
be value in analysing the ways in which base or other libraries broke their
downstream, and see how we can act.

We can for instance consider the following issue of adding names: this
isn't specific to Haskell in any way, but maybe it happens more to Haskel
because we idiomatically import everything in the global namespace. This is
one of the reasons why I care a lot about the Local Module proposal, by the
way https://github.com/ghc-proposals/ghc-proposals/pull/283 .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231013/f322dc22/attachment.html>