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