[ghc-steering-committee] Stability

Simon Peyton Jones simon.peytonjones at gmail.com
Mon Sep 25 16:26:23 UTC 2023 

>
> In a discussion with Simon this morning, we realized that the document
> does two separable things:
>
> 1. It articulates a set of rules for what stability guarantees GHC should
> strive for
> 2. It articulates a possible enforcement mechanism for Haskellers to opt
> for the stable subset of GHC/Haskelll
>

...and I have reflected this observation in the doc by pulling out (2) into
a new Section 6.

Simon

On Mon, 25 Sept 2023 at 14:36, Richard Eisenberg <lists at richarde.dev> wrote:

> In a discussion with Simon this morning, we realized that the document
> does two separable things:
>
> 1. It articulates a set of rules for what stability guarantees GHC should
> strive for
> 2. It articulates a possible enforcement mechanism for Haskellers to opt
> for the stable subset of GHC/Haskelll
>
> It is possible to adopt (1) without (2). Indeed I worry that (2) would
> require much of the structure that we have already seen in Safe Haskell: a
> way to mark a package as "stable-interface" that somehow promises always to
> work, even though it uses experimental features internally. This will be
> necessary for `base`, for example, but I imagine other packages, too.
>
> But even (1) on its own would at least align the committee and make
> forward progress easier to talk about.
>
> I'm not necessarily against (2) -- just wanted to highlight that the two
> notions are separable.
>
> Richard
>
> On Sep 25, 2023, at 4:46 AM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
> A strong stability guarantee is certainly a valuable goal, but it also
>> comes with costs, which I'd like to see more clearly articulated. Some
>> of them include:
>>
>
> Thanks for articulating this.
>
> I see this doc as the language counterpart of the base-libraries document,
> where we split `base` and `ghc-experimental`.  By splitting in this way, we
> allow innovation, while placing stronger stability goals on `base`.
> Stronger,  but not unbreakable: I expect base to continue to evolve, e.g.
> by removing (with deprecation cycles) stuff that is plainly GHC-internal,
> subject to the CLC.  But, as we have seen in the extensive debate that led
> up to this proposal, it is *really *helpful to have a clear line between
> "experimental" and "stable", for all sorts of reasons.
>
> I think we are just doing the same here.  Many GHC proposals add a new
> language feature, guarded by an extension, and are unaffected by the
> proposal.  Others make changes to recently added extensions (Linear Haskell
> is the poster child example), which we informally regard as experimental
> and subject to change. But we don't *say* that at the moment... it's all
> informal.  By identifying which extensions are experimental, and which are
> stable (and subject to higher back-compat goals) we help our users, and
> ourselves.  Just like base vs ghc-experimental.
>
> I called them "General Rules" because (just like changes to base) I think
> we will want to break them.  But I'm content to be considerably more
> careful when we break stable extensions than experimental ones.
>
> =============
>
> Template Haskell is a real problem.  I don't think we can promise never to
> change TH syntax, for the reasons you describe.
>
> Is it true that many TH users use only splices and quotations, not
> explicit use of TH data constructors?  Those programs should be much more
> stable.
>
> For ones that use TH data constructors I think that prompt (but very
> routine) maintenance may be needed.
>
> Simon
>
>
>
>
> On Mon, 25 Sept 2023 at 08:17, Adam Gundry <adam at well-typed.com> wrote:
>
>> I'm afraid that I'm somewhat sceptical of this approach.
>>
>> A strong stability guarantee is certainly a valuable goal, but it also
>> comes with costs, which I'd like to see more clearly articulated. Some
>> of them include:
>>
>>   * Cognitive overhead for users, because of the inability to remove
>> complexity from the design.
>>
>>   * Increasing maintenance burden in the compiler, because of the
>> additional work needed to implement new features and the inability to
>> remove complexity from the implementation.
>>
>>   * A risk of getting stuck in a local optimum, because moving to a
>> better design would entail breaking changes.
>>
>>   * Discouraging volunteer contributors, who are much less likely to
>> work on a potentially beneficial change if the process for getting it
>> approved is too onerous. (I'm worried we're already reaching that point
>> due to the increasing burden of well-intentioned processes.)
>>
>> Ultimately every proposed change has a cost-benefit trade-off, with risk
>> of breakage being one of the costs. We need to consciously evaluate that
>> trade-off on a case-by-case basis. Almost all changes might break
>> something (e.g. by regressing performance, or for Hyrum's Law reasons),
>> so there needs to be a proportionate assessment of how likely each
>> change is to be damaging in practice, bearing in mind that such an
>> assessment is itself costly and limited in scope.
>>
>> It seems to me that the GHC team have taken on board lessons regarding
>> stability of the language, and the extension system already gives quite
>> a lot of flexibility to evolve the language in a backwards-compatible
>> way. In my experience, the key stability problems preventing upgrades to
>> recent GHC releases are:
>>
>>   * The cascading effect of breaking changes in one library causing the
>> need to upgrade libraries which depend upon it. This is primarily under
>> the control of the CLC and library maintainers, however, not the GHC
>> team. It would help if base was minimal and reinstallable, but that
>> isn't a total solution either, because you'd still have to worry about
>> packages depending on template-haskell or the ghc package itself.
>>
>>   * Performance regressions or critical bugs. These tend to be a
>> significant obstacle to upgrading for smaller commercial users. But
>> spending more of our limited resources on stability of the language
>> means fewer resources for resolving these issues.
>>
>> There's surely more we can do here, but let's be careful not to pay too
>> many costs to achieve stability of the *language* alone, when stability
>> of the *libraries* and *implementation* are both more important and
>> harder to fix.
>>
>> Adam
>>
>>
>> On 22/09/2023 10:53, Simon Peyton Jones wrote:
>> > Dear GHC SC
>> >
>> > To avoid derailing the debate about -Wsevere
>> > <
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
>> and HasField redesign <
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
>> I'm starting a new (email for now) thread about stability.
>> >
>> > I have tried to articulate what I believe is an evolving consensus in
>> > this document
>> > <
>> https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing
>> >.
>> >
>> > If we converge, we'll turn that into a proper PR for the GHC proposal
>> > process, although it has wider implications than just GHC proposals and
>> > we should share with a broader audience.  But let's start with the
>> > steering committee.
>> >
>> > Any views?  You all have edit rights.
>> >
>> > I think that the draft covers Moritz's and Julian's goals, at least
>> that
>> > was my intention.  I have pasted Moritz's last email below, for context.
>> >
>> > Simon
>> >
>> >
>> > ========= Moritz's last email ============
>> >
>> > Now, this is derailing the original discussion a bit, and I'm not sure
>> > how far we want to take this. But, regarding @Simon Marlow
>> > <mailto:marlowsd at gmail.com>'s comment
>> >
>> >     This is one cultural aspect of our community I'd like to shift: the
>> >     expectation that it's OK to make breaking changes as long as you
>> >     warn about
>> >     them or go through a migration cycle. It just isn't! (and I speak as
>> >     someone who used to make lots of changes, I'm now fully repentant!).
>> >     That's
>> >     not to say that we shouldn't ever change anything, but when
>> >     considering the
>> >     cost/benefit tradeoff adding a migration cycle doesn't reduce the
>> >     cost, it
>> >     just defers it.
>> >
>> >
>> > I actually read this as we should stop having breaking changes to begin
>> > with. And _if_ we
>> > do have breaking changes, that deprecation does not change the need to
>> > actually change
>> > code (cost). As outlined in my reply to that, and @Richard Eisenberg
>> > <mailto:lists at richarde.dev>'s observation, it
>> > "smears" the cost. The--to me--_much_ bigger implication of deprecation
>> > cycles is that we
>> > _inform_ our _customers_ about upcoming changes _early_, instead of
>> > _after the fact_. We
>> > also give them ample time to react. Being by changing their code, or
>> > raising their concerns.
>> > Would the Simplified Subsumptions / Deep Subsumptions change
>> have looked
>> > differently?
>> > As such I see deprecation cycles as orthogonal to the question if we
>> > should have breaking
>> > changes to begin with.
>> >
>> > Thus I believe the following:
>> >
>> >     - Do have a deprecation cycle if possible.
>> >     - Do not treat a deprecation cycle as an excuse.  Costs are deferred
>> >     but are as large as ever.
>> >
>> >
>> > should be upgraded to:
>> > - Preferably _no_ breaking changes.
>> > - If breaking changes, then with a deprecation cycle, unless
>> technically
>> > infeasible.
>> > - An understanding that any breaking change incurs significant costs.
>> >
>> > Ocaml recently added multicore support, and they put tremendous effort
>> > into making
>> > sure it keeps backwards compatibility:
>> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>> > <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
>> >
>> >     PS: we should also agree that a "stable" extension should not
>> >     require dependencies on ghc-experimental.  To become stable, any
>> >     library support for an extension must move into `base`.
>> >
>> >
>> > This seems like a good idea, however I still remain that _experimental_
>> > features should not be on-by-default in a stable compiler. Yes, ideally
>> > I'd not even see them in a stable compiler, but I know this view is
>> > contentious. The use of `ghc-experimental` should therefore be guarded
>> > by `--std=experimental` as Julian suggested. That is a loud opt-in to
>> > experimental features.
>> >
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230925/28ee6e58/attachment-0001.html>

More information about the ghc-steering-committee mailing list