[ghc-steering-committee] Stability

Wed Sep 27 09:19:38 UTC 2023

Dear Adam,

Thank you for your thoughtful feedback. I understand your reservations, and
it's essential that we continue to have these discussions to ensure we're
making the best decisions for the project and our community. Let me address
each of your points in turn:
- Cognitive Overhead for Users:
I understand the concern about cognitive overhead due to the inability to
remove complexity. However, our primary intention is to ensure a gradual
transition for our users rather than abrupt shifts. Introducing changes via
deprecation cycles allows users to adjust to modifications over time,
reducing the immediate cognitive load. It's a balance between stability and
simplicity, and I believe this approach allows us still to reduce
complexity.

- Maintenance Burden in the Compiler:
Maintaining backward compatibility does indeed introduce some overhead.
Still, it also encourages a more disciplined and considered approach to
changes. With our deprecation cycles in place, it's not that we never
remove complexity; rather, we do it in a way that provides ample time for
adjustments. This benefits both the development team and the community.

- Risk of Local Optimum:
This is a valid concern. However, deprecation cycles don't mean we're
averse to major changes. It means we introduce them responsibly. When we
believe a superior design is possible, we can start a deprecation process
to transition towards it. The flexibility and duration of our deprecation
cycles can be tailored depending on the severity of the breaking change.

- Discouraging Volunteer Contributors:
I understand that lengthy approval processes can be off-putting. But it's
crucial to note that a rigorous process ensures the consistency and
reliability of our project. We always welcome and value contributions.
Moreover, I believe this stability policy will provide us with clear
guardrails on how changes can be contributed.

I will not disagree on the costs. I do believe though that the costs for
_breaking_ changes in the compiler ought to be borne by the people making
the change, instead of those who use the compiler (and may not even benefit
of those changes that caused breakage). I also see the team maintaining GHC
as the one to enforce this; they are the ones who cut the releases. The
fact that we may have breaking changes due to _bugs_ is covered explicitly
in the stability policy document.

With my CLC hat on, I have been focusing on the same stability guidelines
as well (if it breaks existing code, I have been against those changes
without deprecation policies). The issues with the template-haskell, and
ghc library are noted. For the ghc library the question will remain if we
intent to provide a stable api to the compiler or not. I believe many tools
would like to have one, and if we relegate anything unstable to
ghc-experimental this might be achieved. For template-haskell this is a
bigger concern. Maybe we can collectively come up with a solution that
would allow us to provide a more insulated template haskell interface from
the compiler.

However for template-haskell we might also need to look at what exactly
caused those breaking changes in the past.

What this document outlines (in my understanding) is that any experimental
feature development can _only_ be visible behind --std=experimental, and
the dependency of ghc-experimental. Unless those are given, the compiler
should accept existing programs. This should allow us enough room to
innovate (everyone is always free to opt-in to bleeding edge features with
--std=experimental).  I also believe that most of what we have today will
need to be treated as non-experimental simply because we did not have that
mechanism before. We don't want to break existing programs as much as
possible, thus relegating existing features into --std=experimental (except
for some fairly clear ones: e.g. Dependent Haskell, and Linear Types?) is
not really possible. What we can however do is start deprecation phases for
a few versions, moving features we consider highly experimental (or maybe
even bad) into `--std=experimental`. Just by having deprecation phases and
given the ecosystem enough time to adjust (and provide feedback) we might
come to different conclusions.

As I've also outlined in the document, _if_ GHC was trivially swappable,
companies like IOG would _love_ to try new compilers and report back bugs
and regressions. As it is today, we can't. Making a large live codebase
compatible with 9.8 is a multiple weeks effort. Experimenting with
nightlies is technically impossible. _If_ I could setup the built of our
software trivial with ghc nightlies, I'd be _happy_ to build the
infrastructure out it to provide performance regressions (compilation,
runtime, ...) for our codebase and provide the feedback to the GHC team;
however I can't. And thus I'm stuck patching and fixing 8.10, and 9.2
today. 9.6 maybe soon, but likely at the point in time where 9.6 is not
going to see any further releases, so I can spare trying to even forward
port my patches to HEAD. Not that I could even test them with head
properly, as our source is not accepted by HEAD. Thus I end up writing
patches against old stale branches. This to me is a fairly big
discouragement from contributing to GHC.

Best,
 Moritz

On Mon, 25 Sept 2023 at 15: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230927/5e46894b/attachment-0001.html>