[ghc-steering-committee] Stability

[Simon Peyton Jones]

>
> 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 <arnaud.spiwack at tweag.io>
wrote:

> 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/80971aaa/attachment-0001.html>