[ghc-steering-committee] Stability
Simon Peyton Jones
simon.peytonjones at gmail.com
Tue Oct 3 10:08:12 UTC 2023
Moritz
That sounds good to me. Just one thought:
- I really do think it is helpful to separate our *General Rules *(GR1-3)
from a machine supported *enforcement mechanism *(Section 6). The
latter is slower and more complicated than the former, and I'd hate to see
us stall on articulating our principles because we don't yet have a full
enforcement mechanism.
I understand the desirability of enforcement, so you can say "in my
software stack, all packages are stable, and that is checked every night.
So I'm fine with you sketching a proposal for how to do it. I would just
not like to de-rail the GR1-3 debate, including the classification we
develop with the extension-life-cycle-proposal folk.
Thanks for leading on this. I think we are all signed up to a constructive
dialogue that values the balance between innovation and stability, and I'm
optimistic that we can manage that balance better than we do today, *without
*just saying "innovation wins" or "stability wins". Speaking personally,
I'm very keen on innovation ("GHC as a laboratory"), as you know, but I
truly respect the need for stability which is why I have invested so much
time in the base-library discussion and now this one. Onward!
Simon
On Mon, 2 Oct 2023 at 07:25, Moritz Angermann <moritz.angermann at gmail.com>
wrote:
> Simon,
>
> Over the weekend, I've given this considerable thought and decided to
> approach it from a slightly different angle. I concur that we shouldn't
> duplicate or replace any existing work. I'm especially appreciative of Adam
> pointing out the current spreadsheet. Such insights highlight the value of
> our discussions!
>
> My plan right now is as follows:
>
> 1. *GHC Experimental Proposal*: I'll draft a proposal for
> --ghc=experimental. While it won't mark anything as experimental
> immediately, it sets the groundwork for distinguishing between experimental
> and stable features. This will also help us introduce experimental features
> with a clear flag from the outset.
> 2. *Extension Life Cycle Discussion*: I'll reconnect with Adam and
> others regarding the extension life cycle proposal. The core idea of having
> a clear life cycle for extensions seems to be well-received. The nuances
> and details are what sparked our initial conversation.
> 3. *Marking Features as Experimental*: I plan to propose marking
> JavaScriptFFI, Linear Types, and Dependent Haskell as experimental for the
> time being. We'll gauge the community's response and gather feedback from
> the original authors during the proposal process.
> 4. *Stability Policy Proposal*: Based on our collective input, I'll
> draft a proposal centered on the stability policy.
>
> With (1) and (2), I believe we are in a good position to take the GHC
> Extensions sheet (and also add GHC Features), and start moving them through
> the life-cycle into experimental features?
>
> Additionally, I'll be:
>
> - Reviewing prior work on template-haskell.
> - Exploring ways to make more libraries re-installable.
>
> Lastly, let's not lose sight of:
>
> - The Stability Working Group.
> - The GHC API Stability initiative from the HF.
>
> Best,
> Moritz
>
> On Fri, 29 Sept 2023 at 17:53, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Thank you for bringing us this far. I'd be happy to step up to drive this
>>> further.
>>>
>>
>> Thank you Moritz, that would be very helpful. I see the steps (*not *in
>> dependency order) including
>>
>> - Develop stability ideas for Template Haskell. I think we have
>> agreed that it's a tricky case: widely used, but hard to stabilise
>> - Develop a preliminary classification of language extensions, in
>> partnership with the folk (who include Adam) working on the extension
>> life cycle proposal
>> <https://github.com/ghc-proposals/ghc-proposals/pull/601>. The preliminary
>> spreadsheet
>> <https://docs.google.com/spreadsheets/d/1sRIcNKdflX2ogrx2EF3vKOn0vmv-UEOdladBqtYXdaw/edit#gid=0>is
>> helpful -- thank you Adam. Let's not duplicate this work!
>> - Ditto for "experimental features".
>> - Turn the Google doc into a GHC Proposal.
>>
>> I see all this as the GHC counterpart to the GHC base-library proposal
>> <https://github.com/haskellfoundation/tech-proposals/blob/main/proposals/accepted/051-ghc-base-libraries.rst>:
>> our general goal is to make a clear boundary between "stable" and
>> "experimental", so that:
>>
>> - users know when they are moving into experimental land
>> - developers know when they risk breaking stable code
>>
>> While the boundary is unclear, misunderstandings arise in both directions.
>>
>> Simon
>>
>> On Thu, 28 Sept 2023 at 13:39, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> Simon,
>>>
>>> Thank you for bringing us this far. I'd be happy to step up to drive
>>> this further.
>>>
>>> I will say that I do see the tension you see as well. And I do believe
>>> if we come to a conclusion on this stability policy that it will
>>> make GHC development more rigorous, which I think is a good thing for
>>> all of us, not just the consumers of the compiler. I think
>>> we need to stay mindful that we can still freely experiment on the
>>> --std=experimental (or however that flag ends up being named)
>>> side. I see this whole discussion as leading us towards the
>>> language research reactor side of GHC being primarily confined behind
>>> --std=experimental, and the stability seeking (commercial application?)
>>> on the other side.
>>>
>>> I do not yet see how we can end up with the inability to change. We will
>>> just have a clearer process for _breaking_ changes. This
>>> does absolutely not mean we have to end up in a local optimum, or that
>>> we can not change. We can!
>>>
>>> Unless someone speaks up who does _not_ want me to drive, this, I'm
>>> happy to start driving this discussion (including writing the
>>> proposals, starting next week).
>>>
>>> Best,
>>> Moritz
>>>
>>> On Thu, 28 Sept 2023 at 19:30, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> Should we have a document (or better spreadsheet?) with a bullet point
>>>>> for each experimental feature to be considered? I believe we need to take
>>>>> into account that we can’t end up classifying most of todays Haskell
>>>>> programs unstable. As such I’d like to propose that we’d add to each
>>>>> features a counter for how much of hackage (as a proxy for real world
>>>>> usage) uses the specific feature.
>>>>>
>>>>
>>>> I think that would be a helpful way to "ground" the discussion a bit
>>>> more. (The spreadsheet should also give a preliminary classification of
>>>> extensions, at least into stable/experimental.)
>>>>
>>>> I'm running out of capacity to drive this debate, useful though it is.
>>>> Does anyone else feel able to drive some of the legwork?
>>>>
>>>> So far this is all informal committee discussion. The next step would
>>>> be a GHC Proposal inviting broader feedback from the community. I'm just
>>>> hoping that by debugging it between ourselves we can side-step some
>>>> unproductive discussions in that bigger context.
>>>>
>>>> I believe we need to take into account that we can’t end up classifying
>>>>> most of todays Haskell programs unstable
>>>>>
>>>>
>>>> There is a tension here. If we say something is "stable" then we have
>>>> to be super-careful about changing it. (That's the whole point.) And yet
>>>> if the feature (like INCOHERENT) is a flaky "you are on your own"
>>>> unsafePerformIO-like feature, I am axious about tying ourselves into an
>>>> inability to change the behaviour of corner cases. I'm not sure how to
>>>> resolve this tension.
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> On Thu, 28 Sept 2023 at 02:20, Moritz Angermann <
>>>> moritz.angermann at gmail.com> wrote:
>>>>
>>>>> I think we are moving in the right direction! I do see however the
>>>>> tension rising on (2). And without being clear about (2), I don’t think we
>>>>> can properly agree on (1). We can agree on (1) in principle, but we need to
>>>>> clarify what we consider unstable/experimental, as a precondition to have
>>>>> finale agreement on (1). Otherwise people might agree to (1), only to be
>>>>> surprised by (2). For (3), I’d be happy to try to get my employer to
>>>>> provide resources for the implementation of —std=experimental.
>>>>>
>>>>> Thusly I believe we should start to build a list of features we
>>>>> consider sufficiently experimental that they should preclude an existing
>>>>> Haskell program from being considered stable. This list for me contains so
>>>>> far:
>>>>>
>>>>> - Linear Types
>>>>> - Dependent Haskell
>>>>>
>>>>> Adam pointed out experimental backend and non-tire-1 platforms. I tend
>>>>> to agree with this, but see this distinctly separate from the language
>>>>> stability (outside of backend specific language extensions, e.g. JSFFI).
>>>>>
>>>>> Platforms/backends may be experimental but those are (safe for
>>>>> specific lang exts) orthogonal to the Haskell code the compiler accepts.
>>>>>
>>>>> Should we have a document (or better spreadsheet?) with a bullet point
>>>>> for each experimental feature to be considered? I believe we need to take
>>>>> into account that we can’t end up classifying most of todays Haskell
>>>>> programs unstable. As such I’d like to propose that we’d add to each
>>>>> features a counter for how much of hackage (as a proxy for real world
>>>>> usage) uses the specific feature.
>>>>>
>>>>> Best,
>>>>> Moritz
>>>>>
>>>>> On Wed, 27 Sep 2023 at 10:35 PM, Simon Peyton Jones <
>>>>> simon.peytonjones at gmail.com> wrote:
>>>>>
>>>>>> it's essential that we continue to have these discussions to ensure
>>>>>>> we're making the best decisions for the project and our community.
>>>>>>>
>>>>>>
>>>>>> Yes exactly! Its tricky and nuanced; hence trying to articulate
>>>>>> something in a concrete doc, so we are all on the same page (literally!).
>>>>>>
>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> I have tried to make this explicit in Section 4. See what you think.
>>>>>>
>>>>>> I think there are three phases
>>>>>>
>>>>>> 1. Agree this document. Is it what we want.
>>>>>> 2. Categorise extensions into stable/experimental, and identify
>>>>>> experimental language features.
>>>>>> 3. Implement --std=experimental (Section 6).
>>>>>>
>>>>>> (1) is what we are doing now. (2) will be some work, done by us.
>>>>>> (3) is a larger task: it will require significant work to implement, and
>>>>>> may impose unwelcome churn of its own. But that should not stop us doing
>>>>>> (1) and (2).
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>> -
>>>>>>
>>>>>>
>>>>>> On Wed, 27 Sept 2023 at 10:20, Moritz Angermann <
>>>>>> moritz.angermann at gmail.com> wrote:
>>>>>>
>>>>>>> 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
>>>>>>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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/20231003/b8745dae/attachment-0001.html>
More information about the ghc-steering-committee
mailing list