[ghc-steering-committee] Stability

[Arnaud Spiwack]

On Fri, 13 Oct 2023 at 11:53, Simon Peyton Jones <
simon.peytonjones at 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 <marlowsd at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231013/a8633bbd/attachment.html>