Re: [ghc-steering-committee] Stability

I'm not confident about that. Last week, I even thought of a way it could hurt. We chose to name a bunch of things “Experimental” (rather than, say, GHC-specific), this carries the following risk: if features stay in the ghc-experimental package for too long, they may very well become part of “normal Haskell”. Programmers will start depending on it and will be habituated to understand that “experimental” really means “stable”, and we'll lose all the benefits of the scary warning on the tin. We need a very tight process if we're to make this work at all.

I am a bit more optimistic than you. - I expect that corporate users (Facebook, IOG, Standard Chartered, etc) will be strongly motivated to stick with the stable subset. - If they really want to use features labelled experimental they will push for them to be re-cateogised, because "experimental" means "much more liable to change without notice. - That in turn will develop a useful conversation. The alternative, of giving no guidance whatsoever about what is stable and what is not, seems noticeably worse to me. Simon On Fri, 13 Oct 2023 at 14:10, Arnaud Spiwack wrote:

On Fri, 13 Oct 2023 at 11:53, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

But here's the thing: I claim that GR{1-3} aren't going to solve the

...

stability problem. I'm confident about this because they're already the policy. And while it's not entirely impossible to imagine that writing them down more prominently will solve the problems that we have, I don't believe we should count on it.

I agree. They won't solve it. (Incidentally, it's not just GR{1-3} but also the categorisation into stable/experimental, which GR{1-3} is predicated on.) But I think they will help. You are sceptical, but that's fine. We'll see. Provided they are not harmful [and I don't think you are saying that it is] we can just adopt them and move on.

Completely-solving a complex, multi-faceted problem is hard. But that should not discourage us from making incremental progress towards that goal.

I think there's a misunderstanding here, maybe it's due to the limitation of text communication, or maybe I'm just expressing myself very badly. I'm absolutely fine with enshrining GR{1-3}. I don't think there has been any discussion about them apart from minor rewordings.

...

The base-library splitting proposal (now agreed) is another piece of incremental progress that does not solve the problem, but will help.

I'm not confident about that. Last week, I even thought of a way it could hurt. We chose to name a bunch of things “Experimental” (rather than, say, GHC-specific), this carries the following risk: if features stay in the ghc-experimental package for too long, they may very well become part of “normal Haskell”. Programmers will start depending on it and will be habituated to understand that “experimental” really means “stable”, and we'll lose all the benefits of the scary warning on the tin. We need a very tight process if we're to make this work at all.

I am not against (in addition) trying to identify particularly painful

...

problems in the past, and seeing what their root causes were. I just don't want to de-rail making incremental progress at the same time.

I sincerely hope I'm not doing that.

...

I don't like to see you unhappy, Arnaud!

Haha :D Thanks. You know what, I don't like seeing me unhappy either! (but I'm not in this particular case)

On Fri, 13 Oct 2023 at 13:23, Simon Marlow wrote:

...

It's already the policy in the sense that when we break stuff, we generally have a deprecation cycle. But where GR2 diverges from the current (informal) policy is in judging when it's OK to make a breaking change. GR2 - at least in my interpretation of it, and perhaps we should make this clearer - requires that to make a breaking change we have to be forced somehow. Because there's a bug that needs fixing, or because the current behaviour is broken for some reason. We're not going to make a breaking change just because the change would make things better, even with a deprecation cycle: those kinds of changes will still be possible, but they'll go behind a new language extension flag and/or into the next GHC20xx, so the user has control over when they have to adapt their code.

Maybe, though I actually don't have evidence that we've broken this policy, new or not, in the past. I hope you're right of course. Certainly a (somewhat implicit but real) change that has been brought by the conversations of the past few weeks is a reinforcement of the role of the GHC20xx languages. Let's see how much we can lean on this.

It's probably true that a majority of the backwards compatibility issues

...

encountered with a GHC upgrade come from changes in third-party packages. But in order to decouple the compiler upgrade from package upgrades, we have to make all the existing packages compile with the new GHC, so stability has to start with GHC itself.

This gives support to Adam's idea of a reinstallable base.

Incidentally I'd like the stability policy to be extended to compiler and

...

runtime flags - i.e. don't gratuitously change the behaviour of existing flags or remove them. Extend stability to build systems, not just code. This is much harder than language changes because we don't have extensions or GHC20xx, but we can do deprecation cycles.

This is reasonable, but do you have evidence that it's ever been a problem in the past?

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.