From moritz.angermann at gmail.com  Mon Oct  2 03:45:04 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 2 Oct 2023 11:45:04 +0800
Subject: [ghc-steering-committee] #526: Applicative Comprehensions
	(rec:accept)
In-Reply-To: <CANsrgPJz+OZMy1T5QoVmKT8aiC9dFzbiuPfz771zK+=vgN2VbA@mail.gmail.com>
References: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
 <34e43a8b-2525-4931-9d25-95386be1068f@app.fastmail.com>
 <CANsrgPJz+OZMy1T5QoVmKT8aiC9dFzbiuPfz771zK+=vgN2VbA@mail.gmail.com>
Message-ID: <CAKfdd-zsmRuquRwhrL4U2zNux08oni-Xrk3uZBUWTzM6_a9vJw@mail.gmail.com>

As it appears to be only additional syntax with no breakage of existing
programs, I'm supportive!

On Sun, 1 Oct 2023 at 02:32, Simon Marlow <marlowsd at gmail.com> wrote:

> We certainly wouldn't want to include either ApplicativeDo or
> ApplicativeComprehensions in GHC20xx, indeed it was never the intention
> that ApplicativeDo would be enabled by default. Perhaps the simpler
> predictable form (yet to be proposed) could be in a future GHC20xx.
>
> Cheers
> Simon
>
> On Sat, 30 Sept 2023 at 18:57, Eric Seidel <eric at seidel.io> wrote:
>
>> I'm on the fence about this one. I can see the utility, sure, but we've
>> also been talking a lot about stability of extensions lately. One question
>> I asked myself while reading the proposal is whether I would support
>> including this extension (or MonadComprehensions) in the next GHC20XX. I'm
>> not sure but my gut reaction is probably not.
>>
>> On Thu, Sep 28, 2023, at 03:12, Simon Marlow wrote:
>> > Dear committee,
>> >
>> > #526 proposes a new extension ApplicativeComprehensions (implying
>> > MonadComprehensions). It would provide the equivalent of the current
>> > ApplicativeDo desugaring for do-expressions to list comprehensions.
>> >  • Github thread
>> > <https://github.com/ghc-proposals/ghc-proposals/pull/526>
>> >  • Rendered
>> > <
>> https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst
>> >
>> > The extension itself is relatively uncontroversial, but there are some
>> > unresolved quirks in the original ApplicativeDo extension which made us
>> > uneasy about extending it. However, after various discussions I'm going
>> > to propose accepting this proposal in its current state.  Rationale:
>> >  • It doesn't make things worse, and the implementation isn't likely to
>> > add significant complexity.
>> >  • It retains consistency between ApplicativeDo and
>> > ApplicativeComprehensions (in contrast to the idea of making
>> > ApplicativeComprehensions perform a simpler desugaring, which came up
>> > during the discussion)
>> >  • A future proposal can add a simpler version of the desugaring for
>> > both extensions later.
>> >
>> > Cheers
>> > Simon
>> > _______________________________________________
>> > 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
>>
> _______________________________________________
> 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/20231002/95888fa2/attachment.html>

From moritz.angermann at gmail.com  Mon Oct  2 06:24:48 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 2 Oct 2023 14:24:48 +0800
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>
Message-ID: <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>

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/20231002/fc733989/attachment-0001.html>

From adam at well-typed.com  Mon Oct  2 08:07:27 2023
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 2 Oct 2023 09:07:27 +0100
Subject: [ghc-steering-committee] #526: Applicative Comprehensions (rec:
 accept)
In-Reply-To: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
References: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
Message-ID: <4059923d-af9e-9218-9b67-f63033882220@well-typed.com>

I'm unconvinced by the current state of this proposal, for similar 
reasons as Simon PJ gives on the proposal thread 
(https://github.com/ghc-proposals/ghc-proposals/pull/526#issuecomment-1740735610).

If we want to accept this merely for reasons of consistency, I think the 
simplest way forward would be to not introduce a new extension name, and 
instead define the combination of MonadComprehensions + ApplicativeDo to 
do what the proposal suggests.

The author doesn't seem to be responsive on the thread. While I worry 
this may be because of the time the proposal process has been taking, it 
makes it difficult to gauge support for the various alternative 
suggestions that have been made.

Cheers,

Adam


On 28/09/2023 08:12, Simon Marlow wrote:
> Dear committee,
> 
> #526 proposes a new extension ApplicativeComprehensions (implying 
> MonadComprehensions). It would provide the equivalent of the current 
> ApplicativeDo desugaring for do-expressions to list comprehensions.
> 
>   * Github thread <https://github.com/ghc-proposals/ghc-proposals/pull/526>
>   * Rendered
>     <https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst>
> 
> The extension itself is relatively uncontroversial, but there are some 
> unresolved quirks in the original ApplicativeDo extension which made us 
> uneasy about extending it. However, after various discussions I'm going 
> to propose accepting this proposal in its current state.  Rationale:
> 
>   * It doesn't make things worse, and the implementation isn't likely to
>     add significant complexity.
>   * It retains consistency between ApplicativeDo and
>     ApplicativeComprehensions (in contrast to the idea of making
>     ApplicativeComprehensions perform a simpler desugaring, which came
>     up during the discussion)
>   * A future proposal can add a simpler version of the desugaring for
>     both extensions later.
> 
> 
> Cheers
> Simon

-- 
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


From arnaud.spiwack at tweag.io  Mon Oct  2 13:59:35 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 2 Oct 2023 15:59:35 +0200
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <c1f8e93e-6996-40e9-ad86-16a451e95568@app.fastmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <54C921C0-44B1-497C-981D-16BE688CBE6B@chrisdornan.com>
 <CAKfdd-wf3Zj8_rZpPhPq2to-vDs_dRiQw54S6CzbvZK2DSda6w@mail.gmail.com>
 <c1f8e93e-6996-40e9-ad86-16a451e95568@app.fastmail.com>
Message-ID: <CAGwnsnk3iLvyLonEcxKjX5qZiKh72akQwULftecXxMXQ7BMDbg@mail.gmail.com>

I'm good too.

On Sat, 30 Sept 2023 at 19:33, Eric Seidel <eric at seidel.io> wrote:

> I'm happy with this change.
>
> On Fri, Sep 29, 2023, at 08:46, Moritz Angermann wrote:
> > Sounds good to me.
> >
> > On Fri, 29 Sep 2023 at 7:47 PM, Chris Dornan <chris at chrisdornan.com>
> wrote:
> >> All,
> >>
> >> This proposal has now been revised to make it non-disruptive.
> >>
> >> That was the only issue of substance that surfaced in our discussion
> and I recommend that we accept this revised proposal.
> >>
> >> Chris
> >>
> >>
> >>> On 8 Sep 2023, at 11:57, Chris Dornan <chris at chrisdornan.com> wrote:
> >>>
> >>> Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
> >>> Author: Sebastian Graf, David Knothe
> >>> Rendered proposal:
> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
> >>> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609
> >>> Recommendation: Acceptance
> >>>
> >>> ## Summary
> >>>
> >>> This proposal refines the syntax of an already accpted proposal (#522)
> for writing or patterns.
> >>>
> >>> The syntax of the old proposal,
> >>>
> >>> ```haskell
> >>> stringOfT :: T -> Maybe String
> >>> stringOfT (T1 s) = Just s
> >>> stringOfT (one of T2{}, T3{}) = Nothing
> >>> ```
> >>>
> >>> is replaced with
> >>>
> >>> ```haskell
> >>> stringOfT :: T -> Maybe String
> >>> stringOfT (T1 s) = Just s
> >>> stringOfT (T2{}; T3{}) = Nothing
> >>> ```
> >>>
> >>> or indeed
> >>>
> >>> ```haskell
> >>> stringOfT :: T -> Maybe String
> >>> stringOfT x = case x of
> >>> T1 s -> Just s
> >>> T2{}
> >>> T3{} -> Nothing
> >>> ```
> >>>
> >>> (Beacuse the '(' ... ')' are optional here, we can remove them and
> naturally exploit layout.)
> >>>
> >>> The authors have conducted polls to see what folks preferred, landing
> on this proposal. The
> >>> adjustments to the Haskell grammar are really quite minimal requiring
> one extra production.
> >>>
> >>> ## Recommendation
> >>>
> >>> The proposal is nondiruptive and as a whole addresses an important
> practical topic. I recommend
> >>> that we accept it
> >>>
> >>
> >> _______________________________________________
> >> 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
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/20231002/d2c4371c/attachment.html>

From arnaud.spiwack at tweag.io  Mon Oct  2 14:18:16 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 2 Oct 2023 16:18:16 +0200
Subject: [ghc-steering-committee] #526: Applicative Comprehensions (rec:
	accept)
In-Reply-To: <4059923d-af9e-9218-9b67-f63033882220@well-typed.com>
References: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
 <4059923d-af9e-9218-9b67-f63033882220@well-typed.com>
Message-ID: <CAGwnsnkRp5g--ewTFTETqxQifXeKpWJPb0LhAO6b6sK39XP_4A@mail.gmail.com>

The proposal looks a little half-baked in its current state. It'd need a
little bit of clean-up before being accepted in my opinion. The point
raised by Simon PJ about unclear desugaring is one. How guards are handled,
since guards are primitive in the comprehension syntax. I don't think
there's a technical challenge there, though.

I do appreciate the point in the proposal that for applicatives which
aren't monad, the comprehension syntax is actually better suited than the
“do” notation. I learned something in what would have otherwise been a
rather dull day.

That being said, I think it's worth bringing up the question of the status
of MonadComprehension. As far as I can tell, this is an extension that
hasn't seen much love. Is MonadComprehension something that we're confident
we want to build on? Maybe the implementation/maintenance effort for this
proposal is low enough that the answer doesn't matter much?

On Mon, 2 Oct 2023 at 10:07, Adam Gundry <adam at well-typed.com> wrote:

> I'm unconvinced by the current state of this proposal, for similar
> reasons as Simon PJ gives on the proposal thread
> (
> https://github.com/ghc-proposals/ghc-proposals/pull/526#issuecomment-1740735610
> ).
>
> If we want to accept this merely for reasons of consistency, I think the
> simplest way forward would be to not introduce a new extension name, and
> instead define the combination of MonadComprehensions + ApplicativeDo to
> do what the proposal suggests.
>
> The author doesn't seem to be responsive on the thread. While I worry
> this may be because of the time the proposal process has been taking, it
> makes it difficult to gauge support for the various alternative
> suggestions that have been made.
>
> Cheers,
>
> Adam
>
>
> On 28/09/2023 08:12, Simon Marlow wrote:
> > Dear committee,
> >
> > #526 proposes a new extension ApplicativeComprehensions (implying
> > MonadComprehensions). It would provide the equivalent of the current
> > ApplicativeDo desugaring for do-expressions to list comprehensions.
> >
> >   * Github thread <
> https://github.com/ghc-proposals/ghc-proposals/pull/526>
> >   * Rendered
> >     <
> https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst
> >
> >
> > The extension itself is relatively uncontroversial, but there are some
> > unresolved quirks in the original ApplicativeDo extension which made us
> > uneasy about extending it. However, after various discussions I'm going
> > to propose accepting this proposal in its current state.  Rationale:
> >
> >   * It doesn't make things worse, and the implementation isn't likely to
> >     add significant complexity.
> >   * It retains consistency between ApplicativeDo and
> >     ApplicativeComprehensions (in contrast to the idea of making
> >     ApplicativeComprehensions perform a simpler desugaring, which came
> >     up during the discussion)
> >   * A future proposal can add a simpler version of the desugaring for
> >     both extensions later.
> >
> >
> > Cheers
> > Simon
>
> --
> 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
>


-- 
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/20231002/6631cf6c/attachment.html>

From arnaud.spiwack at tweag.io  Mon Oct  2 15:13:55 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 2 Oct 2023 17:13:55 +0200
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>
 <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>
Message-ID: <CAGwnsnn-6uXOYxQY_cx60KukAvF93YXwDdTzbrs+LDiMbYOUag@mail.gmail.com>

I find it difficult to follow this conversation. It's a little overwhelming
to me. So I don't have much to contribute. I have a thought though.

Part of what gives the feeling of instability that GHC has an aura for is
that haskellers are habituated to use dozens of extensions for normal
programs. It makes the act of adding an extension banal, where it
shouldn't. It probably doesn't matter how many options, warnings, explicit
bold text in documentation we add: the single best move that we can do to
promote stability in Haskell is to make it possible to write a normal
Haskell program without extensions. It's not currently possible. The best
effort in this direction is the GHC20xx process that Joachim has been
leading us through. Recent discussions (including this one) contain hints
on how to lean even stronger on this process to improve stability
guarantees.

That being said, the GR{1,2,3} articulated by Simon PJ look quite
reasonable to me.

On Mon, 2 Oct 2023 at 08: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
>>>>>>>
>>>>>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
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/20231002/c7269606/attachment-0001.html>

From arnaud.spiwack at tweag.io  Mon Oct  2 15:30:51 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 2 Oct 2023 17:30:51 +0200
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
Message-ID: <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>

Sorry I took a little bit of time to react to this, it was a lot to take in
and I didn't have the mental space last week.

The only person that may have spoken against the current state of the
proposal is Moritz. Yet I realise that I don't actually know, Moritz, what
your position is.

To recap: to use -XOverloadedRecordUpdate in current GHC, you need to use
-XRebindableSyntax and provide a setField function. In the new proposal you
can use -XOverloadedRecordUpdate without -XRebindableSyntax, but when
-XRebindableSyntax is on, the setField function that you have to provide
has its argument swapped. The current documentation of
OverloadedRecordUpdate has the following text at the top “*EXPERIMENTAL* *This
design of this extension may well change in the future. It would be
inadvisable to start using this extension for long-lived libraries just
yet.*”.

Now, I don't quite see how we could have a transition period that would
allow a smooth transition there. There is no piece of code, with
RebindableSyntax, that would compile before and after the change. So unless
I'm missing something the position we can take as a committee can be either
- Let's have the breakage without a transition period
- Let's not make the breaking change ever and use the earlier argument
order for set

Which one do you argue for, or am I missing another option?

On Sun, 24 Sept 2023 at 15:36, Eric Seidel <eric at seidel.io> wrote:

> I am in favor of this proposal.
>
> On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
> > Dear all.
> >
> > I submitted my recommendation 3 weeks ago, and only Simon has commented
> > yet. Please let me know your thoughts.
> >
> > On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
> >> Dear all,
> >>
> >> Don't forget to opine here. To reiterate, I really don't expect the
> proposal to be controversial. The text of the proposal is rather long, but
> is made easy to read. So it shouldn't take too much of your time.
> >>
> >> /Arnaud
> >>
> >> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
> >>> I support acceptance.
> >>>
> >>> Simon
> >>>
> >>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
> >>>> Dear all,
> >>>>
> >>>> [ Proposal #583
> https://github.com/ghc-proposals/ghc-proposals/pull/583 ]
> >>>>
> >>>> Our own Adam proposes to amend the design of the highly experimental
> OverloadedRecordUpdate extension as had been designed in proposal #158 [
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 ].
> >>>>
> >>>> Specifically, Adam proposes a modification of the type classes that
> would back the extension.
> >>>>
> >>>> In the previous design the HasField class is defined as a lens:
> >>>>
> >>>> class HasField (n :: k) r a | r n -> a
> >>>>   hasField :: r -> (a -> r, a)
> >>>>
> >>>> The proposal is to replace it by two classes (slightly simplified)
> >>>>
> >>>> class HasField (n :: k) r a | r n -> a
> >>>>   hasField :: r -> a
> >>>>
> >>>> class SetField (n::k) r a | r n -> a
> >>>>   modifyField :: (a -> a) -> r -> a
> >>>>   setField :: a -> r -> a
> >>>>
> >>>> This is originally motivated by some performance consideration: the
> prototype implementation of HasField as a lens can be very time consuming
> because instances of HasFields are generated eagerly at record definition
> sites, whereas the simple HasField instances can simply reuse the selectors
> already generated by GHC. But a lot of thoughts have been put into the new
> design, and my summary can certainly not do it justice: the proposal is
> very well argumented.
> >>>>
> >>>> A point I'll make here is that the new design is actually parametric
> in the data representation of the field type. Something that wasn't
> possible in the original design.
> >>>>
> >>>> This proposal is not technically backward compatible, because the
> order of argument in which OverloadedRecordUpdate expects the argument of
> setField is changed. This is not essential to the proposal, but this is a
> more consistent order argument with the rest of Haskell. And considering
> that OverloadedRecordUpdate is very loudly advertised as experimental, I
> recommend accepting this breakage.
> >>>>
> >>>> Overall the proposal is actually more backward compatible with GHC
> 9.8 than the original design, as the HasField class is left unchanged.
> >>>>
> >>>> Overall, the proposal looks quite reasonable to me, and well-argued.
> I recommend acceptance.
> >>>>
> >>>> --
> >>>> Arnaud Spiwack
> >>>> Director, Research at https://moduscreate.com and https://tweag.io.
> >>>> _______________________________________________
> >>>> ghc-steering-committee mailing list
> >>>> ghc-steering-committee at haskell.org
> >>>>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>
> >>
> >> --
> >> Arnaud Spiwack
> >> Director, Research at https://moduscreate.com and https://tweag.io.
> >
> >
> > --
> > Arnaud Spiwack
> > Director, Research at https://moduscreate.com and https://tweag.io.
> > _______________________________________________
> > 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
>


-- 
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/20231002/40e8f355/attachment.html>

From arnaud.spiwack at tweag.io  Mon Oct  2 15:34:22 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 2 Oct 2023 17:34:22 +0200
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
Message-ID: <CAGwnsn=H7MhKyE0FxfU9bh7ahs7w3vJE3GudWcx+WyK0cpS41w@mail.gmail.com>

I'm inclined to follow Adam and make -Werror=severe the default
immediately. But I don't feel strongly about it.

On Fri, 29 Sept 2023 at 20:41, Adam Gundry <adam at well-typed.com> wrote:

> Dear Committee,
>
> It seems we are somewhat split on the -Wsevere proposal, even assuming
> it is introduced with a deprecation period (changing the warning text
> and adding the group in advance). There is consensus that adding the
> group by itself is fine, and potentially enabling -Werror=severe under
> GHC2024, but enabling it by default for existing code is more
> controversial.
>
> Ultimately this is a judgement call about the value of the proposal
> versus the breakage it causes. I remain of the view that it is
> worthwhile. This is not merely about more aggressively enforcing best
> practice. Rather, it eliminates the risk of the following:
>
> * Suppose package A defines a type class, package B depends on package
> A, and package C depends on package B.
>
> * Now package A extends the type class definition with a new method and
> default methods. Everything still compiles; package B now issues a
> -Wmissing-methods warning (but is not actively maintained, and the
> author of package C is unlikely to look at warnings in all their
> dependencies).
>
> * Users of package C have to try to debug an infinite loop.
>
> Given that this change avoids a significant issue, affected code has
> been issuing warnings for many years, and impacted users can very easily
> set -Wwarn=severe either at the package level or the project level, I
> think is worth accepting the backwards compatibility cost and the fact
> that some Haskell2010 code will no longer be accepted by default.
>
> Matt Parsons puts it well in the CLC thread, which is pretty clearly in
> favour of this proposal overall
> (
> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
> ):
>
>  > I think GHC should strive to make fewer breaking changes, and make
> those changes as easy-to-adopt as possible. But this is not a question
> of GHC breaking things, but rather revealing and providing
> early-diagnosis for already broken things.
>
> Further opinions are welcome, of course.
>
> Adam
>
>
> On 14/09/2023 09:32, Adam Gundry wrote:
> > Dear Committee,
> >
> > Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods
> > and -Wmissing-fields warnings into errors by default (retaining the
> > option to downgrade them). I recommend we accept the proposal.
> >
> > Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
> > Rendered:
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> >
> > This is primarily motivated by the fact that when classes have default
> > methods, missing methods can lead to runtime loops, which are generally
> > difficult to debug. Since in practice not all users pay attention to
> > warnings that do not inhibit compilation, it makes sense to identify a
> > class of warnings that are sufficiently serious to require explicit
> > action from the user to silence them.
> >
> > Since these warnings are currently not errors by default, library
> > authors experimentally assessing the impact of changes may be lead to
> > assume that introducing new methods/fields does not lead to breakage
> > (because downstream code will still compile). The proposal thus makes it
> > more obvious that adding a new method or field is a breaking change.
> >
> > The proposal deliberately causes builds to fail by default for some
> > libraries that currently emit warnings. Oleg has kindly performed impact
> > assessments to identify such libraries, and the breakage of a few
> > packages seems worth the cost.
> >
> > It is easy to restore the warnings to their previous classification by
> > passing an option at build time, e.g. using -Wno-error=missing-methods.
> > Users can set such an option in cabal.project or stack.yaml to work
> > around breakage that is not promptly fixed by the library author.
> >
> > This change does mean that GHC with -XHaskell98/2010 will by default
> > reject some programs that are explicitly permitted by the Haskell98/2010
> > specification. I recommend we document this infelicity, but accept it,
> > as much of the benefit of the proposal is that it applies by default.
> >
> > The proposal establishes the precedent that some warnings may be treated
> > as errors by default, and introduces a warning group -Wsevere to
> > classify them. This seems conceptually useful and gives us the option to
> > extend the -Wsevere set in the future (e.g. as a final stage of
> > deprecation before a feature is removed).
> >
> > Thoughts?
> >
> > Adam
> >
> >
> > On 11/09/2023 20:25, Joachim Breitner wrote:
> >> Dear Committee,
> >>
> >> based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a
> >> warning group -Wsevere for on-by-defaults, error-by-default warnings,
> >> and initially fill it with missing-methods and missing-fields.
> >>
> >>
> >> https://github.com/ghc-proposals/ghc-proposals/pull/571
> >>
> >>
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> >>
> >> I’d like to nominate Adam as the shepherd, who already reviewed it a
> >> bit on Github.
> >>
> >> Please guide us to a conclusion as outlined in
> >> https://github.com/ghc-proposals/ghc-proposals#committee-process
> >>
> >>
> >> Cheers,
> >> Joachim
>
>
> --
> 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
>


-- 
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/20231002/ded7e4ec/attachment-0001.html>

From moritz.angermann at gmail.com  Tue Oct  3 00:14:18 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 3 Oct 2023 08:14:18 +0800
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
 <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>
Message-ID: <CAKfdd-zqumiE0FWp4vSyJXO8rqugupdXROa93fEBEYimtXYayQ@mail.gmail.com>

Arnaud,

thank you for your write up. And sorry that my view seems to be not clear.
Let me try to explain.
My position is: I'm against anything that _abruptly_ breaks existing code.
That's basically all there is to it.
Therefore I'm strongly against breaking changes without an appropriate
warning period (from the compiler).
I also strongly believe that most people do not read documentation, and the
authoritative messages are
the ones the compiler produces. As I've alluded to in a different email,
there are lots of people who work
on software as a 9-5 job, and don't spend their freetime tinkering and
playing with languages. They just
want to get the job done they are assigned. I have a lot of respect for
them. In my experience they don't
read compiler release announcements, or even go and read the compiler
documentation. They are given
the compiler version the company decided on for use in production. That's
the tool they use. And that tool
in my opinion needs to be rock solid, and not break easily across versions.
Thus yes, I would very much
like to see us not have breaking changes at all, but I can see that we may
need breaking changes
occasionally. In those cases I want it to be very visible to the consumers
that this breaking change is
coming towards them (compiler warnings). Giving them some time to adjust
(migration period), until the
breaking change happens.  Ultimately we should be able to compiler existing
code that compiles today
with at least the next compiler without it rejecting the code or needing
modifications to the code (-Werror
excluded).

Thus what I'm arguing for is:
- Let's implement this backwards compatibility.
- Add compiler warnings about the arguments being swapped in a future GHC
version. For _a least_ one major release.
- Make the breaking change in a subsequent release.

Alternatively I could also see:
- Adding compiler warnings now that the arguments will be swapped in a
future GHC version (for at least one major release).
- Implement the breaking change in a subsequent release.

Either of those would be ok with me. Implementing a breaking change from
one version to the next, without an
appropriate deprecation/migration period (that is, the compiler will warn
loudly that changes are coming) is something
I am _very_ vehemently against.

If the migration/deprecation warnings would provide a link to a GitHub
ticket or something where more information
can be found and maybe even a discussion could be had would probably also
be a good idea.

I hope this helps clarify my position? If not, feel free to ask more, I'm
also happy to jump onto a call to explain my
position if needed.

Best,
 Moritz


On Mon, 2 Oct 2023 at 23:31, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:

> Sorry I took a little bit of time to react to this, it was a lot to take
> in and I didn't have the mental space last week.
>
> The only person that may have spoken against the current state of the
> proposal is Moritz. Yet I realise that I don't actually know, Moritz, what
> your position is.
>
> To recap: to use -XOverloadedRecordUpdate in current GHC, you need to use
> -XRebindableSyntax and provide a setField function. In the new proposal you
> can use -XOverloadedRecordUpdate without -XRebindableSyntax, but when
> -XRebindableSyntax is on, the setField function that you have to provide
> has its argument swapped. The current documentation of
> OverloadedRecordUpdate has the following text at the top “*EXPERIMENTAL* *This
> design of this extension may well change in the future. It would be
> inadvisable to start using this extension for long-lived libraries just
> yet.*”.
>
> Now, I don't quite see how we could have a transition period that would
> allow a smooth transition there. There is no piece of code, with
> RebindableSyntax, that would compile before and after the change. So unless
> I'm missing something the position we can take as a committee can be either
> - Let's have the breakage without a transition period
> - Let's not make the breaking change ever and use the earlier argument
> order for set
>
> Which one do you argue for, or am I missing another option?
>
> On Sun, 24 Sept 2023 at 15:36, Eric Seidel <eric at seidel.io> wrote:
>
>> I am in favor of this proposal.
>>
>> On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
>> > Dear all.
>> >
>> > I submitted my recommendation 3 weeks ago, and only Simon has commented
>> > yet. Please let me know your thoughts.
>> >
>> > On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>> >> Dear all,
>> >>
>> >> Don't forget to opine here. To reiterate, I really don't expect the
>> proposal to be controversial. The text of the proposal is rather long, but
>> is made easy to read. So it shouldn't take too much of your time.
>> >>
>> >> /Arnaud
>> >>
>> >> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>> >>> I support acceptance.
>> >>>
>> >>> Simon
>> >>>
>> >>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>> >>>> Dear all,
>> >>>>
>> >>>> [ Proposal #583
>> https://github.com/ghc-proposals/ghc-proposals/pull/583 ]
>> >>>>
>> >>>> Our own Adam proposes to amend the design of the highly experimental
>> OverloadedRecordUpdate extension as had been designed in proposal #158 [
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 ].
>> >>>>
>> >>>> Specifically, Adam proposes a modification of the type classes that
>> would back the extension.
>> >>>>
>> >>>> In the previous design the HasField class is defined as a lens:
>> >>>>
>> >>>> class HasField (n :: k) r a | r n -> a
>> >>>>   hasField :: r -> (a -> r, a)
>> >>>>
>> >>>> The proposal is to replace it by two classes (slightly simplified)
>> >>>>
>> >>>> class HasField (n :: k) r a | r n -> a
>> >>>>   hasField :: r -> a
>> >>>>
>> >>>> class SetField (n::k) r a | r n -> a
>> >>>>   modifyField :: (a -> a) -> r -> a
>> >>>>   setField :: a -> r -> a
>> >>>>
>> >>>> This is originally motivated by some performance consideration: the
>> prototype implementation of HasField as a lens can be very time consuming
>> because instances of HasFields are generated eagerly at record definition
>> sites, whereas the simple HasField instances can simply reuse the selectors
>> already generated by GHC. But a lot of thoughts have been put into the new
>> design, and my summary can certainly not do it justice: the proposal is
>> very well argumented.
>> >>>>
>> >>>> A point I'll make here is that the new design is actually parametric
>> in the data representation of the field type. Something that wasn't
>> possible in the original design.
>> >>>>
>> >>>> This proposal is not technically backward compatible, because the
>> order of argument in which OverloadedRecordUpdate expects the argument of
>> setField is changed. This is not essential to the proposal, but this is a
>> more consistent order argument with the rest of Haskell. And considering
>> that OverloadedRecordUpdate is very loudly advertised as experimental, I
>> recommend accepting this breakage.
>> >>>>
>> >>>> Overall the proposal is actually more backward compatible with GHC
>> 9.8 than the original design, as the HasField class is left unchanged.
>> >>>>
>> >>>> Overall, the proposal looks quite reasonable to me, and well-argued.
>> I recommend acceptance.
>> >>>>
>> >>>> --
>> >>>> Arnaud Spiwack
>> >>>> Director, Research at https://moduscreate.com and https://tweag.io.
>> >>>> _______________________________________________
>> >>>> ghc-steering-committee mailing list
>> >>>> ghc-steering-committee at haskell.org
>> >>>>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >>
>> >>
>> >> --
>> >> Arnaud Spiwack
>> >> Director, Research at https://moduscreate.com and https://tweag.io.
>> >
>> >
>> > --
>> > Arnaud Spiwack
>> > Director, Research at https://moduscreate.com and https://tweag.io.
>> > _______________________________________________
>> > 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
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> 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/fb7677d3/attachment.html>

From adam at well-typed.com  Tue Oct  3 07:21:07 2023
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 3 Oct 2023 08:21:07 +0100
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAKfdd-zqumiE0FWp4vSyJXO8rqugupdXROa93fEBEYimtXYayQ@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
 <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>
 <CAKfdd-zqumiE0FWp4vSyJXO8rqugupdXROa93fEBEYimtXYayQ@mail.gmail.com>
Message-ID: <6ecf13eb-7c08-4f09-5696-deadc830231f@well-typed.com>

The backwards compatibility impact here is really extremely small, 
because OverloadedRecordUpdate is essentially unusable at present (as 
well as being explicitly documented as subject to change), so nobody 
uses it. While someone could implement a warning when the extension is 
turned on to say that it will change in the future, I'm not sure I see 
much point.

I used https://hackage-search.serokell.io/?q=OverloadedRecordUpdate to 
look for occurrences of OverloadedRecordUpdate on Hackage, and I found 
precisely one pair of packages using it "for real":

large-anon-0.3.0
large-records-0.4

These packages were created by my colleague Edsko in discussion with me, 
and will need to be amended when the proposal is implemented, because 
they want to take advantage of the new functionality.

The other packages on Hackage containing the string 
OverloadedRecordUpdate are tools that reference all extensions:

Cabal-syntax-3.10.1.0
extensions-0.1.0.0
fourmolu-0.14.0.0
ghc-9.6.3
ghc-boot-th-9.6.3
ghc-exactprint-1.7.0.1
ghc-hs-meta-0.1.2.0
ghc-lib-9.6.2.20230523
ghc-lib-parser-9.6.2.20230523
hackport-0.8.4.0
haskell-src-meta-0.8.12
hindent-6.1.0
hlint-3.6.1
ormolu-0.7.2.0

plus there are a few references in comments:

lifx-lan-0.8.2
optics-core-0.4.1.1
pvector-0.1.1
record-dot-preprocessor-0.2.16
tztime-0.1.1.0

While I generally agree with the "don't abruptly break existing code" 
position, in this case I don't think there is code out there to break.

Adam


On 03/10/2023 01:14, Moritz Angermann wrote:
> Arnaud,
> 
> thank you for your write up. And sorry that my view seems to be not 
> clear. Let me try to explain.
> My position is: I'm against anything that _abruptly_ breaks existing 
> code. That's basically all there is to it.
> Therefore I'm strongly against breaking changes without an appropriate 
> warning period (from the compiler).
> I also strongly believe that most people do not read documentation, and 
> the authoritative messages are
> the ones the compiler produces. As I've alluded to in a different email, 
> there are lots of people who work
> on software as a 9-5 job, and don't spend their freetime tinkering and 
> playing with languages. They just
> want to get the job done they are assigned. I have a lot of respect for 
> them. In my experience they don't
> read compiler release announcements, or even go and read the compiler 
> documentation. They are given
> the compiler version the company decided on for use in production. 
> That's the tool they use. And that tool
> in my opinion needs to be rock solid, and not break easily across 
> versions. Thus yes, I would very much
> like to see us not have breaking changes at all, but I can see that we 
> may need breaking changes
> occasionally. In those cases I want it to be very visible to the 
> consumers that this breaking change is
> coming towards them (compiler warnings). Giving them some time to adjust 
> (migration period), until the
> breaking change happens.  Ultimately we should be able to compiler 
> existing code that compiles today
> with at least the next compiler without it rejecting the code or needing 
> modifications to the code (-Werror
> excluded).
> 
> Thus what I'm arguing for is:
> - Let's implement this backwards compatibility.
> - Add compiler warnings about the arguments being swapped in a future 
> GHC version. For _a least_ one major release.
> - Make the breaking change in a subsequent release.
> 
> Alternatively I could also see:
> - Adding compiler warnings now that the arguments will be swapped in a 
> future GHC version (for at least one major release).
> - Implement the breaking change in a subsequent release.
> 
> Either of those would be ok with me. Implementing a breaking change from 
> one version to the next, without an
> appropriate deprecation/migration period (that is, the compiler will 
> warn loudly that changes are coming) is something
> I am _very_ vehemently against.
> 
> If the migration/deprecation warnings would provide a link to a GitHub 
> ticket or something where more information
> can be found and maybe even a discussion could be had would probably 
> also be a good idea.
> 
> I hope this helps clarify my position? If not, feel free to ask more, 
> I'm also happy to jump onto a call to explain my
> position if needed.
> 
> Best,
>   Moritz
> 
> 
> On Mon, 2 Oct 2023 at 23:31, Arnaud Spiwack <arnaud.spiwack at tweag.io 
> <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
>     Sorry I took a little bit of time to react to this, it was a lot to
>     take in and I didn't have the mental space last week.
> 
>     The only person that may have spoken against the current state of
>     the proposal is Moritz. Yet I realise that I don't actually know,
>     Moritz, what your position is.
> 
>     To recap: to use -XOverloadedRecordUpdate in current GHC, you need
>     to use -XRebindableSyntax and provide a setField function. In the
>     new proposal you can use -XOverloadedRecordUpdate without
>     -XRebindableSyntax, but when -XRebindableSyntax is on, the setField
>     function that you have to provide has its argument swapped. The
>     current documentation of OverloadedRecordUpdate has the following
>     text at the top “*EXPERIMENTAL* /This design of this extension may
>     well change in the future. It would be inadvisable to start using
>     this extension for long-lived libraries just yet./”.
> 
>     Now, I don't quite see how we could have a transition period that
>     would allow a smooth transition there. There is no piece of code,
>     with RebindableSyntax, that would compile before and after the
>     change. So unless I'm missing something the position we can take as
>     a committee can be either
>     - Let's have the breakage without a transition period
>     - Let's not make the breaking change ever and use the earlier
>     argument order for set
> 
>     Which one do you argue for, or am I missing another option?
> 
>     On Sun, 24 Sept 2023 at 15:36, Eric Seidel <eric at seidel.io
>     <mailto:eric at seidel.io>> wrote:
> 
>         I am in favor of this proposal.
> 
>         On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
>          > Dear all.
>          >
>          > I submitted my recommendation 3 weeks ago, and only Simon has
>         commented
>          > yet. Please let me know your thoughts.
>          >
>          > On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack
>         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>          >> Dear all,
>          >>
>          >> Don't forget to opine here. To reiterate, I really don't
>         expect the proposal to be controversial. The text of the
>         proposal is rather long, but is made easy to read. So it
>         shouldn't take too much of your time.
>          >>
>          >> /Arnaud
>          >>
>          >> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones
>         <simon.peytonjones at gmail.com
>         <mailto:simon.peytonjones at gmail.com>> wrote:
>          >>> I support acceptance.
>          >>>
>          >>> Simon
>          >>>
>          >>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack
>         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>          >>>> Dear all,
>          >>>>
>          >>>> [ Proposal #583
>         https://github.com/ghc-proposals/ghc-proposals/pull/583
>         <https://github.com/ghc-proposals/ghc-proposals/pull/583> ]
>          >>>>
>          >>>> Our own Adam proposes to amend the design of the highly
>         experimental OverloadedRecordUpdate extension as had been
>         designed in proposal #158 [
>         https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 <https://github.com/ghc-proposals/ghc-proposals/pull/405> ].
>          >>>>
>          >>>> Specifically, Adam proposes a modification of the type
>         classes that would back the extension.
>          >>>>
>          >>>> In the previous design the HasField class is defined as a
>         lens:
>          >>>>
>          >>>> class HasField (n :: k) r a | r n -> a
>          >>>>   hasField :: r -> (a -> r, a)
>          >>>>
>          >>>> The proposal is to replace it by two classes (slightly
>         simplified)
>          >>>>
>          >>>> class HasField (n :: k) r a | r n -> a
>          >>>>   hasField :: r -> a
>          >>>>
>          >>>> class SetField (n::k) r a | r n -> a
>          >>>>   modifyField :: (a -> a) -> r -> a
>          >>>>   setField :: a -> r -> a
>          >>>>
>          >>>> This is originally motivated by some performance
>         consideration: the prototype implementation of HasField as a
>         lens can be very time consuming because instances of HasFields
>         are generated eagerly at record definition sites, whereas the
>         simple HasField instances can simply reuse the selectors already
>         generated by GHC. But a lot of thoughts have been put into the
>         new design, and my summary can certainly not do it justice: the
>         proposal is very well argumented.
>          >>>>
>          >>>> A point I'll make here is that the new design is actually
>         parametric in the data representation of the field type.
>         Something that wasn't possible in the original design.
>          >>>>
>          >>>> This proposal is not technically backward compatible,
>         because the order of argument in which OverloadedRecordUpdate
>         expects the argument of setField is changed. This is not
>         essential to the proposal, but this is a more consistent order
>         argument with the rest of Haskell. And considering that
>         OverloadedRecordUpdate is very loudly advertised as
>         experimental, I recommend accepting this breakage.
>          >>>>
>          >>>> Overall the proposal is actually more backward compatible
>         with GHC 9.8 than the original design, as the HasField class is
>         left unchanged.
>          >>>>
>          >>>> Overall, the proposal looks quite reasonable to me, and
>         well-argued. I recommend acceptance.



-- 
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


From arnaud.spiwack at tweag.io  Tue Oct  3 07:30:29 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 3 Oct 2023 09:30:29 +0200
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <6ecf13eb-7c08-4f09-5696-deadc830231f@well-typed.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
 <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>
 <CAKfdd-zqumiE0FWp4vSyJXO8rqugupdXROa93fEBEYimtXYayQ@mail.gmail.com>
 <6ecf13eb-7c08-4f09-5696-deadc830231f@well-typed.com>
Message-ID: <CAGwnsnkHOsVeDTqo1gTw10ECMQ+QjabRFbcspwCN8xcsN2eEfg@mail.gmail.com>

@Moritz: very clear thank you, though I'd like to understand how one could
adapt during the transition period to an argument swap, would you say?
Secondary question: if they can't adapt, isn't there a risk of making the
breakage more painful by delaying it, and letting more people use
-XOverloadedRecordUpdate with the argument order which isn't the final one?

@Adam: we have to recognise that Hackage is not all the Haskell code. I
expect Hackage to be a little more conservative in extensions than end-user
applications. As such we're not guaranteed an absence of breakage (it's
still probably quite small, but it's hard to quantify).

On Tue, 3 Oct 2023 at 09:21, Adam Gundry <adam at well-typed.com> wrote:

> The backwards compatibility impact here is really extremely small,
> because OverloadedRecordUpdate is essentially unusable at present (as
> well as being explicitly documented as subject to change), so nobody
> uses it. While someone could implement a warning when the extension is
> turned on to say that it will change in the future, I'm not sure I see
> much point.
>
> I used https://hackage-search.serokell.io/?q=OverloadedRecordUpdate to
> look for occurrences of OverloadedRecordUpdate on Hackage, and I found
> precisely one pair of packages using it "for real":
>
> large-anon-0.3.0
> large-records-0.4
>
> These packages were created by my colleague Edsko in discussion with me,
> and will need to be amended when the proposal is implemented, because
> they want to take advantage of the new functionality.
>
> The other packages on Hackage containing the string
> OverloadedRecordUpdate are tools that reference all extensions:
>
> Cabal-syntax-3.10.1.0
> extensions-0.1.0.0
> fourmolu-0.14.0.0
> ghc-9.6.3
> ghc-boot-th-9.6.3
> ghc-exactprint-1.7.0.1
> ghc-hs-meta-0.1.2.0
> ghc-lib-9.6.2.20230523
> ghc-lib-parser-9.6.2.20230523
> hackport-0.8.4.0
> haskell-src-meta-0.8.12
> hindent-6.1.0
> hlint-3.6.1
> ormolu-0.7.2.0
>
> plus there are a few references in comments:
>
> lifx-lan-0.8.2
> optics-core-0.4.1.1
> pvector-0.1.1
> record-dot-preprocessor-0.2.16
> tztime-0.1.1.0
>
> While I generally agree with the "don't abruptly break existing code"
> position, in this case I don't think there is code out there to break.
>
> Adam
>
>
> On 03/10/2023 01:14, Moritz Angermann wrote:
> > Arnaud,
> >
> > thank you for your write up. And sorry that my view seems to be not
> > clear. Let me try to explain.
> > My position is: I'm against anything that _abruptly_ breaks existing
> > code. That's basically all there is to it.
> > Therefore I'm strongly against breaking changes without an appropriate
> > warning period (from the compiler).
> > I also strongly believe that most people do not read documentation, and
> > the authoritative messages are
> > the ones the compiler produces. As I've alluded to in a different email,
> > there are lots of people who work
> > on software as a 9-5 job, and don't spend their freetime tinkering and
> > playing with languages. They just
> > want to get the job done they are assigned. I have a lot of respect for
> > them. In my experience they don't
> > read compiler release announcements, or even go and read the compiler
> > documentation. They are given
> > the compiler version the company decided on for use in production.
> > That's the tool they use. And that tool
> > in my opinion needs to be rock solid, and not break easily across
> > versions. Thus yes, I would very much
> > like to see us not have breaking changes at all, but I can see that we
> > may need breaking changes
> > occasionally. In those cases I want it to be very visible to the
> > consumers that this breaking change is
> > coming towards them (compiler warnings). Giving them some time to adjust
> > (migration period), until the
> > breaking change happens.  Ultimately we should be able to compiler
> > existing code that compiles today
> > with at least the next compiler without it rejecting the code or needing
> > modifications to the code (-Werror
> > excluded).
> >
> > Thus what I'm arguing for is:
> > - Let's implement this backwards compatibility.
> > - Add compiler warnings about the arguments being swapped in a future
> > GHC version. For _a least_ one major release.
> > - Make the breaking change in a subsequent release.
> >
> > Alternatively I could also see:
> > - Adding compiler warnings now that the arguments will be swapped in a
> > future GHC version (for at least one major release).
> > - Implement the breaking change in a subsequent release.
> >
> > Either of those would be ok with me. Implementing a breaking change from
> > one version to the next, without an
> > appropriate deprecation/migration period (that is, the compiler will
> > warn loudly that changes are coming) is something
> > I am _very_ vehemently against.
> >
> > If the migration/deprecation warnings would provide a link to a GitHub
> > ticket or something where more information
> > can be found and maybe even a discussion could be had would probably
> > also be a good idea.
> >
> > I hope this helps clarify my position? If not, feel free to ask more,
> > I'm also happy to jump onto a call to explain my
> > position if needed.
> >
> > Best,
> >   Moritz
> >
> >
> > On Mon, 2 Oct 2023 at 23:31, Arnaud Spiwack <arnaud.spiwack at tweag.io
> > <mailto:arnaud.spiwack at tweag.io>> wrote:
> >
> >     Sorry I took a little bit of time to react to this, it was a lot to
> >     take in and I didn't have the mental space last week.
> >
> >     The only person that may have spoken against the current state of
> >     the proposal is Moritz. Yet I realise that I don't actually know,
> >     Moritz, what your position is.
> >
> >     To recap: to use -XOverloadedRecordUpdate in current GHC, you need
> >     to use -XRebindableSyntax and provide a setField function. In the
> >     new proposal you can use -XOverloadedRecordUpdate without
> >     -XRebindableSyntax, but when -XRebindableSyntax is on, the setField
> >     function that you have to provide has its argument swapped. The
> >     current documentation of OverloadedRecordUpdate has the following
> >     text at the top “*EXPERIMENTAL* /This design of this extension may
> >     well change in the future. It would be inadvisable to start using
> >     this extension for long-lived libraries just yet./”.
> >
> >     Now, I don't quite see how we could have a transition period that
> >     would allow a smooth transition there. There is no piece of code,
> >     with RebindableSyntax, that would compile before and after the
> >     change. So unless I'm missing something the position we can take as
> >     a committee can be either
> >     - Let's have the breakage without a transition period
> >     - Let's not make the breaking change ever and use the earlier
> >     argument order for set
> >
> >     Which one do you argue for, or am I missing another option?
> >
> >     On Sun, 24 Sept 2023 at 15:36, Eric Seidel <eric at seidel.io
> >     <mailto:eric at seidel.io>> wrote:
> >
> >         I am in favor of this proposal.
> >
> >         On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
> >          > Dear all.
> >          >
> >          > I submitted my recommendation 3 weeks ago, and only Simon has
> >         commented
> >          > yet. Please let me know your thoughts.
> >          >
> >          > On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack
> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
> wrote:
> >          >> Dear all,
> >          >>
> >          >> Don't forget to opine here. To reiterate, I really don't
> >         expect the proposal to be controversial. The text of the
> >         proposal is rather long, but is made easy to read. So it
> >         shouldn't take too much of your time.
> >          >>
> >          >> /Arnaud
> >          >>
> >          >> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones
> >         <simon.peytonjones at gmail.com
> >         <mailto:simon.peytonjones at gmail.com>> wrote:
> >          >>> I support acceptance.
> >          >>>
> >          >>> Simon
> >          >>>
> >          >>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack
> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
> wrote:
> >          >>>> Dear all,
> >          >>>>
> >          >>>> [ Proposal #583
> >         https://github.com/ghc-proposals/ghc-proposals/pull/583
> >         <https://github.com/ghc-proposals/ghc-proposals/pull/583> ]
> >          >>>>
> >          >>>> Our own Adam proposes to amend the design of the highly
> >         experimental OverloadedRecordUpdate extension as had been
> >         designed in proposal #158 [
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
> <
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst>
> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 <
> https://github.com/ghc-proposals/ghc-proposals/pull/405> ].
> >          >>>>
> >          >>>> Specifically, Adam proposes a modification of the type
> >         classes that would back the extension.
> >          >>>>
> >          >>>> In the previous design the HasField class is defined as a
> >         lens:
> >          >>>>
> >          >>>> class HasField (n :: k) r a | r n -> a
> >          >>>>   hasField :: r -> (a -> r, a)
> >          >>>>
> >          >>>> The proposal is to replace it by two classes (slightly
> >         simplified)
> >          >>>>
> >          >>>> class HasField (n :: k) r a | r n -> a
> >          >>>>   hasField :: r -> a
> >          >>>>
> >          >>>> class SetField (n::k) r a | r n -> a
> >          >>>>   modifyField :: (a -> a) -> r -> a
> >          >>>>   setField :: a -> r -> a
> >          >>>>
> >          >>>> This is originally motivated by some performance
> >         consideration: the prototype implementation of HasField as a
> >         lens can be very time consuming because instances of HasFields
> >         are generated eagerly at record definition sites, whereas the
> >         simple HasField instances can simply reuse the selectors already
> >         generated by GHC. But a lot of thoughts have been put into the
> >         new design, and my summary can certainly not do it justice: the
> >         proposal is very well argumented.
> >          >>>>
> >          >>>> A point I'll make here is that the new design is actually
> >         parametric in the data representation of the field type.
> >         Something that wasn't possible in the original design.
> >          >>>>
> >          >>>> This proposal is not technically backward compatible,
> >         because the order of argument in which OverloadedRecordUpdate
> >         expects the argument of setField is changed. This is not
> >         essential to the proposal, but this is a more consistent order
> >         argument with the rest of Haskell. And considering that
> >         OverloadedRecordUpdate is very loudly advertised as
> >         experimental, I recommend accepting this breakage.
> >          >>>>
> >          >>>> Overall the proposal is actually more backward compatible
> >         with GHC 9.8 than the original design, as the HasField class is
> >         left unchanged.
> >          >>>>
> >          >>>> Overall, the proposal looks quite reasonable to me, and
> >         well-argued. I recommend acceptance.
>
>
>
> --
> 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
>


-- 
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/20231003/c218777a/attachment-0001.html>

From moritz.angermann at gmail.com  Tue Oct  3 07:47:44 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 3 Oct 2023 15:47:44 +0800
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAGwnsnkHOsVeDTqo1gTw10ECMQ+QjabRFbcspwCN8xcsN2eEfg@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
 <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>
 <CAKfdd-zqumiE0FWp4vSyJXO8rqugupdXROa93fEBEYimtXYayQ@mail.gmail.com>
 <6ecf13eb-7c08-4f09-5696-deadc830231f@well-typed.com>
 <CAGwnsnkHOsVeDTqo1gTw10ECMQ+QjabRFbcspwCN8xcsN2eEfg@mail.gmail.com>
Message-ID: <CAKfdd-ziOZdZ=gNpZLU-w-n8V6BFE=uu+jdK5MZyZPMcmgv5Bg@mail.gmail.com>

Arnaud,

That is a good argument. Without an opt-in to the new syntax, they can't
adapt. I guess this brings us to the extension lifecycle. A solution could
be
1. Deprecate OverloadedRecordUpdate in favour of OverloadedRecordUpdateNew.
The user can adapt their code and use a different Extension.
2. Eventually Have OverloadedRecordUpdateNew be a synonym for changed
OverloadedRecordUpdate. And Deprecate OverloadedRecordUpdateNew
    over a longer period of time.

I think this actually shows the value a `--std=experimental` could have. If
`OverloadedRecordUpdate` was behind `--std=experimental` breaking it would
be permissible by design. And we would not have this discussion, and Adam
would not need to try to find all the potential breaking codes. This is part
of the proposal to make `--std=experimental` a thing, allow fast(er) paced
iteration on the experimental side of the compiler, while being extremely
explicit about it being experimental features that can break at any time
and without warning.

The deprecation process outlined above would be fore non-experimental
features. They can still be changed, but with a more rigorous change
evolution.

I hope this helps to clarify my position?

Best,
 Moritz


On Tue, 3 Oct 2023 at 15:31, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:

> @Moritz: very clear thank you, though I'd like to understand how one could
> adapt during the transition period to an argument swap, would you say?
> Secondary question: if they can't adapt, isn't there a risk of making the
> breakage more painful by delaying it, and letting more people use
> -XOverloadedRecordUpdate with the argument order which isn't the final one?
>
> @Adam: we have to recognise that Hackage is not all the Haskell code. I
> expect Hackage to be a little more conservative in extensions than end-user
> applications. As such we're not guaranteed an absence of breakage (it's
> still probably quite small, but it's hard to quantify).
>
> On Tue, 3 Oct 2023 at 09:21, Adam Gundry <adam at well-typed.com> wrote:
>
>> The backwards compatibility impact here is really extremely small,
>> because OverloadedRecordUpdate is essentially unusable at present (as
>> well as being explicitly documented as subject to change), so nobody
>> uses it. While someone could implement a warning when the extension is
>> turned on to say that it will change in the future, I'm not sure I see
>> much point.
>>
>> I used https://hackage-search.serokell.io/?q=OverloadedRecordUpdate to
>> look for occurrences of OverloadedRecordUpdate on Hackage, and I found
>> precisely one pair of packages using it "for real":
>>
>> large-anon-0.3.0
>> large-records-0.4
>>
>> These packages were created by my colleague Edsko in discussion with me,
>> and will need to be amended when the proposal is implemented, because
>> they want to take advantage of the new functionality.
>>
>> The other packages on Hackage containing the string
>> OverloadedRecordUpdate are tools that reference all extensions:
>>
>> Cabal-syntax-3.10.1.0
>> extensions-0.1.0.0
>> fourmolu-0.14.0.0
>> ghc-9.6.3
>> ghc-boot-th-9.6.3
>> ghc-exactprint-1.7.0.1
>> ghc-hs-meta-0.1.2.0
>> ghc-lib-9.6.2.20230523
>> ghc-lib-parser-9.6.2.20230523
>> hackport-0.8.4.0
>> haskell-src-meta-0.8.12
>> hindent-6.1.0
>> hlint-3.6.1
>> ormolu-0.7.2.0
>>
>> plus there are a few references in comments:
>>
>> lifx-lan-0.8.2
>> optics-core-0.4.1.1
>> pvector-0.1.1
>> record-dot-preprocessor-0.2.16
>> tztime-0.1.1.0
>>
>> While I generally agree with the "don't abruptly break existing code"
>> position, in this case I don't think there is code out there to break.
>>
>> Adam
>>
>>
>> On 03/10/2023 01:14, Moritz Angermann wrote:
>> > Arnaud,
>> >
>> > thank you for your write up. And sorry that my view seems to be not
>> > clear. Let me try to explain.
>> > My position is: I'm against anything that _abruptly_ breaks existing
>> > code. That's basically all there is to it.
>> > Therefore I'm strongly against breaking changes without an appropriate
>> > warning period (from the compiler).
>> > I also strongly believe that most people do not read documentation, and
>> > the authoritative messages are
>> > the ones the compiler produces. As I've alluded to in a different
>> email,
>> > there are lots of people who work
>> > on software as a 9-5 job, and don't spend their freetime tinkering and
>> > playing with languages. They just
>> > want to get the job done they are assigned. I have a lot of respect for
>> > them. In my experience they don't
>> > read compiler release announcements, or even go and read the compiler
>> > documentation. They are given
>> > the compiler version the company decided on for use in production.
>> > That's the tool they use. And that tool
>> > in my opinion needs to be rock solid, and not break easily across
>> > versions. Thus yes, I would very much
>> > like to see us not have breaking changes at all, but I can see that we
>> > may need breaking changes
>> > occasionally. In those cases I want it to be very visible to the
>> > consumers that this breaking change is
>> > coming towards them (compiler warnings). Giving them some time to
>> adjust
>> > (migration period), until the
>> > breaking change happens.  Ultimately we should be able to compiler
>> > existing code that compiles today
>> > with at least the next compiler without it rejecting the code or
>> needing
>> > modifications to the code (-Werror
>> > excluded).
>> >
>> > Thus what I'm arguing for is:
>> > - Let's implement this backwards compatibility.
>> > - Add compiler warnings about the arguments being swapped in a future
>> > GHC version. For _a least_ one major release.
>> > - Make the breaking change in a subsequent release.
>> >
>> > Alternatively I could also see:
>> > - Adding compiler warnings now that the arguments will be swapped in a
>> > future GHC version (for at least one major release).
>> > - Implement the breaking change in a subsequent release.
>> >
>> > Either of those would be ok with me. Implementing a breaking change
>> from
>> > one version to the next, without an
>> > appropriate deprecation/migration period (that is, the compiler will
>> > warn loudly that changes are coming) is something
>> > I am _very_ vehemently against.
>> >
>> > If the migration/deprecation warnings would provide a link to a GitHub
>> > ticket or something where more information
>> > can be found and maybe even a discussion could be had would probably
>> > also be a good idea.
>> >
>> > I hope this helps clarify my position? If not, feel free to ask more,
>> > I'm also happy to jump onto a call to explain my
>> > position if needed.
>> >
>> > Best,
>> >   Moritz
>> >
>> >
>> > On Mon, 2 Oct 2023 at 23:31, Arnaud Spiwack <arnaud.spiwack at tweag.io
>> > <mailto:arnaud.spiwack at tweag.io>> wrote:
>> >
>> >     Sorry I took a little bit of time to react to this, it was a lot to
>> >     take in and I didn't have the mental space last week.
>> >
>> >     The only person that may have spoken against the current state of
>> >     the proposal is Moritz. Yet I realise that I don't actually know,
>> >     Moritz, what your position is.
>> >
>> >     To recap: to use -XOverloadedRecordUpdate in current GHC, you need
>> >     to use -XRebindableSyntax and provide a setField function. In the
>> >     new proposal you can use -XOverloadedRecordUpdate without
>> >     -XRebindableSyntax, but when -XRebindableSyntax is on, the setField
>> >     function that you have to provide has its argument swapped. The
>> >     current documentation of OverloadedRecordUpdate has the following
>> >     text at the top “*EXPERIMENTAL* /This design of this extension may
>> >     well change in the future. It would be inadvisable to start using
>> >     this extension for long-lived libraries just yet./”.
>> >
>> >     Now, I don't quite see how we could have a transition period that
>> >     would allow a smooth transition there. There is no piece of code,
>> >     with RebindableSyntax, that would compile before and after the
>> >     change. So unless I'm missing something the position we can take as
>> >     a committee can be either
>> >     - Let's have the breakage without a transition period
>> >     - Let's not make the breaking change ever and use the earlier
>> >     argument order for set
>> >
>> >     Which one do you argue for, or am I missing another option?
>> >
>> >     On Sun, 24 Sept 2023 at 15:36, Eric Seidel <eric at seidel.io
>> >     <mailto:eric at seidel.io>> wrote:
>> >
>> >         I am in favor of this proposal.
>> >
>> >         On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
>> >          > Dear all.
>> >          >
>> >          > I submitted my recommendation 3 weeks ago, and only Simon has
>> >         commented
>> >          > yet. Please let me know your thoughts.
>> >          >
>> >          > On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack
>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>> wrote:
>> >          >> Dear all,
>> >          >>
>> >          >> Don't forget to opine here. To reiterate, I really don't
>> >         expect the proposal to be controversial. The text of the
>> >         proposal is rather long, but is made easy to read. So it
>> >         shouldn't take too much of your time.
>> >          >>
>> >          >> /Arnaud
>> >          >>
>> >          >> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones
>> >         <simon.peytonjones at gmail.com
>> >         <mailto:simon.peytonjones at gmail.com>> wrote:
>> >          >>> I support acceptance.
>> >          >>>
>> >          >>> Simon
>> >          >>>
>> >          >>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack
>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>> wrote:
>> >          >>>> Dear all,
>> >          >>>>
>> >          >>>> [ Proposal #583
>> >         https://github.com/ghc-proposals/ghc-proposals/pull/583
>> >         <https://github.com/ghc-proposals/ghc-proposals/pull/583> ]
>> >          >>>>
>> >          >>>> Our own Adam proposes to amend the design of the highly
>> >         experimental OverloadedRecordUpdate extension as had been
>> >         designed in proposal #158 [
>> >
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>> <
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst>
>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 <
>> https://github.com/ghc-proposals/ghc-proposals/pull/405> ].
>> >          >>>>
>> >          >>>> Specifically, Adam proposes a modification of the type
>> >         classes that would back the extension.
>> >          >>>>
>> >          >>>> In the previous design the HasField class is defined as a
>> >         lens:
>> >          >>>>
>> >          >>>> class HasField (n :: k) r a | r n -> a
>> >          >>>>   hasField :: r -> (a -> r, a)
>> >          >>>>
>> >          >>>> The proposal is to replace it by two classes (slightly
>> >         simplified)
>> >          >>>>
>> >          >>>> class HasField (n :: k) r a | r n -> a
>> >          >>>>   hasField :: r -> a
>> >          >>>>
>> >          >>>> class SetField (n::k) r a | r n -> a
>> >          >>>>   modifyField :: (a -> a) -> r -> a
>> >          >>>>   setField :: a -> r -> a
>> >          >>>>
>> >          >>>> This is originally motivated by some performance
>> >         consideration: the prototype implementation of HasField as a
>> >         lens can be very time consuming because instances of HasFields
>> >         are generated eagerly at record definition sites, whereas the
>> >         simple HasField instances can simply reuse the selectors already
>> >         generated by GHC. But a lot of thoughts have been put into the
>> >         new design, and my summary can certainly not do it justice: the
>> >         proposal is very well argumented.
>> >          >>>>
>> >          >>>> A point I'll make here is that the new design is actually
>> >         parametric in the data representation of the field type.
>> >         Something that wasn't possible in the original design.
>> >          >>>>
>> >          >>>> This proposal is not technically backward compatible,
>> >         because the order of argument in which OverloadedRecordUpdate
>> >         expects the argument of setField is changed. This is not
>> >         essential to the proposal, but this is a more consistent order
>> >         argument with the rest of Haskell. And considering that
>> >         OverloadedRecordUpdate is very loudly advertised as
>> >         experimental, I recommend accepting this breakage.
>> >          >>>>
>> >          >>>> Overall the proposal is actually more backward compatible
>> >         with GHC 9.8 than the original design, as the HasField class is
>> >         left unchanged.
>> >          >>>>
>> >          >>>> Overall, the proposal looks quite reasonable to me, and
>> >         well-argued. I recommend acceptance.
>>
>>
>>
>> --
>> 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
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> 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/057be3c5/attachment-0001.html>

From simon.peytonjones at gmail.com  Tue Oct  3 08:17:43 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 3 Oct 2023 09:17:43 +0100
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAKfdd-ziOZdZ=gNpZLU-w-n8V6BFE=uu+jdK5MZyZPMcmgv5Bg@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
 <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>
 <CAKfdd-zqumiE0FWp4vSyJXO8rqugupdXROa93fEBEYimtXYayQ@mail.gmail.com>
 <6ecf13eb-7c08-4f09-5696-deadc830231f@well-typed.com>
 <CAGwnsnkHOsVeDTqo1gTw10ECMQ+QjabRFbcspwCN8xcsN2eEfg@mail.gmail.com>
 <CAKfdd-ziOZdZ=gNpZLU-w-n8V6BFE=uu+jdK5MZyZPMcmgv5Bg@mail.gmail.com>
Message-ID: <CAJKmMz_MeY4bwub1Dy43jW5A9w+yNf-0vqCdHi-iQ0J4A11EMQ@mail.gmail.com>

We have to balance the cost of mitigation against the cost of breakage.

   - Cost of breakage.  Adam has identified only two packages that woud,
   both of which can adapt promptly.  It's true that there is more code out
   there, but the absence on Hackage is strongly indicative that there is
   unlikely to be much.
   - Cost of mitigation.  Supporting both behaviours, having extra language
   flags, that must in turn themselves be deprecated away, are real costs.
   The suck effort away from more productive activity.
   - I completely agree that if we had a classification,
   OverloadedRecordUpdate would have been classified as Experimental, and we
   would not be discussing deprecation cycles.  And signalling what is
   experimental and what is stable is a *primary *goal of the stability
   conversation we are having.  I agree strongly with Moritz on this point.
   - However the user manual (Section 6.5.11
   <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/overloaded_record_update.html?highlight=overloaded%20record#overloaded-record-update>)
   says "*EXPERIMENTAL* *This design of this extension may well change in
   the future. It would be inadvisable to start using this extension for
   long-lived libraries just yet*".  Short of an official classification
   mechanism, which we don't have yet, it seems hard to imagine a clearer
   statement than that.

My judgement: in this case we should forge ahead without introducing
OverloadedRecordNew and supporting both behaviours. (I have not even begun
to think about how hard that would be to implement.)  Let's spend our
precious cycles elsewhere.
Simon

On Tue, 3 Oct 2023 at 08:48, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Arnaud,
>
> That is a good argument. Without an opt-in to the new syntax, they can't
> adapt. I guess this brings us to the extension lifecycle. A solution could
> be
> 1. Deprecate OverloadedRecordUpdate in favour of
> OverloadedRecordUpdateNew. The user can adapt their code and use a
> different Extension.
> 2. Eventually Have OverloadedRecordUpdateNew be a synonym for changed
> OverloadedRecordUpdate. And Deprecate OverloadedRecordUpdateNew
>     over a longer period of time.
>
> I think this actually shows the value a `--std=experimental` could have.
> If `OverloadedRecordUpdate` was behind `--std=experimental` breaking it
> would
> be permissible by design. And we would not have this discussion, and Adam
> would not need to try to find all the potential breaking codes. This is part
> of the proposal to make `--std=experimental` a thing, allow fast(er) paced
> iteration on the experimental side of the compiler, while being extremely
> explicit about it being experimental features that can break at any time
> and without warning.
>
> The deprecation process outlined above would be fore non-experimental
> features. They can still be changed, but with a more rigorous change
> evolution.
>
> I hope this helps to clarify my position?
>
> Best,
>  Moritz
>
>
> On Tue, 3 Oct 2023 at 15:31, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> @Moritz: very clear thank you, though I'd like to understand how one
>> could adapt during the transition period to an argument swap, would you
>> say? Secondary question: if they can't adapt, isn't there a risk of making
>> the breakage more painful by delaying it, and letting more people use
>> -XOverloadedRecordUpdate with the argument order which isn't the final one?
>>
>> @Adam: we have to recognise that Hackage is not all the Haskell code. I
>> expect Hackage to be a little more conservative in extensions than end-user
>> applications. As such we're not guaranteed an absence of breakage (it's
>> still probably quite small, but it's hard to quantify).
>>
>> On Tue, 3 Oct 2023 at 09:21, Adam Gundry <adam at well-typed.com> wrote:
>>
>>> The backwards compatibility impact here is really extremely small,
>>> because OverloadedRecordUpdate is essentially unusable at present (as
>>> well as being explicitly documented as subject to change), so nobody
>>> uses it. While someone could implement a warning when the extension is
>>> turned on to say that it will change in the future, I'm not sure I see
>>> much point.
>>>
>>> I used https://hackage-search.serokell.io/?q=OverloadedRecordUpdate to
>>> look for occurrences of OverloadedRecordUpdate on Hackage, and I found
>>> precisely one pair of packages using it "for real":
>>>
>>> large-anon-0.3.0
>>> large-records-0.4
>>>
>>> These packages were created by my colleague Edsko in discussion with me,
>>> and will need to be amended when the proposal is implemented, because
>>> they want to take advantage of the new functionality.
>>>
>>> The other packages on Hackage containing the string
>>> OverloadedRecordUpdate are tools that reference all extensions:
>>>
>>> Cabal-syntax-3.10.1.0
>>> extensions-0.1.0.0
>>> fourmolu-0.14.0.0
>>> ghc-9.6.3
>>> ghc-boot-th-9.6.3
>>> ghc-exactprint-1.7.0.1
>>> ghc-hs-meta-0.1.2.0
>>> ghc-lib-9.6.2.20230523
>>> ghc-lib-parser-9.6.2.20230523
>>> hackport-0.8.4.0
>>> haskell-src-meta-0.8.12
>>> hindent-6.1.0
>>> hlint-3.6.1
>>> ormolu-0.7.2.0
>>>
>>> plus there are a few references in comments:
>>>
>>> lifx-lan-0.8.2
>>> optics-core-0.4.1.1
>>> pvector-0.1.1
>>> record-dot-preprocessor-0.2.16
>>> tztime-0.1.1.0
>>>
>>> While I generally agree with the "don't abruptly break existing code"
>>> position, in this case I don't think there is code out there to break.
>>>
>>> Adam
>>>
>>>
>>> On 03/10/2023 01:14, Moritz Angermann wrote:
>>> > Arnaud,
>>> >
>>> > thank you for your write up. And sorry that my view seems to be not
>>> > clear. Let me try to explain.
>>> > My position is: I'm against anything that _abruptly_ breaks existing
>>> > code. That's basically all there is to it.
>>> > Therefore I'm strongly against breaking changes without an appropriate
>>> > warning period (from the compiler).
>>> > I also strongly believe that most people do not read documentation,
>>> and
>>> > the authoritative messages are
>>> > the ones the compiler produces. As I've alluded to in a different
>>> email,
>>> > there are lots of people who work
>>> > on software as a 9-5 job, and don't spend their freetime tinkering and
>>> > playing with languages. They just
>>> > want to get the job done they are assigned. I have a lot of respect
>>> for
>>> > them. In my experience they don't
>>> > read compiler release announcements, or even go and read the compiler
>>> > documentation. They are given
>>> > the compiler version the company decided on for use in production.
>>> > That's the tool they use. And that tool
>>> > in my opinion needs to be rock solid, and not break easily across
>>> > versions. Thus yes, I would very much
>>> > like to see us not have breaking changes at all, but I can see that we
>>> > may need breaking changes
>>> > occasionally. In those cases I want it to be very visible to the
>>> > consumers that this breaking change is
>>> > coming towards them (compiler warnings). Giving them some time to
>>> adjust
>>> > (migration period), until the
>>> > breaking change happens.  Ultimately we should be able to compiler
>>> > existing code that compiles today
>>> > with at least the next compiler without it rejecting the code or
>>> needing
>>> > modifications to the code (-Werror
>>> > excluded).
>>> >
>>> > Thus what I'm arguing for is:
>>> > - Let's implement this backwards compatibility.
>>> > - Add compiler warnings about the arguments being swapped in a future
>>> > GHC version. For _a least_ one major release.
>>> > - Make the breaking change in a subsequent release.
>>> >
>>> > Alternatively I could also see:
>>> > - Adding compiler warnings now that the arguments will be swapped in a
>>> > future GHC version (for at least one major release).
>>> > - Implement the breaking change in a subsequent release.
>>> >
>>> > Either of those would be ok with me. Implementing a breaking change
>>> from
>>> > one version to the next, without an
>>> > appropriate deprecation/migration period (that is, the compiler will
>>> > warn loudly that changes are coming) is something
>>> > I am _very_ vehemently against.
>>> >
>>> > If the migration/deprecation warnings would provide a link to a GitHub
>>> > ticket or something where more information
>>> > can be found and maybe even a discussion could be had would probably
>>> > also be a good idea.
>>> >
>>> > I hope this helps clarify my position? If not, feel free to ask more,
>>> > I'm also happy to jump onto a call to explain my
>>> > position if needed.
>>> >
>>> > Best,
>>> >   Moritz
>>> >
>>> >
>>> > On Mon, 2 Oct 2023 at 23:31, Arnaud Spiwack <arnaud.spiwack at tweag.io
>>> > <mailto:arnaud.spiwack at tweag.io>> wrote:
>>> >
>>> >     Sorry I took a little bit of time to react to this, it was a lot to
>>> >     take in and I didn't have the mental space last week.
>>> >
>>> >     The only person that may have spoken against the current state of
>>> >     the proposal is Moritz. Yet I realise that I don't actually know,
>>> >     Moritz, what your position is.
>>> >
>>> >     To recap: to use -XOverloadedRecordUpdate in current GHC, you need
>>> >     to use -XRebindableSyntax and provide a setField function. In the
>>> >     new proposal you can use -XOverloadedRecordUpdate without
>>> >     -XRebindableSyntax, but when -XRebindableSyntax is on, the setField
>>> >     function that you have to provide has its argument swapped. The
>>> >     current documentation of OverloadedRecordUpdate has the following
>>> >     text at the top “*EXPERIMENTAL* /This design of this extension may
>>> >     well change in the future. It would be inadvisable to start using
>>> >     this extension for long-lived libraries just yet./”.
>>> >
>>> >     Now, I don't quite see how we could have a transition period that
>>> >     would allow a smooth transition there. There is no piece of code,
>>> >     with RebindableSyntax, that would compile before and after the
>>> >     change. So unless I'm missing something the position we can take as
>>> >     a committee can be either
>>> >     - Let's have the breakage without a transition period
>>> >     - Let's not make the breaking change ever and use the earlier
>>> >     argument order for set
>>> >
>>> >     Which one do you argue for, or am I missing another option?
>>> >
>>> >     On Sun, 24 Sept 2023 at 15:36, Eric Seidel <eric at seidel.io
>>> >     <mailto:eric at seidel.io>> wrote:
>>> >
>>> >         I am in favor of this proposal.
>>> >
>>> >         On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
>>> >          > Dear all.
>>> >          >
>>> >          > I submitted my recommendation 3 weeks ago, and only Simon
>>> has
>>> >         commented
>>> >          > yet. Please let me know your thoughts.
>>> >          >
>>> >          > On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack
>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>> wrote:
>>> >          >> Dear all,
>>> >          >>
>>> >          >> Don't forget to opine here. To reiterate, I really don't
>>> >         expect the proposal to be controversial. The text of the
>>> >         proposal is rather long, but is made easy to read. So it
>>> >         shouldn't take too much of your time.
>>> >          >>
>>> >          >> /Arnaud
>>> >          >>
>>> >          >> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones
>>> >         <simon.peytonjones at gmail.com
>>> >         <mailto:simon.peytonjones at gmail.com>> wrote:
>>> >          >>> I support acceptance.
>>> >          >>>
>>> >          >>> Simon
>>> >          >>>
>>> >          >>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack
>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>> wrote:
>>> >          >>>> Dear all,
>>> >          >>>>
>>> >          >>>> [ Proposal #583
>>> >         https://github.com/ghc-proposals/ghc-proposals/pull/583
>>> >         <https://github.com/ghc-proposals/ghc-proposals/pull/583> ]
>>> >          >>>>
>>> >          >>>> Our own Adam proposes to amend the design of the highly
>>> >         experimental OverloadedRecordUpdate extension as had been
>>> >         designed in proposal #158 [
>>> >
>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>>> <
>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst>
>>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 <
>>> https://github.com/ghc-proposals/ghc-proposals/pull/405> ].
>>> >          >>>>
>>> >          >>>> Specifically, Adam proposes a modification of the type
>>> >         classes that would back the extension.
>>> >          >>>>
>>> >          >>>> In the previous design the HasField class is defined as a
>>> >         lens:
>>> >          >>>>
>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>> >          >>>>   hasField :: r -> (a -> r, a)
>>> >          >>>>
>>> >          >>>> The proposal is to replace it by two classes (slightly
>>> >         simplified)
>>> >          >>>>
>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>> >          >>>>   hasField :: r -> a
>>> >          >>>>
>>> >          >>>> class SetField (n::k) r a | r n -> a
>>> >          >>>>   modifyField :: (a -> a) -> r -> a
>>> >          >>>>   setField :: a -> r -> a
>>> >          >>>>
>>> >          >>>> This is originally motivated by some performance
>>> >         consideration: the prototype implementation of HasField as a
>>> >         lens can be very time consuming because instances of HasFields
>>> >         are generated eagerly at record definition sites, whereas the
>>> >         simple HasField instances can simply reuse the selectors
>>> already
>>> >         generated by GHC. But a lot of thoughts have been put into the
>>> >         new design, and my summary can certainly not do it justice: the
>>> >         proposal is very well argumented.
>>> >          >>>>
>>> >          >>>> A point I'll make here is that the new design is actually
>>> >         parametric in the data representation of the field type.
>>> >         Something that wasn't possible in the original design.
>>> >          >>>>
>>> >          >>>> This proposal is not technically backward compatible,
>>> >         because the order of argument in which OverloadedRecordUpdate
>>> >         expects the argument of setField is changed. This is not
>>> >         essential to the proposal, but this is a more consistent order
>>> >         argument with the rest of Haskell. And considering that
>>> >         OverloadedRecordUpdate is very loudly advertised as
>>> >         experimental, I recommend accepting this breakage.
>>> >          >>>>
>>> >          >>>> Overall the proposal is actually more backward compatible
>>> >         with GHC 9.8 than the original design, as the HasField class is
>>> >         left unchanged.
>>> >          >>>>
>>> >          >>>> Overall, the proposal looks quite reasonable to me, and
>>> >         well-argued. I recommend acceptance.
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>> _______________________________________________
>> 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/70a8034d/attachment-0001.html>

From moritz.angermann at gmail.com  Tue Oct  3 08:26:08 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 3 Oct 2023 16:26:08 +0800
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAJKmMz_MeY4bwub1Dy43jW5A9w+yNf-0vqCdHi-iQ0J4A11EMQ@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
 <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>
 <CAKfdd-zqumiE0FWp4vSyJXO8rqugupdXROa93fEBEYimtXYayQ@mail.gmail.com>
 <6ecf13eb-7c08-4f09-5696-deadc830231f@well-typed.com>
 <CAGwnsnkHOsVeDTqo1gTw10ECMQ+QjabRFbcspwCN8xcsN2eEfg@mail.gmail.com>
 <CAKfdd-ziOZdZ=gNpZLU-w-n8V6BFE=uu+jdK5MZyZPMcmgv5Bg@mail.gmail.com>
 <CAJKmMz_MeY4bwub1Dy43jW5A9w+yNf-0vqCdHi-iQ0J4A11EMQ@mail.gmail.com>
Message-ID: <CAKfdd-yDN2PLX=Wga-tjndXqAGcg+2+u9nnxzHiH5U=iZBTrHw@mail.gmail.com>

I’m not going to stay in the way of this proposal. I’hope it’s
understandable if I recuse myself.

On Tue, 3 Oct 2023 at 4:18 PM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> We have to balance the cost of mitigation against the cost of breakage.
>
>    - Cost of breakage.  Adam has identified only two packages that woud,
>    both of which can adapt promptly.  It's true that there is more code out
>    there, but the absence on Hackage is strongly indicative that there is
>    unlikely to be much.
>    - Cost of mitigation.  Supporting both behaviours, having extra
>    language flags, that must in turn themselves be deprecated away, are real
>    costs.  The suck effort away from more productive activity.
>    - I completely agree that if we had a classification,
>    OverloadedRecordUpdate would have been classified as Experimental, and we
>    would not be discussing deprecation cycles.  And signalling what is
>    experimental and what is stable is a *primary *goal of the stability
>    conversation we are having.  I agree strongly with Moritz on this point.
>    - However the user manual (Section 6.5.11
>    <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/overloaded_record_update.html?highlight=overloaded%20record#overloaded-record-update>)
>    says "*EXPERIMENTAL* *This design of this extension may well change in
>    the future. It would be inadvisable to start using this extension for
>    long-lived libraries just yet*".  Short of an official classification
>    mechanism, which we don't have yet, it seems hard to imagine a clearer
>    statement than that.
>
> My judgement: in this case we should forge ahead without introducing
> OverloadedRecordNew and supporting both behaviours. (I have not even begun
> to think about how hard that would be to implement.)  Let's spend our
> precious cycles elsewhere.
>
> Simon
>
> On Tue, 3 Oct 2023 at 08:48, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> Arnaud,
>>
>> That is a good argument. Without an opt-in to the new syntax, they can't
>> adapt. I guess this brings us to the extension lifecycle. A solution could
>> be
>> 1. Deprecate OverloadedRecordUpdate in favour of
>> OverloadedRecordUpdateNew. The user can adapt their code and use a
>> different Extension.
>> 2. Eventually Have OverloadedRecordUpdateNew be a synonym for changed
>> OverloadedRecordUpdate. And Deprecate OverloadedRecordUpdateNew
>>     over a longer period of time.
>>
>> I think this actually shows the value a `--std=experimental` could have.
>> If `OverloadedRecordUpdate` was behind `--std=experimental` breaking it
>> would
>> be permissible by design. And we would not have this discussion, and Adam
>> would not need to try to find all the potential breaking codes. This is part
>> of the proposal to make `--std=experimental` a thing, allow fast(er)
>> paced iteration on the experimental side of the compiler, while being
>> extremely
>> explicit about it being experimental features that can break at any time
>> and without warning.
>>
>> The deprecation process outlined above would be fore non-experimental
>> features. They can still be changed, but with a more rigorous change
>> evolution.
>>
>> I hope this helps to clarify my position?
>>
>> Best,
>>  Moritz
>>
>>
>> On Tue, 3 Oct 2023 at 15:31, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> @Moritz: very clear thank you, though I'd like to understand how one
>>> could adapt during the transition period to an argument swap, would you
>>> say? Secondary question: if they can't adapt, isn't there a risk of making
>>> the breakage more painful by delaying it, and letting more people use
>>> -XOverloadedRecordUpdate with the argument order which isn't the final one?
>>>
>>> @Adam: we have to recognise that Hackage is not all the Haskell code. I
>>> expect Hackage to be a little more conservative in extensions than end-user
>>> applications. As such we're not guaranteed an absence of breakage (it's
>>> still probably quite small, but it's hard to quantify).
>>>
>>> On Tue, 3 Oct 2023 at 09:21, Adam Gundry <adam at well-typed.com> wrote:
>>>
>>>> The backwards compatibility impact here is really extremely small,
>>>> because OverloadedRecordUpdate is essentially unusable at present (as
>>>> well as being explicitly documented as subject to change), so nobody
>>>> uses it. While someone could implement a warning when the extension is
>>>> turned on to say that it will change in the future, I'm not sure I see
>>>> much point.
>>>>
>>>> I used https://hackage-search.serokell.io/?q=OverloadedRecordUpdate to
>>>> look for occurrences of OverloadedRecordUpdate on Hackage, and I found
>>>> precisely one pair of packages using it "for real":
>>>>
>>>> large-anon-0.3.0
>>>> large-records-0.4
>>>>
>>>> These packages were created by my colleague Edsko in discussion with
>>>> me,
>>>> and will need to be amended when the proposal is implemented, because
>>>> they want to take advantage of the new functionality.
>>>>
>>>> The other packages on Hackage containing the string
>>>> OverloadedRecordUpdate are tools that reference all extensions:
>>>>
>>>> Cabal-syntax-3.10.1.0
>>>> extensions-0.1.0.0
>>>> fourmolu-0.14.0.0
>>>> ghc-9.6.3
>>>> ghc-boot-th-9.6.3
>>>> ghc-exactprint-1.7.0.1
>>>> ghc-hs-meta-0.1.2.0
>>>> ghc-lib-9.6.2.20230523
>>>> ghc-lib-parser-9.6.2.20230523
>>>> hackport-0.8.4.0
>>>> haskell-src-meta-0.8.12
>>>> hindent-6.1.0
>>>> hlint-3.6.1
>>>> ormolu-0.7.2.0
>>>>
>>>> plus there are a few references in comments:
>>>>
>>>> lifx-lan-0.8.2
>>>> optics-core-0.4.1.1
>>>> pvector-0.1.1
>>>> record-dot-preprocessor-0.2.16
>>>> tztime-0.1.1.0
>>>>
>>>> While I generally agree with the "don't abruptly break existing code"
>>>> position, in this case I don't think there is code out there to break.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On 03/10/2023 01:14, Moritz Angermann wrote:
>>>> > Arnaud,
>>>> >
>>>> > thank you for your write up. And sorry that my view seems to be not
>>>> > clear. Let me try to explain.
>>>> > My position is: I'm against anything that _abruptly_ breaks existing
>>>> > code. That's basically all there is to it.
>>>> > Therefore I'm strongly against breaking changes without an
>>>> appropriate
>>>> > warning period (from the compiler).
>>>> > I also strongly believe that most people do not read documentation,
>>>> and
>>>> > the authoritative messages are
>>>> > the ones the compiler produces. As I've alluded to in a different
>>>> email,
>>>> > there are lots of people who work
>>>> > on software as a 9-5 job, and don't spend their freetime tinkering
>>>> and
>>>> > playing with languages. They just
>>>> > want to get the job done they are assigned. I have a lot of respect
>>>> for
>>>> > them. In my experience they don't
>>>> > read compiler release announcements, or even go and read the compiler
>>>> > documentation. They are given
>>>> > the compiler version the company decided on for use in production.
>>>> > That's the tool they use. And that tool
>>>> > in my opinion needs to be rock solid, and not break easily across
>>>> > versions. Thus yes, I would very much
>>>> > like to see us not have breaking changes at all, but I can see that
>>>> we
>>>> > may need breaking changes
>>>> > occasionally. In those cases I want it to be very visible to the
>>>> > consumers that this breaking change is
>>>> > coming towards them (compiler warnings). Giving them some time to
>>>> adjust
>>>> > (migration period), until the
>>>> > breaking change happens.  Ultimately we should be able to compiler
>>>> > existing code that compiles today
>>>> > with at least the next compiler without it rejecting the code or
>>>> needing
>>>> > modifications to the code (-Werror
>>>> > excluded).
>>>> >
>>>> > Thus what I'm arguing for is:
>>>> > - Let's implement this backwards compatibility.
>>>> > - Add compiler warnings about the arguments being swapped in a future
>>>> > GHC version. For _a least_ one major release.
>>>> > - Make the breaking change in a subsequent release.
>>>> >
>>>> > Alternatively I could also see:
>>>> > - Adding compiler warnings now that the arguments will be swapped in
>>>> a
>>>> > future GHC version (for at least one major release).
>>>> > - Implement the breaking change in a subsequent release.
>>>> >
>>>> > Either of those would be ok with me. Implementing a breaking change
>>>> from
>>>> > one version to the next, without an
>>>> > appropriate deprecation/migration period (that is, the compiler will
>>>> > warn loudly that changes are coming) is something
>>>> > I am _very_ vehemently against.
>>>> >
>>>> > If the migration/deprecation warnings would provide a link to a
>>>> GitHub
>>>> > ticket or something where more information
>>>> > can be found and maybe even a discussion could be had would probably
>>>> > also be a good idea.
>>>> >
>>>> > I hope this helps clarify my position? If not, feel free to ask more,
>>>> > I'm also happy to jump onto a call to explain my
>>>> > position if needed.
>>>> >
>>>> > Best,
>>>> >   Moritz
>>>> >
>>>> >
>>>> > On Mon, 2 Oct 2023 at 23:31, Arnaud Spiwack <arnaud.spiwack at tweag.io
>>>> > <mailto:arnaud.spiwack at tweag.io>> wrote:
>>>> >
>>>> >     Sorry I took a little bit of time to react to this, it was a lot
>>>> to
>>>> >     take in and I didn't have the mental space last week.
>>>> >
>>>> >     The only person that may have spoken against the current state of
>>>> >     the proposal is Moritz. Yet I realise that I don't actually know,
>>>> >     Moritz, what your position is.
>>>> >
>>>> >     To recap: to use -XOverloadedRecordUpdate in current GHC, you need
>>>> >     to use -XRebindableSyntax and provide a setField function. In the
>>>> >     new proposal you can use -XOverloadedRecordUpdate without
>>>> >     -XRebindableSyntax, but when -XRebindableSyntax is on, the
>>>> setField
>>>> >     function that you have to provide has its argument swapped. The
>>>> >     current documentation of OverloadedRecordUpdate has the following
>>>> >     text at the top “*EXPERIMENTAL* /This design of this extension may
>>>> >     well change in the future. It would be inadvisable to start using
>>>> >     this extension for long-lived libraries just yet./”.
>>>> >
>>>> >     Now, I don't quite see how we could have a transition period that
>>>> >     would allow a smooth transition there. There is no piece of code,
>>>> >     with RebindableSyntax, that would compile before and after the
>>>> >     change. So unless I'm missing something the position we can take
>>>> as
>>>> >     a committee can be either
>>>> >     - Let's have the breakage without a transition period
>>>> >     - Let's not make the breaking change ever and use the earlier
>>>> >     argument order for set
>>>> >
>>>> >     Which one do you argue for, or am I missing another option?
>>>> >
>>>> >     On Sun, 24 Sept 2023 at 15:36, Eric Seidel <eric at seidel.io
>>>> >     <mailto:eric at seidel.io>> wrote:
>>>> >
>>>> >         I am in favor of this proposal.
>>>> >
>>>> >         On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
>>>> >          > Dear all.
>>>> >          >
>>>> >          > I submitted my recommendation 3 weeks ago, and only Simon
>>>> has
>>>> >         commented
>>>> >          > yet. Please let me know your thoughts.
>>>> >          >
>>>> >          > On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack
>>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>>> wrote:
>>>> >          >> Dear all,
>>>> >          >>
>>>> >          >> Don't forget to opine here. To reiterate, I really don't
>>>> >         expect the proposal to be controversial. The text of the
>>>> >         proposal is rather long, but is made easy to read. So it
>>>> >         shouldn't take too much of your time.
>>>> >          >>
>>>> >          >> /Arnaud
>>>> >          >>
>>>> >          >> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones
>>>> >         <simon.peytonjones at gmail.com
>>>> >         <mailto:simon.peytonjones at gmail.com>> wrote:
>>>> >          >>> I support acceptance.
>>>> >          >>>
>>>> >          >>> Simon
>>>> >          >>>
>>>> >          >>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack
>>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>>> wrote:
>>>> >          >>>> Dear all,
>>>> >          >>>>
>>>> >          >>>> [ Proposal #583
>>>> >         https://github.com/ghc-proposals/ghc-proposals/pull/583
>>>> >         <https://github.com/ghc-proposals/ghc-proposals/pull/583> ]
>>>> >          >>>>
>>>> >          >>>> Our own Adam proposes to amend the design of the highly
>>>> >         experimental OverloadedRecordUpdate extension as had been
>>>> >         designed in proposal #158 [
>>>> >
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>>>> <
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst>
>>>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 <
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/405> ].
>>>> >          >>>>
>>>> >          >>>> Specifically, Adam proposes a modification of the type
>>>> >         classes that would back the extension.
>>>> >          >>>>
>>>> >          >>>> In the previous design the HasField class is defined as
>>>> a
>>>> >         lens:
>>>> >          >>>>
>>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>>> >          >>>>   hasField :: r -> (a -> r, a)
>>>> >          >>>>
>>>> >          >>>> The proposal is to replace it by two classes (slightly
>>>> >         simplified)
>>>> >          >>>>
>>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>>> >          >>>>   hasField :: r -> a
>>>> >          >>>>
>>>> >          >>>> class SetField (n::k) r a | r n -> a
>>>> >          >>>>   modifyField :: (a -> a) -> r -> a
>>>> >          >>>>   setField :: a -> r -> a
>>>> >          >>>>
>>>> >          >>>> This is originally motivated by some performance
>>>> >         consideration: the prototype implementation of HasField as a
>>>> >         lens can be very time consuming because instances of HasFields
>>>> >         are generated eagerly at record definition sites, whereas the
>>>> >         simple HasField instances can simply reuse the selectors
>>>> already
>>>> >         generated by GHC. But a lot of thoughts have been put into the
>>>> >         new design, and my summary can certainly not do it justice:
>>>> the
>>>> >         proposal is very well argumented.
>>>> >          >>>>
>>>> >          >>>> A point I'll make here is that the new design is
>>>> actually
>>>> >         parametric in the data representation of the field type.
>>>> >         Something that wasn't possible in the original design.
>>>> >          >>>>
>>>> >          >>>> This proposal is not technically backward compatible,
>>>> >         because the order of argument in which OverloadedRecordUpdate
>>>> >         expects the argument of setField is changed. This is not
>>>> >         essential to the proposal, but this is a more consistent order
>>>> >         argument with the rest of Haskell. And considering that
>>>> >         OverloadedRecordUpdate is very loudly advertised as
>>>> >         experimental, I recommend accepting this breakage.
>>>> >          >>>>
>>>> >          >>>> Overall the proposal is actually more backward
>>>> compatible
>>>> >         with GHC 9.8 than the original design, as the HasField class
>>>> is
>>>> >         left unchanged.
>>>> >          >>>>
>>>> >          >>>> Overall, the proposal looks quite reasonable to me, and
>>>> >         well-argued. I recommend acceptance.
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>> _______________________________________________
>>> 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/4e347a75/attachment-0001.html>

From simon.peytonjones at gmail.com  Tue Oct  3 08:33:01 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 3 Oct 2023 09:33:01 +0100
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAKfdd-yDN2PLX=Wga-tjndXqAGcg+2+u9nnxzHiH5U=iZBTrHw@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
 <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>
 <CAKfdd-zqumiE0FWp4vSyJXO8rqugupdXROa93fEBEYimtXYayQ@mail.gmail.com>
 <6ecf13eb-7c08-4f09-5696-deadc830231f@well-typed.com>
 <CAGwnsnkHOsVeDTqo1gTw10ECMQ+QjabRFbcspwCN8xcsN2eEfg@mail.gmail.com>
 <CAKfdd-ziOZdZ=gNpZLU-w-n8V6BFE=uu+jdK5MZyZPMcmgv5Bg@mail.gmail.com>
 <CAJKmMz_MeY4bwub1Dy43jW5A9w+yNf-0vqCdHi-iQ0J4A11EMQ@mail.gmail.com>
 <CAKfdd-yDN2PLX=Wga-tjndXqAGcg+2+u9nnxzHiH5U=iZBTrHw@mail.gmail.com>
Message-ID: <CAJKmMz_tVcqczQoQ0k6YX4uKwas1KusN18JwxK+BHzjMWSLuLw@mail.gmail.com>

Sure.

Just to be clear, I'm not trying to set a precedent here!

Simon

On Tue, 3 Oct 2023 at 09:26, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> I’m not going to stay in the way of this proposal. I’hope it’s
> understandable if I recuse myself.
>
> On Tue, 3 Oct 2023 at 4:18 PM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> We have to balance the cost of mitigation against the cost of breakage.
>>
>>    - Cost of breakage.  Adam has identified only two packages that woud,
>>    both of which can adapt promptly.  It's true that there is more code out
>>    there, but the absence on Hackage is strongly indicative that there is
>>    unlikely to be much.
>>    - Cost of mitigation.  Supporting both behaviours, having extra
>>    language flags, that must in turn themselves be deprecated away, are real
>>    costs.  The suck effort away from more productive activity.
>>    - I completely agree that if we had a classification,
>>    OverloadedRecordUpdate would have been classified as Experimental, and we
>>    would not be discussing deprecation cycles.  And signalling what is
>>    experimental and what is stable is a *primary *goal of the stability
>>    conversation we are having.  I agree strongly with Moritz on this point.
>>    - However the user manual (Section 6.5.11
>>    <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/overloaded_record_update.html?highlight=overloaded%20record#overloaded-record-update>)
>>    says "*EXPERIMENTAL* *This design of this extension may well change
>>    in the future. It would be inadvisable to start using this extension for
>>    long-lived libraries just yet*".  Short of an official classification
>>    mechanism, which we don't have yet, it seems hard to imagine a clearer
>>    statement than that.
>>
>> My judgement: in this case we should forge ahead without introducing
>> OverloadedRecordNew and supporting both behaviours. (I have not even begun
>> to think about how hard that would be to implement.)  Let's spend our
>> precious cycles elsewhere.
>>
>> Simon
>>
>> On Tue, 3 Oct 2023 at 08:48, Moritz Angermann <moritz.angermann at gmail.com>
>> wrote:
>>
>>> Arnaud,
>>>
>>> That is a good argument. Without an opt-in to the new syntax, they can't
>>> adapt. I guess this brings us to the extension lifecycle. A solution could
>>> be
>>> 1. Deprecate OverloadedRecordUpdate in favour of
>>> OverloadedRecordUpdateNew. The user can adapt their code and use a
>>> different Extension.
>>> 2. Eventually Have OverloadedRecordUpdateNew be a synonym for changed
>>> OverloadedRecordUpdate. And Deprecate OverloadedRecordUpdateNew
>>>     over a longer period of time.
>>>
>>> I think this actually shows the value a `--std=experimental` could have.
>>> If `OverloadedRecordUpdate` was behind `--std=experimental` breaking it
>>> would
>>> be permissible by design. And we would not have this discussion, and
>>> Adam would not need to try to find all the potential breaking codes. This
>>> is part
>>> of the proposal to make `--std=experimental` a thing, allow fast(er)
>>> paced iteration on the experimental side of the compiler, while being
>>> extremely
>>> explicit about it being experimental features that can break at any time
>>> and without warning.
>>>
>>> The deprecation process outlined above would be fore non-experimental
>>> features. They can still be changed, but with a more rigorous change
>>> evolution.
>>>
>>> I hope this helps to clarify my position?
>>>
>>> Best,
>>>  Moritz
>>>
>>>
>>> On Tue, 3 Oct 2023 at 15:31, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>> @Moritz: very clear thank you, though I'd like to understand how one
>>>> could adapt during the transition period to an argument swap, would you
>>>> say? Secondary question: if they can't adapt, isn't there a risk of making
>>>> the breakage more painful by delaying it, and letting more people use
>>>> -XOverloadedRecordUpdate with the argument order which isn't the final one?
>>>>
>>>> @Adam: we have to recognise that Hackage is not all the Haskell code. I
>>>> expect Hackage to be a little more conservative in extensions than end-user
>>>> applications. As such we're not guaranteed an absence of breakage (it's
>>>> still probably quite small, but it's hard to quantify).
>>>>
>>>> On Tue, 3 Oct 2023 at 09:21, Adam Gundry <adam at well-typed.com> wrote:
>>>>
>>>>> The backwards compatibility impact here is really extremely small,
>>>>> because OverloadedRecordUpdate is essentially unusable at present (as
>>>>> well as being explicitly documented as subject to change), so nobody
>>>>> uses it. While someone could implement a warning when the extension is
>>>>> turned on to say that it will change in the future, I'm not sure I see
>>>>> much point.
>>>>>
>>>>> I used https://hackage-search.serokell.io/?q=OverloadedRecordUpdate
>>>>> to
>>>>> look for occurrences of OverloadedRecordUpdate on Hackage, and I found
>>>>> precisely one pair of packages using it "for real":
>>>>>
>>>>> large-anon-0.3.0
>>>>> large-records-0.4
>>>>>
>>>>> These packages were created by my colleague Edsko in discussion with
>>>>> me,
>>>>> and will need to be amended when the proposal is implemented, because
>>>>> they want to take advantage of the new functionality.
>>>>>
>>>>> The other packages on Hackage containing the string
>>>>> OverloadedRecordUpdate are tools that reference all extensions:
>>>>>
>>>>> Cabal-syntax-3.10.1.0
>>>>> extensions-0.1.0.0
>>>>> fourmolu-0.14.0.0
>>>>> ghc-9.6.3
>>>>> ghc-boot-th-9.6.3
>>>>> ghc-exactprint-1.7.0.1
>>>>> ghc-hs-meta-0.1.2.0
>>>>> ghc-lib-9.6.2.20230523
>>>>> ghc-lib-parser-9.6.2.20230523
>>>>> hackport-0.8.4.0
>>>>> haskell-src-meta-0.8.12
>>>>> hindent-6.1.0
>>>>> hlint-3.6.1
>>>>> ormolu-0.7.2.0
>>>>>
>>>>> plus there are a few references in comments:
>>>>>
>>>>> lifx-lan-0.8.2
>>>>> optics-core-0.4.1.1
>>>>> pvector-0.1.1
>>>>> record-dot-preprocessor-0.2.16
>>>>> tztime-0.1.1.0
>>>>>
>>>>> While I generally agree with the "don't abruptly break existing code"
>>>>> position, in this case I don't think there is code out there to break.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On 03/10/2023 01:14, Moritz Angermann wrote:
>>>>> > Arnaud,
>>>>> >
>>>>> > thank you for your write up. And sorry that my view seems to be not
>>>>> > clear. Let me try to explain.
>>>>> > My position is: I'm against anything that _abruptly_ breaks existing
>>>>> > code. That's basically all there is to it.
>>>>> > Therefore I'm strongly against breaking changes without an
>>>>> appropriate
>>>>> > warning period (from the compiler).
>>>>> > I also strongly believe that most people do not read documentation,
>>>>> and
>>>>> > the authoritative messages are
>>>>> > the ones the compiler produces. As I've alluded to in a different
>>>>> email,
>>>>> > there are lots of people who work
>>>>> > on software as a 9-5 job, and don't spend their freetime tinkering
>>>>> and
>>>>> > playing with languages. They just
>>>>> > want to get the job done they are assigned. I have a lot of respect
>>>>> for
>>>>> > them. In my experience they don't
>>>>> > read compiler release announcements, or even go and read the
>>>>> compiler
>>>>> > documentation. They are given
>>>>> > the compiler version the company decided on for use in production.
>>>>> > That's the tool they use. And that tool
>>>>> > in my opinion needs to be rock solid, and not break easily across
>>>>> > versions. Thus yes, I would very much
>>>>> > like to see us not have breaking changes at all, but I can see that
>>>>> we
>>>>> > may need breaking changes
>>>>> > occasionally. In those cases I want it to be very visible to the
>>>>> > consumers that this breaking change is
>>>>> > coming towards them (compiler warnings). Giving them some time to
>>>>> adjust
>>>>> > (migration period), until the
>>>>> > breaking change happens.  Ultimately we should be able to compiler
>>>>> > existing code that compiles today
>>>>> > with at least the next compiler without it rejecting the code or
>>>>> needing
>>>>> > modifications to the code (-Werror
>>>>> > excluded).
>>>>> >
>>>>> > Thus what I'm arguing for is:
>>>>> > - Let's implement this backwards compatibility.
>>>>> > - Add compiler warnings about the arguments being swapped in a
>>>>> future
>>>>> > GHC version. For _a least_ one major release.
>>>>> > - Make the breaking change in a subsequent release.
>>>>> >
>>>>> > Alternatively I could also see:
>>>>> > - Adding compiler warnings now that the arguments will be swapped in
>>>>> a
>>>>> > future GHC version (for at least one major release).
>>>>> > - Implement the breaking change in a subsequent release.
>>>>> >
>>>>> > Either of those would be ok with me. Implementing a breaking change
>>>>> from
>>>>> > one version to the next, without an
>>>>> > appropriate deprecation/migration period (that is, the compiler will
>>>>> > warn loudly that changes are coming) is something
>>>>> > I am _very_ vehemently against.
>>>>> >
>>>>> > If the migration/deprecation warnings would provide a link to a
>>>>> GitHub
>>>>> > ticket or something where more information
>>>>> > can be found and maybe even a discussion could be had would probably
>>>>> > also be a good idea.
>>>>> >
>>>>> > I hope this helps clarify my position? If not, feel free to ask
>>>>> more,
>>>>> > I'm also happy to jump onto a call to explain my
>>>>> > position if needed.
>>>>> >
>>>>> > Best,
>>>>> >   Moritz
>>>>> >
>>>>> >
>>>>> > On Mon, 2 Oct 2023 at 23:31, Arnaud Spiwack <arnaud.spiwack at tweag.io
>>>>> > <mailto:arnaud.spiwack at tweag.io>> wrote:
>>>>> >
>>>>> >     Sorry I took a little bit of time to react to this, it was a lot
>>>>> to
>>>>> >     take in and I didn't have the mental space last week.
>>>>> >
>>>>> >     The only person that may have spoken against the current state of
>>>>> >     the proposal is Moritz. Yet I realise that I don't actually know,
>>>>> >     Moritz, what your position is.
>>>>> >
>>>>> >     To recap: to use -XOverloadedRecordUpdate in current GHC, you
>>>>> need
>>>>> >     to use -XRebindableSyntax and provide a setField function. In the
>>>>> >     new proposal you can use -XOverloadedRecordUpdate without
>>>>> >     -XRebindableSyntax, but when -XRebindableSyntax is on, the
>>>>> setField
>>>>> >     function that you have to provide has its argument swapped. The
>>>>> >     current documentation of OverloadedRecordUpdate has the following
>>>>> >     text at the top “*EXPERIMENTAL* /This design of this extension
>>>>> may
>>>>> >     well change in the future. It would be inadvisable to start using
>>>>> >     this extension for long-lived libraries just yet./”.
>>>>> >
>>>>> >     Now, I don't quite see how we could have a transition period that
>>>>> >     would allow a smooth transition there. There is no piece of code,
>>>>> >     with RebindableSyntax, that would compile before and after the
>>>>> >     change. So unless I'm missing something the position we can take
>>>>> as
>>>>> >     a committee can be either
>>>>> >     - Let's have the breakage without a transition period
>>>>> >     - Let's not make the breaking change ever and use the earlier
>>>>> >     argument order for set
>>>>> >
>>>>> >     Which one do you argue for, or am I missing another option?
>>>>> >
>>>>> >     On Sun, 24 Sept 2023 at 15:36, Eric Seidel <eric at seidel.io
>>>>> >     <mailto:eric at seidel.io>> wrote:
>>>>> >
>>>>> >         I am in favor of this proposal.
>>>>> >
>>>>> >         On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
>>>>> >          > Dear all.
>>>>> >          >
>>>>> >          > I submitted my recommendation 3 weeks ago, and only Simon
>>>>> has
>>>>> >         commented
>>>>> >          > yet. Please let me know your thoughts.
>>>>> >          >
>>>>> >          > On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack
>>>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>>>> wrote:
>>>>> >          >> Dear all,
>>>>> >          >>
>>>>> >          >> Don't forget to opine here. To reiterate, I really don't
>>>>> >         expect the proposal to be controversial. The text of the
>>>>> >         proposal is rather long, but is made easy to read. So it
>>>>> >         shouldn't take too much of your time.
>>>>> >          >>
>>>>> >          >> /Arnaud
>>>>> >          >>
>>>>> >          >> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones
>>>>> >         <simon.peytonjones at gmail.com
>>>>> >         <mailto:simon.peytonjones at gmail.com>> wrote:
>>>>> >          >>> I support acceptance.
>>>>> >          >>>
>>>>> >          >>> Simon
>>>>> >          >>>
>>>>> >          >>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack
>>>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>>>> wrote:
>>>>> >          >>>> Dear all,
>>>>> >          >>>>
>>>>> >          >>>> [ Proposal #583
>>>>> >         https://github.com/ghc-proposals/ghc-proposals/pull/583
>>>>> >         <https://github.com/ghc-proposals/ghc-proposals/pull/583> ]
>>>>> >          >>>>
>>>>> >          >>>> Our own Adam proposes to amend the design of the highly
>>>>> >         experimental OverloadedRecordUpdate extension as had been
>>>>> >         designed in proposal #158 [
>>>>> >
>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>>>>> <
>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst>
>>>>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 <
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/405> ].
>>>>> >          >>>>
>>>>> >          >>>> Specifically, Adam proposes a modification of the type
>>>>> >         classes that would back the extension.
>>>>> >          >>>>
>>>>> >          >>>> In the previous design the HasField class is defined
>>>>> as a
>>>>> >         lens:
>>>>> >          >>>>
>>>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>>>> >          >>>>   hasField :: r -> (a -> r, a)
>>>>> >          >>>>
>>>>> >          >>>> The proposal is to replace it by two classes (slightly
>>>>> >         simplified)
>>>>> >          >>>>
>>>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>>>> >          >>>>   hasField :: r -> a
>>>>> >          >>>>
>>>>> >          >>>> class SetField (n::k) r a | r n -> a
>>>>> >          >>>>   modifyField :: (a -> a) -> r -> a
>>>>> >          >>>>   setField :: a -> r -> a
>>>>> >          >>>>
>>>>> >          >>>> This is originally motivated by some performance
>>>>> >         consideration: the prototype implementation of HasField as a
>>>>> >         lens can be very time consuming because instances of
>>>>> HasFields
>>>>> >         are generated eagerly at record definition sites, whereas the
>>>>> >         simple HasField instances can simply reuse the selectors
>>>>> already
>>>>> >         generated by GHC. But a lot of thoughts have been put into
>>>>> the
>>>>> >         new design, and my summary can certainly not do it justice:
>>>>> the
>>>>> >         proposal is very well argumented.
>>>>> >          >>>>
>>>>> >          >>>> A point I'll make here is that the new design is
>>>>> actually
>>>>> >         parametric in the data representation of the field type.
>>>>> >         Something that wasn't possible in the original design.
>>>>> >          >>>>
>>>>> >          >>>> This proposal is not technically backward compatible,
>>>>> >         because the order of argument in which OverloadedRecordUpdate
>>>>> >         expects the argument of setField is changed. This is not
>>>>> >         essential to the proposal, but this is a more consistent
>>>>> order
>>>>> >         argument with the rest of Haskell. And considering that
>>>>> >         OverloadedRecordUpdate is very loudly advertised as
>>>>> >         experimental, I recommend accepting this breakage.
>>>>> >          >>>>
>>>>> >          >>>> Overall the proposal is actually more backward
>>>>> compatible
>>>>> >         with GHC 9.8 than the original design, as the HasField class
>>>>> is
>>>>> >         left unchanged.
>>>>> >          >>>>
>>>>> >          >>>> Overall, the proposal looks quite reasonable to me, and
>>>>> >         well-argued. I recommend acceptance.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>
>>>>
>>>> --
>>>> Arnaud Spiwack
>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>> _______________________________________________
>>>> 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/1ec2a9ed/attachment-0001.html>

From arnaud.spiwack at tweag.io  Tue Oct  3 09:52:25 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 3 Oct 2023 11:52:25 +0200
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAJKmMz_tVcqczQoQ0k6YX4uKwas1KusN18JwxK+BHzjMWSLuLw@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
 <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>
 <CAKfdd-zqumiE0FWp4vSyJXO8rqugupdXROa93fEBEYimtXYayQ@mail.gmail.com>
 <6ecf13eb-7c08-4f09-5696-deadc830231f@well-typed.com>
 <CAGwnsnkHOsVeDTqo1gTw10ECMQ+QjabRFbcspwCN8xcsN2eEfg@mail.gmail.com>
 <CAKfdd-ziOZdZ=gNpZLU-w-n8V6BFE=uu+jdK5MZyZPMcmgv5Bg@mail.gmail.com>
 <CAJKmMz_MeY4bwub1Dy43jW5A9w+yNf-0vqCdHi-iQ0J4A11EMQ@mail.gmail.com>
 <CAKfdd-yDN2PLX=Wga-tjndXqAGcg+2+u9nnxzHiH5U=iZBTrHw@mail.gmail.com>
 <CAJKmMz_tVcqczQoQ0k6YX4uKwas1KusN18JwxK+BHzjMWSLuLw@mail.gmail.com>
Message-ID: <CAGwnsnkAvrwUxDZm2+Mfgg7ngJFbugYjZesL=cGgYQPQC1ai7g@mail.gmail.com>

Let's do a quick vote. All, which do you prefer?

A. Introduce the breakage immediately and change the argument order of
setField (current state of the proposal)
B. Introduce a new extension -XOverloadedRecordUpdateNew which would use a
setField with a different argument order, so that it can be used during the
transition period. Eventually OverloadedRecordUpdateNew becomes deprecated
and OverloadedRecordUpdate swaps the argument order. (Moritz's proposal)
C. Keep the originally proposed setField argument order (nobody have
suggested this yet, but I'm including it for completeness)

On Tue, 3 Oct 2023 at 10:33, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> Sure.
>
> Just to be clear, I'm not trying to set a precedent here!
>
> Simon
>
> On Tue, 3 Oct 2023 at 09:26, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> I’m not going to stay in the way of this proposal. I’hope it’s
>> understandable if I recuse myself.
>>
>> On Tue, 3 Oct 2023 at 4:18 PM, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> We have to balance the cost of mitigation against the cost of breakage.
>>>
>>>    - Cost of breakage.  Adam has identified only two packages that
>>>    woud, both of which can adapt promptly.  It's true that there is more code
>>>    out there, but the absence on Hackage is strongly indicative that there is
>>>    unlikely to be much.
>>>    - Cost of mitigation.  Supporting both behaviours, having extra
>>>    language flags, that must in turn themselves be deprecated away, are real
>>>    costs.  The suck effort away from more productive activity.
>>>    - I completely agree that if we had a classification,
>>>    OverloadedRecordUpdate would have been classified as Experimental, and we
>>>    would not be discussing deprecation cycles.  And signalling what is
>>>    experimental and what is stable is a *primary *goal of the stability
>>>    conversation we are having.  I agree strongly with Moritz on this point.
>>>    - However the user manual (Section 6.5.11
>>>    <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/overloaded_record_update.html?highlight=overloaded%20record#overloaded-record-update>)
>>>    says "*EXPERIMENTAL* *This design of this extension may well change
>>>    in the future. It would be inadvisable to start using this extension for
>>>    long-lived libraries just yet*".  Short of an official
>>>    classification mechanism, which we don't have yet, it seems hard to imagine
>>>    a clearer statement than that.
>>>
>>> My judgement: in this case we should forge ahead without introducing
>>> OverloadedRecordNew and supporting both behaviours. (I have not even begun
>>> to think about how hard that would be to implement.)  Let's spend our
>>> precious cycles elsewhere.
>>>
>>> Simon
>>>
>>> On Tue, 3 Oct 2023 at 08:48, Moritz Angermann <
>>> moritz.angermann at gmail.com> wrote:
>>>
>>>> Arnaud,
>>>>
>>>> That is a good argument. Without an opt-in to the new syntax, they
>>>> can't adapt. I guess this brings us to the extension lifecycle. A solution
>>>> could be
>>>> 1. Deprecate OverloadedRecordUpdate in favour of
>>>> OverloadedRecordUpdateNew. The user can adapt their code and use a
>>>> different Extension.
>>>> 2. Eventually Have OverloadedRecordUpdateNew be a synonym for changed
>>>> OverloadedRecordUpdate. And Deprecate OverloadedRecordUpdateNew
>>>>     over a longer period of time.
>>>>
>>>> I think this actually shows the value a `--std=experimental` could
>>>> have. If `OverloadedRecordUpdate` was behind `--std=experimental` breaking
>>>> it would
>>>> be permissible by design. And we would not have this discussion, and
>>>> Adam would not need to try to find all the potential breaking codes. This
>>>> is part
>>>> of the proposal to make `--std=experimental` a thing, allow fast(er)
>>>> paced iteration on the experimental side of the compiler, while being
>>>> extremely
>>>> explicit about it being experimental features that can break at any
>>>> time and without warning.
>>>>
>>>> The deprecation process outlined above would be fore non-experimental
>>>> features. They can still be changed, but with a more rigorous change
>>>> evolution.
>>>>
>>>> I hope this helps to clarify my position?
>>>>
>>>> Best,
>>>>  Moritz
>>>>
>>>>
>>>> On Tue, 3 Oct 2023 at 15:31, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>>> wrote:
>>>>
>>>>> @Moritz: very clear thank you, though I'd like to understand how one
>>>>> could adapt during the transition period to an argument swap, would you
>>>>> say? Secondary question: if they can't adapt, isn't there a risk of making
>>>>> the breakage more painful by delaying it, and letting more people use
>>>>> -XOverloadedRecordUpdate with the argument order which isn't the final one?
>>>>>
>>>>> @Adam: we have to recognise that Hackage is not all the Haskell code.
>>>>> I expect Hackage to be a little more conservative in extensions than
>>>>> end-user applications. As such we're not guaranteed an absence of breakage
>>>>> (it's still probably quite small, but it's hard to quantify).
>>>>>
>>>>> On Tue, 3 Oct 2023 at 09:21, Adam Gundry <adam at well-typed.com> wrote:
>>>>>
>>>>>> The backwards compatibility impact here is really extremely small,
>>>>>> because OverloadedRecordUpdate is essentially unusable at present (as
>>>>>> well as being explicitly documented as subject to change), so nobody
>>>>>> uses it. While someone could implement a warning when the extension
>>>>>> is
>>>>>> turned on to say that it will change in the future, I'm not sure I
>>>>>> see
>>>>>> much point.
>>>>>>
>>>>>> I used https://hackage-search.serokell.io/?q=OverloadedRecordUpdate
>>>>>> to
>>>>>> look for occurrences of OverloadedRecordUpdate on Hackage, and I
>>>>>> found
>>>>>> precisely one pair of packages using it "for real":
>>>>>>
>>>>>> large-anon-0.3.0
>>>>>> large-records-0.4
>>>>>>
>>>>>> These packages were created by my colleague Edsko in discussion with
>>>>>> me,
>>>>>> and will need to be amended when the proposal is implemented, because
>>>>>> they want to take advantage of the new functionality.
>>>>>>
>>>>>> The other packages on Hackage containing the string
>>>>>> OverloadedRecordUpdate are tools that reference all extensions:
>>>>>>
>>>>>> Cabal-syntax-3.10.1.0
>>>>>> extensions-0.1.0.0
>>>>>> fourmolu-0.14.0.0
>>>>>> ghc-9.6.3
>>>>>> ghc-boot-th-9.6.3
>>>>>> ghc-exactprint-1.7.0.1
>>>>>> ghc-hs-meta-0.1.2.0
>>>>>> ghc-lib-9.6.2.20230523
>>>>>> ghc-lib-parser-9.6.2.20230523
>>>>>> hackport-0.8.4.0
>>>>>> haskell-src-meta-0.8.12
>>>>>> hindent-6.1.0
>>>>>> hlint-3.6.1
>>>>>> ormolu-0.7.2.0
>>>>>>
>>>>>> plus there are a few references in comments:
>>>>>>
>>>>>> lifx-lan-0.8.2
>>>>>> optics-core-0.4.1.1
>>>>>> pvector-0.1.1
>>>>>> record-dot-preprocessor-0.2.16
>>>>>> tztime-0.1.1.0
>>>>>>
>>>>>> While I generally agree with the "don't abruptly break existing code"
>>>>>> position, in this case I don't think there is code out there to break.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>> On 03/10/2023 01:14, Moritz Angermann wrote:
>>>>>> > Arnaud,
>>>>>> >
>>>>>> > thank you for your write up. And sorry that my view seems to be not
>>>>>> > clear. Let me try to explain.
>>>>>> > My position is: I'm against anything that _abruptly_ breaks
>>>>>> existing
>>>>>> > code. That's basically all there is to it.
>>>>>> > Therefore I'm strongly against breaking changes without an
>>>>>> appropriate
>>>>>> > warning period (from the compiler).
>>>>>> > I also strongly believe that most people do not read documentation,
>>>>>> and
>>>>>> > the authoritative messages are
>>>>>> > the ones the compiler produces. As I've alluded to in a different
>>>>>> email,
>>>>>> > there are lots of people who work
>>>>>> > on software as a 9-5 job, and don't spend their freetime tinkering
>>>>>> and
>>>>>> > playing with languages. They just
>>>>>> > want to get the job done they are assigned. I have a lot of respect
>>>>>> for
>>>>>> > them. In my experience they don't
>>>>>> > read compiler release announcements, or even go and read the
>>>>>> compiler
>>>>>> > documentation. They are given
>>>>>> > the compiler version the company decided on for use in production.
>>>>>> > That's the tool they use. And that tool
>>>>>> > in my opinion needs to be rock solid, and not break easily across
>>>>>> > versions. Thus yes, I would very much
>>>>>> > like to see us not have breaking changes at all, but I can see that
>>>>>> we
>>>>>> > may need breaking changes
>>>>>> > occasionally. In those cases I want it to be very visible to the
>>>>>> > consumers that this breaking change is
>>>>>> > coming towards them (compiler warnings). Giving them some time to
>>>>>> adjust
>>>>>> > (migration period), until the
>>>>>> > breaking change happens.  Ultimately we should be able to compiler
>>>>>> > existing code that compiles today
>>>>>> > with at least the next compiler without it rejecting the code or
>>>>>> needing
>>>>>> > modifications to the code (-Werror
>>>>>> > excluded).
>>>>>> >
>>>>>> > Thus what I'm arguing for is:
>>>>>> > - Let's implement this backwards compatibility.
>>>>>> > - Add compiler warnings about the arguments being swapped in a
>>>>>> future
>>>>>> > GHC version. For _a least_ one major release.
>>>>>> > - Make the breaking change in a subsequent release.
>>>>>> >
>>>>>> > Alternatively I could also see:
>>>>>> > - Adding compiler warnings now that the arguments will be swapped
>>>>>> in a
>>>>>> > future GHC version (for at least one major release).
>>>>>> > - Implement the breaking change in a subsequent release.
>>>>>> >
>>>>>> > Either of those would be ok with me. Implementing a breaking change
>>>>>> from
>>>>>> > one version to the next, without an
>>>>>> > appropriate deprecation/migration period (that is, the compiler
>>>>>> will
>>>>>> > warn loudly that changes are coming) is something
>>>>>> > I am _very_ vehemently against.
>>>>>> >
>>>>>> > If the migration/deprecation warnings would provide a link to a
>>>>>> GitHub
>>>>>> > ticket or something where more information
>>>>>> > can be found and maybe even a discussion could be had would
>>>>>> probably
>>>>>> > also be a good idea.
>>>>>> >
>>>>>> > I hope this helps clarify my position? If not, feel free to ask
>>>>>> more,
>>>>>> > I'm also happy to jump onto a call to explain my
>>>>>> > position if needed.
>>>>>> >
>>>>>> > Best,
>>>>>> >   Moritz
>>>>>> >
>>>>>> >
>>>>>> > On Mon, 2 Oct 2023 at 23:31, Arnaud Spiwack <
>>>>>> arnaud.spiwack at tweag.io
>>>>>> > <mailto:arnaud.spiwack at tweag.io>> wrote:
>>>>>> >
>>>>>> >     Sorry I took a little bit of time to react to this, it was a
>>>>>> lot to
>>>>>> >     take in and I didn't have the mental space last week.
>>>>>> >
>>>>>> >     The only person that may have spoken against the current state
>>>>>> of
>>>>>> >     the proposal is Moritz. Yet I realise that I don't actually
>>>>>> know,
>>>>>> >     Moritz, what your position is.
>>>>>> >
>>>>>> >     To recap: to use -XOverloadedRecordUpdate in current GHC, you
>>>>>> need
>>>>>> >     to use -XRebindableSyntax and provide a setField function. In
>>>>>> the
>>>>>> >     new proposal you can use -XOverloadedRecordUpdate without
>>>>>> >     -XRebindableSyntax, but when -XRebindableSyntax is on, the
>>>>>> setField
>>>>>> >     function that you have to provide has its argument swapped. The
>>>>>> >     current documentation of OverloadedRecordUpdate has the
>>>>>> following
>>>>>> >     text at the top “*EXPERIMENTAL* /This design of this extension
>>>>>> may
>>>>>> >     well change in the future. It would be inadvisable to start
>>>>>> using
>>>>>> >     this extension for long-lived libraries just yet./”.
>>>>>> >
>>>>>> >     Now, I don't quite see how we could have a transition period
>>>>>> that
>>>>>> >     would allow a smooth transition there. There is no piece of
>>>>>> code,
>>>>>> >     with RebindableSyntax, that would compile before and after the
>>>>>> >     change. So unless I'm missing something the position we can
>>>>>> take as
>>>>>> >     a committee can be either
>>>>>> >     - Let's have the breakage without a transition period
>>>>>> >     - Let's not make the breaking change ever and use the earlier
>>>>>> >     argument order for set
>>>>>> >
>>>>>> >     Which one do you argue for, or am I missing another option?
>>>>>> >
>>>>>> >     On Sun, 24 Sept 2023 at 15:36, Eric Seidel <eric at seidel.io
>>>>>> >     <mailto:eric at seidel.io>> wrote:
>>>>>> >
>>>>>> >         I am in favor of this proposal.
>>>>>> >
>>>>>> >         On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
>>>>>> >          > Dear all.
>>>>>> >          >
>>>>>> >          > I submitted my recommendation 3 weeks ago, and only
>>>>>> Simon has
>>>>>> >         commented
>>>>>> >          > yet. Please let me know your thoughts.
>>>>>> >          >
>>>>>> >          > On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack
>>>>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>>>>> wrote:
>>>>>> >          >> Dear all,
>>>>>> >          >>
>>>>>> >          >> Don't forget to opine here. To reiterate, I really don't
>>>>>> >         expect the proposal to be controversial. The text of the
>>>>>> >         proposal is rather long, but is made easy to read. So it
>>>>>> >         shouldn't take too much of your time.
>>>>>> >          >>
>>>>>> >          >> /Arnaud
>>>>>> >          >>
>>>>>> >          >> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones
>>>>>> >         <simon.peytonjones at gmail.com
>>>>>> >         <mailto:simon.peytonjones at gmail.com>> wrote:
>>>>>> >          >>> I support acceptance.
>>>>>> >          >>>
>>>>>> >          >>> Simon
>>>>>> >          >>>
>>>>>> >          >>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack
>>>>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>>>>> wrote:
>>>>>> >          >>>> Dear all,
>>>>>> >          >>>>
>>>>>> >          >>>> [ Proposal #583
>>>>>> >         https://github.com/ghc-proposals/ghc-proposals/pull/583
>>>>>> >         <https://github.com/ghc-proposals/ghc-proposals/pull/583> ]
>>>>>> >          >>>>
>>>>>> >          >>>> Our own Adam proposes to amend the design of the
>>>>>> highly
>>>>>> >         experimental OverloadedRecordUpdate extension as had been
>>>>>> >         designed in proposal #158 [
>>>>>> >
>>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>>>>>> <
>>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst>
>>>>>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405
>>>>>> <https://github.com/ghc-proposals/ghc-proposals/pull/405> ].
>>>>>> >          >>>>
>>>>>> >          >>>> Specifically, Adam proposes a modification of the type
>>>>>> >         classes that would back the extension.
>>>>>> >          >>>>
>>>>>> >          >>>> In the previous design the HasField class is defined
>>>>>> as a
>>>>>> >         lens:
>>>>>> >          >>>>
>>>>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>>>>> >          >>>>   hasField :: r -> (a -> r, a)
>>>>>> >          >>>>
>>>>>> >          >>>> The proposal is to replace it by two classes (slightly
>>>>>> >         simplified)
>>>>>> >          >>>>
>>>>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>>>>> >          >>>>   hasField :: r -> a
>>>>>> >          >>>>
>>>>>> >          >>>> class SetField (n::k) r a | r n -> a
>>>>>> >          >>>>   modifyField :: (a -> a) -> r -> a
>>>>>> >          >>>>   setField :: a -> r -> a
>>>>>> >          >>>>
>>>>>> >          >>>> This is originally motivated by some performance
>>>>>> >         consideration: the prototype implementation of HasField as a
>>>>>> >         lens can be very time consuming because instances of
>>>>>> HasFields
>>>>>> >         are generated eagerly at record definition sites, whereas
>>>>>> the
>>>>>> >         simple HasField instances can simply reuse the selectors
>>>>>> already
>>>>>> >         generated by GHC. But a lot of thoughts have been put into
>>>>>> the
>>>>>> >         new design, and my summary can certainly not do it justice:
>>>>>> the
>>>>>> >         proposal is very well argumented.
>>>>>> >          >>>>
>>>>>> >          >>>> A point I'll make here is that the new design is
>>>>>> actually
>>>>>> >         parametric in the data representation of the field type.
>>>>>> >         Something that wasn't possible in the original design.
>>>>>> >          >>>>
>>>>>> >          >>>> This proposal is not technically backward compatible,
>>>>>> >         because the order of argument in which
>>>>>> OverloadedRecordUpdate
>>>>>> >         expects the argument of setField is changed. This is not
>>>>>> >         essential to the proposal, but this is a more consistent
>>>>>> order
>>>>>> >         argument with the rest of Haskell. And considering that
>>>>>> >         OverloadedRecordUpdate is very loudly advertised as
>>>>>> >         experimental, I recommend accepting this breakage.
>>>>>> >          >>>>
>>>>>> >          >>>> Overall the proposal is actually more backward
>>>>>> compatible
>>>>>> >         with GHC 9.8 than the original design, as the HasField
>>>>>> class is
>>>>>> >         left unchanged.
>>>>>> >          >>>>
>>>>>> >          >>>> Overall, the proposal looks quite reasonable to me,
>>>>>> and
>>>>>> >         well-argued. I recommend acceptance.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Arnaud Spiwack
>>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>

-- 
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/20231003/adc2f186/attachment-0001.html>

From arnaud.spiwack at tweag.io  Tue Oct  3 09:52:58 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 3 Oct 2023 11:52:58 +0200
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAGwnsnkAvrwUxDZm2+Mfgg7ngJFbugYjZesL=cGgYQPQC1ai7g@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
 <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>
 <CAKfdd-zqumiE0FWp4vSyJXO8rqugupdXROa93fEBEYimtXYayQ@mail.gmail.com>
 <6ecf13eb-7c08-4f09-5696-deadc830231f@well-typed.com>
 <CAGwnsnkHOsVeDTqo1gTw10ECMQ+QjabRFbcspwCN8xcsN2eEfg@mail.gmail.com>
 <CAKfdd-ziOZdZ=gNpZLU-w-n8V6BFE=uu+jdK5MZyZPMcmgv5Bg@mail.gmail.com>
 <CAJKmMz_MeY4bwub1Dy43jW5A9w+yNf-0vqCdHi-iQ0J4A11EMQ@mail.gmail.com>
 <CAKfdd-yDN2PLX=Wga-tjndXqAGcg+2+u9nnxzHiH5U=iZBTrHw@mail.gmail.com>
 <CAJKmMz_tVcqczQoQ0k6YX4uKwas1KusN18JwxK+BHzjMWSLuLw@mail.gmail.com>
 <CAGwnsnkAvrwUxDZm2+Mfgg7ngJFbugYjZesL=cGgYQPQC1ai7g@mail.gmail.com>
Message-ID: <CAGwnsnns2kpWamSegWEP1KxzReeni5re=qkK5spAbt0FqUxzFA@mail.gmail.com>

Simon votes A above. I vote A too (I think I actually feel pretty strongly
about this one).

On Tue, 3 Oct 2023 at 11:52, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:

> Let's do a quick vote. All, which do you prefer?
>
> A. Introduce the breakage immediately and change the argument order of
> setField (current state of the proposal)
> B. Introduce a new extension -XOverloadedRecordUpdateNew which would use a
> setField with a different argument order, so that it can be used during the
> transition period. Eventually OverloadedRecordUpdateNew becomes deprecated
> and OverloadedRecordUpdate swaps the argument order. (Moritz's proposal)
> C. Keep the originally proposed setField argument order (nobody have
> suggested this yet, but I'm including it for completeness)
>
> On Tue, 3 Oct 2023 at 10:33, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Sure.
>>
>> Just to be clear, I'm not trying to set a precedent here!
>>
>> Simon
>>
>> On Tue, 3 Oct 2023 at 09:26, Moritz Angermann <moritz.angermann at gmail.com>
>> wrote:
>>
>>> I’m not going to stay in the way of this proposal. I’hope it’s
>>> understandable if I recuse myself.
>>>
>>> On Tue, 3 Oct 2023 at 4:18 PM, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> We have to balance the cost of mitigation against the cost of breakage.
>>>>
>>>>    - Cost of breakage.  Adam has identified only two packages that
>>>>    woud, both of which can adapt promptly.  It's true that there is more code
>>>>    out there, but the absence on Hackage is strongly indicative that there is
>>>>    unlikely to be much.
>>>>    - Cost of mitigation.  Supporting both behaviours, having extra
>>>>    language flags, that must in turn themselves be deprecated away, are real
>>>>    costs.  The suck effort away from more productive activity.
>>>>    - I completely agree that if we had a classification,
>>>>    OverloadedRecordUpdate would have been classified as Experimental, and we
>>>>    would not be discussing deprecation cycles.  And signalling what is
>>>>    experimental and what is stable is a *primary *goal of the
>>>>    stability conversation we are having.  I agree strongly with Moritz on this
>>>>    point.
>>>>    - However the user manual (Section 6.5.11
>>>>    <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/overloaded_record_update.html?highlight=overloaded%20record#overloaded-record-update>)
>>>>    says "*EXPERIMENTAL* *This design of this extension may well change
>>>>    in the future. It would be inadvisable to start using this extension for
>>>>    long-lived libraries just yet*".  Short of an official
>>>>    classification mechanism, which we don't have yet, it seems hard to imagine
>>>>    a clearer statement than that.
>>>>
>>>> My judgement: in this case we should forge ahead without introducing
>>>> OverloadedRecordNew and supporting both behaviours. (I have not even begun
>>>> to think about how hard that would be to implement.)  Let's spend our
>>>> precious cycles elsewhere.
>>>>
>>>> Simon
>>>>
>>>> On Tue, 3 Oct 2023 at 08:48, Moritz Angermann <
>>>> moritz.angermann at gmail.com> wrote:
>>>>
>>>>> Arnaud,
>>>>>
>>>>> That is a good argument. Without an opt-in to the new syntax, they
>>>>> can't adapt. I guess this brings us to the extension lifecycle. A solution
>>>>> could be
>>>>> 1. Deprecate OverloadedRecordUpdate in favour of
>>>>> OverloadedRecordUpdateNew. The user can adapt their code and use a
>>>>> different Extension.
>>>>> 2. Eventually Have OverloadedRecordUpdateNew be a synonym for changed
>>>>> OverloadedRecordUpdate. And Deprecate OverloadedRecordUpdateNew
>>>>>     over a longer period of time.
>>>>>
>>>>> I think this actually shows the value a `--std=experimental` could
>>>>> have. If `OverloadedRecordUpdate` was behind `--std=experimental` breaking
>>>>> it would
>>>>> be permissible by design. And we would not have this discussion, and
>>>>> Adam would not need to try to find all the potential breaking codes. This
>>>>> is part
>>>>> of the proposal to make `--std=experimental` a thing, allow fast(er)
>>>>> paced iteration on the experimental side of the compiler, while being
>>>>> extremely
>>>>> explicit about it being experimental features that can break at any
>>>>> time and without warning.
>>>>>
>>>>> The deprecation process outlined above would be fore non-experimental
>>>>> features. They can still be changed, but with a more rigorous change
>>>>> evolution.
>>>>>
>>>>> I hope this helps to clarify my position?
>>>>>
>>>>> Best,
>>>>>  Moritz
>>>>>
>>>>>
>>>>> On Tue, 3 Oct 2023 at 15:31, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>>>> wrote:
>>>>>
>>>>>> @Moritz: very clear thank you, though I'd like to understand how one
>>>>>> could adapt during the transition period to an argument swap, would you
>>>>>> say? Secondary question: if they can't adapt, isn't there a risk of making
>>>>>> the breakage more painful by delaying it, and letting more people use
>>>>>> -XOverloadedRecordUpdate with the argument order which isn't the final one?
>>>>>>
>>>>>> @Adam: we have to recognise that Hackage is not all the Haskell code.
>>>>>> I expect Hackage to be a little more conservative in extensions than
>>>>>> end-user applications. As such we're not guaranteed an absence of breakage
>>>>>> (it's still probably quite small, but it's hard to quantify).
>>>>>>
>>>>>> On Tue, 3 Oct 2023 at 09:21, Adam Gundry <adam at well-typed.com> wrote:
>>>>>>
>>>>>>> The backwards compatibility impact here is really extremely small,
>>>>>>> because OverloadedRecordUpdate is essentially unusable at present
>>>>>>> (as
>>>>>>> well as being explicitly documented as subject to change), so nobody
>>>>>>> uses it. While someone could implement a warning when the extension
>>>>>>> is
>>>>>>> turned on to say that it will change in the future, I'm not sure I
>>>>>>> see
>>>>>>> much point.
>>>>>>>
>>>>>>> I used https://hackage-search.serokell.io/?q=OverloadedRecordUpdate
>>>>>>> to
>>>>>>> look for occurrences of OverloadedRecordUpdate on Hackage, and I
>>>>>>> found
>>>>>>> precisely one pair of packages using it "for real":
>>>>>>>
>>>>>>> large-anon-0.3.0
>>>>>>> large-records-0.4
>>>>>>>
>>>>>>> These packages were created by my colleague Edsko in discussion with
>>>>>>> me,
>>>>>>> and will need to be amended when the proposal is implemented,
>>>>>>> because
>>>>>>> they want to take advantage of the new functionality.
>>>>>>>
>>>>>>> The other packages on Hackage containing the string
>>>>>>> OverloadedRecordUpdate are tools that reference all extensions:
>>>>>>>
>>>>>>> Cabal-syntax-3.10.1.0
>>>>>>> extensions-0.1.0.0
>>>>>>> fourmolu-0.14.0.0
>>>>>>> ghc-9.6.3
>>>>>>> ghc-boot-th-9.6.3
>>>>>>> ghc-exactprint-1.7.0.1
>>>>>>> ghc-hs-meta-0.1.2.0
>>>>>>> ghc-lib-9.6.2.20230523
>>>>>>> ghc-lib-parser-9.6.2.20230523
>>>>>>> hackport-0.8.4.0
>>>>>>> haskell-src-meta-0.8.12
>>>>>>> hindent-6.1.0
>>>>>>> hlint-3.6.1
>>>>>>> ormolu-0.7.2.0
>>>>>>>
>>>>>>> plus there are a few references in comments:
>>>>>>>
>>>>>>> lifx-lan-0.8.2
>>>>>>> optics-core-0.4.1.1
>>>>>>> pvector-0.1.1
>>>>>>> record-dot-preprocessor-0.2.16
>>>>>>> tztime-0.1.1.0
>>>>>>>
>>>>>>> While I generally agree with the "don't abruptly break existing
>>>>>>> code"
>>>>>>> position, in this case I don't think there is code out there to
>>>>>>> break.
>>>>>>>
>>>>>>> Adam
>>>>>>>
>>>>>>>
>>>>>>> On 03/10/2023 01:14, Moritz Angermann wrote:
>>>>>>> > Arnaud,
>>>>>>> >
>>>>>>> > thank you for your write up. And sorry that my view seems to be
>>>>>>> not
>>>>>>> > clear. Let me try to explain.
>>>>>>> > My position is: I'm against anything that _abruptly_ breaks
>>>>>>> existing
>>>>>>> > code. That's basically all there is to it.
>>>>>>> > Therefore I'm strongly against breaking changes without an
>>>>>>> appropriate
>>>>>>> > warning period (from the compiler).
>>>>>>> > I also strongly believe that most people do not read
>>>>>>> documentation, and
>>>>>>> > the authoritative messages are
>>>>>>> > the ones the compiler produces. As I've alluded to in a different
>>>>>>> email,
>>>>>>> > there are lots of people who work
>>>>>>> > on software as a 9-5 job, and don't spend their freetime tinkering
>>>>>>> and
>>>>>>> > playing with languages. They just
>>>>>>> > want to get the job done they are assigned. I have a lot of
>>>>>>> respect for
>>>>>>> > them. In my experience they don't
>>>>>>> > read compiler release announcements, or even go and read the
>>>>>>> compiler
>>>>>>> > documentation. They are given
>>>>>>> > the compiler version the company decided on for use in production.
>>>>>>> > That's the tool they use. And that tool
>>>>>>> > in my opinion needs to be rock solid, and not break easily across
>>>>>>> > versions. Thus yes, I would very much
>>>>>>> > like to see us not have breaking changes at all, but I can see
>>>>>>> that we
>>>>>>> > may need breaking changes
>>>>>>> > occasionally. In those cases I want it to be very visible to the
>>>>>>> > consumers that this breaking change is
>>>>>>> > coming towards them (compiler warnings). Giving them some time to
>>>>>>> adjust
>>>>>>> > (migration period), until the
>>>>>>> > breaking change happens.  Ultimately we should be able to compiler
>>>>>>> > existing code that compiles today
>>>>>>> > with at least the next compiler without it rejecting the code or
>>>>>>> needing
>>>>>>> > modifications to the code (-Werror
>>>>>>> > excluded).
>>>>>>> >
>>>>>>> > Thus what I'm arguing for is:
>>>>>>> > - Let's implement this backwards compatibility.
>>>>>>> > - Add compiler warnings about the arguments being swapped in a
>>>>>>> future
>>>>>>> > GHC version. For _a least_ one major release.
>>>>>>> > - Make the breaking change in a subsequent release.
>>>>>>> >
>>>>>>> > Alternatively I could also see:
>>>>>>> > - Adding compiler warnings now that the arguments will be swapped
>>>>>>> in a
>>>>>>> > future GHC version (for at least one major release).
>>>>>>> > - Implement the breaking change in a subsequent release.
>>>>>>> >
>>>>>>> > Either of those would be ok with me. Implementing a breaking
>>>>>>> change from
>>>>>>> > one version to the next, without an
>>>>>>> > appropriate deprecation/migration period (that is, the compiler
>>>>>>> will
>>>>>>> > warn loudly that changes are coming) is something
>>>>>>> > I am _very_ vehemently against.
>>>>>>> >
>>>>>>> > If the migration/deprecation warnings would provide a link to a
>>>>>>> GitHub
>>>>>>> > ticket or something where more information
>>>>>>> > can be found and maybe even a discussion could be had would
>>>>>>> probably
>>>>>>> > also be a good idea.
>>>>>>> >
>>>>>>> > I hope this helps clarify my position? If not, feel free to ask
>>>>>>> more,
>>>>>>> > I'm also happy to jump onto a call to explain my
>>>>>>> > position if needed.
>>>>>>> >
>>>>>>> > Best,
>>>>>>> >   Moritz
>>>>>>> >
>>>>>>> >
>>>>>>> > On Mon, 2 Oct 2023 at 23:31, Arnaud Spiwack <
>>>>>>> arnaud.spiwack at tweag.io
>>>>>>> > <mailto:arnaud.spiwack at tweag.io>> wrote:
>>>>>>> >
>>>>>>> >     Sorry I took a little bit of time to react to this, it was a
>>>>>>> lot to
>>>>>>> >     take in and I didn't have the mental space last week.
>>>>>>> >
>>>>>>> >     The only person that may have spoken against the current state
>>>>>>> of
>>>>>>> >     the proposal is Moritz. Yet I realise that I don't actually
>>>>>>> know,
>>>>>>> >     Moritz, what your position is.
>>>>>>> >
>>>>>>> >     To recap: to use -XOverloadedRecordUpdate in current GHC, you
>>>>>>> need
>>>>>>> >     to use -XRebindableSyntax and provide a setField function. In
>>>>>>> the
>>>>>>> >     new proposal you can use -XOverloadedRecordUpdate without
>>>>>>> >     -XRebindableSyntax, but when -XRebindableSyntax is on, the
>>>>>>> setField
>>>>>>> >     function that you have to provide has its argument swapped. The
>>>>>>> >     current documentation of OverloadedRecordUpdate has the
>>>>>>> following
>>>>>>> >     text at the top “*EXPERIMENTAL* /This design of this extension
>>>>>>> may
>>>>>>> >     well change in the future. It would be inadvisable to start
>>>>>>> using
>>>>>>> >     this extension for long-lived libraries just yet./”.
>>>>>>> >
>>>>>>> >     Now, I don't quite see how we could have a transition period
>>>>>>> that
>>>>>>> >     would allow a smooth transition there. There is no piece of
>>>>>>> code,
>>>>>>> >     with RebindableSyntax, that would compile before and after the
>>>>>>> >     change. So unless I'm missing something the position we can
>>>>>>> take as
>>>>>>> >     a committee can be either
>>>>>>> >     - Let's have the breakage without a transition period
>>>>>>> >     - Let's not make the breaking change ever and use the earlier
>>>>>>> >     argument order for set
>>>>>>> >
>>>>>>> >     Which one do you argue for, or am I missing another option?
>>>>>>> >
>>>>>>> >     On Sun, 24 Sept 2023 at 15:36, Eric Seidel <eric at seidel.io
>>>>>>> >     <mailto:eric at seidel.io>> wrote:
>>>>>>> >
>>>>>>> >         I am in favor of this proposal.
>>>>>>> >
>>>>>>> >         On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
>>>>>>> >          > Dear all.
>>>>>>> >          >
>>>>>>> >          > I submitted my recommendation 3 weeks ago, and only
>>>>>>> Simon has
>>>>>>> >         commented
>>>>>>> >          > yet. Please let me know your thoughts.
>>>>>>> >          >
>>>>>>> >          > On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack
>>>>>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>>>>>> wrote:
>>>>>>> >          >> Dear all,
>>>>>>> >          >>
>>>>>>> >          >> Don't forget to opine here. To reiterate, I really
>>>>>>> don't
>>>>>>> >         expect the proposal to be controversial. The text of the
>>>>>>> >         proposal is rather long, but is made easy to read. So it
>>>>>>> >         shouldn't take too much of your time.
>>>>>>> >          >>
>>>>>>> >          >> /Arnaud
>>>>>>> >          >>
>>>>>>> >          >> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones
>>>>>>> >         <simon.peytonjones at gmail.com
>>>>>>> >         <mailto:simon.peytonjones at gmail.com>> wrote:
>>>>>>> >          >>> I support acceptance.
>>>>>>> >          >>>
>>>>>>> >          >>> Simon
>>>>>>> >          >>>
>>>>>>> >          >>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack
>>>>>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>>>>>> wrote:
>>>>>>> >          >>>> Dear all,
>>>>>>> >          >>>>
>>>>>>> >          >>>> [ Proposal #583
>>>>>>> >         https://github.com/ghc-proposals/ghc-proposals/pull/583
>>>>>>> >         <https://github.com/ghc-proposals/ghc-proposals/pull/583>
>>>>>>> ]
>>>>>>> >          >>>>
>>>>>>> >          >>>> Our own Adam proposes to amend the design of the
>>>>>>> highly
>>>>>>> >         experimental OverloadedRecordUpdate extension as had been
>>>>>>> >         designed in proposal #158 [
>>>>>>> >
>>>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>>>>>>> <
>>>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst>
>>>>>>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405
>>>>>>> <https://github.com/ghc-proposals/ghc-proposals/pull/405> ].
>>>>>>> >          >>>>
>>>>>>> >          >>>> Specifically, Adam proposes a modification of the
>>>>>>> type
>>>>>>> >         classes that would back the extension.
>>>>>>> >          >>>>
>>>>>>> >          >>>> In the previous design the HasField class is defined
>>>>>>> as a
>>>>>>> >         lens:
>>>>>>> >          >>>>
>>>>>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>>>>>> >          >>>>   hasField :: r -> (a -> r, a)
>>>>>>> >          >>>>
>>>>>>> >          >>>> The proposal is to replace it by two classes
>>>>>>> (slightly
>>>>>>> >         simplified)
>>>>>>> >          >>>>
>>>>>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>>>>>> >          >>>>   hasField :: r -> a
>>>>>>> >          >>>>
>>>>>>> >          >>>> class SetField (n::k) r a | r n -> a
>>>>>>> >          >>>>   modifyField :: (a -> a) -> r -> a
>>>>>>> >          >>>>   setField :: a -> r -> a
>>>>>>> >          >>>>
>>>>>>> >          >>>> This is originally motivated by some performance
>>>>>>> >         consideration: the prototype implementation of HasField as
>>>>>>> a
>>>>>>> >         lens can be very time consuming because instances of
>>>>>>> HasFields
>>>>>>> >         are generated eagerly at record definition sites, whereas
>>>>>>> the
>>>>>>> >         simple HasField instances can simply reuse the selectors
>>>>>>> already
>>>>>>> >         generated by GHC. But a lot of thoughts have been put into
>>>>>>> the
>>>>>>> >         new design, and my summary can certainly not do it
>>>>>>> justice: the
>>>>>>> >         proposal is very well argumented.
>>>>>>> >          >>>>
>>>>>>> >          >>>> A point I'll make here is that the new design is
>>>>>>> actually
>>>>>>> >         parametric in the data representation of the field type.
>>>>>>> >         Something that wasn't possible in the original design.
>>>>>>> >          >>>>
>>>>>>> >          >>>> This proposal is not technically backward compatible,
>>>>>>> >         because the order of argument in which
>>>>>>> OverloadedRecordUpdate
>>>>>>> >         expects the argument of setField is changed. This is not
>>>>>>> >         essential to the proposal, but this is a more consistent
>>>>>>> order
>>>>>>> >         argument with the rest of Haskell. And considering that
>>>>>>> >         OverloadedRecordUpdate is very loudly advertised as
>>>>>>> >         experimental, I recommend accepting this breakage.
>>>>>>> >          >>>>
>>>>>>> >          >>>> Overall the proposal is actually more backward
>>>>>>> compatible
>>>>>>> >         with GHC 9.8 than the original design, as the HasField
>>>>>>> class is
>>>>>>> >         left unchanged.
>>>>>>> >          >>>>
>>>>>>> >          >>>> Overall, the proposal looks quite reasonable to me,
>>>>>>> and
>>>>>>> >         well-argued. I recommend acceptance.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Arnaud Spiwack
>>>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>


-- 
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/20231003/c1b0da79/attachment-0001.html>

From simon.peytonjones at gmail.com  Tue Oct  3 10:00:01 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 3 Oct 2023 11:00:01 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
Message-ID: <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>

Here's my summary:

   - There is strong (universal, even) support for the `severe` category.
   - There is pretty strong support for making severe warnings into errors
   at some point.  As Matt puts it "this is not a question of GHC breaking
   things, but rather *revealing* and providing early-diagnosis for *already
   broken* things".
   - But I think we are moving towards a policy of giving users time to
   adapt via a deprecation cycle, whenever that is feasible.  And it is
   feasible here.

So my suggestion would be:

   - When implemented, make `-Wwarn=severe` the default, but add to each
   severe warning a deprecation-style message saying that it'll become an
   error in the next iteration.
   - In the next released, make `-Werror=severe` the default.
   - Don't complicate matters by involving GHC2024.  That is another
   conversation, and even if we wanted to include `-Werorr=severe` in GHC2024,
   we would *still* want a deprecation cycle!

Would that be acceptable?

Simon

On Fri, 29 Sept 2023 at 19:41, Adam Gundry <adam at well-typed.com> wrote:

> Dear Committee,
>
> It seems we are somewhat split on the -Wsevere proposal, even assuming
> it is introduced with a deprecation period (changing the warning text
> and adding the group in advance). There is consensus that adding the
> group by itself is fine, and potentially enabling -Werror=severe under
> GHC2024, but enabling it by default for existing code is more
> controversial.
>
> Ultimately this is a judgement call about the value of the proposal
> versus the breakage it causes. I remain of the view that it is
> worthwhile. This is not merely about more aggressively enforcing best
> practice. Rather, it eliminates the risk of the following:
>
> * Suppose package A defines a type class, package B depends on package
> A, and package C depends on package B.
>
> * Now package A extends the type class definition with a new method and
> default methods. Everything still compiles; package B now issues a
> -Wmissing-methods warning (but is not actively maintained, and the
> author of package C is unlikely to look at warnings in all their
> dependencies).
>
> * Users of package C have to try to debug an infinite loop.
>
> Given that this change avoids a significant issue, affected code has
> been issuing warnings for many years, and impacted users can very easily
> set -Wwarn=severe either at the package level or the project level, I
> think is worth accepting the backwards compatibility cost and the fact
> that some Haskell2010 code will no longer be accepted by default.
>
> Matt Parsons puts it well in the CLC thread, which is pretty clearly in
> favour of this proposal overall
> (
> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
> ):
>
>  > I think GHC should strive to make fewer breaking changes, and make
> those changes as easy-to-adopt as possible. But this is not a question
> of GHC breaking things, but rather revealing and providing
> early-diagnosis for already broken things.
>
> Further opinions are welcome, of course.
>
> Adam
>
>
> On 14/09/2023 09:32, Adam Gundry wrote:
> > Dear Committee,
> >
> > Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods
> > and -Wmissing-fields warnings into errors by default (retaining the
> > option to downgrade them). I recommend we accept the proposal.
> >
> > Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
> > Rendered:
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> >
> > This is primarily motivated by the fact that when classes have default
> > methods, missing methods can lead to runtime loops, which are generally
> > difficult to debug. Since in practice not all users pay attention to
> > warnings that do not inhibit compilation, it makes sense to identify a
> > class of warnings that are sufficiently serious to require explicit
> > action from the user to silence them.
> >
> > Since these warnings are currently not errors by default, library
> > authors experimentally assessing the impact of changes may be lead to
> > assume that introducing new methods/fields does not lead to breakage
> > (because downstream code will still compile). The proposal thus makes it
> > more obvious that adding a new method or field is a breaking change.
> >
> > The proposal deliberately causes builds to fail by default for some
> > libraries that currently emit warnings. Oleg has kindly performed impact
> > assessments to identify such libraries, and the breakage of a few
> > packages seems worth the cost.
> >
> > It is easy to restore the warnings to their previous classification by
> > passing an option at build time, e.g. using -Wno-error=missing-methods.
> > Users can set such an option in cabal.project or stack.yaml to work
> > around breakage that is not promptly fixed by the library author.
> >
> > This change does mean that GHC with -XHaskell98/2010 will by default
> > reject some programs that are explicitly permitted by the Haskell98/2010
> > specification. I recommend we document this infelicity, but accept it,
> > as much of the benefit of the proposal is that it applies by default.
> >
> > The proposal establishes the precedent that some warnings may be treated
> > as errors by default, and introduces a warning group -Wsevere to
> > classify them. This seems conceptually useful and gives us the option to
> > extend the -Wsevere set in the future (e.g. as a final stage of
> > deprecation before a feature is removed).
> >
> > Thoughts?
> >
> > Adam
> >
> >
> > On 11/09/2023 20:25, Joachim Breitner wrote:
> >> Dear Committee,
> >>
> >> based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a
> >> warning group -Wsevere for on-by-defaults, error-by-default warnings,
> >> and initially fill it with missing-methods and missing-fields.
> >>
> >>
> >> https://github.com/ghc-proposals/ghc-proposals/pull/571
> >>
> >>
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> >>
> >> I’d like to nominate Adam as the shepherd, who already reviewed it a
> >> bit on Github.
> >>
> >> Please guide us to a conclusion as outlined in
> >> https://github.com/ghc-proposals/ghc-proposals#committee-process
> >>
> >>
> >> Cheers,
> >> Joachim
>
>
> --
> 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/20231003/84ccf7aa/attachment.html>

From simon.peytonjones at gmail.com  Tue Oct  3 10:08:12 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 3 Oct 2023 11:08:12 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>
 <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>
Message-ID: <CAJKmMz9vkMbFwsbYj3A3eiD-XTJE3vx_TXHoSv323CQTmoWRQw@mail.gmail.com>

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>

From simon.peytonjones at gmail.com  Tue Oct  3 10:11:20 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 3 Oct 2023 11:11:20 +0100
Subject: [ghc-steering-committee] #526: Applicative Comprehensions (rec:
	accept)
In-Reply-To: <4059923d-af9e-9218-9b67-f63033882220@well-typed.com>
References: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
 <4059923d-af9e-9218-9b67-f63033882220@well-typed.com>
Message-ID: <CAJKmMz9RrknSxPNDx+3JDNTT7WvjMsEKO2sjn0khBeH1ZVTt4g@mail.gmail.com>

I too am concerned that the author @strake has not responded since Oct
2022.   Nor have we seen a chorus of support from other users.

My suggestion

   - Park the proposal for now
   - Reach out to the author to check that they are OK

Simon M: you are shepherding; what do you think?

Simon

On Mon, 2 Oct 2023 at 09:07, Adam Gundry <adam at well-typed.com> wrote:

> I'm unconvinced by the current state of this proposal, for similar
> reasons as Simon PJ gives on the proposal thread
> (
> https://github.com/ghc-proposals/ghc-proposals/pull/526#issuecomment-1740735610
> ).
>
> If we want to accept this merely for reasons of consistency, I think the
> simplest way forward would be to not introduce a new extension name, and
> instead define the combination of MonadComprehensions + ApplicativeDo to
> do what the proposal suggests.
>
> The author doesn't seem to be responsive on the thread. While I worry
> this may be because of the time the proposal process has been taking, it
> makes it difficult to gauge support for the various alternative
> suggestions that have been made.
>
> Cheers,
>
> Adam
>
>
> On 28/09/2023 08:12, Simon Marlow wrote:
> > Dear committee,
> >
> > #526 proposes a new extension ApplicativeComprehensions (implying
> > MonadComprehensions). It would provide the equivalent of the current
> > ApplicativeDo desugaring for do-expressions to list comprehensions.
> >
> >   * Github thread <
> https://github.com/ghc-proposals/ghc-proposals/pull/526>
> >   * Rendered
> >     <
> https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst
> >
> >
> > The extension itself is relatively uncontroversial, but there are some
> > unresolved quirks in the original ApplicativeDo extension which made us
> > uneasy about extending it. However, after various discussions I'm going
> > to propose accepting this proposal in its current state.  Rationale:
> >
> >   * It doesn't make things worse, and the implementation isn't likely to
> >     add significant complexity.
> >   * It retains consistency between ApplicativeDo and
> >     ApplicativeComprehensions (in contrast to the idea of making
> >     ApplicativeComprehensions perform a simpler desugaring, which came
> >     up during the discussion)
> >   * A future proposal can add a simpler version of the desugaring for
> >     both extensions later.
> >
> >
> > Cheers
> > Simon
>
> --
> 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/20231003/028c99c0/attachment.html>

From simon.peytonjones at gmail.com  Tue Oct  3 10:15:10 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 3 Oct 2023 11:15:10 +0100
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <CANsrgPJsT3qwCwwgaOMPTxzY-FMhcEP2bh-C8mpTU++T1QeC4g@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
 <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
 <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>
 <CAKfdd-yMiHABzKREnyra8TGCPe49LhVgL8qq0Fp_045=tHEu9w@mail.gmail.com>
 <5deb3358-0fc1-4b8f-af8d-dfe5eb3d59d9@joachim-breitner.de>
 <CAKfdd-zZNQj5LYOJYbZ8TXwvRHMxTvTiUPABd4w5dqF+gBnntA@mail.gmail.com>
 <CANsrgPJsT3qwCwwgaOMPTxzY-FMhcEP2bh-C8mpTU++T1QeC4g@mail.gmail.com>
Message-ID: <CAJKmMz_7s+WRwN5xzQ14wK6N7Y086v7nOZps4vS-xEnx6JfAPg@mail.gmail.com>

>
> Looks to me like it would be a breaking change even when the extension is
> not enabled, because the grammar is not conditional on extensions. The
> usual trick of using keywords to enable extensions (because keywords can be
> conditionally enabled in the lexer) doesn't work in this case.
>

Breaking changes gated by a language extension are OK, right?  According to
our still-draft (GR1).  As Moritz says

I have absolutely no issue with new extensions rejecting code that compiles
> fine without them. My only objections is to GHC not accepting code it
> accepted before without a deprecation period in between.
>

Simon M: are you arguing against, or just pointing out?

Simon

On Tue, 12 Sept 2023 at 08:27, Simon Marlow <marlowsd at gmail.com> wrote:

> Looks to me like it would be a breaking change even when the extension is
> not enabled, because the grammar is not conditional on extensions. The
> usual trick of using keywords to enable extensions (because keywords can be
> conditionally enabled in the lexer) doesn't work in this case.
>
> Cheers
> Simon
>
> On Sun, 10 Sept 2023 at 05:17, Moritz Angermann <
> moritz.angermann at gmail.com> wrote:
>
>> Joachim,
>>
>> My understand if the cost and drawbacks section[1], is that existing code
>> breaks even without explicitly enabling the extension. If this is indeed
>> not the case it should be called our explicitly in the section that
>> breakage requires the extension to be enabled. Also an explanation why the
>> patsyn test cases fail. Do we automatically enable that extension in the
>> testsuite? Where does the regression come from?
>>
>> Maybe I’m misreading that section and it just needs to be clarified that
>> there is _no breakage without **explixitly** enabling the extension_ to
>> existing code.
>>
>> Cheers,
>>  Moritz
>>
>> [1]:
>>
>> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst#costs-and-drawbacks
>>
>> On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>>
>>> Hi,
>>>
>>> since this is guarded by an extension that doesn't even exist yet, no
>>> code is broken, is there?
>>>
>>> I also don't expect this to be enabled in the future without coinciding
>>> with an intentional action by the developers - enabling this extension or
>>> switching to a future language edition that has this enabled by default
>>> (should that ever exist). Is it not sufficient if they are _then_ bothered
>>> with this change?
>>>
>>> (That said, we could say that a unparenthized type annotation on a
>>> pattern synonym is simply confusing, and thus use a warning to nudge the
>>> developers to add the parentheses now.)
>>>
>>> So not opposed to an early warning, I just don't think it's strictly
>>> necessary for this change.
>>>
>>> Cheers,
>>> Joachim
>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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/10e838f0/attachment.html>

From simon.peytonjones at gmail.com  Tue Oct  3 10:17:15 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 3 Oct 2023 11:17:15 +0100
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
Message-ID: <CAJKmMz_VcJ7cBQ3kTv8acBVNYpHN5BxCnjEGLby9gPqv3WfmEA@mail.gmail.com>

Chris

*Joachim, Simon, and Richard *have yet to vote; but I think you have a
majority anyway.  Would you like to move this forward?

Simon

On Fri, 8 Sept 2023 at 11:57, Chris Dornan <chris at chrisdornan.com> wrote:

> Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
> Author: Sebastian Graf, David Knothe
> Rendered proposal:
> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609
> Recommendation: Acceptance
>
> ## Summary
>
> This proposal refines the syntax of an already accpted proposal (#522) for
> writing or patterns.
>
> The syntax of the old proposal,
>
> ```haskell
> stringOfT :: T -> Maybe String
> stringOfT (T1 s) = Just s
> stringOfT (one of T2{}, T3{}) = Nothing
> ```
>
> is replaced with
>
> ```haskell
> stringOfT :: T -> Maybe String
> stringOfT (T1 s) = Just s
> stringOfT (T2{}; T3{}) = Nothing
> ```
>
> or indeed
>
> ```haskell
> stringOfT :: T -> Maybe String
> stringOfT x = case x of
> T1 s -> Just s
> T2{}
> T3{} -> Nothing
> ```
>
> (Beacuse the '(' ... ')' are optional here, we can remove them and
> naturally exploit layout.)
>
> The authors have conducted polls to see what folks preferred, landing on
> this proposal. The
> adjustments to the Haskell grammar are really quite minimal requiring one
> extra production.
>
> ## Recommendation
>
> The proposal is nondiruptive and as a whole addresses an important
> practical topic. I recommend
> that we accept it
>
> _______________________________________________
> 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/23b57e6e/attachment-0001.html>

From mail at joachim-breitner.de  Tue Oct  3 10:49:26 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 03 Oct 2023 12:49:26 +0200
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
 p2 (#609)
In-Reply-To: <CAJKmMz_VcJ7cBQ3kTv8acBVNYpHN5BxCnjEGLby9gPqv3WfmEA@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz_VcJ7cBQ3kTv8acBVNYpHN5BxCnjEGLby9gPqv3WfmEA@mail.gmail.com>
Message-ID: <89a573f115918f0c65c8f7006d8eb724869b278c.camel@joachim-breitner.de>

Hi,

ah, yes, I’m in favor!

Cheers,
Joachim

Am Dienstag, dem 03.10.2023 um 11:17 +0100 schrieb Simon Peyton Jones:
> Chris
> 
> Joachim, Simon, and Richard have yet to vote; but I think you have a
> majority anyway.  Would you like to move this forward?
> 
> Simon
> 
> On Fri, 8 Sept 2023 at 11:57, Chris Dornan <chris at chrisdornan.com>
> wrote:
> > Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
> > Author: Sebastian Graf, David Knothe
> > Rendered proposal:
> > https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
> > Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609
> > Recommendation: Acceptance
> > 
> > ## Summary
> > 
> > This proposal refines the syntax of an already accpted proposal
> > (#522) for writing or patterns.
> > 
> > The syntax of the old proposal,
> > 
> > ```haskell
> >     stringOfT :: T -> Maybe String
> >     stringOfT (T1 s)              = Just s
> >     stringOfT (one of T2{}, T3{}) = Nothing
> > ```
> > 
> > is replaced with
> > 
> > ```haskell
> >     stringOfT :: T -> Maybe String
> >     stringOfT (T1 s)       = Just s
> >     stringOfT (T2{}; T3{}) = Nothing
> > ```
> > 
> > or indeed
> > 
> > ```haskell
> >     stringOfT :: T -> Maybe String
> >     stringOfT x = case x of
> >       T1 s -> Just s
> >       T2{}
> >       T3{} -> Nothing
> > ```
> > 
> > (Beacuse the '(' ... ')' are optional here, we can remove them and
> > naturally exploit layout.)
> > 
> > The authors have conducted polls to see what folks preferred,
> > landing on this proposal. The
> > adjustments to the Haskell grammar are really quite minimal
> > requiring one extra production.
> > 
> > ## Recommendation
> > 
> > The proposal is nondiruptive and as a whole addresses an important
> > practical topic. I recommend
> > that we accept it
> > 
> > _______________________________________________
> > 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

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From lists at richarde.dev  Tue Oct  3 13:11:47 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Tue, 3 Oct 2023 13:11:47 +0000
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
 p2 (#609)
In-Reply-To: <89a573f115918f0c65c8f7006d8eb724869b278c.camel@joachim-breitner.de>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz_VcJ7cBQ3kTv8acBVNYpHN5BxCnjEGLby9gPqv3WfmEA@mail.gmail.com>
 <89a573f115918f0c65c8f7006d8eb724869b278c.camel@joachim-breitner.de>
Message-ID: <010f018af5aa85d1-9b942691-b2fc-4702-9ea8-4c5c7f0ee95c-000000@us-east-2.amazonses.com>

I'm in support.

> On Oct 3, 2023, at 6:49 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> ah, yes, I’m in favor!
> 
> Cheers,
> Joachim
> 
> Am Dienstag, dem 03.10.2023 um 11:17 +0100 schrieb Simon Peyton Jones:
>> Chris
>> 
>> Joachim, Simon, and Richard have yet to vote; but I think you have a
>> majority anyway.  Would you like to move this forward?
>> 
>> Simon
>> 
>> On Fri, 8 Sept 2023 at 11:57, Chris Dornan <chris at chrisdornan.com>
>> wrote:
>>> Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
>>> Author: Sebastian Graf, David Knothe
>>> Rendered proposal:
>>> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
>>> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609
>>> Recommendation: Acceptance
>>> 
>>> ## Summary
>>> 
>>> This proposal refines the syntax of an already accpted proposal
>>> (#522) for writing or patterns.
>>> 
>>> The syntax of the old proposal,
>>> 
>>> ```haskell
>>>     stringOfT :: T -> Maybe String
>>>     stringOfT (T1 s)              = Just s
>>>     stringOfT (one of T2{}, T3{}) = Nothing
>>> ```
>>> 
>>> is replaced with
>>> 
>>> ```haskell
>>>     stringOfT :: T -> Maybe String
>>>     stringOfT (T1 s)       = Just s
>>>     stringOfT (T2{}; T3{}) = Nothing
>>> ```
>>> 
>>> or indeed
>>> 
>>> ```haskell
>>>     stringOfT :: T -> Maybe String
>>>     stringOfT x = case x of
>>>       T1 s -> Just s
>>>       T2{}
>>>       T3{} -> Nothing
>>> ```
>>> 
>>> (Beacuse the '(' ... ')' are optional here, we can remove them and
>>> naturally exploit layout.)
>>> 
>>> The authors have conducted polls to see what folks preferred,
>>> landing on this proposal. The
>>> adjustments to the Haskell grammar are really quite minimal
>>> requiring one extra production.
>>> 
>>> ## Recommendation
>>> 
>>> The proposal is nondiruptive and as a whole addresses an important
>>> practical topic. I recommend
>>> that we accept it
>>> 
>>> _______________________________________________
>>> 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
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From marlowsd at gmail.com  Tue Oct  3 15:36:18 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 3 Oct 2023 16:36:18 +0100
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <CAJKmMz_7s+WRwN5xzQ14wK6N7Y086v7nOZps4vS-xEnx6JfAPg@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
 <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
 <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>
 <CAKfdd-yMiHABzKREnyra8TGCPe49LhVgL8qq0Fp_045=tHEu9w@mail.gmail.com>
 <5deb3358-0fc1-4b8f-af8d-dfe5eb3d59d9@joachim-breitner.de>
 <CAKfdd-zZNQj5LYOJYbZ8TXwvRHMxTvTiUPABd4w5dqF+gBnntA@mail.gmail.com>
 <CANsrgPJsT3qwCwwgaOMPTxzY-FMhcEP2bh-C8mpTU++T1QeC4g@mail.gmail.com>
 <CAJKmMz_7s+WRwN5xzQ14wK6N7Y086v7nOZps4vS-xEnx6JfAPg@mail.gmail.com>
Message-ID: <CANsrgPJi=tZjv6JTh19U9j2AuBxSG0kQR6bGKz+7LLcJS1dAgw@mail.gmail.com>

On Tue, 3 Oct 2023 at 11:15, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> Looks to me like it would be a breaking change even when the extension is
>> not enabled, because the grammar is not conditional on extensions. The
>> usual trick of using keywords to enable extensions (because keywords can be
>> conditionally enabled in the lexer) doesn't work in this case.
>>
>
> Breaking changes gated by a language extension are OK, right?  According
> to our still-draft (GR1).  As Moritz says
>
> I have absolutely no issue with new extensions rejecting code that
>> compiles fine without them. My only objections is to GHC not accepting code
>> it accepted before without a deprecation period in between.
>>
>
> Simon M: are you arguing against, or just pointing out?
>

To clarify: the proposal originally contained a breaking change that wasn't
gated by the extension flag, but that's now been fixed. I don't have any
objection to the proposal as it stands.

Cheers
Simon


>
> Simon
>
> On Tue, 12 Sept 2023 at 08:27, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> Looks to me like it would be a breaking change even when the extension is
>> not enabled, because the grammar is not conditional on extensions. The
>> usual trick of using keywords to enable extensions (because keywords can be
>> conditionally enabled in the lexer) doesn't work in this case.
>>
>> Cheers
>> Simon
>>
>> On Sun, 10 Sept 2023 at 05:17, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> Joachim,
>>>
>>> My understand if the cost and drawbacks section[1], is that existing
>>> code breaks even without explicitly enabling the extension. If this is
>>> indeed not the case it should be called our explicitly in the section that
>>> breakage requires the extension to be enabled. Also an explanation why the
>>> patsyn test cases fail. Do we automatically enable that extension in the
>>> testsuite? Where does the regression come from?
>>>
>>> Maybe I’m misreading that section and it just needs to be clarified that
>>> there is _no breakage without **explixitly** enabling the extension_ to
>>> existing code.
>>>
>>> Cheers,
>>>  Moritz
>>>
>>> [1]:
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst#costs-and-drawbacks
>>>
>>> On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner <
>>> mail at joachim-breitner.de> wrote:
>>>
>>>> Hi,
>>>>
>>>> since this is guarded by an extension that doesn't even exist yet, no
>>>> code is broken, is there?
>>>>
>>>> I also don't expect this to be enabled in the future without coinciding
>>>> with an intentional action by the developers - enabling this extension or
>>>> switching to a future language edition that has this enabled by default
>>>> (should that ever exist). Is it not sufficient if they are _then_ bothered
>>>> with this change?
>>>>
>>>> (That said, we could say that a unparenthized type annotation on a
>>>> pattern synonym is simply confusing, and thus use a warning to nudge the
>>>> developers to add the parentheses now.)
>>>>
>>>> So not opposed to an early warning, I just don't think it's strictly
>>>> necessary for this change.
>>>>
>>>> Cheers,
>>>> Joachim
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> 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/dd08efa0/attachment.html>

From marlowsd at gmail.com  Tue Oct  3 16:05:03 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 3 Oct 2023 17:05:03 +0100
Subject: [ghc-steering-committee] #526: Applicative Comprehensions (rec:
	accept)
In-Reply-To: <CAJKmMz9RrknSxPNDx+3JDNTT7WvjMsEKO2sjn0khBeH1ZVTt4g@mail.gmail.com>
References: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
 <4059923d-af9e-9218-9b67-f63033882220@well-typed.com>
 <CAJKmMz9RrknSxPNDx+3JDNTT7WvjMsEKO2sjn0khBeH1ZVTt4g@mail.gmail.com>
Message-ID: <CANsrgPKdwk7YAH7K3PXi+eUVuSkSf1DCdh4Bs-f8Xg2sn8PyqQ@mail.gmail.com>

I've made it dormant and posted on the thread to ask the submitter if
they're still interested in the proposal.

On Tue, 3 Oct 2023 at 11:11, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> I too am concerned that the author @strake has not responded since Oct
> 2022.   Nor have we seen a chorus of support from other users.
>
> My suggestion
>
>    - Park the proposal for now
>    - Reach out to the author to check that they are OK
>
> Simon M: you are shepherding; what do you think?
>
> Simon
>
> On Mon, 2 Oct 2023 at 09:07, Adam Gundry <adam at well-typed.com> wrote:
>
>> I'm unconvinced by the current state of this proposal, for similar
>> reasons as Simon PJ gives on the proposal thread
>> (
>> https://github.com/ghc-proposals/ghc-proposals/pull/526#issuecomment-1740735610
>> ).
>>
>> If we want to accept this merely for reasons of consistency, I think the
>> simplest way forward would be to not introduce a new extension name, and
>> instead define the combination of MonadComprehensions + ApplicativeDo to
>> do what the proposal suggests.
>>
>> The author doesn't seem to be responsive on the thread. While I worry
>> this may be because of the time the proposal process has been taking, it
>> makes it difficult to gauge support for the various alternative
>> suggestions that have been made.
>>
>> Cheers,
>>
>> Adam
>>
>>
>> On 28/09/2023 08:12, Simon Marlow wrote:
>> > Dear committee,
>> >
>> > #526 proposes a new extension ApplicativeComprehensions (implying
>> > MonadComprehensions). It would provide the equivalent of the current
>> > ApplicativeDo desugaring for do-expressions to list comprehensions.
>> >
>> >   * Github thread <
>> https://github.com/ghc-proposals/ghc-proposals/pull/526>
>> >   * Rendered
>> >     <
>> https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst
>> >
>> >
>> > The extension itself is relatively uncontroversial, but there are some
>> > unresolved quirks in the original ApplicativeDo extension which made us
>> > uneasy about extending it. However, after various discussions I'm going
>> > to propose accepting this proposal in its current state.  Rationale:
>> >
>> >   * It doesn't make things worse, and the implementation isn't likely to
>> >     add significant complexity.
>> >   * It retains consistency between ApplicativeDo and
>> >     ApplicativeComprehensions (in contrast to the idea of making
>> >     ApplicativeComprehensions perform a simpler desugaring, which came
>> >     up during the discussion)
>> >   * A future proposal can add a simpler version of the desugaring for
>> >     both extensions later.
>> >
>> >
>> > Cheers
>> > Simon
>>
>> --
>> 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/20231003/fdda5793/attachment-0001.html>

From marlowsd at gmail.com  Wed Oct  4 08:17:51 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 4 Oct 2023 09:17:51 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
Message-ID: <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>

I don't think this breaking change (namely making -Werror=severe the
default) meets the bar for "compelling reason" according to GR2 of our
proposed policy, so I'm voting against. It's certainly not a bug or a
security hole. Maybe you could argue that it's a design flaw in the
language, but I'm not all that convinced. It's an unforced breaking change
in my opinion. If we add "makes it more difficult to shoot yourself in the
foot" a compelling enough reason to break GR1 then I think we've weakened
it significantly.

Here's another problem: if we make -Werror=severe the default, then any new
warning added to -Wsevere is a new breaking change, and we would have to
judge it to be compelling enough by GR2. If we don't make -Werror=severe
the default, then we're not restricted in what we can add to -Wsevere.
Probably -Wsevere would end up being more useful as a result.

Cheers
Simon


On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> Here's my summary:
>
>    - There is strong (universal, even) support for the `severe` category.
>    - There is pretty strong support for making severe warnings into
>    errors at some point.  As Matt puts it "this is not a question of GHC
>    breaking things, but rather *revealing* and providing early-diagnosis
>    for *already broken* things".
>    - But I think we are moving towards a policy of giving users time to
>    adapt via a deprecation cycle, whenever that is feasible.  And it is
>    feasible here.
>
> So my suggestion would be:
>
>    - When implemented, make `-Wwarn=severe` the default, but add to each
>    severe warning a deprecation-style message saying that it'll become an
>    error in the next iteration.
>    - In the next released, make `-Werror=severe` the default.
>    - Don't complicate matters by involving GHC2024.  That is another
>    conversation, and even if we wanted to include `-Werorr=severe` in GHC2024,
>    we would *still* want a deprecation cycle!
>
> Would that be acceptable?
>
> Simon
>
> On Fri, 29 Sept 2023 at 19:41, Adam Gundry <adam at well-typed.com> wrote:
>
>> Dear Committee,
>>
>> It seems we are somewhat split on the -Wsevere proposal, even assuming
>> it is introduced with a deprecation period (changing the warning text
>> and adding the group in advance). There is consensus that adding the
>> group by itself is fine, and potentially enabling -Werror=severe under
>> GHC2024, but enabling it by default for existing code is more
>> controversial.
>>
>> Ultimately this is a judgement call about the value of the proposal
>> versus the breakage it causes. I remain of the view that it is
>> worthwhile. This is not merely about more aggressively enforcing best
>> practice. Rather, it eliminates the risk of the following:
>>
>> * Suppose package A defines a type class, package B depends on package
>> A, and package C depends on package B.
>>
>> * Now package A extends the type class definition with a new method and
>> default methods. Everything still compiles; package B now issues a
>> -Wmissing-methods warning (but is not actively maintained, and the
>> author of package C is unlikely to look at warnings in all their
>> dependencies).
>>
>> * Users of package C have to try to debug an infinite loop.
>>
>> Given that this change avoids a significant issue, affected code has
>> been issuing warnings for many years, and impacted users can very easily
>> set -Wwarn=severe either at the package level or the project level, I
>> think is worth accepting the backwards compatibility cost and the fact
>> that some Haskell2010 code will no longer be accepted by default.
>>
>> Matt Parsons puts it well in the CLC thread, which is pretty clearly in
>> favour of this proposal overall
>> (
>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>> ):
>>
>>  > I think GHC should strive to make fewer breaking changes, and make
>> those changes as easy-to-adopt as possible. But this is not a question
>> of GHC breaking things, but rather revealing and providing
>> early-diagnosis for already broken things.
>>
>> Further opinions are welcome, of course.
>>
>> Adam
>>
>>
>> On 14/09/2023 09:32, Adam Gundry wrote:
>> > Dear Committee,
>> >
>> > Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods
>> > and -Wmissing-fields warnings into errors by default (retaining the
>> > option to downgrade them). I recommend we accept the proposal.
>> >
>> > Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
>> > Rendered:
>> >
>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>> >
>> > This is primarily motivated by the fact that when classes have default
>> > methods, missing methods can lead to runtime loops, which are generally
>> > difficult to debug. Since in practice not all users pay attention to
>> > warnings that do not inhibit compilation, it makes sense to identify a
>> > class of warnings that are sufficiently serious to require explicit
>> > action from the user to silence them.
>> >
>> > Since these warnings are currently not errors by default, library
>> > authors experimentally assessing the impact of changes may be lead to
>> > assume that introducing new methods/fields does not lead to breakage
>> > (because downstream code will still compile). The proposal thus makes
>> it
>> > more obvious that adding a new method or field is a breaking change.
>> >
>> > The proposal deliberately causes builds to fail by default for some
>> > libraries that currently emit warnings. Oleg has kindly performed
>> impact
>> > assessments to identify such libraries, and the breakage of a few
>> > packages seems worth the cost.
>> >
>> > It is easy to restore the warnings to their previous classification by
>> > passing an option at build time, e.g. using -Wno-error=missing-methods.
>> > Users can set such an option in cabal.project or stack.yaml to work
>> > around breakage that is not promptly fixed by the library author.
>> >
>> > This change does mean that GHC with -XHaskell98/2010 will by default
>> > reject some programs that are explicitly permitted by the
>> Haskell98/2010
>> > specification. I recommend we document this infelicity, but accept it,
>> > as much of the benefit of the proposal is that it applies by default.
>> >
>> > The proposal establishes the precedent that some warnings may be
>> treated
>> > as errors by default, and introduces a warning group -Wsevere to
>> > classify them. This seems conceptually useful and gives us the option
>> to
>> > extend the -Wsevere set in the future (e.g. as a final stage of
>> > deprecation before a feature is removed).
>> >
>> > Thoughts?
>> >
>> > Adam
>> >
>> >
>> > On 11/09/2023 20:25, Joachim Breitner wrote:
>> >> Dear Committee,
>> >>
>> >> based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a
>> >> warning group -Wsevere for on-by-defaults, error-by-default warnings,
>> >> and initially fill it with missing-methods and missing-fields.
>> >>
>> >>
>> >> https://github.com/ghc-proposals/ghc-proposals/pull/571
>> >>
>> >>
>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>> >>
>> >> I’d like to nominate Adam as the shepherd, who already reviewed it a
>> >> bit on Github.
>> >>
>> >> Please guide us to a conclusion as outlined in
>> >> https://github.com/ghc-proposals/ghc-proposals#committee-process
>> >>
>> >>
>> >> Cheers,
>> >> Joachim
>>
>>
>> --
>> 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/20231004/af2381a0/attachment.html>

From simon.peytonjones at gmail.com  Wed Oct  4 08:28:21 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 4 Oct 2023 09:28:21 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
Message-ID: <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>

I must say that I am strongly influenced by the fact that

   - Matt Parsons
   - Andrew Lelechenko (bodigrim)

are both not just in favour, but *strongly *in favour.  They must think of
the case as compelling, because they are both usually very careful about
unnecessary breakage.

if we make -Werror=severe the default, then any new warning added to
> -Wsevere is a new breaking change, and we would have to judge it to be
> compelling enough by GR2
>

Yes indeed.  But that's not a bug -- it's a feature.

To be clear I have no strongly held opinion myself.   Perhaps we should
canvas opinion among people using Haskell in production? We did so with CLC
but we could do so publicly.

Simon

On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com> wrote:

> I don't think this breaking change (namely making -Werror=severe the
> default) meets the bar for "compelling reason" according to GR2 of our
> proposed policy, so I'm voting against. It's certainly not a bug or a
> security hole. Maybe you could argue that it's a design flaw in the
> language, but I'm not all that convinced. It's an unforced breaking change
> in my opinion. If we add "makes it more difficult to shoot yourself in the
> foot" a compelling enough reason to break GR1 then I think we've weakened
> it significantly.
>
> Here's another problem: if we make -Werror=severe the default, then any
> new warning added to -Wsevere is a new breaking change, and we would have
> to judge it to be compelling enough by GR2. If we don't make -Werror=severe
> the default, then we're not restricted in what we can add to -Wsevere.
> Probably -Wsevere would end up being more useful as a result.
>
> Cheers
> Simon
>
>
> On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Here's my summary:
>>
>>    - There is strong (universal, even) support for the `severe` category.
>>    - There is pretty strong support for making severe warnings into
>>    errors at some point.  As Matt puts it "this is not a question of GHC
>>    breaking things, but rather *revealing* and providing early-diagnosis
>>    for *already broken* things".
>>    - But I think we are moving towards a policy of giving users time to
>>    adapt via a deprecation cycle, whenever that is feasible.  And it is
>>    feasible here.
>>
>> So my suggestion would be:
>>
>>    - When implemented, make `-Wwarn=severe` the default, but add to each
>>    severe warning a deprecation-style message saying that it'll become an
>>    error in the next iteration.
>>    - In the next released, make `-Werror=severe` the default.
>>    - Don't complicate matters by involving GHC2024.  That is another
>>    conversation, and even if we wanted to include `-Werorr=severe` in GHC2024,
>>    we would *still* want a deprecation cycle!
>>
>> Would that be acceptable?
>>
>> Simon
>>
>> On Fri, 29 Sept 2023 at 19:41, Adam Gundry <adam at well-typed.com> wrote:
>>
>>> Dear Committee,
>>>
>>> It seems we are somewhat split on the -Wsevere proposal, even assuming
>>> it is introduced with a deprecation period (changing the warning text
>>> and adding the group in advance). There is consensus that adding the
>>> group by itself is fine, and potentially enabling -Werror=severe under
>>> GHC2024, but enabling it by default for existing code is more
>>> controversial.
>>>
>>> Ultimately this is a judgement call about the value of the proposal
>>> versus the breakage it causes. I remain of the view that it is
>>> worthwhile. This is not merely about more aggressively enforcing best
>>> practice. Rather, it eliminates the risk of the following:
>>>
>>> * Suppose package A defines a type class, package B depends on package
>>> A, and package C depends on package B.
>>>
>>> * Now package A extends the type class definition with a new method and
>>> default methods. Everything still compiles; package B now issues a
>>> -Wmissing-methods warning (but is not actively maintained, and the
>>> author of package C is unlikely to look at warnings in all their
>>> dependencies).
>>>
>>> * Users of package C have to try to debug an infinite loop.
>>>
>>> Given that this change avoids a significant issue, affected code has
>>> been issuing warnings for many years, and impacted users can very easily
>>> set -Wwarn=severe either at the package level or the project level, I
>>> think is worth accepting the backwards compatibility cost and the fact
>>> that some Haskell2010 code will no longer be accepted by default.
>>>
>>> Matt Parsons puts it well in the CLC thread, which is pretty clearly in
>>> favour of this proposal overall
>>> (
>>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>>> ):
>>>
>>>  > I think GHC should strive to make fewer breaking changes, and make
>>> those changes as easy-to-adopt as possible. But this is not a question
>>> of GHC breaking things, but rather revealing and providing
>>> early-diagnosis for already broken things.
>>>
>>> Further opinions are welcome, of course.
>>>
>>> Adam
>>>
>>>
>>> On 14/09/2023 09:32, Adam Gundry wrote:
>>> > Dear Committee,
>>> >
>>> > Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods
>>> > and -Wmissing-fields warnings into errors by default (retaining the
>>> > option to downgrade them). I recommend we accept the proposal.
>>> >
>>> > Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
>>> > Rendered:
>>> >
>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>> >
>>> > This is primarily motivated by the fact that when classes have default
>>> > methods, missing methods can lead to runtime loops, which are
>>> generally
>>> > difficult to debug. Since in practice not all users pay attention to
>>> > warnings that do not inhibit compilation, it makes sense to identify a
>>> > class of warnings that are sufficiently serious to require explicit
>>> > action from the user to silence them.
>>> >
>>> > Since these warnings are currently not errors by default, library
>>> > authors experimentally assessing the impact of changes may be lead to
>>> > assume that introducing new methods/fields does not lead to breakage
>>> > (because downstream code will still compile). The proposal thus makes
>>> it
>>> > more obvious that adding a new method or field is a breaking change.
>>> >
>>> > The proposal deliberately causes builds to fail by default for some
>>> > libraries that currently emit warnings. Oleg has kindly performed
>>> impact
>>> > assessments to identify such libraries, and the breakage of a few
>>> > packages seems worth the cost.
>>> >
>>> > It is easy to restore the warnings to their previous classification by
>>> > passing an option at build time, e.g. using
>>> -Wno-error=missing-methods.
>>> > Users can set such an option in cabal.project or stack.yaml to work
>>> > around breakage that is not promptly fixed by the library author.
>>> >
>>> > This change does mean that GHC with -XHaskell98/2010 will by default
>>> > reject some programs that are explicitly permitted by the
>>> Haskell98/2010
>>> > specification. I recommend we document this infelicity, but accept it,
>>> > as much of the benefit of the proposal is that it applies by default.
>>> >
>>> > The proposal establishes the precedent that some warnings may be
>>> treated
>>> > as errors by default, and introduces a warning group -Wsevere to
>>> > classify them. This seems conceptually useful and gives us the option
>>> to
>>> > extend the -Wsevere set in the future (e.g. as a final stage of
>>> > deprecation before a feature is removed).
>>> >
>>> > Thoughts?
>>> >
>>> > Adam
>>> >
>>> >
>>> > On 11/09/2023 20:25, Joachim Breitner wrote:
>>> >> Dear Committee,
>>> >>
>>> >> based on suggestions by Oleg Grenrus, I wrote a proposal to introduce
>>> a
>>> >> warning group -Wsevere for on-by-defaults, error-by-default warnings,
>>> >> and initially fill it with missing-methods and missing-fields.
>>> >>
>>> >>
>>> >> https://github.com/ghc-proposals/ghc-proposals/pull/571
>>> >>
>>> >>
>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>> >>
>>> >> I’d like to nominate Adam as the shepherd, who already reviewed it a
>>> >> bit on Github.
>>> >>
>>> >> Please guide us to a conclusion as outlined in
>>> >> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>> >>
>>> >>
>>> >> Cheers,
>>> >> Joachim
>>>
>>>
>>> --
>>> 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/20231004/c2248abd/attachment-0001.html>

From moritz.angermann at gmail.com  Wed Oct  4 08:38:26 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 4 Oct 2023 16:38:26 +0800
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
Message-ID: <CAKfdd-yEHpH5r4Ln4zaCBUJ80p3QUtgt6p4xU_Xxp1SgFQF1iQ@mail.gmail.com>

Let me pose a slightly loaded question on this:

if we had -Werror=severe by default, and severe being empty, as well as
adding notes to warnings we intent to promote to
severe (This warning will be part of severe in GHC X.Y.Z and therefore
become an error. See https://...), isn't that effectively
canvasing a wider opinion among people using Haskell in production?

Cheers,
 Moritz

On Wed, 4 Oct 2023 at 16:28, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> I must say that I am strongly influenced by the fact that
>
>    - Matt Parsons
>    - Andrew Lelechenko (bodigrim)
>
> are both not just in favour, but *strongly *in favour.  They must think
> of the case as compelling, because they are both usually very careful about
> unnecessary breakage.
>
> if we make -Werror=severe the default, then any new warning added to
>> -Wsevere is a new breaking change, and we would have to judge it to be
>> compelling enough by GR2
>>
>
> Yes indeed.  But that's not a bug -- it's a feature.
>
> To be clear I have no strongly held opinion myself.   Perhaps we should
> canvas opinion among people using Haskell in production? We did so with CLC
> but we could do so publicly.
>
> Simon
>
> On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> I don't think this breaking change (namely making -Werror=severe the
>> default) meets the bar for "compelling reason" according to GR2 of our
>> proposed policy, so I'm voting against. It's certainly not a bug or a
>> security hole. Maybe you could argue that it's a design flaw in the
>> language, but I'm not all that convinced. It's an unforced breaking change
>> in my opinion. If we add "makes it more difficult to shoot yourself in the
>> foot" a compelling enough reason to break GR1 then I think we've weakened
>> it significantly.
>>
>> Here's another problem: if we make -Werror=severe the default, then any
>> new warning added to -Wsevere is a new breaking change, and we would have
>> to judge it to be compelling enough by GR2. If we don't make -Werror=severe
>> the default, then we're not restricted in what we can add to -Wsevere.
>> Probably -Wsevere would end up being more useful as a result.
>>
>> Cheers
>> Simon
>>
>>
>> On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Here's my summary:
>>>
>>>    - There is strong (universal, even) support for the `severe`
>>>    category.
>>>    - There is pretty strong support for making severe warnings into
>>>    errors at some point.  As Matt puts it "this is not a question of GHC
>>>    breaking things, but rather *revealing* and providing
>>>    early-diagnosis for *already broken* things".
>>>    - But I think we are moving towards a policy of giving users time to
>>>    adapt via a deprecation cycle, whenever that is feasible.  And it is
>>>    feasible here.
>>>
>>> So my suggestion would be:
>>>
>>>    - When implemented, make `-Wwarn=severe` the default, but add to
>>>    each severe warning a deprecation-style message saying that it'll become an
>>>    error in the next iteration.
>>>    - In the next released, make `-Werror=severe` the default.
>>>    - Don't complicate matters by involving GHC2024.  That is another
>>>    conversation, and even if we wanted to include `-Werorr=severe` in GHC2024,
>>>    we would *still* want a deprecation cycle!
>>>
>>> Would that be acceptable?
>>>
>>> Simon
>>>
>>> On Fri, 29 Sept 2023 at 19:41, Adam Gundry <adam at well-typed.com> wrote:
>>>
>>>> Dear Committee,
>>>>
>>>> It seems we are somewhat split on the -Wsevere proposal, even assuming
>>>> it is introduced with a deprecation period (changing the warning text
>>>> and adding the group in advance). There is consensus that adding the
>>>> group by itself is fine, and potentially enabling -Werror=severe under
>>>> GHC2024, but enabling it by default for existing code is more
>>>> controversial.
>>>>
>>>> Ultimately this is a judgement call about the value of the proposal
>>>> versus the breakage it causes. I remain of the view that it is
>>>> worthwhile. This is not merely about more aggressively enforcing best
>>>> practice. Rather, it eliminates the risk of the following:
>>>>
>>>> * Suppose package A defines a type class, package B depends on package
>>>> A, and package C depends on package B.
>>>>
>>>> * Now package A extends the type class definition with a new method and
>>>> default methods. Everything still compiles; package B now issues a
>>>> -Wmissing-methods warning (but is not actively maintained, and the
>>>> author of package C is unlikely to look at warnings in all their
>>>> dependencies).
>>>>
>>>> * Users of package C have to try to debug an infinite loop.
>>>>
>>>> Given that this change avoids a significant issue, affected code has
>>>> been issuing warnings for many years, and impacted users can very
>>>> easily
>>>> set -Wwarn=severe either at the package level or the project level, I
>>>> think is worth accepting the backwards compatibility cost and the fact
>>>> that some Haskell2010 code will no longer be accepted by default.
>>>>
>>>> Matt Parsons puts it well in the CLC thread, which is pretty clearly in
>>>> favour of this proposal overall
>>>> (
>>>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>>>> ):
>>>>
>>>>  > I think GHC should strive to make fewer breaking changes, and make
>>>> those changes as easy-to-adopt as possible. But this is not a question
>>>> of GHC breaking things, but rather revealing and providing
>>>> early-diagnosis for already broken things.
>>>>
>>>> Further opinions are welcome, of course.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On 14/09/2023 09:32, Adam Gundry wrote:
>>>> > Dear Committee,
>>>> >
>>>> > Joachim, along with Oleg Grenrus, proposes to change
>>>> -Wmissing-methods
>>>> > and -Wmissing-fields warnings into errors by default (retaining the
>>>> > option to downgrade them). I recommend we accept the proposal.
>>>> >
>>>> > Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>> > Rendered:
>>>> >
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>> >
>>>> > This is primarily motivated by the fact that when classes have
>>>> default
>>>> > methods, missing methods can lead to runtime loops, which are
>>>> generally
>>>> > difficult to debug. Since in practice not all users pay attention to
>>>> > warnings that do not inhibit compilation, it makes sense to identify
>>>> a
>>>> > class of warnings that are sufficiently serious to require explicit
>>>> > action from the user to silence them.
>>>> >
>>>> > Since these warnings are currently not errors by default, library
>>>> > authors experimentally assessing the impact of changes may be lead to
>>>> > assume that introducing new methods/fields does not lead to breakage
>>>> > (because downstream code will still compile). The proposal thus makes
>>>> it
>>>> > more obvious that adding a new method or field is a breaking change.
>>>> >
>>>> > The proposal deliberately causes builds to fail by default for some
>>>> > libraries that currently emit warnings. Oleg has kindly performed
>>>> impact
>>>> > assessments to identify such libraries, and the breakage of a few
>>>> > packages seems worth the cost.
>>>> >
>>>> > It is easy to restore the warnings to their previous classification
>>>> by
>>>> > passing an option at build time, e.g. using
>>>> -Wno-error=missing-methods.
>>>> > Users can set such an option in cabal.project or stack.yaml to work
>>>> > around breakage that is not promptly fixed by the library author.
>>>> >
>>>> > This change does mean that GHC with -XHaskell98/2010 will by default
>>>> > reject some programs that are explicitly permitted by the
>>>> Haskell98/2010
>>>> > specification. I recommend we document this infelicity, but accept
>>>> it,
>>>> > as much of the benefit of the proposal is that it applies by default.
>>>> >
>>>> > The proposal establishes the precedent that some warnings may be
>>>> treated
>>>> > as errors by default, and introduces a warning group -Wsevere to
>>>> > classify them. This seems conceptually useful and gives us the option
>>>> to
>>>> > extend the -Wsevere set in the future (e.g. as a final stage of
>>>> > deprecation before a feature is removed).
>>>> >
>>>> > Thoughts?
>>>> >
>>>> > Adam
>>>> >
>>>> >
>>>> > On 11/09/2023 20:25, Joachim Breitner wrote:
>>>> >> Dear Committee,
>>>> >>
>>>> >> based on suggestions by Oleg Grenrus, I wrote a proposal to
>>>> introduce a
>>>> >> warning group -Wsevere for on-by-defaults, error-by-default warnings,
>>>> >> and initially fill it with missing-methods and missing-fields.
>>>> >>
>>>> >>
>>>> >> https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>> >>
>>>> >>
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>> >>
>>>> >> I’d like to nominate Adam as the shepherd, who already reviewed it a
>>>> >> bit on Github.
>>>> >>
>>>> >> Please guide us to a conclusion as outlined in
>>>> >> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>> >>
>>>> >>
>>>> >> Cheers,
>>>> >> Joachim
>>>>
>>>>
>>>> --
>>>> 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
>>>
>> _______________________________________________
> 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/20231004/b05369bc/attachment.html>

From simon.peytonjones at gmail.com  Wed Oct  4 08:52:56 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 4 Oct 2023 09:52:56 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CAKfdd-yEHpH5r4Ln4zaCBUJ80p3QUtgt6p4xU_Xxp1SgFQF1iQ@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CAKfdd-yEHpH5r4Ln4zaCBUJ80p3QUtgt6p4xU_Xxp1SgFQF1iQ@mail.gmail.com>
Message-ID: <CAJKmMz-H78tj36c0ozRz4_92ONxXA-fCuXe=VWehPevmfyVXJA@mail.gmail.com>

>
> isn't that effectively canvasing a wider opinion among people
> using Haskell in production?
>

Not really?  We would not get any feedback, would we?  Or perhaps we might
hear from a couple of folk who don't like the change, but we'd hear nothing
from a (I'm guessing) silent majority who thought "great".

S

On Wed, 4 Oct 2023 at 09:38, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Let me pose a slightly loaded question on this:
>
> if we had -Werror=severe by default, and severe being empty, as well as
> adding notes to warnings we intent to promote to
> severe (This warning will be part of severe in GHC X.Y.Z and therefore
> become an error. See https://...), isn't that effectively
> canvasing a wider opinion among people using Haskell in production?
>
> Cheers,
>  Moritz
>
> On Wed, 4 Oct 2023 at 16:28, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I must say that I am strongly influenced by the fact that
>>
>>    - Matt Parsons
>>    - Andrew Lelechenko (bodigrim)
>>
>> are both not just in favour, but *strongly *in favour.  They must think
>> of the case as compelling, because they are both usually very careful about
>> unnecessary breakage.
>>
>> if we make -Werror=severe the default, then any new warning added to
>>> -Wsevere is a new breaking change, and we would have to judge it to be
>>> compelling enough by GR2
>>>
>>
>> Yes indeed.  But that's not a bug -- it's a feature.
>>
>> To be clear I have no strongly held opinion myself.   Perhaps we should
>> canvas opinion among people using Haskell in production? We did so with CLC
>> but we could do so publicly.
>>
>> Simon
>>
>> On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com> wrote:
>>
>>> I don't think this breaking change (namely making -Werror=severe the
>>> default) meets the bar for "compelling reason" according to GR2 of our
>>> proposed policy, so I'm voting against. It's certainly not a bug or a
>>> security hole. Maybe you could argue that it's a design flaw in the
>>> language, but I'm not all that convinced. It's an unforced breaking change
>>> in my opinion. If we add "makes it more difficult to shoot yourself in the
>>> foot" a compelling enough reason to break GR1 then I think we've weakened
>>> it significantly.
>>>
>>> Here's another problem: if we make -Werror=severe the default, then any
>>> new warning added to -Wsevere is a new breaking change, and we would have
>>> to judge it to be compelling enough by GR2. If we don't make -Werror=severe
>>> the default, then we're not restricted in what we can add to -Wsevere.
>>> Probably -Wsevere would end up being more useful as a result.
>>>
>>> Cheers
>>> Simon
>>>
>>>
>>> On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> Here's my summary:
>>>>
>>>>    - There is strong (universal, even) support for the `severe`
>>>>    category.
>>>>    - There is pretty strong support for making severe warnings into
>>>>    errors at some point.  As Matt puts it "this is not a question of GHC
>>>>    breaking things, but rather *revealing* and providing
>>>>    early-diagnosis for *already broken* things".
>>>>    - But I think we are moving towards a policy of giving users time
>>>>    to adapt via a deprecation cycle, whenever that is feasible.  And it is
>>>>    feasible here.
>>>>
>>>> So my suggestion would be:
>>>>
>>>>    - When implemented, make `-Wwarn=severe` the default, but add to
>>>>    each severe warning a deprecation-style message saying that it'll become an
>>>>    error in the next iteration.
>>>>    - In the next released, make `-Werror=severe` the default.
>>>>    - Don't complicate matters by involving GHC2024.  That is another
>>>>    conversation, and even if we wanted to include `-Werorr=severe` in GHC2024,
>>>>    we would *still* want a deprecation cycle!
>>>>
>>>> Would that be acceptable?
>>>>
>>>> Simon
>>>>
>>>> On Fri, 29 Sept 2023 at 19:41, Adam Gundry <adam at well-typed.com> wrote:
>>>>
>>>>> Dear Committee,
>>>>>
>>>>> It seems we are somewhat split on the -Wsevere proposal, even assuming
>>>>> it is introduced with a deprecation period (changing the warning text
>>>>> and adding the group in advance). There is consensus that adding the
>>>>> group by itself is fine, and potentially enabling -Werror=severe under
>>>>> GHC2024, but enabling it by default for existing code is more
>>>>> controversial.
>>>>>
>>>>> Ultimately this is a judgement call about the value of the proposal
>>>>> versus the breakage it causes. I remain of the view that it is
>>>>> worthwhile. This is not merely about more aggressively enforcing best
>>>>> practice. Rather, it eliminates the risk of the following:
>>>>>
>>>>> * Suppose package A defines a type class, package B depends on package
>>>>> A, and package C depends on package B.
>>>>>
>>>>> * Now package A extends the type class definition with a new method
>>>>> and
>>>>> default methods. Everything still compiles; package B now issues a
>>>>> -Wmissing-methods warning (but is not actively maintained, and the
>>>>> author of package C is unlikely to look at warnings in all their
>>>>> dependencies).
>>>>>
>>>>> * Users of package C have to try to debug an infinite loop.
>>>>>
>>>>> Given that this change avoids a significant issue, affected code has
>>>>> been issuing warnings for many years, and impacted users can very
>>>>> easily
>>>>> set -Wwarn=severe either at the package level or the project level, I
>>>>> think is worth accepting the backwards compatibility cost and the fact
>>>>> that some Haskell2010 code will no longer be accepted by default.
>>>>>
>>>>> Matt Parsons puts it well in the CLC thread, which is pretty clearly
>>>>> in
>>>>> favour of this proposal overall
>>>>> (
>>>>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>>>>> ):
>>>>>
>>>>>  > I think GHC should strive to make fewer breaking changes, and make
>>>>> those changes as easy-to-adopt as possible. But this is not a question
>>>>> of GHC breaking things, but rather revealing and providing
>>>>> early-diagnosis for already broken things.
>>>>>
>>>>> Further opinions are welcome, of course.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On 14/09/2023 09:32, Adam Gundry wrote:
>>>>> > Dear Committee,
>>>>> >
>>>>> > Joachim, along with Oleg Grenrus, proposes to change
>>>>> -Wmissing-methods
>>>>> > and -Wmissing-fields warnings into errors by default (retaining the
>>>>> > option to downgrade them). I recommend we accept the proposal.
>>>>> >
>>>>> > Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>>> > Rendered:
>>>>> >
>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>>> >
>>>>> > This is primarily motivated by the fact that when classes have
>>>>> default
>>>>> > methods, missing methods can lead to runtime loops, which are
>>>>> generally
>>>>> > difficult to debug. Since in practice not all users pay attention to
>>>>> > warnings that do not inhibit compilation, it makes sense to identify
>>>>> a
>>>>> > class of warnings that are sufficiently serious to require explicit
>>>>> > action from the user to silence them.
>>>>> >
>>>>> > Since these warnings are currently not errors by default, library
>>>>> > authors experimentally assessing the impact of changes may be lead
>>>>> to
>>>>> > assume that introducing new methods/fields does not lead to breakage
>>>>> > (because downstream code will still compile). The proposal thus
>>>>> makes it
>>>>> > more obvious that adding a new method or field is a breaking change.
>>>>> >
>>>>> > The proposal deliberately causes builds to fail by default for some
>>>>> > libraries that currently emit warnings. Oleg has kindly performed
>>>>> impact
>>>>> > assessments to identify such libraries, and the breakage of a few
>>>>> > packages seems worth the cost.
>>>>> >
>>>>> > It is easy to restore the warnings to their previous classification
>>>>> by
>>>>> > passing an option at build time, e.g. using
>>>>> -Wno-error=missing-methods.
>>>>> > Users can set such an option in cabal.project or stack.yaml to work
>>>>> > around breakage that is not promptly fixed by the library author.
>>>>> >
>>>>> > This change does mean that GHC with -XHaskell98/2010 will by default
>>>>> > reject some programs that are explicitly permitted by the
>>>>> Haskell98/2010
>>>>> > specification. I recommend we document this infelicity, but accept
>>>>> it,
>>>>> > as much of the benefit of the proposal is that it applies by default.
>>>>> >
>>>>> > The proposal establishes the precedent that some warnings may be
>>>>> treated
>>>>> > as errors by default, and introduces a warning group -Wsevere to
>>>>> > classify them. This seems conceptually useful and gives us the
>>>>> option to
>>>>> > extend the -Wsevere set in the future (e.g. as a final stage of
>>>>> > deprecation before a feature is removed).
>>>>> >
>>>>> > Thoughts?
>>>>> >
>>>>> > Adam
>>>>> >
>>>>> >
>>>>> > On 11/09/2023 20:25, Joachim Breitner wrote:
>>>>> >> Dear Committee,
>>>>> >>
>>>>> >> based on suggestions by Oleg Grenrus, I wrote a proposal to
>>>>> introduce a
>>>>> >> warning group -Wsevere for on-by-defaults, error-by-default
>>>>> warnings,
>>>>> >> and initially fill it with missing-methods and missing-fields.
>>>>> >>
>>>>> >>
>>>>> >> https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>>> >>
>>>>> >>
>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>>> >>
>>>>> >> I’d like to nominate Adam as the shepherd, who already reviewed it a
>>>>> >> bit on Github.
>>>>> >>
>>>>> >> Please guide us to a conclusion as outlined in
>>>>> >> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>> >>
>>>>> >>
>>>>> >> Cheers,
>>>>> >> Joachim
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>
>>> _______________________________________________
>> 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/20231004/89dc2fe9/attachment-0001.html>

From moritz.angermann at gmail.com  Wed Oct  4 09:28:25 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 4 Oct 2023 17:28:25 +0800
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CAJKmMz-H78tj36c0ozRz4_92ONxXA-fCuXe=VWehPevmfyVXJA@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CAKfdd-yEHpH5r4Ln4zaCBUJ80p3QUtgt6p4xU_Xxp1SgFQF1iQ@mail.gmail.com>
 <CAJKmMz-H78tj36c0ozRz4_92ONxXA-fCuXe=VWehPevmfyVXJA@mail.gmail.com>
Message-ID: <CAKfdd-y6jsX3ML5dMv0S5gzLP=n=krGRVr=ZczEXHejtDr-71g@mail.gmail.com>

I guess we'll always have to deal with some form of selection bias? If we
put it into the warning, I agree that the selection will mostly
be people who run into it and are opposed to it. If we put it onto
discourse we'll end up with people who frequent discourse, but that
does need to correlate with people working with haskell. If we put it onto
reddit or the cafe or elsewhere we always end up with that
selection bias. I could ask at $work, but that would also mean I get
selection bias only from those at $work, and I'm not certain it's
a representative sample of people working with haskell?

We could put it into a warning, pointing to a github issue (so people can
provide feedback), and concurrently publish this with the
release notes? Would explicitly asking "please provide your feedback" in
the warning motivate the potential silent majority? Without
hard numbers it would even be hard to judge how large the (and if) those
that find their way to the issue then would even constitute
a minority?

Would 10, 50, 100 people raising concerns mean anything? How many people
working with haskell are there?

I'm happy to run a poll at $work, and report the results back. Something
along the lines of:

> Regarding ghc-proposals#571, which introduces a new warning category:
> severe

- Would you prefer this to be -Werror=severe by default? Thus turning
> existing warnings into hard errors with a breaking change?

- Have a grace period where the warnings that will turn into errors clearly
> state this in their warning? Thus giving a grace period into -Werror=severe
> by default.

- We should not have warnings be errors by default that's what the -Werror
> opt-in is for? There should be no -Werror=severe ever.

?

On Wed, 4 Oct 2023 at 16:53, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> isn't that effectively canvasing a wider opinion among people
>> using Haskell in production?
>>
>
> Not really?  We would not get any feedback, would we?  Or perhaps we might
> hear from a couple of folk who don't like the change, but we'd hear nothing
> from a (I'm guessing) silent majority who thought "great".
>
> S
>
> On Wed, 4 Oct 2023 at 09:38, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> Let me pose a slightly loaded question on this:
>>
>> if we had -Werror=severe by default, and severe being empty, as well as
>> adding notes to warnings we intent to promote to
>> severe (This warning will be part of severe in GHC X.Y.Z and therefore
>> become an error. See https://...), isn't that effectively
>> canvasing a wider opinion among people using Haskell in production?
>>
>> Cheers,
>>  Moritz
>>
>> On Wed, 4 Oct 2023 at 16:28, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> I must say that I am strongly influenced by the fact that
>>>
>>>    - Matt Parsons
>>>    - Andrew Lelechenko (bodigrim)
>>>
>>> are both not just in favour, but *strongly *in favour.  They must think
>>> of the case as compelling, because they are both usually very careful about
>>> unnecessary breakage.
>>>
>>> if we make -Werror=severe the default, then any new warning added to
>>>> -Wsevere is a new breaking change, and we would have to judge it to be
>>>> compelling enough by GR2
>>>>
>>>
>>> Yes indeed.  But that's not a bug -- it's a feature.
>>>
>>> To be clear I have no strongly held opinion myself.   Perhaps we should
>>> canvas opinion among people using Haskell in production? We did so with CLC
>>> but we could do so publicly.
>>>
>>> Simon
>>>
>>> On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com> wrote:
>>>
>>>> I don't think this breaking change (namely making -Werror=severe the
>>>> default) meets the bar for "compelling reason" according to GR2 of our
>>>> proposed policy, so I'm voting against. It's certainly not a bug or a
>>>> security hole. Maybe you could argue that it's a design flaw in the
>>>> language, but I'm not all that convinced. It's an unforced breaking change
>>>> in my opinion. If we add "makes it more difficult to shoot yourself in the
>>>> foot" a compelling enough reason to break GR1 then I think we've weakened
>>>> it significantly.
>>>>
>>>> Here's another problem: if we make -Werror=severe the default, then any
>>>> new warning added to -Wsevere is a new breaking change, and we would have
>>>> to judge it to be compelling enough by GR2. If we don't make -Werror=severe
>>>> the default, then we're not restricted in what we can add to -Wsevere.
>>>> Probably -Wsevere would end up being more useful as a result.
>>>>
>>>> Cheers
>>>> Simon
>>>>
>>>>
>>>> On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones <
>>>> simon.peytonjones at gmail.com> wrote:
>>>>
>>>>> Here's my summary:
>>>>>
>>>>>    - There is strong (universal, even) support for the `severe`
>>>>>    category.
>>>>>    - There is pretty strong support for making severe warnings into
>>>>>    errors at some point.  As Matt puts it "this is not a question of GHC
>>>>>    breaking things, but rather *revealing* and providing
>>>>>    early-diagnosis for *already broken* things".
>>>>>    - But I think we are moving towards a policy of giving users time
>>>>>    to adapt via a deprecation cycle, whenever that is feasible.  And it is
>>>>>    feasible here.
>>>>>
>>>>> So my suggestion would be:
>>>>>
>>>>>    - When implemented, make `-Wwarn=severe` the default, but add to
>>>>>    each severe warning a deprecation-style message saying that it'll become an
>>>>>    error in the next iteration.
>>>>>    - In the next released, make `-Werror=severe` the default.
>>>>>    - Don't complicate matters by involving GHC2024.  That is another
>>>>>    conversation, and even if we wanted to include `-Werorr=severe` in GHC2024,
>>>>>    we would *still* want a deprecation cycle!
>>>>>
>>>>> Would that be acceptable?
>>>>>
>>>>> Simon
>>>>>
>>>>> On Fri, 29 Sept 2023 at 19:41, Adam Gundry <adam at well-typed.com>
>>>>> wrote:
>>>>>
>>>>>> Dear Committee,
>>>>>>
>>>>>> It seems we are somewhat split on the -Wsevere proposal, even
>>>>>> assuming
>>>>>> it is introduced with a deprecation period (changing the warning text
>>>>>> and adding the group in advance). There is consensus that adding the
>>>>>> group by itself is fine, and potentially enabling -Werror=severe
>>>>>> under
>>>>>> GHC2024, but enabling it by default for existing code is more
>>>>>> controversial.
>>>>>>
>>>>>> Ultimately this is a judgement call about the value of the proposal
>>>>>> versus the breakage it causes. I remain of the view that it is
>>>>>> worthwhile. This is not merely about more aggressively enforcing best
>>>>>> practice. Rather, it eliminates the risk of the following:
>>>>>>
>>>>>> * Suppose package A defines a type class, package B depends on
>>>>>> package
>>>>>> A, and package C depends on package B.
>>>>>>
>>>>>> * Now package A extends the type class definition with a new method
>>>>>> and
>>>>>> default methods. Everything still compiles; package B now issues a
>>>>>> -Wmissing-methods warning (but is not actively maintained, and the
>>>>>> author of package C is unlikely to look at warnings in all their
>>>>>> dependencies).
>>>>>>
>>>>>> * Users of package C have to try to debug an infinite loop.
>>>>>>
>>>>>> Given that this change avoids a significant issue, affected code has
>>>>>> been issuing warnings for many years, and impacted users can very
>>>>>> easily
>>>>>> set -Wwarn=severe either at the package level or the project level, I
>>>>>> think is worth accepting the backwards compatibility cost and the
>>>>>> fact
>>>>>> that some Haskell2010 code will no longer be accepted by default.
>>>>>>
>>>>>> Matt Parsons puts it well in the CLC thread, which is pretty clearly
>>>>>> in
>>>>>> favour of this proposal overall
>>>>>> (
>>>>>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>>>>>> ):
>>>>>>
>>>>>>  > I think GHC should strive to make fewer breaking changes, and make
>>>>>> those changes as easy-to-adopt as possible. But this is not a
>>>>>> question
>>>>>> of GHC breaking things, but rather revealing and providing
>>>>>> early-diagnosis for already broken things.
>>>>>>
>>>>>> Further opinions are welcome, of course.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>> On 14/09/2023 09:32, Adam Gundry wrote:
>>>>>> > Dear Committee,
>>>>>> >
>>>>>> > Joachim, along with Oleg Grenrus, proposes to change
>>>>>> -Wmissing-methods
>>>>>> > and -Wmissing-fields warnings into errors by default (retaining the
>>>>>> > option to downgrade them). I recommend we accept the proposal.
>>>>>> >
>>>>>> > Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>>>> > Rendered:
>>>>>> >
>>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>>>> >
>>>>>> > This is primarily motivated by the fact that when classes have
>>>>>> default
>>>>>> > methods, missing methods can lead to runtime loops, which are
>>>>>> generally
>>>>>> > difficult to debug. Since in practice not all users pay attention
>>>>>> to
>>>>>> > warnings that do not inhibit compilation, it makes sense to
>>>>>> identify a
>>>>>> > class of warnings that are sufficiently serious to require explicit
>>>>>> > action from the user to silence them.
>>>>>> >
>>>>>> > Since these warnings are currently not errors by default, library
>>>>>> > authors experimentally assessing the impact of changes may be lead
>>>>>> to
>>>>>> > assume that introducing new methods/fields does not lead to
>>>>>> breakage
>>>>>> > (because downstream code will still compile). The proposal thus
>>>>>> makes it
>>>>>> > more obvious that adding a new method or field is a breaking change.
>>>>>> >
>>>>>> > The proposal deliberately causes builds to fail by default for some
>>>>>> > libraries that currently emit warnings. Oleg has kindly performed
>>>>>> impact
>>>>>> > assessments to identify such libraries, and the breakage of a few
>>>>>> > packages seems worth the cost.
>>>>>> >
>>>>>> > It is easy to restore the warnings to their previous classification
>>>>>> by
>>>>>> > passing an option at build time, e.g. using
>>>>>> -Wno-error=missing-methods.
>>>>>> > Users can set such an option in cabal.project or stack.yaml to work
>>>>>> > around breakage that is not promptly fixed by the library author.
>>>>>> >
>>>>>> > This change does mean that GHC with -XHaskell98/2010 will by
>>>>>> default
>>>>>> > reject some programs that are explicitly permitted by the
>>>>>> Haskell98/2010
>>>>>> > specification. I recommend we document this infelicity, but accept
>>>>>> it,
>>>>>> > as much of the benefit of the proposal is that it applies by
>>>>>> default.
>>>>>> >
>>>>>> > The proposal establishes the precedent that some warnings may be
>>>>>> treated
>>>>>> > as errors by default, and introduces a warning group -Wsevere to
>>>>>> > classify them. This seems conceptually useful and gives us the
>>>>>> option to
>>>>>> > extend the -Wsevere set in the future (e.g. as a final stage of
>>>>>> > deprecation before a feature is removed).
>>>>>> >
>>>>>> > Thoughts?
>>>>>> >
>>>>>> > Adam
>>>>>> >
>>>>>> >
>>>>>> > On 11/09/2023 20:25, Joachim Breitner wrote:
>>>>>> >> Dear Committee,
>>>>>> >>
>>>>>> >> based on suggestions by Oleg Grenrus, I wrote a proposal to
>>>>>> introduce a
>>>>>> >> warning group -Wsevere for on-by-defaults, error-by-default
>>>>>> warnings,
>>>>>> >> and initially fill it with missing-methods and missing-fields.
>>>>>> >>
>>>>>> >>
>>>>>> >> https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>>>> >>
>>>>>> >>
>>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>>>> >>
>>>>>> >> I’d like to nominate Adam as the shepherd, who already reviewed it
>>>>>> a
>>>>>> >> bit on Github.
>>>>>> >>
>>>>>> >> Please guide us to a conclusion as outlined in
>>>>>> >> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>>> >>
>>>>>> >>
>>>>>> >> Cheers,
>>>>>> >> Joachim
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>> _______________________________________________
>>> 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/20231004/8ccb4eb4/attachment-0001.html>

From marlowsd at gmail.com  Wed Oct  4 21:04:20 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 4 Oct 2023 22:04:20 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
Message-ID: <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>

My concrete suggestion is we EITHER

   - Enable -Werror=severe in future GHC20xx versions only, or
   - Enable it by default and in future GHC20xx versions, but not in
   GHC2021, Haskell2010, or Haskell98

both of these would satisfy the stability policy without having to make an
argument about the breaking change being compelling enough. We could still
add some text to the warning to inform people about the upcoming change.

Cheers
Simon


On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> I must say that I am strongly influenced by the fact that
>
>    - Matt Parsons
>    - Andrew Lelechenko (bodigrim)
>
> are both not just in favour, but *strongly *in favour.  They must think
> of the case as compelling, because they are both usually very careful about
> unnecessary breakage.
>
> if we make -Werror=severe the default, then any new warning added to
>> -Wsevere is a new breaking change, and we would have to judge it to be
>> compelling enough by GR2
>>
>
> Yes indeed.  But that's not a bug -- it's a feature.
>
> To be clear I have no strongly held opinion myself.   Perhaps we should
> canvas opinion among people using Haskell in production? We did so with CLC
> but we could do so publicly.
>
> Simon
>
> On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> I don't think this breaking change (namely making -Werror=severe the
>> default) meets the bar for "compelling reason" according to GR2 of our
>> proposed policy, so I'm voting against. It's certainly not a bug or a
>> security hole. Maybe you could argue that it's a design flaw in the
>> language, but I'm not all that convinced. It's an unforced breaking change
>> in my opinion. If we add "makes it more difficult to shoot yourself in the
>> foot" a compelling enough reason to break GR1 then I think we've weakened
>> it significantly.
>>
>> Here's another problem: if we make -Werror=severe the default, then any
>> new warning added to -Wsevere is a new breaking change, and we would have
>> to judge it to be compelling enough by GR2. If we don't make -Werror=severe
>> the default, then we're not restricted in what we can add to -Wsevere.
>> Probably -Wsevere would end up being more useful as a result.
>>
>> Cheers
>> Simon
>>
>>
>> On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Here's my summary:
>>>
>>>    - There is strong (universal, even) support for the `severe`
>>>    category.
>>>    - There is pretty strong support for making severe warnings into
>>>    errors at some point.  As Matt puts it "this is not a question of GHC
>>>    breaking things, but rather *revealing* and providing
>>>    early-diagnosis for *already broken* things".
>>>    - But I think we are moving towards a policy of giving users time to
>>>    adapt via a deprecation cycle, whenever that is feasible.  And it is
>>>    feasible here.
>>>
>>> So my suggestion would be:
>>>
>>>    - When implemented, make `-Wwarn=severe` the default, but add to
>>>    each severe warning a deprecation-style message saying that it'll become an
>>>    error in the next iteration.
>>>    - In the next released, make `-Werror=severe` the default.
>>>    - Don't complicate matters by involving GHC2024.  That is another
>>>    conversation, and even if we wanted to include `-Werorr=severe` in GHC2024,
>>>    we would *still* want a deprecation cycle!
>>>
>>> Would that be acceptable?
>>>
>>> Simon
>>>
>>> On Fri, 29 Sept 2023 at 19:41, Adam Gundry <adam at well-typed.com> wrote:
>>>
>>>> Dear Committee,
>>>>
>>>> It seems we are somewhat split on the -Wsevere proposal, even assuming
>>>> it is introduced with a deprecation period (changing the warning text
>>>> and adding the group in advance). There is consensus that adding the
>>>> group by itself is fine, and potentially enabling -Werror=severe under
>>>> GHC2024, but enabling it by default for existing code is more
>>>> controversial.
>>>>
>>>> Ultimately this is a judgement call about the value of the proposal
>>>> versus the breakage it causes. I remain of the view that it is
>>>> worthwhile. This is not merely about more aggressively enforcing best
>>>> practice. Rather, it eliminates the risk of the following:
>>>>
>>>> * Suppose package A defines a type class, package B depends on package
>>>> A, and package C depends on package B.
>>>>
>>>> * Now package A extends the type class definition with a new method and
>>>> default methods. Everything still compiles; package B now issues a
>>>> -Wmissing-methods warning (but is not actively maintained, and the
>>>> author of package C is unlikely to look at warnings in all their
>>>> dependencies).
>>>>
>>>> * Users of package C have to try to debug an infinite loop.
>>>>
>>>> Given that this change avoids a significant issue, affected code has
>>>> been issuing warnings for many years, and impacted users can very
>>>> easily
>>>> set -Wwarn=severe either at the package level or the project level, I
>>>> think is worth accepting the backwards compatibility cost and the fact
>>>> that some Haskell2010 code will no longer be accepted by default.
>>>>
>>>> Matt Parsons puts it well in the CLC thread, which is pretty clearly in
>>>> favour of this proposal overall
>>>> (
>>>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>>>> ):
>>>>
>>>>  > I think GHC should strive to make fewer breaking changes, and make
>>>> those changes as easy-to-adopt as possible. But this is not a question
>>>> of GHC breaking things, but rather revealing and providing
>>>> early-diagnosis for already broken things.
>>>>
>>>> Further opinions are welcome, of course.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On 14/09/2023 09:32, Adam Gundry wrote:
>>>> > Dear Committee,
>>>> >
>>>> > Joachim, along with Oleg Grenrus, proposes to change
>>>> -Wmissing-methods
>>>> > and -Wmissing-fields warnings into errors by default (retaining the
>>>> > option to downgrade them). I recommend we accept the proposal.
>>>> >
>>>> > Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>> > Rendered:
>>>> >
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>> >
>>>> > This is primarily motivated by the fact that when classes have
>>>> default
>>>> > methods, missing methods can lead to runtime loops, which are
>>>> generally
>>>> > difficult to debug. Since in practice not all users pay attention to
>>>> > warnings that do not inhibit compilation, it makes sense to identify
>>>> a
>>>> > class of warnings that are sufficiently serious to require explicit
>>>> > action from the user to silence them.
>>>> >
>>>> > Since these warnings are currently not errors by default, library
>>>> > authors experimentally assessing the impact of changes may be lead to
>>>> > assume that introducing new methods/fields does not lead to breakage
>>>> > (because downstream code will still compile). The proposal thus makes
>>>> it
>>>> > more obvious that adding a new method or field is a breaking change.
>>>> >
>>>> > The proposal deliberately causes builds to fail by default for some
>>>> > libraries that currently emit warnings. Oleg has kindly performed
>>>> impact
>>>> > assessments to identify such libraries, and the breakage of a few
>>>> > packages seems worth the cost.
>>>> >
>>>> > It is easy to restore the warnings to their previous classification
>>>> by
>>>> > passing an option at build time, e.g. using
>>>> -Wno-error=missing-methods.
>>>> > Users can set such an option in cabal.project or stack.yaml to work
>>>> > around breakage that is not promptly fixed by the library author.
>>>> >
>>>> > This change does mean that GHC with -XHaskell98/2010 will by default
>>>> > reject some programs that are explicitly permitted by the
>>>> Haskell98/2010
>>>> > specification. I recommend we document this infelicity, but accept
>>>> it,
>>>> > as much of the benefit of the proposal is that it applies by default.
>>>> >
>>>> > The proposal establishes the precedent that some warnings may be
>>>> treated
>>>> > as errors by default, and introduces a warning group -Wsevere to
>>>> > classify them. This seems conceptually useful and gives us the option
>>>> to
>>>> > extend the -Wsevere set in the future (e.g. as a final stage of
>>>> > deprecation before a feature is removed).
>>>> >
>>>> > Thoughts?
>>>> >
>>>> > Adam
>>>> >
>>>> >
>>>> > On 11/09/2023 20:25, Joachim Breitner wrote:
>>>> >> Dear Committee,
>>>> >>
>>>> >> based on suggestions by Oleg Grenrus, I wrote a proposal to
>>>> introduce a
>>>> >> warning group -Wsevere for on-by-defaults, error-by-default warnings,
>>>> >> and initially fill it with missing-methods and missing-fields.
>>>> >>
>>>> >>
>>>> >> https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>> >>
>>>> >>
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>> >>
>>>> >> I’d like to nominate Adam as the shepherd, who already reviewed it a
>>>> >> bit on Github.
>>>> >>
>>>> >> Please guide us to a conclusion as outlined in
>>>> >> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>> >>
>>>> >>
>>>> >> Cheers,
>>>> >> Joachim
>>>>
>>>>
>>>> --
>>>> 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/20231004/126b8a87/attachment.html>

From adam at well-typed.com  Thu Oct  5 06:56:22 2023
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 5 Oct 2023 07:56:22 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
Message-ID: <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>

On 04/10/2023 22:04, Simon Marlow wrote:
> My concrete suggestion is we EITHER
> 
>   * Enable -Werror=severe in future GHC20xx versions only, or
>   * Enable it by default and in future GHC20xx versions, but not in
>     GHC2021, Haskell2010, or Haskell98

Sorry, I don't quite understand the difference between these options. 
What does it mean to enable -Werror=severe by default but not in 
GHC2021, given that GHC2021 is the (current) default?

Cheers,

Adam


> On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones 
> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> 
>     I must say that I am strongly influenced by the fact that
> 
>       * Matt Parsons
>       * Andrew Lelechenko (bodigrim)
> 
>     are both not just in favour, but *strongly *in favour.  They must
>     think of the case as compelling, because they are both usually very
>     careful about unnecessary breakage.
> 
>         if we make -Werror=severe the default, then any new warning
>         added to -Wsevere is a new breaking change, and we would have to
>         judge it to be compelling enough by GR2
> 
> 
>     Yes indeed.  But that's not a bug -- it's a feature.
> 
>     To be clear I have no strongly held opinion myself.   Perhaps we
>     should canvas opinion among people using Haskell in production? We
>     did so with CLC but we could do so publicly.
> 
>     Simon
> 
>     On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com
>     <mailto:marlowsd at gmail.com>> wrote:
> 
>         I don't think this breaking change (namely making -Werror=severe
>         the default) meets the bar for "compelling reason" according to
>         GR2 of our proposed policy, so I'm voting against. It's
>         certainly not a bug or a security hole. Maybe you could argue
>         that it's a design flaw in the language, but I'm not all that
>         convinced. It's an unforced breaking change in my opinion. If we
>         add "makes it more difficult to shoot yourself in the foot" a
>         compelling enough reason to break GR1 then I think we've
>         weakened it significantly.
> 
>         Here's another problem: if we make -Werror=severe the default,
>         then any new warning added to -Wsevere is a new breaking change,
>         and we would have to judge it to be compelling enough by GR2. If
>         we don't make -Werror=severe the default, then we're not
>         restricted in what we can add to -Wsevere. Probably -Wsevere
>         would end up being more useful as a result.
> 
>         Cheers
>         Simon
> 
> 
>         On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones
>         <simon.peytonjones at gmail.com
>         <mailto:simon.peytonjones at gmail.com>> wrote:
> 
>             Here's my summary:
> 
>               * There is strong (universal, even) support for the
>                 `severe` category.
>               * There is pretty strong support for making severe
>                 warnings into errors at some point.  As Matt puts it
>                 "this is not a question of GHC breaking things, but
>                 rather /revealing/ and providing early-diagnosis for
>                 /already broken/ things".
>               * But I think we are moving towards a policy of giving
>                 users time to adapt via a deprecation cycle, whenever
>                 that is feasible.  And it is feasible here.
> 
>             So my suggestion would be:
> 
>               * When implemented, make `-Wwarn=severe` the default, but
>                 add to each severe warning a deprecation-style message
>                 saying that it'll become an error in the next iteration.
>               * In the next released, make `-Werror=severe` the default.
>               * Don't complicate matters by involving GHC2024.  That is
>                 another conversation, and even if we wanted to include
>                 `-Werorr=severe` in GHC2024, we would *still* want a
>                 deprecation cycle!
> 
>             Would that be acceptable?
> 
>             Simon
> 
>             On Fri, 29 Sept 2023 at 19:41, Adam Gundry
>             <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
> 
>                 Dear Committee,
> 
>                 It seems we are somewhat split on the -Wsevere proposal,
>                 even assuming
>                 it is introduced with a deprecation period (changing the
>                 warning text
>                 and adding the group in advance). There is consensus
>                 that adding the
>                 group by itself is fine, and potentially enabling
>                 -Werror=severe under
>                 GHC2024, but enabling it by default for existing code is
>                 more controversial.
> 
>                 Ultimately this is a judgement call about the value of
>                 the proposal
>                 versus the breakage it causes. I remain of the view that
>                 it is
>                 worthwhile. This is not merely about more aggressively
>                 enforcing best
>                 practice. Rather, it eliminates the risk of the following:
> 
>                 * Suppose package A defines a type class, package B
>                 depends on package
>                 A, and package C depends on package B.
> 
>                 * Now package A extends the type class definition with a
>                 new method and
>                 default methods. Everything still compiles; package B
>                 now issues a
>                 -Wmissing-methods warning (but is not actively
>                 maintained, and the
>                 author of package C is unlikely to look at warnings in
>                 all their
>                 dependencies).
> 
>                 * Users of package C have to try to debug an infinite loop.
> 
>                 Given that this change avoids a significant issue,
>                 affected code has
>                 been issuing warnings for many years, and impacted users
>                 can very easily
>                 set -Wwarn=severe either at the package level or the
>                 project level, I
>                 think is worth accepting the backwards compatibility
>                 cost and the fact
>                 that some Haskell2010 code will no longer be accepted by
>                 default.
> 
>                 Matt Parsons puts it well in the CLC thread, which is
>                 pretty clearly in
>                 favour of this proposal overall
>                 (https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889 <https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889>):
> 
>                   > I think GHC should strive to make fewer breaking
>                 changes, and make
>                 those changes as easy-to-adopt as possible. But this is
>                 not a question
>                 of GHC breaking things, but rather revealing and providing
>                 early-diagnosis for already broken things.
> 
>                 Further opinions are welcome, of course.
> 
>                 Adam
> 
> 
>                 On 14/09/2023 09:32, Adam Gundry wrote:
>                  > Dear Committee,
>                  >
>                  > Joachim, along with Oleg Grenrus, proposes to change
>                 -Wmissing-methods
>                  > and -Wmissing-fields warnings into errors by default
>                 (retaining the
>                  > option to downgrade them). I recommend we accept the
>                 proposal.
>                  >
>                  > Proposal:
>                 https://github.com/ghc-proposals/ghc-proposals/pull/571
>                 <https://github.com/ghc-proposals/ghc-proposals/pull/571>
>                  > Rendered:
>                  >
>                 https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst>
>                  >
>                  > This is primarily motivated by the fact that when
>                 classes have default
>                  > methods, missing methods can lead to runtime loops,
>                 which are generally
>                  > difficult to debug. Since in practice not all users
>                 pay attention to
>                  > warnings that do not inhibit compilation, it makes
>                 sense to identify a
>                  > class of warnings that are sufficiently serious to
>                 require explicit
>                  > action from the user to silence them.
>                  >
>                  > Since these warnings are currently not errors by
>                 default, library
>                  > authors experimentally assessing the impact of
>                 changes may be lead to
>                  > assume that introducing new methods/fields does not
>                 lead to breakage
>                  > (because downstream code will still compile). The
>                 proposal thus makes it
>                  > more obvious that adding a new method or field is a
>                 breaking change.
>                  >
>                  > The proposal deliberately causes builds to fail by
>                 default for some
>                  > libraries that currently emit warnings. Oleg has
>                 kindly performed impact
>                  > assessments to identify such libraries, and the
>                 breakage of a few
>                  > packages seems worth the cost.
>                  >
>                  > It is easy to restore the warnings to their previous
>                 classification by
>                  > passing an option at build time, e.g. using
>                 -Wno-error=missing-methods.
>                  > Users can set such an option in cabal.project or
>                 stack.yaml to work
>                  > around breakage that is not promptly fixed by the
>                 library author.
>                  >
>                  > This change does mean that GHC with -XHaskell98/2010
>                 will by default
>                  > reject some programs that are explicitly permitted by
>                 the Haskell98/2010
>                  > specification. I recommend we document this
>                 infelicity, but accept it,
>                  > as much of the benefit of the proposal is that it
>                 applies by default.
>                  >
>                  > The proposal establishes the precedent that some
>                 warnings may be treated
>                  > as errors by default, and introduces a warning group
>                 -Wsevere to
>                  > classify them. This seems conceptually useful and
>                 gives us the option to
>                  > extend the -Wsevere set in the future (e.g. as a
>                 final stage of
>                  > deprecation before a feature is removed).
>                  >
>                  > Thoughts?
>                  >
>                  > Adam
>                  >
>                  >
>                  > On 11/09/2023 20:25, Joachim Breitner wrote:
>                  >> Dear Committee,
>                  >>
>                  >> based on suggestions by Oleg Grenrus, I wrote a
>                 proposal to introduce a
>                  >> warning group -Wsevere for on-by-defaults,
>                 error-by-default warnings,
>                  >> and initially fill it with missing-methods and
>                 missing-fields.
>                  >>
>                  >>
>                  >>
>                 https://github.com/ghc-proposals/ghc-proposals/pull/571
>                 <https://github.com/ghc-proposals/ghc-proposals/pull/571>
>                  >>
>                  >>
>                 https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst>
>                  >>
>                  >> I’d like to nominate Adam as the shepherd, who
>                 already reviewed it a
>                  >> bit on Github.
>                  >>
>                  >> Please guide us to a conclusion as outlined in
>                  >>
>                 https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
>                  >>
>                  >>
>                  >> Cheers,
>                  >> Joachim


-- 
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


From marlowsd at gmail.com  Thu Oct  5 17:07:09 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 5 Oct 2023 18:07:09 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
Message-ID: <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>

Ah thanks, I forgot GHC2021 was the default (I'm personally stuck using
pre-GHC2021 myself).

In that case, I'm suggesting that we enable -Werror=severe in the next
GHC20xx iteration, and leave GHC2021 etc. unaffected.

Cheers
Simon


On Thu, 5 Oct 2023, 07:56 Adam Gundry, <adam at well-typed.com> wrote:

> On 04/10/2023 22:04, Simon Marlow wrote:
> > My concrete suggestion is we EITHER
> >
> >   * Enable -Werror=severe in future GHC20xx versions only, or
> >   * Enable it by default and in future GHC20xx versions, but not in
> >     GHC2021, Haskell2010, or Haskell98
>
> Sorry, I don't quite understand the difference between these options.
> What does it mean to enable -Werror=severe by default but not in
> GHC2021, given that GHC2021 is the (current) default?
>
> Cheers,
>
> Adam
>
>
> > On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones
> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> wrote:
> >
> >     I must say that I am strongly influenced by the fact that
> >
> >       * Matt Parsons
> >       * Andrew Lelechenko (bodigrim)
> >
> >     are both not just in favour, but *strongly *in favour.  They must
> >     think of the case as compelling, because they are both usually very
> >     careful about unnecessary breakage.
> >
> >         if we make -Werror=severe the default, then any new warning
> >         added to -Wsevere is a new breaking change, and we would have to
> >         judge it to be compelling enough by GR2
> >
> >
> >     Yes indeed.  But that's not a bug -- it's a feature.
> >
> >     To be clear I have no strongly held opinion myself.   Perhaps we
> >     should canvas opinion among people using Haskell in production? We
> >     did so with CLC but we could do so publicly.
> >
> >     Simon
> >
> >     On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com
> >     <mailto:marlowsd at gmail.com>> wrote:
> >
> >         I don't think this breaking change (namely making -Werror=severe
> >         the default) meets the bar for "compelling reason" according to
> >         GR2 of our proposed policy, so I'm voting against. It's
> >         certainly not a bug or a security hole. Maybe you could argue
> >         that it's a design flaw in the language, but I'm not all that
> >         convinced. It's an unforced breaking change in my opinion. If we
> >         add "makes it more difficult to shoot yourself in the foot" a
> >         compelling enough reason to break GR1 then I think we've
> >         weakened it significantly.
> >
> >         Here's another problem: if we make -Werror=severe the default,
> >         then any new warning added to -Wsevere is a new breaking change,
> >         and we would have to judge it to be compelling enough by GR2. If
> >         we don't make -Werror=severe the default, then we're not
> >         restricted in what we can add to -Wsevere. Probably -Wsevere
> >         would end up being more useful as a result.
> >
> >         Cheers
> >         Simon
> >
> >
> >         On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones
> >         <simon.peytonjones at gmail.com
> >         <mailto:simon.peytonjones at gmail.com>> wrote:
> >
> >             Here's my summary:
> >
> >               * There is strong (universal, even) support for the
> >                 `severe` category.
> >               * There is pretty strong support for making severe
> >                 warnings into errors at some point.  As Matt puts it
> >                 "this is not a question of GHC breaking things, but
> >                 rather /revealing/ and providing early-diagnosis for
> >                 /already broken/ things".
> >               * But I think we are moving towards a policy of giving
> >                 users time to adapt via a deprecation cycle, whenever
> >                 that is feasible.  And it is feasible here.
> >
> >             So my suggestion would be:
> >
> >               * When implemented, make `-Wwarn=severe` the default, but
> >                 add to each severe warning a deprecation-style message
> >                 saying that it'll become an error in the next iteration.
> >               * In the next released, make `-Werror=severe` the default.
> >               * Don't complicate matters by involving GHC2024.  That is
> >                 another conversation, and even if we wanted to include
> >                 `-Werorr=severe` in GHC2024, we would *still* want a
> >                 deprecation cycle!
> >
> >             Would that be acceptable?
> >
> >             Simon
> >
> >             On Fri, 29 Sept 2023 at 19:41, Adam Gundry
> >             <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
> >
> >                 Dear Committee,
> >
> >                 It seems we are somewhat split on the -Wsevere proposal,
> >                 even assuming
> >                 it is introduced with a deprecation period (changing the
> >                 warning text
> >                 and adding the group in advance). There is consensus
> >                 that adding the
> >                 group by itself is fine, and potentially enabling
> >                 -Werror=severe under
> >                 GHC2024, but enabling it by default for existing code is
> >                 more controversial.
> >
> >                 Ultimately this is a judgement call about the value of
> >                 the proposal
> >                 versus the breakage it causes. I remain of the view that
> >                 it is
> >                 worthwhile. This is not merely about more aggressively
> >                 enforcing best
> >                 practice. Rather, it eliminates the risk of the
> following:
> >
> >                 * Suppose package A defines a type class, package B
> >                 depends on package
> >                 A, and package C depends on package B.
> >
> >                 * Now package A extends the type class definition with a
> >                 new method and
> >                 default methods. Everything still compiles; package B
> >                 now issues a
> >                 -Wmissing-methods warning (but is not actively
> >                 maintained, and the
> >                 author of package C is unlikely to look at warnings in
> >                 all their
> >                 dependencies).
> >
> >                 * Users of package C have to try to debug an infinite
> loop.
> >
> >                 Given that this change avoids a significant issue,
> >                 affected code has
> >                 been issuing warnings for many years, and impacted users
> >                 can very easily
> >                 set -Wwarn=severe either at the package level or the
> >                 project level, I
> >                 think is worth accepting the backwards compatibility
> >                 cost and the fact
> >                 that some Haskell2010 code will no longer be accepted by
> >                 default.
> >
> >                 Matt Parsons puts it well in the CLC thread, which is
> >                 pretty clearly in
> >                 favour of this proposal overall
> >                 (
> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
> <
> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
> >):
> >
> >                   > I think GHC should strive to make fewer breaking
> >                 changes, and make
> >                 those changes as easy-to-adopt as possible. But this is
> >                 not a question
> >                 of GHC breaking things, but rather revealing and
> providing
> >                 early-diagnosis for already broken things.
> >
> >                 Further opinions are welcome, of course.
> >
> >                 Adam
> >
> >
> >                 On 14/09/2023 09:32, Adam Gundry wrote:
> >                  > Dear Committee,
> >                  >
> >                  > Joachim, along with Oleg Grenrus, proposes to change
> >                 -Wmissing-methods
> >                  > and -Wmissing-fields warnings into errors by default
> >                 (retaining the
> >                  > option to downgrade them). I recommend we accept the
> >                 proposal.
> >                  >
> >                  > Proposal:
> >                 https://github.com/ghc-proposals/ghc-proposals/pull/571
> >                 <https://github.com/ghc-proposals/ghc-proposals/pull/571
> >
> >                  > Rendered:
> >                  >
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> <
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> >
> >                  >
> >                  > This is primarily motivated by the fact that when
> >                 classes have default
> >                  > methods, missing methods can lead to runtime loops,
> >                 which are generally
> >                  > difficult to debug. Since in practice not all users
> >                 pay attention to
> >                  > warnings that do not inhibit compilation, it makes
> >                 sense to identify a
> >                  > class of warnings that are sufficiently serious to
> >                 require explicit
> >                  > action from the user to silence them.
> >                  >
> >                  > Since these warnings are currently not errors by
> >                 default, library
> >                  > authors experimentally assessing the impact of
> >                 changes may be lead to
> >                  > assume that introducing new methods/fields does not
> >                 lead to breakage
> >                  > (because downstream code will still compile). The
> >                 proposal thus makes it
> >                  > more obvious that adding a new method or field is a
> >                 breaking change.
> >                  >
> >                  > The proposal deliberately causes builds to fail by
> >                 default for some
> >                  > libraries that currently emit warnings. Oleg has
> >                 kindly performed impact
> >                  > assessments to identify such libraries, and the
> >                 breakage of a few
> >                  > packages seems worth the cost.
> >                  >
> >                  > It is easy to restore the warnings to their previous
> >                 classification by
> >                  > passing an option at build time, e.g. using
> >                 -Wno-error=missing-methods.
> >                  > Users can set such an option in cabal.project or
> >                 stack.yaml to work
> >                  > around breakage that is not promptly fixed by the
> >                 library author.
> >                  >
> >                  > This change does mean that GHC with -XHaskell98/2010
> >                 will by default
> >                  > reject some programs that are explicitly permitted by
> >                 the Haskell98/2010
> >                  > specification. I recommend we document this
> >                 infelicity, but accept it,
> >                  > as much of the benefit of the proposal is that it
> >                 applies by default.
> >                  >
> >                  > The proposal establishes the precedent that some
> >                 warnings may be treated
> >                  > as errors by default, and introduces a warning group
> >                 -Wsevere to
> >                  > classify them. This seems conceptually useful and
> >                 gives us the option to
> >                  > extend the -Wsevere set in the future (e.g. as a
> >                 final stage of
> >                  > deprecation before a feature is removed).
> >                  >
> >                  > Thoughts?
> >                  >
> >                  > Adam
> >                  >
> >                  >
> >                  > On 11/09/2023 20:25, Joachim Breitner wrote:
> >                  >> Dear Committee,
> >                  >>
> >                  >> based on suggestions by Oleg Grenrus, I wrote a
> >                 proposal to introduce a
> >                  >> warning group -Wsevere for on-by-defaults,
> >                 error-by-default warnings,
> >                  >> and initially fill it with missing-methods and
> >                 missing-fields.
> >                  >>
> >                  >>
> >                  >>
> >                 https://github.com/ghc-proposals/ghc-proposals/pull/571
> >                 <https://github.com/ghc-proposals/ghc-proposals/pull/571
> >
> >                  >>
> >                  >>
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> <
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> >
> >                  >>
> >                  >> I’d like to nominate Adam as the shepherd, who
> >                 already reviewed it a
> >                  >> bit on Github.
> >                  >>
> >                  >> Please guide us to a conclusion as outlined in
> >                  >>
> >
> https://github.com/ghc-proposals/ghc-proposals#committee-process <
> https://github.com/ghc-proposals/ghc-proposals#committee-process>
> >                  >>
> >                  >>
> >                  >> Cheers,
> >                  >> Joachim
>
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231005/c4beb3d2/attachment-0001.html>

From chris at chrisdornan.com  Sun Oct  8 15:15:57 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Sun, 8 Oct 2023 16:15:57 +0100
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
 p2 (#609)
In-Reply-To: <CAJKmMz_VcJ7cBQ3kTv8acBVNYpHN5BxCnjEGLby9gPqv3WfmEA@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz_VcJ7cBQ3kTv8acBVNYpHN5BxCnjEGLby9gPqv3WfmEA@mail.gmail.com>
Message-ID: <4A46973F-852C-44B7-9B04-0F12D0BC71DC@chrisdornan.com>

The motion is carried. I have asked the authors to make some final changes proposed by Simon and Adam -- once that is done we can press the big green button. 

> On 3 Oct 2023, at 11:17, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Chris
> 
> Joachim, Simon, and Richard have yet to vote; but I think you have a majority anyway.  Would you like to move this forward?
> 
> Simon
> 
> On Fri, 8 Sept 2023 at 11:57, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>> Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
>> Author: Sebastian Graf, David Knothe
>> Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
>> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609
>> Recommendation: Acceptance
>> 
>> ## Summary
>> 
>> This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.
>> 
>> The syntax of the old proposal,
>> 
>> ```haskell
>>     stringOfT :: T -> Maybe String
>>     stringOfT (T1 s)              = Just s
>>     stringOfT (one of T2{}, T3{}) = Nothing
>> ```
>> 
>> is replaced with
>> 
>> ```haskell
>>     stringOfT :: T -> Maybe String
>>     stringOfT (T1 s)       = Just s
>>     stringOfT (T2{}; T3{}) = Nothing
>> ```
>> 
>> or indeed
>> 
>> ```haskell
>>     stringOfT :: T -> Maybe String
>>     stringOfT x = case x of
>>       T1 s -> Just s
>>       T2{}
>>       T3{} -> Nothing
>> ```
>> 
>> (Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)
>> 
>> The authors have conducted polls to see what folks preferred, landing on this proposal. The
>> adjustments to the Haskell grammar are really quite minimal requiring one extra production.
>> 
>> ## Recommendation
>> 
>> The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend
>> that we accept it
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto: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/20231008/f27a68d3/attachment.html>

From chris at chrisdornan.com  Sun Oct  8 18:11:34 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Sun, 8 Oct 2023 19:11:34 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
Message-ID: <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>


The discussion of this proposal has really boiled down to how we roll this change out. I think it is important to understand why some of us have been pleading for us to follow agreed processes when making these changes, starting with this proposal, so I have written up some notes on why I think it is important to adopt a process for these kinds of changes and endeavour to stick to it.

We have a mechanism for getting everything the proposers want using established mechanisms. Why don't we follow them? If an urgent need had arisen to make this change then it would be easily understandable but this is proposal addressing a longstanding issue.

I get the sense that folks fear that there is a big push to freeze GHC/Haskell in its current configuration (or at least make it very difficult to change anything) to satisfy those that want to just make stuff with Haskell and stop all the experimentation and language development, and that this push needs to be stopped before it gathers any more momentum. I don't think this is all gamed out -- more a feeling or a vibe informing the debate.

I strongly believe this is a misunderstanding, and certainly where the proponents of these proposed protocols are concerned, nothing could be further from the truth. Properly understood, we want to create a framework that will remove a lot of friction in making changes, and also remove key stressors from all those maintaining the critical infrastructure outside of the core tools that make Haskell truly viable for real-world development.

I have written up my thoughts in this gist <https://gist.github.com/cdornan/68267aa63546e5d674cc8d083510c3e3>, explaining why I think we need the framework and why we should hold to it without good reason to do otherwise. Feel free to respond there or here as you see fit.

I remain opposed to this proposal in its current form, at least until I can understand why the changes have to be made outside of the framework for change we are trying to establish.

Chris
 


> On 5 Oct 2023, at 18:07, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> Ah thanks, I forgot GHC2021 was the default (I'm personally stuck using pre-GHC2021 myself).
> 
> In that case, I'm suggesting that we enable -Werror=severe in the next GHC20xx iteration, and leave GHC2021 etc. unaffected.
> 
> Cheers
> Simon
> 
> 
> On Thu, 5 Oct 2023, 07:56 Adam Gundry, <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>> On 04/10/2023 22:04, Simon Marlow wrote:
>> > My concrete suggestion is we EITHER
>> > 
>> >   * Enable -Werror=severe in future GHC20xx versions only, or
>> >   * Enable it by default and in future GHC20xx versions, but not in
>> >     GHC2021, Haskell2010, or Haskell98
>> 
>> Sorry, I don't quite understand the difference between these options. 
>> What does it mean to enable -Werror=severe by default but not in 
>> GHC2021, given that GHC2021 is the (current) default?
>> 
>> Cheers,
>> 
>> Adam
>> 
>> 
>> > On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones 
>> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com> <mailto:simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>> wrote:
>> > 
>> >     I must say that I am strongly influenced by the fact that
>> > 
>> >       * Matt Parsons
>> >       * Andrew Lelechenko (bodigrim)
>> > 
>> >     are both not just in favour, but *strongly *in favour.  They must
>> >     think of the case as compelling, because they are both usually very
>> >     careful about unnecessary breakage.
>> > 
>> >         if we make -Werror=severe the default, then any new warning
>> >         added to -Wsevere is a new breaking change, and we would have to
>> >         judge it to be compelling enough by GR2
>> > 
>> > 
>> >     Yes indeed.  But that's not a bug -- it's a feature.
>> > 
>> >     To be clear I have no strongly held opinion myself.   Perhaps we
>> >     should canvas opinion among people using Haskell in production? We
>> >     did so with CLC but we could do so publicly.
>> > 
>> >     Simon
>> > 
>> >     On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>
>> >     <mailto:marlowsd at gmail.com <mailto:marlowsd at gmail.com>>> wrote:
>> > 
>> >         I don't think this breaking change (namely making -Werror=severe
>> >         the default) meets the bar for "compelling reason" according to
>> >         GR2 of our proposed policy, so I'm voting against. It's
>> >         certainly not a bug or a security hole. Maybe you could argue
>> >         that it's a design flaw in the language, but I'm not all that
>> >         convinced. It's an unforced breaking change in my opinion. If we
>> >         add "makes it more difficult to shoot yourself in the foot" a
>> >         compelling enough reason to break GR1 then I think we've
>> >         weakened it significantly.
>> > 
>> >         Here's another problem: if we make -Werror=severe the default,
>> >         then any new warning added to -Wsevere is a new breaking change,
>> >         and we would have to judge it to be compelling enough by GR2. If
>> >         we don't make -Werror=severe the default, then we're not
>> >         restricted in what we can add to -Wsevere. Probably -Wsevere
>> >         would end up being more useful as a result.
>> > 
>> >         Cheers
>> >         Simon
>> > 
>> > 
>> >         On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones
>> >         <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>
>> >         <mailto:simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>> wrote:
>> > 
>> >             Here's my summary:
>> > 
>> >               * There is strong (universal, even) support for the
>> >                 `severe` category.
>> >               * There is pretty strong support for making severe
>> >                 warnings into errors at some point.  As Matt puts it
>> >                 "this is not a question of GHC breaking things, but
>> >                 rather /revealing/ and providing early-diagnosis for
>> >                 /already broken/ things".
>> >               * But I think we are moving towards a policy of giving
>> >                 users time to adapt via a deprecation cycle, whenever
>> >                 that is feasible.  And it is feasible here.
>> > 
>> >             So my suggestion would be:
>> > 
>> >               * When implemented, make `-Wwarn=severe` the default, but
>> >                 add to each severe warning a deprecation-style message
>> >                 saying that it'll become an error in the next iteration.
>> >               * In the next released, make `-Werror=severe` the default.
>> >               * Don't complicate matters by involving GHC2024.  That is
>> >                 another conversation, and even if we wanted to include
>> >                 `-Werorr=severe` in GHC2024, we would *still* want a
>> >                 deprecation cycle!
>> > 
>> >             Would that be acceptable?
>> > 
>> >             Simon
>> > 
>> >             On Fri, 29 Sept 2023 at 19:41, Adam Gundry
>> >             <adam at well-typed.com <mailto:adam at well-typed.com> <mailto:adam at well-typed.com <mailto:adam at well-typed.com>>> wrote:
>> > 
>> >                 Dear Committee,
>> > 
>> >                 It seems we are somewhat split on the -Wsevere proposal,
>> >                 even assuming
>> >                 it is introduced with a deprecation period (changing the
>> >                 warning text
>> >                 and adding the group in advance). There is consensus
>> >                 that adding the
>> >                 group by itself is fine, and potentially enabling
>> >                 -Werror=severe under
>> >                 GHC2024, but enabling it by default for existing code is
>> >                 more controversial.
>> > 
>> >                 Ultimately this is a judgement call about the value of
>> >                 the proposal
>> >                 versus the breakage it causes. I remain of the view that
>> >                 it is
>> >                 worthwhile. This is not merely about more aggressively
>> >                 enforcing best
>> >                 practice. Rather, it eliminates the risk of the following:
>> > 
>> >                 * Suppose package A defines a type class, package B
>> >                 depends on package
>> >                 A, and package C depends on package B.
>> > 
>> >                 * Now package A extends the type class definition with a
>> >                 new method and
>> >                 default methods. Everything still compiles; package B
>> >                 now issues a
>> >                 -Wmissing-methods warning (but is not actively
>> >                 maintained, and the
>> >                 author of package C is unlikely to look at warnings in
>> >                 all their
>> >                 dependencies).
>> > 
>> >                 * Users of package C have to try to debug an infinite loop.
>> > 
>> >                 Given that this change avoids a significant issue,
>> >                 affected code has
>> >                 been issuing warnings for many years, and impacted users
>> >                 can very easily
>> >                 set -Wwarn=severe either at the package level or the
>> >                 project level, I
>> >                 think is worth accepting the backwards compatibility
>> >                 cost and the fact
>> >                 that some Haskell2010 code will no longer be accepted by
>> >                 default.
>> > 
>> >                 Matt Parsons puts it well in the CLC thread, which is
>> >                 pretty clearly in
>> >                 favour of this proposal overall
>> >                 (https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889 <https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889>):
>> > 
>> >                   > I think GHC should strive to make fewer breaking
>> >                 changes, and make
>> >                 those changes as easy-to-adopt as possible. But this is
>> >                 not a question
>> >                 of GHC breaking things, but rather revealing and providing
>> >                 early-diagnosis for already broken things.
>> > 
>> >                 Further opinions are welcome, of course.
>> > 
>> >                 Adam
>> > 
>> > 
>> >                 On 14/09/2023 09:32, Adam Gundry wrote:
>> >                  > Dear Committee,
>> >                  >
>> >                  > Joachim, along with Oleg Grenrus, proposes to change
>> >                 -Wmissing-methods
>> >                  > and -Wmissing-fields warnings into errors by default
>> >                 (retaining the
>> >                  > option to downgrade them). I recommend we accept the
>> >                 proposal.
>> >                  >
>> >                  > Proposal:
>> >                 https://github.com/ghc-proposals/ghc-proposals/pull/571
>> >                 <https://github.com/ghc-proposals/ghc-proposals/pull/571>
>> >                  > Rendered:
>> >                  >
>> >                 https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst>
>> >                  >
>> >                  > This is primarily motivated by the fact that when
>> >                 classes have default
>> >                  > methods, missing methods can lead to runtime loops,
>> >                 which are generally
>> >                  > difficult to debug. Since in practice not all users
>> >                 pay attention to
>> >                  > warnings that do not inhibit compilation, it makes
>> >                 sense to identify a
>> >                  > class of warnings that are sufficiently serious to
>> >                 require explicit
>> >                  > action from the user to silence them.
>> >                  >
>> >                  > Since these warnings are currently not errors by
>> >                 default, library
>> >                  > authors experimentally assessing the impact of
>> >                 changes may be lead to
>> >                  > assume that introducing new methods/fields does not
>> >                 lead to breakage
>> >                  > (because downstream code will still compile). The
>> >                 proposal thus makes it
>> >                  > more obvious that adding a new method or field is a
>> >                 breaking change.
>> >                  >
>> >                  > The proposal deliberately causes builds to fail by
>> >                 default for some
>> >                  > libraries that currently emit warnings. Oleg has
>> >                 kindly performed impact
>> >                  > assessments to identify such libraries, and the
>> >                 breakage of a few
>> >                  > packages seems worth the cost.
>> >                  >
>> >                  > It is easy to restore the warnings to their previous
>> >                 classification by
>> >                  > passing an option at build time, e.g. using
>> >                 -Wno-error=missing-methods.
>> >                  > Users can set such an option in cabal.project or
>> >                 stack.yaml to work
>> >                  > around breakage that is not promptly fixed by the
>> >                 library author.
>> >                  >
>> >                  > This change does mean that GHC with -XHaskell98/2010
>> >                 will by default
>> >                  > reject some programs that are explicitly permitted by
>> >                 the Haskell98/2010
>> >                  > specification. I recommend we document this
>> >                 infelicity, but accept it,
>> >                  > as much of the benefit of the proposal is that it
>> >                 applies by default.
>> >                  >
>> >                  > The proposal establishes the precedent that some
>> >                 warnings may be treated
>> >                  > as errors by default, and introduces a warning group
>> >                 -Wsevere to
>> >                  > classify them. This seems conceptually useful and
>> >                 gives us the option to
>> >                  > extend the -Wsevere set in the future (e.g. as a
>> >                 final stage of
>> >                  > deprecation before a feature is removed).
>> >                  >
>> >                  > Thoughts?
>> >                  >
>> >                  > Adam
>> >                  >
>> >                  >
>> >                  > On 11/09/2023 20:25, Joachim Breitner wrote:
>> >                  >> Dear Committee,
>> >                  >>
>> >                  >> based on suggestions by Oleg Grenrus, I wrote a
>> >                 proposal to introduce a
>> >                  >> warning group -Wsevere for on-by-defaults,
>> >                 error-by-default warnings,
>> >                  >> and initially fill it with missing-methods and
>> >                 missing-fields.
>> >                  >>
>> >                  >>
>> >                  >>
>> >                 https://github.com/ghc-proposals/ghc-proposals/pull/571
>> >                 <https://github.com/ghc-proposals/ghc-proposals/pull/571>
>> >                  >>
>> >                  >>
>> >                 https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst>
>> >                  >>
>> >                  >> I’d like to nominate Adam as the shepherd, who
>> >                 already reviewed it a
>> >                  >> bit on Github.
>> >                  >>
>> >                  >> Please guide us to a conclusion as outlined in
>> >                  >>
>> >                 https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
>> >                  >>
>> >                  >>
>> >                  >> Cheers,
>> >                  >> Joachim
>> 
>> 
>> -- 
>> 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/20231008/d7601033/attachment-0001.html>

From arnaud.spiwack at tweag.io  Mon Oct  9 08:06:32 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 9 Oct 2023 10:06:32 +0200
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAGwnsnns2kpWamSegWEP1KxzReeni5re=qkK5spAbt0FqUxzFA@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
 <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>
 <CAKfdd-zqumiE0FWp4vSyJXO8rqugupdXROa93fEBEYimtXYayQ@mail.gmail.com>
 <6ecf13eb-7c08-4f09-5696-deadc830231f@well-typed.com>
 <CAGwnsnkHOsVeDTqo1gTw10ECMQ+QjabRFbcspwCN8xcsN2eEfg@mail.gmail.com>
 <CAKfdd-ziOZdZ=gNpZLU-w-n8V6BFE=uu+jdK5MZyZPMcmgv5Bg@mail.gmail.com>
 <CAJKmMz_MeY4bwub1Dy43jW5A9w+yNf-0vqCdHi-iQ0J4A11EMQ@mail.gmail.com>
 <CAKfdd-yDN2PLX=Wga-tjndXqAGcg+2+u9nnxzHiH5U=iZBTrHw@mail.gmail.com>
 <CAJKmMz_tVcqczQoQ0k6YX4uKwas1KusN18JwxK+BHzjMWSLuLw@mail.gmail.com>
 <CAGwnsnkAvrwUxDZm2+Mfgg7ngJFbugYjZesL=cGgYQPQC1ai7g@mail.gmail.com>
 <CAGwnsnns2kpWamSegWEP1KxzReeni5re=qkK5spAbt0FqUxzFA@mail.gmail.com>
Message-ID: <CAGwnsnniSGMLd_S8f81vdj9DmEVvKeWuhCLTtNNjWGeSKO0D6g@mail.gmail.com>

Dear all,

Absent votes, based on my current understanding of everybody's position,
I'll mark the proposal as accepted, without modification, on Wednesday
(11th October).

On Tue, 3 Oct 2023 at 11:52, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:

> Simon votes A above. I vote A too (I think I actually feel pretty strongly
> about this one).
>
> On Tue, 3 Oct 2023 at 11:52, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Let's do a quick vote. All, which do you prefer?
>>
>> A. Introduce the breakage immediately and change the argument order of
>> setField (current state of the proposal)
>> B. Introduce a new extension -XOverloadedRecordUpdateNew which would use
>> a setField with a different argument order, so that it can be used during
>> the transition period. Eventually OverloadedRecordUpdateNew becomes
>> deprecated and OverloadedRecordUpdate swaps the argument order. (Moritz's
>> proposal)
>> C. Keep the originally proposed setField argument order (nobody have
>> suggested this yet, but I'm including it for completeness)
>>
>> On Tue, 3 Oct 2023 at 10:33, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Sure.
>>>
>>> Just to be clear, I'm not trying to set a precedent here!
>>>
>>> Simon
>>>
>>> On Tue, 3 Oct 2023 at 09:26, Moritz Angermann <
>>> moritz.angermann at gmail.com> wrote:
>>>
>>>> I’m not going to stay in the way of this proposal. I’hope it’s
>>>> understandable if I recuse myself.
>>>>
>>>> On Tue, 3 Oct 2023 at 4:18 PM, Simon Peyton Jones <
>>>> simon.peytonjones at gmail.com> wrote:
>>>>
>>>>> We have to balance the cost of mitigation against the cost of breakage.
>>>>>
>>>>>    - Cost of breakage.  Adam has identified only two packages that
>>>>>    woud, both of which can adapt promptly.  It's true that there is more code
>>>>>    out there, but the absence on Hackage is strongly indicative that there is
>>>>>    unlikely to be much.
>>>>>    - Cost of mitigation.  Supporting both behaviours, having extra
>>>>>    language flags, that must in turn themselves be deprecated away, are real
>>>>>    costs.  The suck effort away from more productive activity.
>>>>>    - I completely agree that if we had a classification,
>>>>>    OverloadedRecordUpdate would have been classified as Experimental, and we
>>>>>    would not be discussing deprecation cycles.  And signalling what is
>>>>>    experimental and what is stable is a *primary *goal of the
>>>>>    stability conversation we are having.  I agree strongly with Moritz on this
>>>>>    point.
>>>>>    - However the user manual (Section 6.5.11
>>>>>    <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/overloaded_record_update.html?highlight=overloaded%20record#overloaded-record-update>)
>>>>>    says "*EXPERIMENTAL* *This design of this extension may well
>>>>>    change in the future. It would be inadvisable to start using this extension
>>>>>    for long-lived libraries just yet*".  Short of an official
>>>>>    classification mechanism, which we don't have yet, it seems hard to imagine
>>>>>    a clearer statement than that.
>>>>>
>>>>> My judgement: in this case we should forge ahead without introducing
>>>>> OverloadedRecordNew and supporting both behaviours. (I have not even begun
>>>>> to think about how hard that would be to implement.)  Let's spend our
>>>>> precious cycles elsewhere.
>>>>>
>>>>> Simon
>>>>>
>>>>> On Tue, 3 Oct 2023 at 08:48, Moritz Angermann <
>>>>> moritz.angermann at gmail.com> wrote:
>>>>>
>>>>>> Arnaud,
>>>>>>
>>>>>> That is a good argument. Without an opt-in to the new syntax, they
>>>>>> can't adapt. I guess this brings us to the extension lifecycle. A solution
>>>>>> could be
>>>>>> 1. Deprecate OverloadedRecordUpdate in favour of
>>>>>> OverloadedRecordUpdateNew. The user can adapt their code and use a
>>>>>> different Extension.
>>>>>> 2. Eventually Have OverloadedRecordUpdateNew be a synonym for changed
>>>>>> OverloadedRecordUpdate. And Deprecate OverloadedRecordUpdateNew
>>>>>>     over a longer period of time.
>>>>>>
>>>>>> I think this actually shows the value a `--std=experimental` could
>>>>>> have. If `OverloadedRecordUpdate` was behind `--std=experimental` breaking
>>>>>> it would
>>>>>> be permissible by design. And we would not have this discussion, and
>>>>>> Adam would not need to try to find all the potential breaking codes. This
>>>>>> is part
>>>>>> of the proposal to make `--std=experimental` a thing, allow fast(er)
>>>>>> paced iteration on the experimental side of the compiler, while being
>>>>>> extremely
>>>>>> explicit about it being experimental features that can break at any
>>>>>> time and without warning.
>>>>>>
>>>>>> The deprecation process outlined above would be fore non-experimental
>>>>>> features. They can still be changed, but with a more rigorous change
>>>>>> evolution.
>>>>>>
>>>>>> I hope this helps to clarify my position?
>>>>>>
>>>>>> Best,
>>>>>>  Moritz
>>>>>>
>>>>>>
>>>>>> On Tue, 3 Oct 2023 at 15:31, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>>>>> wrote:
>>>>>>
>>>>>>> @Moritz: very clear thank you, though I'd like to understand how one
>>>>>>> could adapt during the transition period to an argument swap, would you
>>>>>>> say? Secondary question: if they can't adapt, isn't there a risk of making
>>>>>>> the breakage more painful by delaying it, and letting more people use
>>>>>>> -XOverloadedRecordUpdate with the argument order which isn't the final one?
>>>>>>>
>>>>>>> @Adam: we have to recognise that Hackage is not all the Haskell
>>>>>>> code. I expect Hackage to be a little more conservative in extensions than
>>>>>>> end-user applications. As such we're not guaranteed an absence of breakage
>>>>>>> (it's still probably quite small, but it's hard to quantify).
>>>>>>>
>>>>>>> On Tue, 3 Oct 2023 at 09:21, Adam Gundry <adam at well-typed.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> The backwards compatibility impact here is really extremely small,
>>>>>>>> because OverloadedRecordUpdate is essentially unusable at present
>>>>>>>> (as
>>>>>>>> well as being explicitly documented as subject to change), so
>>>>>>>> nobody
>>>>>>>> uses it. While someone could implement a warning when the extension
>>>>>>>> is
>>>>>>>> turned on to say that it will change in the future, I'm not sure I
>>>>>>>> see
>>>>>>>> much point.
>>>>>>>>
>>>>>>>> I used https://hackage-search.serokell.io/?q=OverloadedRecordUpdate
>>>>>>>> to
>>>>>>>> look for occurrences of OverloadedRecordUpdate on Hackage, and I
>>>>>>>> found
>>>>>>>> precisely one pair of packages using it "for real":
>>>>>>>>
>>>>>>>> large-anon-0.3.0
>>>>>>>> large-records-0.4
>>>>>>>>
>>>>>>>> These packages were created by my colleague Edsko in discussion
>>>>>>>> with me,
>>>>>>>> and will need to be amended when the proposal is implemented,
>>>>>>>> because
>>>>>>>> they want to take advantage of the new functionality.
>>>>>>>>
>>>>>>>> The other packages on Hackage containing the string
>>>>>>>> OverloadedRecordUpdate are tools that reference all extensions:
>>>>>>>>
>>>>>>>> Cabal-syntax-3.10.1.0
>>>>>>>> extensions-0.1.0.0
>>>>>>>> fourmolu-0.14.0.0
>>>>>>>> ghc-9.6.3
>>>>>>>> ghc-boot-th-9.6.3
>>>>>>>> ghc-exactprint-1.7.0.1
>>>>>>>> ghc-hs-meta-0.1.2.0
>>>>>>>> ghc-lib-9.6.2.20230523
>>>>>>>> ghc-lib-parser-9.6.2.20230523
>>>>>>>> hackport-0.8.4.0
>>>>>>>> haskell-src-meta-0.8.12
>>>>>>>> hindent-6.1.0
>>>>>>>> hlint-3.6.1
>>>>>>>> ormolu-0.7.2.0
>>>>>>>>
>>>>>>>> plus there are a few references in comments:
>>>>>>>>
>>>>>>>> lifx-lan-0.8.2
>>>>>>>> optics-core-0.4.1.1
>>>>>>>> pvector-0.1.1
>>>>>>>> record-dot-preprocessor-0.2.16
>>>>>>>> tztime-0.1.1.0
>>>>>>>>
>>>>>>>> While I generally agree with the "don't abruptly break existing
>>>>>>>> code"
>>>>>>>> position, in this case I don't think there is code out there to
>>>>>>>> break.
>>>>>>>>
>>>>>>>> Adam
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03/10/2023 01:14, Moritz Angermann wrote:
>>>>>>>> > Arnaud,
>>>>>>>> >
>>>>>>>> > thank you for your write up. And sorry that my view seems to be
>>>>>>>> not
>>>>>>>> > clear. Let me try to explain.
>>>>>>>> > My position is: I'm against anything that _abruptly_ breaks
>>>>>>>> existing
>>>>>>>> > code. That's basically all there is to it.
>>>>>>>> > Therefore I'm strongly against breaking changes without an
>>>>>>>> appropriate
>>>>>>>> > warning period (from the compiler).
>>>>>>>> > I also strongly believe that most people do not read
>>>>>>>> documentation, and
>>>>>>>> > the authoritative messages are
>>>>>>>> > the ones the compiler produces. As I've alluded to in a different
>>>>>>>> email,
>>>>>>>> > there are lots of people who work
>>>>>>>> > on software as a 9-5 job, and don't spend their freetime
>>>>>>>> tinkering and
>>>>>>>> > playing with languages. They just
>>>>>>>> > want to get the job done they are assigned. I have a lot of
>>>>>>>> respect for
>>>>>>>> > them. In my experience they don't
>>>>>>>> > read compiler release announcements, or even go and read the
>>>>>>>> compiler
>>>>>>>> > documentation. They are given
>>>>>>>> > the compiler version the company decided on for use in
>>>>>>>> production.
>>>>>>>> > That's the tool they use. And that tool
>>>>>>>> > in my opinion needs to be rock solid, and not break easily across
>>>>>>>> > versions. Thus yes, I would very much
>>>>>>>> > like to see us not have breaking changes at all, but I can see
>>>>>>>> that we
>>>>>>>> > may need breaking changes
>>>>>>>> > occasionally. In those cases I want it to be very visible to the
>>>>>>>> > consumers that this breaking change is
>>>>>>>> > coming towards them (compiler warnings). Giving them some time to
>>>>>>>> adjust
>>>>>>>> > (migration period), until the
>>>>>>>> > breaking change happens.  Ultimately we should be able to
>>>>>>>> compiler
>>>>>>>> > existing code that compiles today
>>>>>>>> > with at least the next compiler without it rejecting the code or
>>>>>>>> needing
>>>>>>>> > modifications to the code (-Werror
>>>>>>>> > excluded).
>>>>>>>> >
>>>>>>>> > Thus what I'm arguing for is:
>>>>>>>> > - Let's implement this backwards compatibility.
>>>>>>>> > - Add compiler warnings about the arguments being swapped in a
>>>>>>>> future
>>>>>>>> > GHC version. For _a least_ one major release.
>>>>>>>> > - Make the breaking change in a subsequent release.
>>>>>>>> >
>>>>>>>> > Alternatively I could also see:
>>>>>>>> > - Adding compiler warnings now that the arguments will be swapped
>>>>>>>> in a
>>>>>>>> > future GHC version (for at least one major release).
>>>>>>>> > - Implement the breaking change in a subsequent release.
>>>>>>>> >
>>>>>>>> > Either of those would be ok with me. Implementing a breaking
>>>>>>>> change from
>>>>>>>> > one version to the next, without an
>>>>>>>> > appropriate deprecation/migration period (that is, the compiler
>>>>>>>> will
>>>>>>>> > warn loudly that changes are coming) is something
>>>>>>>> > I am _very_ vehemently against.
>>>>>>>> >
>>>>>>>> > If the migration/deprecation warnings would provide a link to a
>>>>>>>> GitHub
>>>>>>>> > ticket or something where more information
>>>>>>>> > can be found and maybe even a discussion could be had would
>>>>>>>> probably
>>>>>>>> > also be a good idea.
>>>>>>>> >
>>>>>>>> > I hope this helps clarify my position? If not, feel free to ask
>>>>>>>> more,
>>>>>>>> > I'm also happy to jump onto a call to explain my
>>>>>>>> > position if needed.
>>>>>>>> >
>>>>>>>> > Best,
>>>>>>>> >   Moritz
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Mon, 2 Oct 2023 at 23:31, Arnaud Spiwack <
>>>>>>>> arnaud.spiwack at tweag.io
>>>>>>>> > <mailto:arnaud.spiwack at tweag.io>> wrote:
>>>>>>>> >
>>>>>>>> >     Sorry I took a little bit of time to react to this, it was a
>>>>>>>> lot to
>>>>>>>> >     take in and I didn't have the mental space last week.
>>>>>>>> >
>>>>>>>> >     The only person that may have spoken against the current
>>>>>>>> state of
>>>>>>>> >     the proposal is Moritz. Yet I realise that I don't actually
>>>>>>>> know,
>>>>>>>> >     Moritz, what your position is.
>>>>>>>> >
>>>>>>>> >     To recap: to use -XOverloadedRecordUpdate in current GHC, you
>>>>>>>> need
>>>>>>>> >     to use -XRebindableSyntax and provide a setField function. In
>>>>>>>> the
>>>>>>>> >     new proposal you can use -XOverloadedRecordUpdate without
>>>>>>>> >     -XRebindableSyntax, but when -XRebindableSyntax is on, the
>>>>>>>> setField
>>>>>>>> >     function that you have to provide has its argument swapped.
>>>>>>>> The
>>>>>>>> >     current documentation of OverloadedRecordUpdate has the
>>>>>>>> following
>>>>>>>> >     text at the top “*EXPERIMENTAL* /This design of this
>>>>>>>> extension may
>>>>>>>> >     well change in the future. It would be inadvisable to start
>>>>>>>> using
>>>>>>>> >     this extension for long-lived libraries just yet./”.
>>>>>>>> >
>>>>>>>> >     Now, I don't quite see how we could have a transition period
>>>>>>>> that
>>>>>>>> >     would allow a smooth transition there. There is no piece of
>>>>>>>> code,
>>>>>>>> >     with RebindableSyntax, that would compile before and after the
>>>>>>>> >     change. So unless I'm missing something the position we can
>>>>>>>> take as
>>>>>>>> >     a committee can be either
>>>>>>>> >     - Let's have the breakage without a transition period
>>>>>>>> >     - Let's not make the breaking change ever and use the earlier
>>>>>>>> >     argument order for set
>>>>>>>> >
>>>>>>>> >     Which one do you argue for, or am I missing another option?
>>>>>>>> >
>>>>>>>> >     On Sun, 24 Sept 2023 at 15:36, Eric Seidel <eric at seidel.io
>>>>>>>> >     <mailto:eric at seidel.io>> wrote:
>>>>>>>> >
>>>>>>>> >         I am in favor of this proposal.
>>>>>>>> >
>>>>>>>> >         On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
>>>>>>>> >          > Dear all.
>>>>>>>> >          >
>>>>>>>> >          > I submitted my recommendation 3 weeks ago, and only
>>>>>>>> Simon has
>>>>>>>> >         commented
>>>>>>>> >          > yet. Please let me know your thoughts.
>>>>>>>> >          >
>>>>>>>> >          > On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack
>>>>>>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>>>>>>> wrote:
>>>>>>>> >          >> Dear all,
>>>>>>>> >          >>
>>>>>>>> >          >> Don't forget to opine here. To reiterate, I really
>>>>>>>> don't
>>>>>>>> >         expect the proposal to be controversial. The text of the
>>>>>>>> >         proposal is rather long, but is made easy to read. So it
>>>>>>>> >         shouldn't take too much of your time.
>>>>>>>> >          >>
>>>>>>>> >          >> /Arnaud
>>>>>>>> >          >>
>>>>>>>> >          >> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones
>>>>>>>> >         <simon.peytonjones at gmail.com
>>>>>>>> >         <mailto:simon.peytonjones at gmail.com>> wrote:
>>>>>>>> >          >>> I support acceptance.
>>>>>>>> >          >>>
>>>>>>>> >          >>> Simon
>>>>>>>> >          >>>
>>>>>>>> >          >>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack
>>>>>>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>>>>>>> wrote:
>>>>>>>> >          >>>> Dear all,
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> [ Proposal #583
>>>>>>>> >         https://github.com/ghc-proposals/ghc-proposals/pull/583
>>>>>>>> >         <https://github.com/ghc-proposals/ghc-proposals/pull/583>
>>>>>>>> ]
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> Our own Adam proposes to amend the design of the
>>>>>>>> highly
>>>>>>>> >         experimental OverloadedRecordUpdate extension as had been
>>>>>>>> >         designed in proposal #158 [
>>>>>>>> >
>>>>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>>>>>>>> <
>>>>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst>
>>>>>>>> ] and #405 [
>>>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/405 <
>>>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/405> ].
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> Specifically, Adam proposes a modification of the
>>>>>>>> type
>>>>>>>> >         classes that would back the extension.
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> In the previous design the HasField class is
>>>>>>>> defined as a
>>>>>>>> >         lens:
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>>>>>>> >          >>>>   hasField :: r -> (a -> r, a)
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> The proposal is to replace it by two classes
>>>>>>>> (slightly
>>>>>>>> >         simplified)
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>>>>>>> >          >>>>   hasField :: r -> a
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> class SetField (n::k) r a | r n -> a
>>>>>>>> >          >>>>   modifyField :: (a -> a) -> r -> a
>>>>>>>> >          >>>>   setField :: a -> r -> a
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> This is originally motivated by some performance
>>>>>>>> >         consideration: the prototype implementation of HasField
>>>>>>>> as a
>>>>>>>> >         lens can be very time consuming because instances of
>>>>>>>> HasFields
>>>>>>>> >         are generated eagerly at record definition sites, whereas
>>>>>>>> the
>>>>>>>> >         simple HasField instances can simply reuse the selectors
>>>>>>>> already
>>>>>>>> >         generated by GHC. But a lot of thoughts have been put
>>>>>>>> into the
>>>>>>>> >         new design, and my summary can certainly not do it
>>>>>>>> justice: the
>>>>>>>> >         proposal is very well argumented.
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> A point I'll make here is that the new design is
>>>>>>>> actually
>>>>>>>> >         parametric in the data representation of the field type.
>>>>>>>> >         Something that wasn't possible in the original design.
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> This proposal is not technically backward
>>>>>>>> compatible,
>>>>>>>> >         because the order of argument in which
>>>>>>>> OverloadedRecordUpdate
>>>>>>>> >         expects the argument of setField is changed. This is not
>>>>>>>> >         essential to the proposal, but this is a more consistent
>>>>>>>> order
>>>>>>>> >         argument with the rest of Haskell. And considering that
>>>>>>>> >         OverloadedRecordUpdate is very loudly advertised as
>>>>>>>> >         experimental, I recommend accepting this breakage.
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> Overall the proposal is actually more backward
>>>>>>>> compatible
>>>>>>>> >         with GHC 9.8 than the original design, as the HasField
>>>>>>>> class is
>>>>>>>> >         left unchanged.
>>>>>>>> >          >>>>
>>>>>>>> >          >>>> Overall, the proposal looks quite reasonable to me,
>>>>>>>> and
>>>>>>>> >         well-argued. I recommend acceptance.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Arnaud Spiwack
>>>>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>


-- 
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/20231009/06278b2d/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Oct  9 08:09:39 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 9 Oct 2023 09:09:39 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
Message-ID: <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>

>
> I remain opposed to this proposal in its current form, at least until I
> can understand why the changes have to be made outside of the framework for
> change we are trying to establish.
>

Chris, can you just lay out "the framework for change we are trying to
establish"?  I accept the importance of the considerations you describe, in
this email and in your gist.  So I understand what you are arguing *against*;
but I don't yet see what you are arguing *for*.

It's hard to argue against "a framework that will remove a lot of friction
in making changes, and also remove key stressors from all those maintaining
the critical infrastructure outside of the core tools that make Haskell
truly viable for real-world development".   But what, precisely, do you
have in mind?

And in the context of this specific proposal, what are you arguing for?

Thanks. Sorry to be dim.

Simon


On Sun, 8 Oct 2023 at 19:12, Chris Dornan <chris at chrisdornan.com> wrote:

> The discussion of this proposal has really boiled down to how we roll this
> change out. I think it is important to understand why some of us have been
> pleading for us to follow agreed processes when making these changes,
> starting with this proposal, so I have written up some notes on why I think
> it is important to adopt a process for these kinds of changes and endeavour
> to stick to it.
>
> We have a mechanism for getting everything the proposers want using
> established mechanisms. Why don't we follow them? If an urgent need had
> arisen to make this change then it would be easily understandable but this
> is proposal addressing a longstanding issue.
>
> I get the sense that folks fear that there is a big push to freeze
> GHC/Haskell in its current configuration (or at least make it very
> difficult to change anything) to satisfy those that want to just make stuff
> with Haskell and stop all the experimentation and language development, and
> that this push needs to be stopped before it gathers any more momentum. I
> don't think this is all gamed out -- more a feeling or a vibe informing the
> debate.
>
> I strongly believe this is a misunderstanding, and certainly where the
> proponents of these proposed protocols are concerned, nothing could be
> further from the truth. Properly understood, we want to create a framework
> that will remove a lot of friction in making changes, and also remove key
> stressors from all those maintaining the critical infrastructure outside of
> the core tools that make Haskell truly viable for real-world development.
>
> I have written up my thoughts in this gist
> <https://gist.github.com/cdornan/68267aa63546e5d674cc8d083510c3e3>,
> explaining why I think we need the framework and why we should hold to it
> without good reason to do otherwise. Feel free to respond there or here as
> you see fit.
>
> I remain opposed to this proposal in its current form, at least until I
> can understand why the changes have to be made outside of the framework for
> change we are trying to establish.
>
> Chris
>
>
>
> On 5 Oct 2023, at 18:07, Simon Marlow <marlowsd at gmail.com> wrote:
>
> Ah thanks, I forgot GHC2021 was the default (I'm personally stuck using
> pre-GHC2021 myself).
>
> In that case, I'm suggesting that we enable -Werror=severe in the next
> GHC20xx iteration, and leave GHC2021 etc. unaffected.
>
> Cheers
> Simon
>
>
> On Thu, 5 Oct 2023, 07:56 Adam Gundry, <adam at well-typed.com> wrote:
>
>> On 04/10/2023 22:04, Simon Marlow wrote:
>> > My concrete suggestion is we EITHER
>> >
>> >   * Enable -Werror=severe in future GHC20xx versions only, or
>> >   * Enable it by default and in future GHC20xx versions, but not in
>> >     GHC2021, Haskell2010, or Haskell98
>>
>> Sorry, I don't quite understand the difference between these options.
>> What does it mean to enable -Werror=severe by default but not in
>> GHC2021, given that GHC2021 is the (current) default?
>>
>> Cheers,
>>
>> Adam
>>
>>
>> > On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones
>> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>> wrote:
>> >
>> >     I must say that I am strongly influenced by the fact that
>> >
>> >       * Matt Parsons
>> >       * Andrew Lelechenko (bodigrim)
>> >
>> >     are both not just in favour, but *strongly *in favour.  They must
>> >     think of the case as compelling, because they are both usually very
>> >     careful about unnecessary breakage.
>> >
>> >         if we make -Werror=severe the default, then any new warning
>> >         added to -Wsevere is a new breaking change, and we would have to
>> >         judge it to be compelling enough by GR2
>> >
>> >
>> >     Yes indeed.  But that's not a bug -- it's a feature.
>> >
>> >     To be clear I have no strongly held opinion myself.   Perhaps we
>> >     should canvas opinion among people using Haskell in production? We
>> >     did so with CLC but we could do so publicly.
>> >
>> >     Simon
>> >
>> >     On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com
>> >     <mailto:marlowsd at gmail.com>> wrote:
>> >
>> >         I don't think this breaking change (namely making -Werror=severe
>> >         the default) meets the bar for "compelling reason" according to
>> >         GR2 of our proposed policy, so I'm voting against. It's
>> >         certainly not a bug or a security hole. Maybe you could argue
>> >         that it's a design flaw in the language, but I'm not all that
>> >         convinced. It's an unforced breaking change in my opinion. If we
>> >         add "makes it more difficult to shoot yourself in the foot" a
>> >         compelling enough reason to break GR1 then I think we've
>> >         weakened it significantly.
>> >
>> >         Here's another problem: if we make -Werror=severe the default,
>> >         then any new warning added to -Wsevere is a new breaking change,
>> >         and we would have to judge it to be compelling enough by GR2. If
>> >         we don't make -Werror=severe the default, then we're not
>> >         restricted in what we can add to -Wsevere. Probably -Wsevere
>> >         would end up being more useful as a result.
>> >
>> >         Cheers
>> >         Simon
>> >
>> >
>> >         On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones
>> >         <simon.peytonjones at gmail.com
>> >         <mailto:simon.peytonjones at gmail.com>> wrote:
>> >
>> >             Here's my summary:
>> >
>> >               * There is strong (universal, even) support for the
>> >                 `severe` category.
>> >               * There is pretty strong support for making severe
>> >                 warnings into errors at some point.  As Matt puts it
>> >                 "this is not a question of GHC breaking things, but
>> >                 rather /revealing/ and providing early-diagnosis for
>> >                 /already broken/ things".
>> >               * But I think we are moving towards a policy of giving
>> >                 users time to adapt via a deprecation cycle, whenever
>> >                 that is feasible.  And it is feasible here.
>> >
>> >             So my suggestion would be:
>> >
>> >               * When implemented, make `-Wwarn=severe` the default, but
>> >                 add to each severe warning a deprecation-style message
>> >                 saying that it'll become an error in the next iteration.
>> >               * In the next released, make `-Werror=severe` the default.
>> >               * Don't complicate matters by involving GHC2024.  That is
>> >                 another conversation, and even if we wanted to include
>> >                 `-Werorr=severe` in GHC2024, we would *still* want a
>> >                 deprecation cycle!
>> >
>> >             Would that be acceptable?
>> >
>> >             Simon
>> >
>> >             On Fri, 29 Sept 2023 at 19:41, Adam Gundry
>> >             <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>> >
>> >                 Dear Committee,
>> >
>> >                 It seems we are somewhat split on the -Wsevere proposal,
>> >                 even assuming
>> >                 it is introduced with a deprecation period (changing the
>> >                 warning text
>> >                 and adding the group in advance). There is consensus
>> >                 that adding the
>> >                 group by itself is fine, and potentially enabling
>> >                 -Werror=severe under
>> >                 GHC2024, but enabling it by default for existing code is
>> >                 more controversial.
>> >
>> >                 Ultimately this is a judgement call about the value of
>> >                 the proposal
>> >                 versus the breakage it causes. I remain of the view that
>> >                 it is
>> >                 worthwhile. This is not merely about more aggressively
>> >                 enforcing best
>> >                 practice. Rather, it eliminates the risk of the
>> following:
>> >
>> >                 * Suppose package A defines a type class, package B
>> >                 depends on package
>> >                 A, and package C depends on package B.
>> >
>> >                 * Now package A extends the type class definition with a
>> >                 new method and
>> >                 default methods. Everything still compiles; package B
>> >                 now issues a
>> >                 -Wmissing-methods warning (but is not actively
>> >                 maintained, and the
>> >                 author of package C is unlikely to look at warnings in
>> >                 all their
>> >                 dependencies).
>> >
>> >                 * Users of package C have to try to debug an infinite
>> loop.
>> >
>> >                 Given that this change avoids a significant issue,
>> >                 affected code has
>> >                 been issuing warnings for many years, and impacted users
>> >                 can very easily
>> >                 set -Wwarn=severe either at the package level or the
>> >                 project level, I
>> >                 think is worth accepting the backwards compatibility
>> >                 cost and the fact
>> >                 that some Haskell2010 code will no longer be accepted by
>> >                 default.
>> >
>> >                 Matt Parsons puts it well in the CLC thread, which is
>> >                 pretty clearly in
>> >                 favour of this proposal overall
>> >                 (
>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>> <
>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>> >):
>> >
>> >                   > I think GHC should strive to make fewer breaking
>> >                 changes, and make
>> >                 those changes as easy-to-adopt as possible. But this is
>> >                 not a question
>> >                 of GHC breaking things, but rather revealing and
>> providing
>> >                 early-diagnosis for already broken things.
>> >
>> >                 Further opinions are welcome, of course.
>> >
>> >                 Adam
>> >
>> >
>> >                 On 14/09/2023 09:32, Adam Gundry wrote:
>> >                  > Dear Committee,
>> >                  >
>> >                  > Joachim, along with Oleg Grenrus, proposes to change
>> >                 -Wmissing-methods
>> >                  > and -Wmissing-fields warnings into errors by default
>> >                 (retaining the
>> >                  > option to downgrade them). I recommend we accept the
>> >                 proposal.
>> >                  >
>> >                  > Proposal:
>> >                 https://github.com/ghc-proposals/ghc-proposals/pull/571
>> >                 <
>> https://github.com/ghc-proposals/ghc-proposals/pull/571>
>> >                  > Rendered:
>> >                  >
>> >
>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>> <
>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>> >
>> >                  >
>> >                  > This is primarily motivated by the fact that when
>> >                 classes have default
>> >                  > methods, missing methods can lead to runtime loops,
>> >                 which are generally
>> >                  > difficult to debug. Since in practice not all users
>> >                 pay attention to
>> >                  > warnings that do not inhibit compilation, it makes
>> >                 sense to identify a
>> >                  > class of warnings that are sufficiently serious to
>> >                 require explicit
>> >                  > action from the user to silence them.
>> >                  >
>> >                  > Since these warnings are currently not errors by
>> >                 default, library
>> >                  > authors experimentally assessing the impact of
>> >                 changes may be lead to
>> >                  > assume that introducing new methods/fields does not
>> >                 lead to breakage
>> >                  > (because downstream code will still compile). The
>> >                 proposal thus makes it
>> >                  > more obvious that adding a new method or field is a
>> >                 breaking change.
>> >                  >
>> >                  > The proposal deliberately causes builds to fail by
>> >                 default for some
>> >                  > libraries that currently emit warnings. Oleg has
>> >                 kindly performed impact
>> >                  > assessments to identify such libraries, and the
>> >                 breakage of a few
>> >                  > packages seems worth the cost.
>> >                  >
>> >                  > It is easy to restore the warnings to their previous
>> >                 classification by
>> >                  > passing an option at build time, e.g. using
>> >                 -Wno-error=missing-methods.
>> >                  > Users can set such an option in cabal.project or
>> >                 stack.yaml to work
>> >                  > around breakage that is not promptly fixed by the
>> >                 library author.
>> >                  >
>> >                  > This change does mean that GHC with -XHaskell98/2010
>> >                 will by default
>> >                  > reject some programs that are explicitly permitted by
>> >                 the Haskell98/2010
>> >                  > specification. I recommend we document this
>> >                 infelicity, but accept it,
>> >                  > as much of the benefit of the proposal is that it
>> >                 applies by default.
>> >                  >
>> >                  > The proposal establishes the precedent that some
>> >                 warnings may be treated
>> >                  > as errors by default, and introduces a warning group
>> >                 -Wsevere to
>> >                  > classify them. This seems conceptually useful and
>> >                 gives us the option to
>> >                  > extend the -Wsevere set in the future (e.g. as a
>> >                 final stage of
>> >                  > deprecation before a feature is removed).
>> >                  >
>> >                  > Thoughts?
>> >                  >
>> >                  > Adam
>> >                  >
>> >                  >
>> >                  > On 11/09/2023 20:25, Joachim Breitner wrote:
>> >                  >> Dear Committee,
>> >                  >>
>> >                  >> based on suggestions by Oleg Grenrus, I wrote a
>> >                 proposal to introduce a
>> >                  >> warning group -Wsevere for on-by-defaults,
>> >                 error-by-default warnings,
>> >                  >> and initially fill it with missing-methods and
>> >                 missing-fields.
>> >                  >>
>> >                  >>
>> >                  >>
>> >                 https://github.com/ghc-proposals/ghc-proposals/pull/571
>> >                 <
>> https://github.com/ghc-proposals/ghc-proposals/pull/571>
>> >                  >>
>> >                  >>
>> >
>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>> <
>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>> >
>> >                  >>
>> >                  >> I’d like to nominate Adam as the shepherd, who
>> >                 already reviewed it a
>> >                  >> bit on Github.
>> >                  >>
>> >                  >> Please guide us to a conclusion as outlined in
>> >                  >>
>> >
>> https://github.com/ghc-proposals/ghc-proposals#committee-process <
>> https://github.com/ghc-proposals/ghc-proposals#committee-process>
>> >                  >>
>> >                  >>
>> >                  >> Cheers,
>> >                  >> Joachim
>>
>>
>> --
>> 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/20231009/58bcf7b6/attachment-0001.html>

From chris at chrisdornan.com  Mon Oct  9 08:45:29 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 9 Oct 2023 09:45:29 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
Message-ID: <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>

When I refer to `the framework` I was thinking of the GHC Stability Policy document that you created (where we try not to introduce breaking changes, but when we do we use deprecation cycles unless there is a good reason not to).

My favoured solution is to predicate this new behaviour on a language extension and incorporate that into GHC2024 -- that could be done using established mechanisms -- but my overriding concern is that the changes in behaviour be fitted into the framework for introducing breaking changes that we have been discussing these past few weeks in the GHC Stability Policy document.

The key to me is that it be fitted into an agreed policy for making breaking changes, not that it adhere to my particular preferences, or the state of a particular proposal under discussion -- hence my somewhat abstract choice of terms.

Is that clear? I don't want to prescribe here (though I have preferences) but please give me something that could plausibly be part of a general policy for introducing breaking changes moving forward.

Chris

> On 9 Oct 2023, at 09:09, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
>> I remain opposed to this proposal in its current form, at least until I can understand why the changes have to be made outside of the framework for change we are trying to establish.
> 
> Chris, can you just lay out "the framework for change we are trying to establish"?  I accept the importance of the considerations you describe, in this email and in your gist.  So I understand what you are arguing against; but I don't yet see what you are arguing for.
> 
> It's hard to argue against "a framework that will remove a lot of friction in making changes, and also remove key stressors from all those maintaining the critical infrastructure outside of the core tools that make Haskell truly viable for real-world development".   But what, precisely, do you have in mind?  
> 
> And in the context of this specific proposal, what are you arguing for?
> 
> Thanks. Sorry to be dim.
> 
> Simon
>  
> 
> On Sun, 8 Oct 2023 at 19:12, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>> 
>> The discussion of this proposal has really boiled down to how we roll this change out. I think it is important to understand why some of us have been pleading for us to follow agreed processes when making these changes, starting with this proposal, so I have written up some notes on why I think it is important to adopt a process for these kinds of changes and endeavour to stick to it.
>> 
>> We have a mechanism for getting everything the proposers want using established mechanisms. Why don't we follow them? If an urgent need had arisen to make this change then it would be easily understandable but this is proposal addressing a longstanding issue.
>> 
>> I get the sense that folks fear that there is a big push to freeze GHC/Haskell in its current configuration (or at least make it very difficult to change anything) to satisfy those that want to just make stuff with Haskell and stop all the experimentation and language development, and that this push needs to be stopped before it gathers any more momentum. I don't think this is all gamed out -- more a feeling or a vibe informing the debate.
>> 
>> I strongly believe this is a misunderstanding, and certainly where the proponents of these proposed protocols are concerned, nothing could be further from the truth. Properly understood, we want to create a framework that will remove a lot of friction in making changes, and also remove key stressors from all those maintaining the critical infrastructure outside of the core tools that make Haskell truly viable for real-world development.
>> 
>> I have written up my thoughts in this gist <https://gist.github.com/cdornan/68267aa63546e5d674cc8d083510c3e3>, explaining why I think we need the framework and why we should hold to it without good reason to do otherwise. Feel free to respond there or here as you see fit.
>> 
>> I remain opposed to this proposal in its current form, at least until I can understand why the changes have to be made outside of the framework for change we are trying to establish.
>> 
>> Chris
>>  
>> 
>> 
>>> On 5 Oct 2023, at 18:07, Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>> wrote:
>>> 
>>> Ah thanks, I forgot GHC2021 was the default (I'm personally stuck using pre-GHC2021 myself).
>>> 
>>> In that case, I'm suggesting that we enable -Werror=severe in the next GHC20xx iteration, and leave GHC2021 etc. unaffected.
>>> 
>>> Cheers
>>> Simon
>>> 
>>> 
>>> On Thu, 5 Oct 2023, 07:56 Adam Gundry, <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>>>> On 04/10/2023 22:04, Simon Marlow wrote:
>>>> > My concrete suggestion is we EITHER
>>>> > 
>>>> >   * Enable -Werror=severe in future GHC20xx versions only, or
>>>> >   * Enable it by default and in future GHC20xx versions, but not in
>>>> >     GHC2021, Haskell2010, or Haskell98
>>>> 
>>>> Sorry, I don't quite understand the difference between these options. 
>>>> What does it mean to enable -Werror=severe by default but not in 
>>>> GHC2021, given that GHC2021 is the (current) default?
>>>> 
>>>> Cheers,
>>>> 
>>>> Adam
>>>> 
>>>> 
>>>> > On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones 
>>>> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com> <mailto:simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>> wrote:
>>>> > 
>>>> >     I must say that I am strongly influenced by the fact that
>>>> > 
>>>> >       * Matt Parsons
>>>> >       * Andrew Lelechenko (bodigrim)
>>>> > 
>>>> >     are both not just in favour, but *strongly *in favour.  They must
>>>> >     think of the case as compelling, because they are both usually very
>>>> >     careful about unnecessary breakage.
>>>> > 
>>>> >         if we make -Werror=severe the default, then any new warning
>>>> >         added to -Wsevere is a new breaking change, and we would have to
>>>> >         judge it to be compelling enough by GR2
>>>> > 
>>>> > 
>>>> >     Yes indeed.  But that's not a bug -- it's a feature.
>>>> > 
>>>> >     To be clear I have no strongly held opinion myself.   Perhaps we
>>>> >     should canvas opinion among people using Haskell in production? We
>>>> >     did so with CLC but we could do so publicly.
>>>> > 
>>>> >     Simon
>>>> > 
>>>> >     On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>
>>>> >     <mailto:marlowsd at gmail.com <mailto:marlowsd at gmail.com>>> wrote:
>>>> > 
>>>> >         I don't think this breaking change (namely making -Werror=severe
>>>> >         the default) meets the bar for "compelling reason" according to
>>>> >         GR2 of our proposed policy, so I'm voting against. It's
>>>> >         certainly not a bug or a security hole. Maybe you could argue
>>>> >         that it's a design flaw in the language, but I'm not all that
>>>> >         convinced. It's an unforced breaking change in my opinion. If we
>>>> >         add "makes it more difficult to shoot yourself in the foot" a
>>>> >         compelling enough reason to break GR1 then I think we've
>>>> >         weakened it significantly.
>>>> > 
>>>> >         Here's another problem: if we make -Werror=severe the default,
>>>> >         then any new warning added to -Wsevere is a new breaking change,
>>>> >         and we would have to judge it to be compelling enough by GR2. If
>>>> >         we don't make -Werror=severe the default, then we're not
>>>> >         restricted in what we can add to -Wsevere. Probably -Wsevere
>>>> >         would end up being more useful as a result.
>>>> > 
>>>> >         Cheers
>>>> >         Simon
>>>> > 
>>>> > 
>>>> >         On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones
>>>> >         <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>
>>>> >         <mailto:simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>> wrote:
>>>> > 
>>>> >             Here's my summary:
>>>> > 
>>>> >               * There is strong (universal, even) support for the
>>>> >                 `severe` category.
>>>> >               * There is pretty strong support for making severe
>>>> >                 warnings into errors at some point.  As Matt puts it
>>>> >                 "this is not a question of GHC breaking things, but
>>>> >                 rather /revealing/ and providing early-diagnosis for
>>>> >                 /already broken/ things".
>>>> >               * But I think we are moving towards a policy of giving
>>>> >                 users time to adapt via a deprecation cycle, whenever
>>>> >                 that is feasible.  And it is feasible here.
>>>> > 
>>>> >             So my suggestion would be:
>>>> > 
>>>> >               * When implemented, make `-Wwarn=severe` the default, but
>>>> >                 add to each severe warning a deprecation-style message
>>>> >                 saying that it'll become an error in the next iteration.
>>>> >               * In the next released, make `-Werror=severe` the default.
>>>> >               * Don't complicate matters by involving GHC2024.  That is
>>>> >                 another conversation, and even if we wanted to include
>>>> >                 `-Werorr=severe` in GHC2024, we would *still* want a
>>>> >                 deprecation cycle!
>>>> > 
>>>> >             Would that be acceptable?
>>>> > 
>>>> >             Simon
>>>> > 
>>>> >             On Fri, 29 Sept 2023 at 19:41, Adam Gundry
>>>> >             <adam at well-typed.com <mailto:adam at well-typed.com> <mailto:adam at well-typed.com <mailto:adam at well-typed.com>>> wrote:
>>>> > 
>>>> >                 Dear Committee,
>>>> > 
>>>> >                 It seems we are somewhat split on the -Wsevere proposal,
>>>> >                 even assuming
>>>> >                 it is introduced with a deprecation period (changing the
>>>> >                 warning text
>>>> >                 and adding the group in advance). There is consensus
>>>> >                 that adding the
>>>> >                 group by itself is fine, and potentially enabling
>>>> >                 -Werror=severe under
>>>> >                 GHC2024, but enabling it by default for existing code is
>>>> >                 more controversial.
>>>> > 
>>>> >                 Ultimately this is a judgement call about the value of
>>>> >                 the proposal
>>>> >                 versus the breakage it causes. I remain of the view that
>>>> >                 it is
>>>> >                 worthwhile. This is not merely about more aggressively
>>>> >                 enforcing best
>>>> >                 practice. Rather, it eliminates the risk of the following:
>>>> > 
>>>> >                 * Suppose package A defines a type class, package B
>>>> >                 depends on package
>>>> >                 A, and package C depends on package B.
>>>> > 
>>>> >                 * Now package A extends the type class definition with a
>>>> >                 new method and
>>>> >                 default methods. Everything still compiles; package B
>>>> >                 now issues a
>>>> >                 -Wmissing-methods warning (but is not actively
>>>> >                 maintained, and the
>>>> >                 author of package C is unlikely to look at warnings in
>>>> >                 all their
>>>> >                 dependencies).
>>>> > 
>>>> >                 * Users of package C have to try to debug an infinite loop.
>>>> > 
>>>> >                 Given that this change avoids a significant issue,
>>>> >                 affected code has
>>>> >                 been issuing warnings for many years, and impacted users
>>>> >                 can very easily
>>>> >                 set -Wwarn=severe either at the package level or the
>>>> >                 project level, I
>>>> >                 think is worth accepting the backwards compatibility
>>>> >                 cost and the fact
>>>> >                 that some Haskell2010 code will no longer be accepted by
>>>> >                 default.
>>>> > 
>>>> >                 Matt Parsons puts it well in the CLC thread, which is
>>>> >                 pretty clearly in
>>>> >                 favour of this proposal overall
>>>> >                 (https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889 <https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889>):
>>>> > 
>>>> >                   > I think GHC should strive to make fewer breaking
>>>> >                 changes, and make
>>>> >                 those changes as easy-to-adopt as possible. But this is
>>>> >                 not a question
>>>> >                 of GHC breaking things, but rather revealing and providing
>>>> >                 early-diagnosis for already broken things.
>>>> > 
>>>> >                 Further opinions are welcome, of course.
>>>> > 
>>>> >                 Adam
>>>> > 
>>>> > 
>>>> >                 On 14/09/2023 09:32, Adam Gundry wrote:
>>>> >                  > Dear Committee,
>>>> >                  >
>>>> >                  > Joachim, along with Oleg Grenrus, proposes to change
>>>> >                 -Wmissing-methods
>>>> >                  > and -Wmissing-fields warnings into errors by default
>>>> >                 (retaining the
>>>> >                  > option to downgrade them). I recommend we accept the
>>>> >                 proposal.
>>>> >                  >
>>>> >                  > Proposal:
>>>> >                 https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>> >                 <https://github.com/ghc-proposals/ghc-proposals/pull/571>
>>>> >                  > Rendered:
>>>> >                  >
>>>> >                 https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst>
>>>> >                  >
>>>> >                  > This is primarily motivated by the fact that when
>>>> >                 classes have default
>>>> >                  > methods, missing methods can lead to runtime loops,
>>>> >                 which are generally
>>>> >                  > difficult to debug. Since in practice not all users
>>>> >                 pay attention to
>>>> >                  > warnings that do not inhibit compilation, it makes
>>>> >                 sense to identify a
>>>> >                  > class of warnings that are sufficiently serious to
>>>> >                 require explicit
>>>> >                  > action from the user to silence them.
>>>> >                  >
>>>> >                  > Since these warnings are currently not errors by
>>>> >                 default, library
>>>> >                  > authors experimentally assessing the impact of
>>>> >                 changes may be lead to
>>>> >                  > assume that introducing new methods/fields does not
>>>> >                 lead to breakage
>>>> >                  > (because downstream code will still compile). The
>>>> >                 proposal thus makes it
>>>> >                  > more obvious that adding a new method or field is a
>>>> >                 breaking change.
>>>> >                  >
>>>> >                  > The proposal deliberately causes builds to fail by
>>>> >                 default for some
>>>> >                  > libraries that currently emit warnings. Oleg has
>>>> >                 kindly performed impact
>>>> >                  > assessments to identify such libraries, and the
>>>> >                 breakage of a few
>>>> >                  > packages seems worth the cost.
>>>> >                  >
>>>> >                  > It is easy to restore the warnings to their previous
>>>> >                 classification by
>>>> >                  > passing an option at build time, e.g. using
>>>> >                 -Wno-error=missing-methods.
>>>> >                  > Users can set such an option in cabal.project or
>>>> >                 stack.yaml to work
>>>> >                  > around breakage that is not promptly fixed by the
>>>> >                 library author.
>>>> >                  >
>>>> >                  > This change does mean that GHC with -XHaskell98/2010
>>>> >                 will by default
>>>> >                  > reject some programs that are explicitly permitted by
>>>> >                 the Haskell98/2010
>>>> >                  > specification. I recommend we document this
>>>> >                 infelicity, but accept it,
>>>> >                  > as much of the benefit of the proposal is that it
>>>> >                 applies by default.
>>>> >                  >
>>>> >                  > The proposal establishes the precedent that some
>>>> >                 warnings may be treated
>>>> >                  > as errors by default, and introduces a warning group
>>>> >                 -Wsevere to
>>>> >                  > classify them. This seems conceptually useful and
>>>> >                 gives us the option to
>>>> >                  > extend the -Wsevere set in the future (e.g. as a
>>>> >                 final stage of
>>>> >                  > deprecation before a feature is removed).
>>>> >                  >
>>>> >                  > Thoughts?
>>>> >                  >
>>>> >                  > Adam
>>>> >                  >
>>>> >                  >
>>>> >                  > On 11/09/2023 20:25, Joachim Breitner wrote:
>>>> >                  >> Dear Committee,
>>>> >                  >>
>>>> >                  >> based on suggestions by Oleg Grenrus, I wrote a
>>>> >                 proposal to introduce a
>>>> >                  >> warning group -Wsevere for on-by-defaults,
>>>> >                 error-by-default warnings,
>>>> >                  >> and initially fill it with missing-methods and
>>>> >                 missing-fields.
>>>> >                  >>
>>>> >                  >>
>>>> >                  >>
>>>> >                 https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>> >                 <https://github.com/ghc-proposals/ghc-proposals/pull/571>
>>>> >                  >>
>>>> >                  >>
>>>> >                 https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst>
>>>> >                  >>
>>>> >                  >> I’d like to nominate Adam as the shepherd, who
>>>> >                 already reviewed it a
>>>> >                  >> bit on Github.
>>>> >                  >>
>>>> >                  >> Please guide us to a conclusion as outlined in
>>>> >                  >>
>>>> >                 https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
>>>> >                  >>
>>>> >                  >>
>>>> >                  >> Cheers,
>>>> >                  >> Joachim
>>>> 
>>>> 
>>>> -- 
>>>> 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 <mailto: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 <mailto: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/20231009/5c16ddda/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Oct  9 09:18:14 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 9 Oct 2023 10:18:14 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
 <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
Message-ID: <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>

OK so concretely you are saying

   - Expressing support for the general rules in the draft GHC stability
   policy
   <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>
   .
   - Advocating for a deprecation cycle for this specific -Wsevere
   proposal, rather than introducing it immediately.

OK now I understand.

Moreover, you add

My favoured solution is to predicate this new behaviour on a language
> extension and incorporate that into GHC2024
>

I'm not quite sure what you mean here.  I think that you could be saying:

   - Do not add -Wsevere
   - Instead add an extension -XMissingMethods, on by default.
   - At some point, after a deprecation cycle, make -XNoMissingMethods
   become the default.
   - -Wwarn=missing-methods would be unaffected; but would become redundant
   with -XNoMissingMethods.

 and follow the same pattern for missing-fields.

That is, you want to address
https://github.com/ghc-proposals/ghc-proposals/issues/615 by doubling down
on language extensions, rather than by bigging-up warning flags.

Do I have that correct?  Perhaps you can make the case on that discussion
thread?

Simon

On Mon, 9 Oct 2023 at 09:45, Chris Dornan <chris at chrisdornan.com> wrote:

> When I refer to `the framework` I was thinking of the *GHC Stability
> Policy* document that you created (where we try not to introduce breaking
> changes, but when we do we use deprecation cycles unless there is a good
> reason not to).
>
> My favoured solution is to predicate this new behaviour on a language
> extension and incorporate that into GHC2024 -- that could be done using
> established mechanisms -- but my overriding concern is that the changes in
> behaviour be fitted into the framework for introducing breaking changes
> that we have been discussing these past few weeks in the *GHC Stability
> Policy* document.
>
> The key to me is that it be fitted into an agreed policy for making
> breaking changes, not that it adhere to my particular preferences, or the
> state of a particular proposal under discussion -- hence my somewhat
> abstract choice of terms.
>
> Is that clear? I don't want to prescribe here (though I have preferences)
> but please give me something that could plausibly be part of a general
> policy for introducing breaking changes moving forward.
>
> Chris
>
> On 9 Oct 2023, at 09:09, Simon Peyton Jones <simon.peytonjones at gmail.com>
> wrote:
>
> I remain opposed to this proposal in its current form, at least until I
>> can understand why the changes have to be made outside of the framework for
>> change we are trying to establish.
>>
>
> Chris, can you just lay out "the framework for change we are trying to
> establish"?  I accept the importance of the considerations you describe, in
> this email and in your gist.  So I understand what you are arguing
> *against*; but I don't yet see what you are arguing *for*.
>
> It's hard to argue against "a framework that will remove a lot of friction
> in making changes, and also remove key stressors from all those maintaining
> the critical infrastructure outside of the core tools that make Haskell
> truly viable for real-world development".   But what, precisely, do you
> have in mind?
>
> And in the context of this specific proposal, what are you arguing for?
>
> Thanks. Sorry to be dim.
>
> Simon
>
>
> On Sun, 8 Oct 2023 at 19:12, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> The discussion of this proposal has really boiled down to how we roll
>> this change out. I think it is important to understand why some of us have
>> been pleading for us to follow agreed processes when making these changes,
>> starting with this proposal, so I have written up some notes on why I think
>> it is important to adopt a process for these kinds of changes and endeavour
>> to stick to it.
>>
>> We have a mechanism for getting everything the proposers want using
>> established mechanisms. Why don't we follow them? If an urgent need had
>> arisen to make this change then it would be easily understandable but this
>> is proposal addressing a longstanding issue.
>>
>> I get the sense that folks fear that there is a big push to freeze
>> GHC/Haskell in its current configuration (or at least make it very
>> difficult to change anything) to satisfy those that want to just make stuff
>> with Haskell and stop all the experimentation and language development, and
>> that this push needs to be stopped before it gathers any more momentum. I
>> don't think this is all gamed out -- more a feeling or a vibe informing the
>> debate.
>>
>> I strongly believe this is a misunderstanding, and certainly where the
>> proponents of these proposed protocols are concerned, nothing could be
>> further from the truth. Properly understood, we want to create a framework
>> that will remove a lot of friction in making changes, and also remove key
>> stressors from all those maintaining the critical infrastructure outside of
>> the core tools that make Haskell truly viable for real-world development.
>>
>> I have written up my thoughts in this gist
>> <https://gist.github.com/cdornan/68267aa63546e5d674cc8d083510c3e3>,
>> explaining why I think we need the framework and why we should hold to it
>> without good reason to do otherwise. Feel free to respond there or here as
>> you see fit.
>>
>> I remain opposed to this proposal in its current form, at least until I
>> can understand why the changes have to be made outside of the framework for
>> change we are trying to establish.
>>
>> Chris
>>
>>
>>
>> On 5 Oct 2023, at 18:07, Simon Marlow <marlowsd at gmail.com> wrote:
>>
>> Ah thanks, I forgot GHC2021 was the default (I'm personally stuck using
>> pre-GHC2021 myself).
>>
>> In that case, I'm suggesting that we enable -Werror=severe in the next
>> GHC20xx iteration, and leave GHC2021 etc. unaffected.
>>
>> Cheers
>> Simon
>>
>>
>> On Thu, 5 Oct 2023, 07:56 Adam Gundry, <adam at well-typed.com> wrote:
>>
>>> On 04/10/2023 22:04, Simon Marlow wrote:
>>> > My concrete suggestion is we EITHER
>>> >
>>> >   * Enable -Werror=severe in future GHC20xx versions only, or
>>> >   * Enable it by default and in future GHC20xx versions, but not in
>>> >     GHC2021, Haskell2010, or Haskell98
>>>
>>> Sorry, I don't quite understand the difference between these options.
>>> What does it mean to enable -Werror=severe by default but not in
>>> GHC2021, given that GHC2021 is the (current) default?
>>>
>>> Cheers,
>>>
>>> Adam
>>>
>>>
>>> > On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones
>>> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>>> wrote:
>>> >
>>> >     I must say that I am strongly influenced by the fact that
>>> >
>>> >       * Matt Parsons
>>> >       * Andrew Lelechenko (bodigrim)
>>> >
>>> >     are both not just in favour, but *strongly *in favour.  They must
>>> >     think of the case as compelling, because they are both usually very
>>> >     careful about unnecessary breakage.
>>> >
>>> >         if we make -Werror=severe the default, then any new warning
>>> >         added to -Wsevere is a new breaking change, and we would have
>>> to
>>> >         judge it to be compelling enough by GR2
>>> >
>>> >
>>> >     Yes indeed.  But that's not a bug -- it's a feature.
>>> >
>>> >     To be clear I have no strongly held opinion myself.   Perhaps we
>>> >     should canvas opinion among people using Haskell in production? We
>>> >     did so with CLC but we could do so publicly.
>>> >
>>> >     Simon
>>> >
>>> >     On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com
>>> >     <mailto:marlowsd at gmail.com>> wrote:
>>> >
>>> >         I don't think this breaking change (namely making
>>> -Werror=severe
>>> >         the default) meets the bar for "compelling reason" according to
>>> >         GR2 of our proposed policy, so I'm voting against. It's
>>> >         certainly not a bug or a security hole. Maybe you could argue
>>> >         that it's a design flaw in the language, but I'm not all that
>>> >         convinced. It's an unforced breaking change in my opinion. If
>>> we
>>> >         add "makes it more difficult to shoot yourself in the foot" a
>>> >         compelling enough reason to break GR1 then I think we've
>>> >         weakened it significantly.
>>> >
>>> >         Here's another problem: if we make -Werror=severe the default,
>>> >         then any new warning added to -Wsevere is a new breaking
>>> change,
>>> >         and we would have to judge it to be compelling enough by GR2.
>>> If
>>> >         we don't make -Werror=severe the default, then we're not
>>> >         restricted in what we can add to -Wsevere. Probably -Wsevere
>>> >         would end up being more useful as a result.
>>> >
>>> >         Cheers
>>> >         Simon
>>> >
>>> >
>>> >         On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones
>>> >         <simon.peytonjones at gmail.com
>>> >         <mailto:simon.peytonjones at gmail.com>> wrote:
>>> >
>>> >             Here's my summary:
>>> >
>>> >               * There is strong (universal, even) support for the
>>> >                 `severe` category.
>>> >               * There is pretty strong support for making severe
>>> >                 warnings into errors at some point.  As Matt puts it
>>> >                 "this is not a question of GHC breaking things, but
>>> >                 rather /revealing/ and providing early-diagnosis for
>>> >                 /already broken/ things".
>>> >               * But I think we are moving towards a policy of giving
>>> >                 users time to adapt via a deprecation cycle, whenever
>>> >                 that is feasible.  And it is feasible here.
>>> >
>>> >             So my suggestion would be:
>>> >
>>> >               * When implemented, make `-Wwarn=severe` the default, but
>>> >                 add to each severe warning a deprecation-style message
>>> >                 saying that it'll become an error in the next
>>> iteration.
>>> >               * In the next released, make `-Werror=severe` the
>>> default.
>>> >               * Don't complicate matters by involving GHC2024.  That is
>>> >                 another conversation, and even if we wanted to include
>>> >                 `-Werorr=severe` in GHC2024, we would *still* want a
>>> >                 deprecation cycle!
>>> >
>>> >             Would that be acceptable?
>>> >
>>> >             Simon
>>> >
>>> >             On Fri, 29 Sept 2023 at 19:41, Adam Gundry
>>> >             <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>>> >
>>> >                 Dear Committee,
>>> >
>>> >                 It seems we are somewhat split on the -Wsevere
>>> proposal,
>>> >                 even assuming
>>> >                 it is introduced with a deprecation period (changing
>>> the
>>> >                 warning text
>>> >                 and adding the group in advance). There is consensus
>>> >                 that adding the
>>> >                 group by itself is fine, and potentially enabling
>>> >                 -Werror=severe under
>>> >                 GHC2024, but enabling it by default for existing code
>>> is
>>> >                 more controversial.
>>> >
>>> >                 Ultimately this is a judgement call about the value of
>>> >                 the proposal
>>> >                 versus the breakage it causes. I remain of the view
>>> that
>>> >                 it is
>>> >                 worthwhile. This is not merely about more aggressively
>>> >                 enforcing best
>>> >                 practice. Rather, it eliminates the risk of the
>>> following:
>>> >
>>> >                 * Suppose package A defines a type class, package B
>>> >                 depends on package
>>> >                 A, and package C depends on package B.
>>> >
>>> >                 * Now package A extends the type class definition with
>>> a
>>> >                 new method and
>>> >                 default methods. Everything still compiles; package B
>>> >                 now issues a
>>> >                 -Wmissing-methods warning (but is not actively
>>> >                 maintained, and the
>>> >                 author of package C is unlikely to look at warnings in
>>> >                 all their
>>> >                 dependencies).
>>> >
>>> >                 * Users of package C have to try to debug an infinite
>>> loop.
>>> >
>>> >                 Given that this change avoids a significant issue,
>>> >                 affected code has
>>> >                 been issuing warnings for many years, and impacted
>>> users
>>> >                 can very easily
>>> >                 set -Wwarn=severe either at the package level or the
>>> >                 project level, I
>>> >                 think is worth accepting the backwards compatibility
>>> >                 cost and the fact
>>> >                 that some Haskell2010 code will no longer be accepted
>>> by
>>> >                 default.
>>> >
>>> >                 Matt Parsons puts it well in the CLC thread, which is
>>> >                 pretty clearly in
>>> >                 favour of this proposal overall
>>> >                 (
>>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>>> <
>>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>>> >):
>>> >
>>> >                   > I think GHC should strive to make fewer breaking
>>> >                 changes, and make
>>> >                 those changes as easy-to-adopt as possible. But this is
>>> >                 not a question
>>> >                 of GHC breaking things, but rather revealing and
>>> providing
>>> >                 early-diagnosis for already broken things.
>>> >
>>> >                 Further opinions are welcome, of course.
>>> >
>>> >                 Adam
>>> >
>>> >
>>> >                 On 14/09/2023 09:32, Adam Gundry wrote:
>>> >                  > Dear Committee,
>>> >                  >
>>> >                  > Joachim, along with Oleg Grenrus, proposes to change
>>> >                 -Wmissing-methods
>>> >                  > and -Wmissing-fields warnings into errors by default
>>> >                 (retaining the
>>> >                  > option to downgrade them). I recommend we accept the
>>> >                 proposal.
>>> >                  >
>>> >                  > Proposal:
>>> >
>>> https://github.com/ghc-proposals/ghc-proposals/pull/571
>>> >                 <
>>> https://github.com/ghc-proposals/ghc-proposals/pull/571>
>>> >                  > Rendered:
>>> >                  >
>>> >
>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>> <
>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>> >
>>> >                  >
>>> >                  > This is primarily motivated by the fact that when
>>> >                 classes have default
>>> >                  > methods, missing methods can lead to runtime loops,
>>> >                 which are generally
>>> >                  > difficult to debug. Since in practice not all users
>>> >                 pay attention to
>>> >                  > warnings that do not inhibit compilation, it makes
>>> >                 sense to identify a
>>> >                  > class of warnings that are sufficiently serious to
>>> >                 require explicit
>>> >                  > action from the user to silence them.
>>> >                  >
>>> >                  > Since these warnings are currently not errors by
>>> >                 default, library
>>> >                  > authors experimentally assessing the impact of
>>> >                 changes may be lead to
>>> >                  > assume that introducing new methods/fields does not
>>> >                 lead to breakage
>>> >                  > (because downstream code will still compile). The
>>> >                 proposal thus makes it
>>> >                  > more obvious that adding a new method or field is a
>>> >                 breaking change.
>>> >                  >
>>> >                  > The proposal deliberately causes builds to fail by
>>> >                 default for some
>>> >                  > libraries that currently emit warnings. Oleg has
>>> >                 kindly performed impact
>>> >                  > assessments to identify such libraries, and the
>>> >                 breakage of a few
>>> >                  > packages seems worth the cost.
>>> >                  >
>>> >                  > It is easy to restore the warnings to their previous
>>> >                 classification by
>>> >                  > passing an option at build time, e.g. using
>>> >                 -Wno-error=missing-methods.
>>> >                  > Users can set such an option in cabal.project or
>>> >                 stack.yaml to work
>>> >                  > around breakage that is not promptly fixed by the
>>> >                 library author.
>>> >                  >
>>> >                  > This change does mean that GHC with -XHaskell98/2010
>>> >                 will by default
>>> >                  > reject some programs that are explicitly permitted
>>> by
>>> >                 the Haskell98/2010
>>> >                  > specification. I recommend we document this
>>> >                 infelicity, but accept it,
>>> >                  > as much of the benefit of the proposal is that it
>>> >                 applies by default.
>>> >                  >
>>> >                  > The proposal establishes the precedent that some
>>> >                 warnings may be treated
>>> >                  > as errors by default, and introduces a warning group
>>> >                 -Wsevere to
>>> >                  > classify them. This seems conceptually useful and
>>> >                 gives us the option to
>>> >                  > extend the -Wsevere set in the future (e.g. as a
>>> >                 final stage of
>>> >                  > deprecation before a feature is removed).
>>> >                  >
>>> >                  > Thoughts?
>>> >                  >
>>> >                  > Adam
>>> >                  >
>>> >                  >
>>> >                  > On 11/09/2023 20:25, Joachim Breitner wrote:
>>> >                  >> Dear Committee,
>>> >                  >>
>>> >                  >> based on suggestions by Oleg Grenrus, I wrote a
>>> >                 proposal to introduce a
>>> >                  >> warning group -Wsevere for on-by-defaults,
>>> >                 error-by-default warnings,
>>> >                  >> and initially fill it with missing-methods and
>>> >                 missing-fields.
>>> >                  >>
>>> >                  >>
>>> >                  >>
>>> >
>>> https://github.com/ghc-proposals/ghc-proposals/pull/571
>>> >                 <
>>> https://github.com/ghc-proposals/ghc-proposals/pull/571>
>>> >                  >>
>>> >                  >>
>>> >
>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>> <
>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>> >
>>> >                  >>
>>> >                  >> I’d like to nominate Adam as the shepherd, who
>>> >                 already reviewed it a
>>> >                  >> bit on Github.
>>> >                  >>
>>> >                  >> Please guide us to a conclusion as outlined in
>>> >                  >>
>>> >
>>> https://github.com/ghc-proposals/ghc-proposals#committee-process <
>>> https://github.com/ghc-proposals/ghc-proposals#committee-process>
>>> >                  >>
>>> >                  >>
>>> >                  >> Cheers,
>>> >                  >> Joachim
>>>
>>>
>>> --
>>> 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/20231009/ec59c3fb/attachment-0001.html>

From chris at chrisdornan.com  Mon Oct  9 10:59:26 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 9 Oct 2023 11:59:26 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
 <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
 <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
Message-ID: <22AA9963-2CCB-4DE9-974F-940525221969@chrisdornan.com>

I am trying to not be prescriptive.

If I were writing the proposal I would leave it as it is, but simply add a language extension (NoSevereWarnings say), that make -Werror=severe the default.

I would then add NoSevereWarnings to GHC2024 ready for it to become the default out-of-the-box behaviour in GHC9.10 (say) without any need for deprecation cycles.

Chris


> On 9 Oct 2023, at 10:18, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> OK so concretely you are saying
> Expressing support for the general rules in the draft GHC stability policy <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>.
> Advocating for a deprecation cycle for this specific -Wsevere proposal, rather than introducing it immediately.
> OK now I understand.
> 
> Moreover, you add
> 
>> My favoured solution is to predicate this new behaviour on a language extension and incorporate that into GHC2024
> 
> I'm not quite sure what you mean here.  I think that you could be saying:
> Do not add -Wsevere
> Instead add an extension -XMissingMethods, on by default.
> At some point, after a deprecation cycle, make -XNoMissingMethods become the default.
> -Wwarn=missing-methods would be unaffected; but would become redundant with -XNoMissingMethods.
>  and follow the same pattern for missing-fields.
> 
> That is, you want to address https://github.com/ghc-proposals/ghc-proposals/issues/615 by doubling down on language extensions, rather than by bigging-up warning flags. 
> 
> Do I have that correct?  Perhaps you can make the case on that discussion thread?
> 
> Simon
> 
> On Mon, 9 Oct 2023 at 09:45, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>> When I refer to `the framework` I was thinking of the GHC Stability Policy document that you created (where we try not to introduce breaking changes, but when we do we use deprecation cycles unless there is a good reason not to).
>> 
>> My favoured solution is to predicate this new behaviour on a language extension and incorporate that into GHC2024 -- that could be done using established mechanisms -- but my overriding concern is that the changes in behaviour be fitted into the framework for introducing breaking changes that we have been discussing these past few weeks in the GHC Stability Policy document.
>> 
>> The key to me is that it be fitted into an agreed policy for making breaking changes, not that it adhere to my particular preferences, or the state of a particular proposal under discussion -- hence my somewhat abstract choice of terms.
>> 
>> Is that clear? I don't want to prescribe here (though I have preferences) but please give me something that could plausibly be part of a general policy for introducing breaking changes moving forward.
>> 
>> Chris
>> 
>>> On 9 Oct 2023, at 09:09, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>> 
>>>> I remain opposed to this proposal in its current form, at least until I can understand why the changes have to be made outside of the framework for change we are trying to establish.
>>> 
>>> Chris, can you just lay out "the framework for change we are trying to establish"?  I accept the importance of the considerations you describe, in this email and in your gist.  So I understand what you are arguing against; but I don't yet see what you are arguing for.
>>> 
>>> It's hard to argue against "a framework that will remove a lot of friction in making changes, and also remove key stressors from all those maintaining the critical infrastructure outside of the core tools that make Haskell truly viable for real-world development".   But what, precisely, do you have in mind?  
>>> 
>>> And in the context of this specific proposal, what are you arguing for?
>>> 
>>> Thanks. Sorry to be dim.
>>> 
>>> Simon
>>>  
>>> 
>>> On Sun, 8 Oct 2023 at 19:12, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>>>> 
>>>> The discussion of this proposal has really boiled down to how we roll this change out. I think it is important to understand why some of us have been pleading for us to follow agreed processes when making these changes, starting with this proposal, so I have written up some notes on why I think it is important to adopt a process for these kinds of changes and endeavour to stick to it.
>>>> 
>>>> We have a mechanism for getting everything the proposers want using established mechanisms. Why don't we follow them? If an urgent need had arisen to make this change then it would be easily understandable but this is proposal addressing a longstanding issue.
>>>> 
>>>> I get the sense that folks fear that there is a big push to freeze GHC/Haskell in its current configuration (or at least make it very difficult to change anything) to satisfy those that want to just make stuff with Haskell and stop all the experimentation and language development, and that this push needs to be stopped before it gathers any more momentum. I don't think this is all gamed out -- more a feeling or a vibe informing the debate.
>>>> 
>>>> I strongly believe this is a misunderstanding, and certainly where the proponents of these proposed protocols are concerned, nothing could be further from the truth. Properly understood, we want to create a framework that will remove a lot of friction in making changes, and also remove key stressors from all those maintaining the critical infrastructure outside of the core tools that make Haskell truly viable for real-world development.
>>>> 
>>>> I have written up my thoughts in this gist <https://gist.github.com/cdornan/68267aa63546e5d674cc8d083510c3e3>, explaining why I think we need the framework and why we should hold to it without good reason to do otherwise. Feel free to respond there or here as you see fit.
>>>> 
>>>> I remain opposed to this proposal in its current form, at least until I can understand why the changes have to be made outside of the framework for change we are trying to establish.
>>>> 
>>>> Chris
>>>>  
>>>> 
>>>> 
>>>>> On 5 Oct 2023, at 18:07, Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>> wrote:
>>>>> 
>>>>> Ah thanks, I forgot GHC2021 was the default (I'm personally stuck using pre-GHC2021 myself).
>>>>> 
>>>>> In that case, I'm suggesting that we enable -Werror=severe in the next GHC20xx iteration, and leave GHC2021 etc. unaffected.
>>>>> 
>>>>> Cheers
>>>>> Simon
>>>>> 
>>>>> 
>>>>> On Thu, 5 Oct 2023, 07:56 Adam Gundry, <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>>>>>> On 04/10/2023 22:04, Simon Marlow wrote:
>>>>>> > My concrete suggestion is we EITHER
>>>>>> > 
>>>>>> >   * Enable -Werror=severe in future GHC20xx versions only, or
>>>>>> >   * Enable it by default and in future GHC20xx versions, but not in
>>>>>> >     GHC2021, Haskell2010, or Haskell98
>>>>>> 
>>>>>> Sorry, I don't quite understand the difference between these options. 
>>>>>> What does it mean to enable -Werror=severe by default but not in 
>>>>>> GHC2021, given that GHC2021 is the (current) default?
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> Adam
>>>>>> 
>>>>>> 
>>>>>> > On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones 
>>>>>> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com> <mailto:simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>> wrote:
>>>>>> > 
>>>>>> >     I must say that I am strongly influenced by the fact that
>>>>>> > 
>>>>>> >       * Matt Parsons
>>>>>> >       * Andrew Lelechenko (bodigrim)
>>>>>> > 
>>>>>> >     are both not just in favour, but *strongly *in favour.  They must
>>>>>> >     think of the case as compelling, because they are both usually very
>>>>>> >     careful about unnecessary breakage.
>>>>>> > 
>>>>>> >         if we make -Werror=severe the default, then any new warning
>>>>>> >         added to -Wsevere is a new breaking change, and we would have to
>>>>>> >         judge it to be compelling enough by GR2
>>>>>> > 
>>>>>> > 
>>>>>> >     Yes indeed.  But that's not a bug -- it's a feature.
>>>>>> > 
>>>>>> >     To be clear I have no strongly held opinion myself.   Perhaps we
>>>>>> >     should canvas opinion among people using Haskell in production? We
>>>>>> >     did so with CLC but we could do so publicly.
>>>>>> > 
>>>>>> >     Simon
>>>>>> > 
>>>>>> >     On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>
>>>>>> >     <mailto:marlowsd at gmail.com <mailto:marlowsd at gmail.com>>> wrote:
>>>>>> > 
>>>>>> >         I don't think this breaking change (namely making -Werror=severe
>>>>>> >         the default) meets the bar for "compelling reason" according to
>>>>>> >         GR2 of our proposed policy, so I'm voting against. It's
>>>>>> >         certainly not a bug or a security hole. Maybe you could argue
>>>>>> >         that it's a design flaw in the language, but I'm not all that
>>>>>> >         convinced. It's an unforced breaking change in my opinion. If we
>>>>>> >         add "makes it more difficult to shoot yourself in the foot" a
>>>>>> >         compelling enough reason to break GR1 then I think we've
>>>>>> >         weakened it significantly.
>>>>>> > 
>>>>>> >         Here's another problem: if we make -Werror=severe the default,
>>>>>> >         then any new warning added to -Wsevere is a new breaking change,
>>>>>> >         and we would have to judge it to be compelling enough by GR2. If
>>>>>> >         we don't make -Werror=severe the default, then we're not
>>>>>> >         restricted in what we can add to -Wsevere. Probably -Wsevere
>>>>>> >         would end up being more useful as a result.
>>>>>> > 
>>>>>> >         Cheers
>>>>>> >         Simon
>>>>>> > 
>>>>>> > 
>>>>>> >         On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones
>>>>>> >         <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>
>>>>>> >         <mailto:simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>> wrote:
>>>>>> > 
>>>>>> >             Here's my summary:
>>>>>> > 
>>>>>> >               * There is strong (universal, even) support for the
>>>>>> >                 `severe` category.
>>>>>> >               * There is pretty strong support for making severe
>>>>>> >                 warnings into errors at some point.  As Matt puts it
>>>>>> >                 "this is not a question of GHC breaking things, but
>>>>>> >                 rather /revealing/ and providing early-diagnosis for
>>>>>> >                 /already broken/ things".
>>>>>> >               * But I think we are moving towards a policy of giving
>>>>>> >                 users time to adapt via a deprecation cycle, whenever
>>>>>> >                 that is feasible.  And it is feasible here.
>>>>>> > 
>>>>>> >             So my suggestion would be:
>>>>>> > 
>>>>>> >               * When implemented, make `-Wwarn=severe` the default, but
>>>>>> >                 add to each severe warning a deprecation-style message
>>>>>> >                 saying that it'll become an error in the next iteration.
>>>>>> >               * In the next released, make `-Werror=severe` the default.
>>>>>> >               * Don't complicate matters by involving GHC2024.  That is
>>>>>> >                 another conversation, and even if we wanted to include
>>>>>> >                 `-Werorr=severe` in GHC2024, we would *still* want a
>>>>>> >                 deprecation cycle!
>>>>>> > 
>>>>>> >             Would that be acceptable?
>>>>>> > 
>>>>>> >             Simon
>>>>>> > 
>>>>>> >             On Fri, 29 Sept 2023 at 19:41, Adam Gundry
>>>>>> >             <adam at well-typed.com <mailto:adam at well-typed.com> <mailto:adam at well-typed.com <mailto:adam at well-typed.com>>> wrote:
>>>>>> > 
>>>>>> >                 Dear Committee,
>>>>>> > 
>>>>>> >                 It seems we are somewhat split on the -Wsevere proposal,
>>>>>> >                 even assuming
>>>>>> >                 it is introduced with a deprecation period (changing the
>>>>>> >                 warning text
>>>>>> >                 and adding the group in advance). There is consensus
>>>>>> >                 that adding the
>>>>>> >                 group by itself is fine, and potentially enabling
>>>>>> >                 -Werror=severe under
>>>>>> >                 GHC2024, but enabling it by default for existing code is
>>>>>> >                 more controversial.
>>>>>> > 
>>>>>> >                 Ultimately this is a judgement call about the value of
>>>>>> >                 the proposal
>>>>>> >                 versus the breakage it causes. I remain of the view that
>>>>>> >                 it is
>>>>>> >                 worthwhile. This is not merely about more aggressively
>>>>>> >                 enforcing best
>>>>>> >                 practice. Rather, it eliminates the risk of the following:
>>>>>> > 
>>>>>> >                 * Suppose package A defines a type class, package B
>>>>>> >                 depends on package
>>>>>> >                 A, and package C depends on package B.
>>>>>> > 
>>>>>> >                 * Now package A extends the type class definition with a
>>>>>> >                 new method and
>>>>>> >                 default methods. Everything still compiles; package B
>>>>>> >                 now issues a
>>>>>> >                 -Wmissing-methods warning (but is not actively
>>>>>> >                 maintained, and the
>>>>>> >                 author of package C is unlikely to look at warnings in
>>>>>> >                 all their
>>>>>> >                 dependencies).
>>>>>> > 
>>>>>> >                 * Users of package C have to try to debug an infinite loop.
>>>>>> > 
>>>>>> >                 Given that this change avoids a significant issue,
>>>>>> >                 affected code has
>>>>>> >                 been issuing warnings for many years, and impacted users
>>>>>> >                 can very easily
>>>>>> >                 set -Wwarn=severe either at the package level or the
>>>>>> >                 project level, I
>>>>>> >                 think is worth accepting the backwards compatibility
>>>>>> >                 cost and the fact
>>>>>> >                 that some Haskell2010 code will no longer be accepted by
>>>>>> >                 default.
>>>>>> > 
>>>>>> >                 Matt Parsons puts it well in the CLC thread, which is
>>>>>> >                 pretty clearly in
>>>>>> >                 favour of this proposal overall
>>>>>> >                 (https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889 <https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889>):
>>>>>> > 
>>>>>> >                   > I think GHC should strive to make fewer breaking
>>>>>> >                 changes, and make
>>>>>> >                 those changes as easy-to-adopt as possible. But this is
>>>>>> >                 not a question
>>>>>> >                 of GHC breaking things, but rather revealing and providing
>>>>>> >                 early-diagnosis for already broken things.
>>>>>> > 
>>>>>> >                 Further opinions are welcome, of course.
>>>>>> > 
>>>>>> >                 Adam
>>>>>> > 
>>>>>> > 
>>>>>> >                 On 14/09/2023 09:32, Adam Gundry wrote:
>>>>>> >                  > Dear Committee,
>>>>>> >                  >
>>>>>> >                  > Joachim, along with Oleg Grenrus, proposes to change
>>>>>> >                 -Wmissing-methods
>>>>>> >                  > and -Wmissing-fields warnings into errors by default
>>>>>> >                 (retaining the
>>>>>> >                  > option to downgrade them). I recommend we accept the
>>>>>> >                 proposal.
>>>>>> >                  >
>>>>>> >                  > Proposal:
>>>>>> >                 https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>>>> >                 <https://github.com/ghc-proposals/ghc-proposals/pull/571>
>>>>>> >                  > Rendered:
>>>>>> >                  >
>>>>>> >                 https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst>
>>>>>> >                  >
>>>>>> >                  > This is primarily motivated by the fact that when
>>>>>> >                 classes have default
>>>>>> >                  > methods, missing methods can lead to runtime loops,
>>>>>> >                 which are generally
>>>>>> >                  > difficult to debug. Since in practice not all users
>>>>>> >                 pay attention to
>>>>>> >                  > warnings that do not inhibit compilation, it makes
>>>>>> >                 sense to identify a
>>>>>> >                  > class of warnings that are sufficiently serious to
>>>>>> >                 require explicit
>>>>>> >                  > action from the user to silence them.
>>>>>> >                  >
>>>>>> >                  > Since these warnings are currently not errors by
>>>>>> >                 default, library
>>>>>> >                  > authors experimentally assessing the impact of
>>>>>> >                 changes may be lead to
>>>>>> >                  > assume that introducing new methods/fields does not
>>>>>> >                 lead to breakage
>>>>>> >                  > (because downstream code will still compile). The
>>>>>> >                 proposal thus makes it
>>>>>> >                  > more obvious that adding a new method or field is a
>>>>>> >                 breaking change.
>>>>>> >                  >
>>>>>> >                  > The proposal deliberately causes builds to fail by
>>>>>> >                 default for some
>>>>>> >                  > libraries that currently emit warnings. Oleg has
>>>>>> >                 kindly performed impact
>>>>>> >                  > assessments to identify such libraries, and the
>>>>>> >                 breakage of a few
>>>>>> >                  > packages seems worth the cost.
>>>>>> >                  >
>>>>>> >                  > It is easy to restore the warnings to their previous
>>>>>> >                 classification by
>>>>>> >                  > passing an option at build time, e.g. using
>>>>>> >                 -Wno-error=missing-methods.
>>>>>> >                  > Users can set such an option in cabal.project or
>>>>>> >                 stack.yaml to work
>>>>>> >                  > around breakage that is not promptly fixed by the
>>>>>> >                 library author.
>>>>>> >                  >
>>>>>> >                  > This change does mean that GHC with -XHaskell98/2010
>>>>>> >                 will by default
>>>>>> >                  > reject some programs that are explicitly permitted by
>>>>>> >                 the Haskell98/2010
>>>>>> >                  > specification. I recommend we document this
>>>>>> >                 infelicity, but accept it,
>>>>>> >                  > as much of the benefit of the proposal is that it
>>>>>> >                 applies by default.
>>>>>> >                  >
>>>>>> >                  > The proposal establishes the precedent that some
>>>>>> >                 warnings may be treated
>>>>>> >                  > as errors by default, and introduces a warning group
>>>>>> >                 -Wsevere to
>>>>>> >                  > classify them. This seems conceptually useful and
>>>>>> >                 gives us the option to
>>>>>> >                  > extend the -Wsevere set in the future (e.g. as a
>>>>>> >                 final stage of
>>>>>> >                  > deprecation before a feature is removed).
>>>>>> >                  >
>>>>>> >                  > Thoughts?
>>>>>> >                  >
>>>>>> >                  > Adam
>>>>>> >                  >
>>>>>> >                  >
>>>>>> >                  > On 11/09/2023 20:25, Joachim Breitner wrote:
>>>>>> >                  >> Dear Committee,
>>>>>> >                  >>
>>>>>> >                  >> based on suggestions by Oleg Grenrus, I wrote a
>>>>>> >                 proposal to introduce a
>>>>>> >                  >> warning group -Wsevere for on-by-defaults,
>>>>>> >                 error-by-default warnings,
>>>>>> >                  >> and initially fill it with missing-methods and
>>>>>> >                 missing-fields.
>>>>>> >                  >>
>>>>>> >                  >>
>>>>>> >                  >>
>>>>>> >                 https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>>>> >                 <https://github.com/ghc-proposals/ghc-proposals/pull/571>
>>>>>> >                  >>
>>>>>> >                  >>
>>>>>> >                 https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst>
>>>>>> >                  >>
>>>>>> >                  >> I’d like to nominate Adam as the shepherd, who
>>>>>> >                 already reviewed it a
>>>>>> >                  >> bit on Github.
>>>>>> >                  >>
>>>>>> >                  >> Please guide us to a conclusion as outlined in
>>>>>> >                  >>
>>>>>> >                 https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
>>>>>> >                  >>
>>>>>> >                  >>
>>>>>> >                  >> Cheers,
>>>>>> >                  >> Joachim
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> 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 <mailto: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 <mailto: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/20231009/1d4d2d5d/attachment-0001.html>

From marlowsd at gmail.com  Mon Oct  9 11:25:38 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 9 Oct 2023 12:25:38 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
 <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
 <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
Message-ID: <CANsrgPKzmoP0pFz6C+D4Kuengjwx821aYHf3MRwf2PtvqVpcMQ@mail.gmail.com>

Simon - I hope this will clarify: Chris is saying that we should *not* make
a breaking change, at all, even with a deprecation cycle. Instead we should
introduce the new behaviour of `-Werror=severe` with GHC2024. This is in
line with the stability policy, and it's the proposal I put forward earlier
in the thread and that people have been discussing on github.

We don't need a deprecation cycle because we don't need to make a breaking
change. By putting the new behaviour in GHC2024, users can choose when to
update their code to accommodate the change. This is a much better model
than deprecation cycles because it fully decouples the breaking change from
compiler releases, and means that even when the user skips multiple GHC
releases with an upgrade their code still compiles, and they can update it
to the latest GHC20xx when they want.

Cheers
Simon


On Mon, 9 Oct 2023 at 10:18, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> OK so concretely you are saying
>
>    - Expressing support for the general rules in the draft GHC stability
>    policy
>    <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>
>    .
>    - Advocating for a deprecation cycle for this specific -Wsevere
>    proposal, rather than introducing it immediately.
>
> OK now I understand.
>
> Moreover, you add
>
> My favoured solution is to predicate this new behaviour on a language
>> extension and incorporate that into GHC2024
>>
>
> I'm not quite sure what you mean here.  I think that you could be saying:
>
>    - Do not add -Wsevere
>    - Instead add an extension -XMissingMethods, on by default.
>    - At some point, after a deprecation cycle, make -XNoMissingMethods
>    become the default.
>    - -Wwarn=missing-methods would be unaffected; but would become
>    redundant with -XNoMissingMethods.
>
>  and follow the same pattern for missing-fields.
>
> That is, you want to address
> https://github.com/ghc-proposals/ghc-proposals/issues/615 by doubling
> down on language extensions, rather than by bigging-up warning flags.
>
> Do I have that correct?  Perhaps you can make the case on that discussion
> thread?
>
> Simon
>
> On Mon, 9 Oct 2023 at 09:45, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> When I refer to `the framework` I was thinking of the *GHC Stability
>> Policy* document that you created (where we try not to introduce
>> breaking changes, but when we do we use deprecation cycles unless there is
>> a good reason not to).
>>
>> My favoured solution is to predicate this new behaviour on a language
>> extension and incorporate that into GHC2024 -- that could be done using
>> established mechanisms -- but my overriding concern is that the changes in
>> behaviour be fitted into the framework for introducing breaking changes
>> that we have been discussing these past few weeks in the *GHC Stability
>> Policy* document.
>>
>> The key to me is that it be fitted into an agreed policy for making
>> breaking changes, not that it adhere to my particular preferences, or the
>> state of a particular proposal under discussion -- hence my somewhat
>> abstract choice of terms.
>>
>> Is that clear? I don't want to prescribe here (though I have preferences)
>> but please give me something that could plausibly be part of a general
>> policy for introducing breaking changes moving forward.
>>
>> Chris
>>
>> On 9 Oct 2023, at 09:09, Simon Peyton Jones <simon.peytonjones at gmail.com>
>> wrote:
>>
>> I remain opposed to this proposal in its current form, at least until I
>>> can understand why the changes have to be made outside of the framework for
>>> change we are trying to establish.
>>>
>>
>> Chris, can you just lay out "the framework for change we are trying to
>> establish"?  I accept the importance of the considerations you describe, in
>> this email and in your gist.  So I understand what you are arguing
>> *against*; but I don't yet see what you are arguing *for*.
>>
>> It's hard to argue against "a framework that will remove a lot of
>> friction in making changes, and also remove key stressors from all those
>> maintaining the critical infrastructure outside of the core tools that make
>> Haskell truly viable for real-world development".   But what, precisely, do
>> you have in mind?
>>
>> And in the context of this specific proposal, what are you arguing for?
>>
>> Thanks. Sorry to be dim.
>>
>> Simon
>>
>>
>> On Sun, 8 Oct 2023 at 19:12, Chris Dornan <chris at chrisdornan.com> wrote:
>>
>>> The discussion of this proposal has really boiled down to how we roll
>>> this change out. I think it is important to understand why some of us have
>>> been pleading for us to follow agreed processes when making these changes,
>>> starting with this proposal, so I have written up some notes on why I think
>>> it is important to adopt a process for these kinds of changes and endeavour
>>> to stick to it.
>>>
>>> We have a mechanism for getting everything the proposers want using
>>> established mechanisms. Why don't we follow them? If an urgent need had
>>> arisen to make this change then it would be easily understandable but this
>>> is proposal addressing a longstanding issue.
>>>
>>> I get the sense that folks fear that there is a big push to freeze
>>> GHC/Haskell in its current configuration (or at least make it very
>>> difficult to change anything) to satisfy those that want to just make stuff
>>> with Haskell and stop all the experimentation and language development, and
>>> that this push needs to be stopped before it gathers any more momentum. I
>>> don't think this is all gamed out -- more a feeling or a vibe informing the
>>> debate.
>>>
>>> I strongly believe this is a misunderstanding, and certainly where the
>>> proponents of these proposed protocols are concerned, nothing could be
>>> further from the truth. Properly understood, we want to create a framework
>>> that will remove a lot of friction in making changes, and also remove key
>>> stressors from all those maintaining the critical infrastructure outside of
>>> the core tools that make Haskell truly viable for real-world development.
>>>
>>> I have written up my thoughts in this gist
>>> <https://gist.github.com/cdornan/68267aa63546e5d674cc8d083510c3e3>,
>>> explaining why I think we need the framework and why we should hold to it
>>> without good reason to do otherwise. Feel free to respond there or here as
>>> you see fit.
>>>
>>> I remain opposed to this proposal in its current form, at least until I
>>> can understand why the changes have to be made outside of the framework for
>>> change we are trying to establish.
>>>
>>> Chris
>>>
>>>
>>>
>>> On 5 Oct 2023, at 18:07, Simon Marlow <marlowsd at gmail.com> wrote:
>>>
>>> Ah thanks, I forgot GHC2021 was the default (I'm personally stuck using
>>> pre-GHC2021 myself).
>>>
>>> In that case, I'm suggesting that we enable -Werror=severe in the next
>>> GHC20xx iteration, and leave GHC2021 etc. unaffected.
>>>
>>> Cheers
>>> Simon
>>>
>>>
>>> On Thu, 5 Oct 2023, 07:56 Adam Gundry, <adam at well-typed.com> wrote:
>>>
>>>> On 04/10/2023 22:04, Simon Marlow wrote:
>>>> > My concrete suggestion is we EITHER
>>>> >
>>>> >   * Enable -Werror=severe in future GHC20xx versions only, or
>>>> >   * Enable it by default and in future GHC20xx versions, but not in
>>>> >     GHC2021, Haskell2010, or Haskell98
>>>>
>>>> Sorry, I don't quite understand the difference between these options.
>>>> What does it mean to enable -Werror=severe by default but not in
>>>> GHC2021, given that GHC2021 is the (current) default?
>>>>
>>>> Cheers,
>>>>
>>>> Adam
>>>>
>>>>
>>>> > On Wed, 4 Oct 2023 at 09:28, Simon Peyton Jones
>>>> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>>>> wrote:
>>>> >
>>>> >     I must say that I am strongly influenced by the fact that
>>>> >
>>>> >       * Matt Parsons
>>>> >       * Andrew Lelechenko (bodigrim)
>>>> >
>>>> >     are both not just in favour, but *strongly *in favour.  They must
>>>> >     think of the case as compelling, because they are both usually
>>>> very
>>>> >     careful about unnecessary breakage.
>>>> >
>>>> >         if we make -Werror=severe the default, then any new warning
>>>> >         added to -Wsevere is a new breaking change, and we would have
>>>> to
>>>> >         judge it to be compelling enough by GR2
>>>> >
>>>> >
>>>> >     Yes indeed.  But that's not a bug -- it's a feature.
>>>> >
>>>> >     To be clear I have no strongly held opinion myself.   Perhaps we
>>>> >     should canvas opinion among people using Haskell in production? We
>>>> >     did so with CLC but we could do so publicly.
>>>> >
>>>> >     Simon
>>>> >
>>>> >     On Wed, 4 Oct 2023 at 09:18, Simon Marlow <marlowsd at gmail.com
>>>> >     <mailto:marlowsd at gmail.com>> wrote:
>>>> >
>>>> >         I don't think this breaking change (namely making
>>>> -Werror=severe
>>>> >         the default) meets the bar for "compelling reason" according
>>>> to
>>>> >         GR2 of our proposed policy, so I'm voting against. It's
>>>> >         certainly not a bug or a security hole. Maybe you could argue
>>>> >         that it's a design flaw in the language, but I'm not all that
>>>> >         convinced. It's an unforced breaking change in my opinion. If
>>>> we
>>>> >         add "makes it more difficult to shoot yourself in the foot" a
>>>> >         compelling enough reason to break GR1 then I think we've
>>>> >         weakened it significantly.
>>>> >
>>>> >         Here's another problem: if we make -Werror=severe the default,
>>>> >         then any new warning added to -Wsevere is a new breaking
>>>> change,
>>>> >         and we would have to judge it to be compelling enough by GR2.
>>>> If
>>>> >         we don't make -Werror=severe the default, then we're not
>>>> >         restricted in what we can add to -Wsevere. Probably -Wsevere
>>>> >         would end up being more useful as a result.
>>>> >
>>>> >         Cheers
>>>> >         Simon
>>>> >
>>>> >
>>>> >         On Tue, 3 Oct 2023 at 11:00, Simon Peyton Jones
>>>> >         <simon.peytonjones at gmail.com
>>>> >         <mailto:simon.peytonjones at gmail.com>> wrote:
>>>> >
>>>> >             Here's my summary:
>>>> >
>>>> >               * There is strong (universal, even) support for the
>>>> >                 `severe` category.
>>>> >               * There is pretty strong support for making severe
>>>> >                 warnings into errors at some point.  As Matt puts it
>>>> >                 "this is not a question of GHC breaking things, but
>>>> >                 rather /revealing/ and providing early-diagnosis for
>>>> >                 /already broken/ things".
>>>> >               * But I think we are moving towards a policy of giving
>>>> >                 users time to adapt via a deprecation cycle, whenever
>>>> >                 that is feasible.  And it is feasible here.
>>>> >
>>>> >             So my suggestion would be:
>>>> >
>>>> >               * When implemented, make `-Wwarn=severe` the default,
>>>> but
>>>> >                 add to each severe warning a deprecation-style message
>>>> >                 saying that it'll become an error in the next
>>>> iteration.
>>>> >               * In the next released, make `-Werror=severe` the
>>>> default.
>>>> >               * Don't complicate matters by involving GHC2024.  That
>>>> is
>>>> >                 another conversation, and even if we wanted to include
>>>> >                 `-Werorr=severe` in GHC2024, we would *still* want a
>>>> >                 deprecation cycle!
>>>> >
>>>> >             Would that be acceptable?
>>>> >
>>>> >             Simon
>>>> >
>>>> >             On Fri, 29 Sept 2023 at 19:41, Adam Gundry
>>>> >             <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>>>> >
>>>> >                 Dear Committee,
>>>> >
>>>> >                 It seems we are somewhat split on the -Wsevere
>>>> proposal,
>>>> >                 even assuming
>>>> >                 it is introduced with a deprecation period (changing
>>>> the
>>>> >                 warning text
>>>> >                 and adding the group in advance). There is consensus
>>>> >                 that adding the
>>>> >                 group by itself is fine, and potentially enabling
>>>> >                 -Werror=severe under
>>>> >                 GHC2024, but enabling it by default for existing code
>>>> is
>>>> >                 more controversial.
>>>> >
>>>> >                 Ultimately this is a judgement call about the value of
>>>> >                 the proposal
>>>> >                 versus the breakage it causes. I remain of the view
>>>> that
>>>> >                 it is
>>>> >                 worthwhile. This is not merely about more aggressively
>>>> >                 enforcing best
>>>> >                 practice. Rather, it eliminates the risk of the
>>>> following:
>>>> >
>>>> >                 * Suppose package A defines a type class, package B
>>>> >                 depends on package
>>>> >                 A, and package C depends on package B.
>>>> >
>>>> >                 * Now package A extends the type class definition
>>>> with a
>>>> >                 new method and
>>>> >                 default methods. Everything still compiles; package B
>>>> >                 now issues a
>>>> >                 -Wmissing-methods warning (but is not actively
>>>> >                 maintained, and the
>>>> >                 author of package C is unlikely to look at warnings in
>>>> >                 all their
>>>> >                 dependencies).
>>>> >
>>>> >                 * Users of package C have to try to debug an infinite
>>>> loop.
>>>> >
>>>> >                 Given that this change avoids a significant issue,
>>>> >                 affected code has
>>>> >                 been issuing warnings for many years, and impacted
>>>> users
>>>> >                 can very easily
>>>> >                 set -Wwarn=severe either at the package level or the
>>>> >                 project level, I
>>>> >                 think is worth accepting the backwards compatibility
>>>> >                 cost and the fact
>>>> >                 that some Haskell2010 code will no longer be accepted
>>>> by
>>>> >                 default.
>>>> >
>>>> >                 Matt Parsons puts it well in the CLC thread, which is
>>>> >                 pretty clearly in
>>>> >                 favour of this proposal overall
>>>> >                 (
>>>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>>>> <
>>>> https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889
>>>> >):
>>>> >
>>>> >                   > I think GHC should strive to make fewer breaking
>>>> >                 changes, and make
>>>> >                 those changes as easy-to-adopt as possible. But this
>>>> is
>>>> >                 not a question
>>>> >                 of GHC breaking things, but rather revealing and
>>>> providing
>>>> >                 early-diagnosis for already broken things.
>>>> >
>>>> >                 Further opinions are welcome, of course.
>>>> >
>>>> >                 Adam
>>>> >
>>>> >
>>>> >                 On 14/09/2023 09:32, Adam Gundry wrote:
>>>> >                  > Dear Committee,
>>>> >                  >
>>>> >                  > Joachim, along with Oleg Grenrus, proposes to
>>>> change
>>>> >                 -Wmissing-methods
>>>> >                  > and -Wmissing-fields warnings into errors by
>>>> default
>>>> >                 (retaining the
>>>> >                  > option to downgrade them). I recommend we accept
>>>> the
>>>> >                 proposal.
>>>> >                  >
>>>> >                  > Proposal:
>>>> >
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>> >                 <
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/571>
>>>> >                  > Rendered:
>>>> >                  >
>>>> >
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>> <
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>> >
>>>> >                  >
>>>> >                  > This is primarily motivated by the fact that when
>>>> >                 classes have default
>>>> >                  > methods, missing methods can lead to runtime loops,
>>>> >                 which are generally
>>>> >                  > difficult to debug. Since in practice not all users
>>>> >                 pay attention to
>>>> >                  > warnings that do not inhibit compilation, it makes
>>>> >                 sense to identify a
>>>> >                  > class of warnings that are sufficiently serious to
>>>> >                 require explicit
>>>> >                  > action from the user to silence them.
>>>> >                  >
>>>> >                  > Since these warnings are currently not errors by
>>>> >                 default, library
>>>> >                  > authors experimentally assessing the impact of
>>>> >                 changes may be lead to
>>>> >                  > assume that introducing new methods/fields does not
>>>> >                 lead to breakage
>>>> >                  > (because downstream code will still compile). The
>>>> >                 proposal thus makes it
>>>> >                  > more obvious that adding a new method or field is a
>>>> >                 breaking change.
>>>> >                  >
>>>> >                  > The proposal deliberately causes builds to fail by
>>>> >                 default for some
>>>> >                  > libraries that currently emit warnings. Oleg has
>>>> >                 kindly performed impact
>>>> >                  > assessments to identify such libraries, and the
>>>> >                 breakage of a few
>>>> >                  > packages seems worth the cost.
>>>> >                  >
>>>> >                  > It is easy to restore the warnings to their
>>>> previous
>>>> >                 classification by
>>>> >                  > passing an option at build time, e.g. using
>>>> >                 -Wno-error=missing-methods.
>>>> >                  > Users can set such an option in cabal.project or
>>>> >                 stack.yaml to work
>>>> >                  > around breakage that is not promptly fixed by the
>>>> >                 library author.
>>>> >                  >
>>>> >                  > This change does mean that GHC with
>>>> -XHaskell98/2010
>>>> >                 will by default
>>>> >                  > reject some programs that are explicitly permitted
>>>> by
>>>> >                 the Haskell98/2010
>>>> >                  > specification. I recommend we document this
>>>> >                 infelicity, but accept it,
>>>> >                  > as much of the benefit of the proposal is that it
>>>> >                 applies by default.
>>>> >                  >
>>>> >                  > The proposal establishes the precedent that some
>>>> >                 warnings may be treated
>>>> >                  > as errors by default, and introduces a warning
>>>> group
>>>> >                 -Wsevere to
>>>> >                  > classify them. This seems conceptually useful and
>>>> >                 gives us the option to
>>>> >                  > extend the -Wsevere set in the future (e.g. as a
>>>> >                 final stage of
>>>> >                  > deprecation before a feature is removed).
>>>> >                  >
>>>> >                  > Thoughts?
>>>> >                  >
>>>> >                  > Adam
>>>> >                  >
>>>> >                  >
>>>> >                  > On 11/09/2023 20:25, Joachim Breitner wrote:
>>>> >                  >> Dear Committee,
>>>> >                  >>
>>>> >                  >> based on suggestions by Oleg Grenrus, I wrote a
>>>> >                 proposal to introduce a
>>>> >                  >> warning group -Wsevere for on-by-defaults,
>>>> >                 error-by-default warnings,
>>>> >                  >> and initially fill it with missing-methods and
>>>> >                 missing-fields.
>>>> >                  >>
>>>> >                  >>
>>>> >                  >>
>>>> >
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/571
>>>> >                 <
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/571>
>>>> >                  >>
>>>> >                  >>
>>>> >
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>> <
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>>> >
>>>> >                  >>
>>>> >                  >> I’d like to nominate Adam as the shepherd, who
>>>> >                 already reviewed it a
>>>> >                  >> bit on Github.
>>>> >                  >>
>>>> >                  >> Please guide us to a conclusion as outlined in
>>>> >                  >>
>>>> >
>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process <
>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process>
>>>> >                  >>
>>>> >                  >>
>>>> >                  >> Cheers,
>>>> >                  >> Joachim
>>>>
>>>>
>>>> --
>>>> 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/20231009/4e667b47/attachment-0001.html>

From mail at joachim-breitner.de  Mon Oct  9 12:16:07 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 09 Oct 2023 14:16:07 +0200
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <CANsrgPKzmoP0pFz6C+D4Kuengjwx821aYHf3MRwf2PtvqVpcMQ@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
 <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
 <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
 <CANsrgPKzmoP0pFz6C+D4Kuengjwx821aYHf3MRwf2PtvqVpcMQ@mail.gmail.com>
Message-ID: <7633fbec83765a9c26e8d67e4f1ddbd7976727d4.camel@joachim-breitner.de>

Hi,

Am Montag, dem 09.10.2023 um 12:25 +0100 schrieb Simon Marlow:
> By putting the new behaviour in GHC2024, users can choose when to
> update their code to accommodate the change.

almost. Users choose when to update _their_ code to a new language
edition, but not when their dependencies are updated.

For most proposals, I’d fully agree that going via a new language
extension, possibly on by default in a future GHC20xx, is the way to
go. But in this _particular_ case, we have that the main driving
motivation is that we really want libraries to stop building if their
dependencies have introduced new methods. These libraries are very
likely not going to use GHC2024 any time soon: 

Firstly, because libraries can’t upgrade to new GHC20xx as quickly as
programs can, because they want to support older versions of GHC.

But secondly, because this quality control of “build fails when things
are likely wrong” is especially important for less-actively maintained
libraries.

Changes tied to language pragmas only affect those modules/libraries
that want to be affected. This is great in general, but not helpful for
changes that need to apply to _all_ modules/libraries.

So it seems that the present use case is only well addressed if `-
Werror=missing-methods` becomes a default in a future GHC version
_independent_ of the language model. The stability document has a
provision vor this: 

> (GR2) We may break (GR1), but only with a compelling reason, and with
> careful consideration of impact..


I suggest we first focus on this question: Does the proposed change
should fall under this exception and be rolled out (with deprecation)
globally.
If yes, we do that.
If not, we can then ponder if this change is still useful as part of a
future GHC20xx, or not worth the bother then.


Cheers,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From moritz.angermann at gmail.com  Mon Oct  9 13:04:25 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 9 Oct 2023 21:04:25 +0800
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <7633fbec83765a9c26e8d67e4f1ddbd7976727d4.camel@joachim-breitner.de>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
 <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
 <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
 <CANsrgPKzmoP0pFz6C+D4Kuengjwx821aYHf3MRwf2PtvqVpcMQ@mail.gmail.com>
 <7633fbec83765a9c26e8d67e4f1ddbd7976727d4.camel@joachim-breitner.de>
Message-ID: <CAKfdd-xodyYm15SCkPNamtAxV6zckYmLQRVOMYbwKi6tzYDHew@mail.gmail.com>

Joachim,

> the main driving motivation is that we really want libraries to stop
building if their dependencies have introduced new methods.

So we want this because we introduce extra fields in a dependency and thus
"silently" break all consumers? Not because
people write new green-field code and end up ignoring the warning? And even
worse because you can transitively depend
on a library that was broken by one of its dependencies adding fields? This
case was not clear to me from the proposal.
Wouldn't this be something that PVP should guard against? Adding new fields
should result in a new major version, because
it's technically a breaking change?

I think this is more of an education/communication problem.  The existing
warnings do not seem to convey this insight very
well?

>From the PVP (https://pvp.haskell.org):
> Breaking change. If any entity was removed, or the types of any entities
or **the definitions of datatypes or classes were changed**, or orphan
instances were added or any instances were removed, then the new A.B MUST
be greater than the previous A.B. Note that modifying imports or depending
on a newer version of another package may cause extra orphan instances to
be exported and thus force a major version change.
(emphasis mine)

Cheers,
  Moritz

On Mon, 9 Oct 2023 at 20:16, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, dem 09.10.2023 um 12:25 +0100 schrieb Simon Marlow:
> > By putting the new behaviour in GHC2024, users can choose when to
> > update their code to accommodate the change.
>
> almost. Users choose when to update _their_ code to a new language
> edition, but not when their dependencies are updated.
>
> For most proposals, I’d fully agree that going via a new language
> extension, possibly on by default in a future GHC20xx, is the way to
> go. But in this _particular_ case, we have that the main driving
> motivation is that we really want libraries to stop building if their
> dependencies have introduced new methods. These libraries are very
> likely not going to use GHC2024 any time soon:
>
> Firstly, because libraries can’t upgrade to new GHC20xx as quickly as
> programs can, because they want to support older versions of GHC.
>
> But secondly, because this quality control of “build fails when things
> are likely wrong” is especially important for less-actively maintained
> libraries.
>
> Changes tied to language pragmas only affect those modules/libraries
> that want to be affected. This is great in general, but not helpful for
> changes that need to apply to _all_ modules/libraries.
>
> So it seems that the present use case is only well addressed if `-
> Werror=missing-methods` becomes a default in a future GHC version
> _independent_ of the language model. The stability document has a
> provision vor this:
>
> > (GR2) We may break (GR1), but only with a compelling reason, and with
> > careful consideration of impact..
>
>
> I suggest we first focus on this question: Does the proposed change
> should fall under this exception and be rolled out (with deprecation)
> globally.
> If yes, we do that.
> If not, we can then ponder if this change is still useful as part of a
> future GHC20xx, or not worth the bother then.
>
>
> Cheers,
> Joachim
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20231009/89998ac4/attachment.html>

From chris at chrisdornan.com  Mon Oct  9 13:38:58 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 9 Oct 2023 14:38:58 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <7633fbec83765a9c26e8d67e4f1ddbd7976727d4.camel@joachim-breitner.de>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
 <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
 <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
 <CANsrgPKzmoP0pFz6C+D4Kuengjwx821aYHf3MRwf2PtvqVpcMQ@mail.gmail.com>
 <7633fbec83765a9c26e8d67e4f1ddbd7976727d4.camel@joachim-breitner.de>
Message-ID: <41CF2C4A-B966-4FCA-9BA3-AC234C77AACB@chrisdornan.com>

If I understand you rightly, you are arguing that any legacy packages that would flag severe warnings should now fail to compile, even if they are marked as being (say) Haskell2010? For reasons I have given (I have no wish to be repetive), that strikes me as undesirable. If the impetus for the proposal was driven by observed problematic failures of packaged code that could be caught by these warnings then, for me, there would be a discussion to be had. But my understanding is that the proposal is driven by a desire to tighten up the language moving forward with severe warnings treated as errors by default. Maybe one of the authors could say which they intended.

Chris

> On 9 Oct 2023, at 13:16, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Montag, dem 09.10.2023 um 12:25 +0100 schrieb Simon Marlow:
>> By putting the new behaviour in GHC2024, users can choose when to
>> update their code to accommodate the change.
> 
> almost. Users choose when to update _their_ code to a new language
> edition, but not when their dependencies are updated.
> 
> For most proposals, I’d fully agree that going via a new language
> extension, possibly on by default in a future GHC20xx, is the way to
> go. But in this _particular_ case, we have that the main driving
> motivation is that we really want libraries to stop building if their
> dependencies have introduced new methods. These libraries are very
> likely not going to use GHC2024 any time soon: 
> 
> Firstly, because libraries can’t upgrade to new GHC20xx as quickly as
> programs can, because they want to support older versions of GHC.
> 
> But secondly, because this quality control of “build fails when things
> are likely wrong” is especially important for less-actively maintained
> libraries.
> 
> Changes tied to language pragmas only affect those modules/libraries
> that want to be affected. This is great in general, but not helpful for
> changes that need to apply to _all_ modules/libraries.
> 
> So it seems that the present use case is only well addressed if `-
> Werror=missing-methods` becomes a default in a future GHC version
> _independent_ of the language model. The stability document has a
> provision vor this: 
> 
>> (GR2) We may break (GR1), but only with a compelling reason, and with
>> careful consideration of impact..
> 
> 
> I suggest we first focus on this question: Does the proposed change
> should fall under this exception and be rolled out (with deprecation)
> globally.
> If yes, we do that.
> If not, we can then ponder if this change is still useful as part of a
> future GHC20xx, or not worth the bother then.
> 
> 
> Cheers,
> Joachim
> 
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From mail at joachim-breitner.de  Mon Oct  9 14:22:03 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 09 Oct 2023 16:22:03 +0200
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <CAKfdd-xodyYm15SCkPNamtAxV6zckYmLQRVOMYbwKi6tzYDHew@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
 <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
 <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
 <CANsrgPKzmoP0pFz6C+D4Kuengjwx821aYHf3MRwf2PtvqVpcMQ@mail.gmail.com>
 <7633fbec83765a9c26e8d67e4f1ddbd7976727d4.camel@joachim-breitner.de>
 <CAKfdd-xodyYm15SCkPNamtAxV6zckYmLQRVOMYbwKi6tzYDHew@mail.gmail.com>
Message-ID: <f7dae457ba241b805996794258e2c46723018fa9.camel@joachim-breitner.de>

Hi,

Am Montag, dem 09.10.2023 um 21:04 +0800 schrieb Moritz Angermann:
> Joachim,
> 
> > the main driving motivation is that we really want libraries to
> > stop building if their dependencies have introduced new methods.
> 
> So we want this because we introduce extra fields in a dependency and
> thus "silently" break all consumers? Not because
> people write new green-field code and end up ignoring the warning?

That is my understanding, yes.  Oleg, who suggested this originally (I
just wrote it up) says (see motivation section of the proposal)

> not having -Wsevere=missing-methods by default essentially prevents 
> any (true) breakage assessment of adding new, non-defaulted members
> to existing type-classes.

> Wouldn't this be something that PVP should guard against? Adding new
> fields should result in a new major version, because
> it's technically a breaking change?

Yeah, probably in a world where everyone follows the PVP perfectly, we
wouldn’t have this discussion.

Am Montag, dem 09.10.2023 um 14:38 +0100 schrieb Chris Dornan:
> If I understand you rightly, you are arguing that any legacy packages
> that would flag severe warnings should now fail to compile, even if 
> they are marked as being (say) Haskell2010?

I’m not arguing that we should do this, but I am arguing that this is
the question we are supposed to decide here. (I’m personally not
decided

> If the impetus for the proposal was driven by observed problematic
> failures of packaged code that could be caught by these warnings
> then, for me, there would be a discussion to be had. 

My understanding, based on the motivation section, is that this _is_
the impetus.

Cheers,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From chris at chrisdornan.com  Mon Oct  9 15:27:22 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 9 Oct 2023 16:27:22 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <f7dae457ba241b805996794258e2c46723018fa9.camel@joachim-breitner.de>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
 <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
 <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
 <CANsrgPKzmoP0pFz6C+D4Kuengjwx821aYHf3MRwf2PtvqVpcMQ@mail.gmail.com>
 <7633fbec83765a9c26e8d67e4f1ddbd7976727d4.camel@joachim-breitner.de>
 <CAKfdd-xodyYm15SCkPNamtAxV6zckYmLQRVOMYbwKi6tzYDHew@mail.gmail.com>
 <f7dae457ba241b805996794258e2c46723018fa9.camel@joachim-breitner.de>
Message-ID: <6F2D8C6E-2BC8-4554-A25F-BCF30EB52380@chrisdornan.com>

> 
>> If the impetus for the proposal was driven by observed problematic
>> failures of packaged code that could be caught by these warnings
>> then, for me, there would be a discussion to be had.
> 
> My understanding, based on the motivation section, is that this _is_
> the impetus.

I have read the motivation closely (which makes complete sense to me) but nowhere can I see any suggestion that anyone has observed problems with running code that would have been caught by the proposed severe warnings/errors.

This is not to say that that hasn't happened, just that the proposal (entirely correctly in my view) seems principally concerned with making the language safer and removing a class of footguns.

Maybe if I give a simple example to illustrate. I had a fairly mercifully brief time when I liked to use printf -- it tickled historical attachments in my C programming days when displaying formatted string seemed so much more useful. (Of course I got briefly burnt by this practice -- we now have more expressive alternatives that are also type-safe.)  If everybody agreed that printf was a newbie footgun that we wanted to remove then we could attack this problem by deprecating printf and discouraging its use.

Another situation could arise where changes to Haskell have lead to legacy packages relying on printf blowing up, where its continued presence in the ecosystem was providing a systemic risk, with everyone agreeing that the cleanest way to solve the problem would be to force the compiler to fail to build any package that tried o use printf.  The compiler would do this by default, but somebody who really knew what they were doing, could supply incantations to the compiler that would override this behaviour.

My point here is that the motivating sections for removing a footgun and that for blowing up any existing code that does not adhere to a new discipline looks quite different. Any proposal for tightening up the language to provide better static guarantees is going to be seeking to avoid programs that can fail at runtime. A proposal that seeks to invalidate longstanding packages because of an emergent threat to the ecosystem will need to do more work, documented high-profile failures. The motivation section for #571 doesn't appear (to me at least) to be of this latter kind.

Chris

From marlowsd at gmail.com  Mon Oct  9 15:53:19 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 9 Oct 2023 16:53:19 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <f7dae457ba241b805996794258e2c46723018fa9.camel@joachim-breitner.de>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
 <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
 <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
 <CANsrgPKzmoP0pFz6C+D4Kuengjwx821aYHf3MRwf2PtvqVpcMQ@mail.gmail.com>
 <7633fbec83765a9c26e8d67e4f1ddbd7976727d4.camel@joachim-breitner.de>
 <CAKfdd-xodyYm15SCkPNamtAxV6zckYmLQRVOMYbwKi6tzYDHew@mail.gmail.com>
 <f7dae457ba241b805996794258e2c46723018fa9.camel@joachim-breitner.de>
Message-ID: <CANsrgP+mOdSY5=13ABLpwsqDrf7KbEkAHQ4C8rx12iz5Ji0JgA@mail.gmail.com>

On Mon, 9 Oct 2023 at 15:22, Joachim Breitner <mail at joachim-breitner.de>
wrote:

>
> That is my understanding, yes.  Oleg, who suggested this originally (I
> just wrote it up) says (see motivation section of the proposal)
>
> > not having -Wsevere=missing-methods by default essentially prevents
> > any (true) breakage assessment of adding new, non-defaulted members
> > to existing type-classes.
>

If the goal is to do a breakage assessment, couldn't you make the change to
your library and then build all of Hackage with
`--ghc-option=-Werror=severe`?

Cheers
Simon



> > Wouldn't this be something that PVP should guard against? Adding new
> > fields should result in a new major version, because
> > it's technically a breaking change?
>
> Yeah, probably in a world where everyone follows the PVP perfectly, we
> wouldn’t have this discussion.
>
> Am Montag, dem 09.10.2023 um 14:38 +0100 schrieb Chris Dornan:
> > If I understand you rightly, you are arguing that any legacy packages
> > that would flag severe warnings should now fail to compile, even if
> > they are marked as being (say) Haskell2010?
>
> I’m not arguing that we should do this, but I am arguing that this is
> the question we are supposed to decide here. (I’m personally not
> decided
>
> > If the impetus for the proposal was driven by observed problematic
> > failures of packaged code that could be caught by these warnings
> > then, for me, there would be a discussion to be had.
>
> My understanding, based on the motivation section, is that this _is_
> the impetus.
>
> Cheers,
> Joachim
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20231009/b4980659/attachment.html>

From mail at joachim-breitner.de  Mon Oct  9 15:57:04 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 09 Oct 2023 17:57:04 +0200
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <CANsrgP+mOdSY5=13ABLpwsqDrf7KbEkAHQ4C8rx12iz5Ji0JgA@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
 <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
 <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
 <CANsrgPKzmoP0pFz6C+D4Kuengjwx821aYHf3MRwf2PtvqVpcMQ@mail.gmail.com>
 <7633fbec83765a9c26e8d67e4f1ddbd7976727d4.camel@joachim-breitner.de>
 <CAKfdd-xodyYm15SCkPNamtAxV6zckYmLQRVOMYbwKi6tzYDHew@mail.gmail.com>
 <f7dae457ba241b805996794258e2c46723018fa9.camel@joachim-breitner.de>
 <CANsrgP+mOdSY5=13ABLpwsqDrf7KbEkAHQ4C8rx12iz5Ji0JgA@mail.gmail.com>
Message-ID: <4593b331744f499628f20e00d5a844bd62cea0ff.camel@joachim-breitner.de>

Hi,

Am Montag, dem 09.10.2023 um 16:53 +0100 schrieb Simon Marlow:
> On Mon, 9 Oct 2023 at 15:22, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > That is my understanding, yes.  Oleg, who suggested this originally (I
> > just wrote it up) says (see motivation section of the proposal)
> > 
> > > not having -Wsevere=missing-methods by default essentially prevents 
> > > any (true) breakage assessment of adding new, non-defaulted members
> > > to existing type-classes.
> 
> 
> If the goal is to do a breakage assessment, couldn't you make the
> change to your library and then build all of Hackage with `--ghc-
> option=-Werror=severe`?

Not if Hackage already fails with -Werror=severe even without the
change under assessment. But we should ask Oleg on Github, I am just
relaying what I thought his motivation was.

Should we send this back for revision? It seems there is plenty of
discussion going on here and on github. (Is there an equivalent of
Wadler’s law about “compiler flags” instead of “whitespace”?)

Cheers,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From moritz.angermann at gmail.com  Mon Oct  9 23:48:56 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 10 Oct 2023 07:48:56 +0800
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <4593b331744f499628f20e00d5a844bd62cea0ff.camel@joachim-breitner.de>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>
 <CAJKmMz_8Vk=zUAijWzYPY77V82fo7r2h-4PAx+5uHYnKXW6VTA@mail.gmail.com>
 <CANsrgPK6-90oysyDx0+Y00+3rvzGkdYTU3LNQo6-80e0XG6G=w@mail.gmail.com>
 <CAJKmMz--VN8c4kUGneq+yPrqsbJHLcPM1hS1cVRL0eFB4TsSPw@mail.gmail.com>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
 <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
 <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
 <CANsrgPKzmoP0pFz6C+D4Kuengjwx821aYHf3MRwf2PtvqVpcMQ@mail.gmail.com>
 <7633fbec83765a9c26e8d67e4f1ddbd7976727d4.camel@joachim-breitner.de>
 <CAKfdd-xodyYm15SCkPNamtAxV6zckYmLQRVOMYbwKi6tzYDHew@mail.gmail.com>
 <f7dae457ba241b805996794258e2c46723018fa9.camel@joachim-breitner.de>
 <CANsrgP+mOdSY5=13ABLpwsqDrf7KbEkAHQ4C8rx12iz5Ji0JgA@mail.gmail.com>
 <4593b331744f499628f20e00d5a844bd62cea0ff.camel@joachim-breitner.de>
Message-ID: <CAKfdd-wGBZEgo8CpQkgxPgMdjpTmj_yOOK0+cW-bdwA2j9cszg@mail.gmail.com>

This all sounds to me like we are trying to fix PVP by adding errors. I'm
ok to declare
PVP bankruptcy. If it's too hard to be practically used, we need to find a
different solution.

But this problem to me sounds more like we rather need some automation?
What we
seem to essentially want to achieve is guarantee that component integration
is not
faulty? It all sounds to me like what we really want is an automated
solution that flags
packages that were broken by changes in their dependencies. And then be
trivially able
to address those (and open PRs). Though I guess you'd also need to deal with
version bounds, the inverse of missing-fields would be overspecified
fields, and thus
the library that depends on something that added more fields, now needs a
hard lower
bound after adding the fields?

https://github.com/ghc-proposals/ghc-proposals/pull/617 likely also would
benefit from
automation. Maybe reboot hackage matrix in some form? Can someone point me
in
the right direction?

Best,
 Moritz

On Mon, 9 Oct 2023 at 23:57, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, dem 09.10.2023 um 16:53 +0100 schrieb Simon Marlow:
> > On Mon, 9 Oct 2023 at 15:22, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> > >
> > > That is my understanding, yes.  Oleg, who suggested this originally (I
> > > just wrote it up) says (see motivation section of the proposal)
> > >
> > > > not having -Wsevere=missing-methods by default essentially prevents
> > > > any (true) breakage assessment of adding new, non-defaulted members
> > > > to existing type-classes.
> >
> >
> > If the goal is to do a breakage assessment, couldn't you make the
> > change to your library and then build all of Hackage with `--ghc-
> > option=-Werror=severe`?
>
> Not if Hackage already fails with -Werror=severe even without the
> change under assessment. But we should ask Oleg on Github, I am just
> relaying what I thought his motivation was.
>
> Should we send this back for revision? It seems there is plenty of
> discussion going on here and on github. (Is there an equivalent of
> Wadler’s law about “compiler flags” instead of “whitespace”?)
>
> Cheers,
> Joachim
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20231010/8cdf91c7/attachment.html>

From mail at joachim-breitner.de  Wed Oct 11 17:27:20 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 11 Oct 2023 19:27:20 +0200
Subject: [ghc-steering-committee] GHC2024 timeline
Message-ID: <f6116c88f45649b1c6170adcc8457c341426fba6.camel@joachim-breitner.de>

Dear Committee,

like every year so far, I will make a push to define a new GHC20xx.
Maybe this year it will happen…

TL;DR: If you want GHC2024, head to
https://github.com/ghc-proposals/ghc-proposals/pull/613 and tell us
what it should look like.

I am proposing the following procedure and timeline:

Phase 1 (now): Nominations and discussion

   The community (including us) nominates extensions for inclusion (or
   removal) for GHC2024, relative to GHC2021, at
   https://github.com/ghc-proposals/ghc-proposals/pull/613
   together, and everyone can help refining the rationales/pros/cons.
   I have taken the list from last year to seed this document
   
   I propose to conclude this by end of October.

Phase 2 (November): Committee deliberation

   Based on that list, we do what we do best: discuss.
   
   Until end of November
   
Phase 3 (early Decemb): Voting

   Finally, we vote. Last year, we first had a “should do we GHC20xx”
   vote, which (had it not been rejected) would be followed by a vote
   where each nominated extension can be yay’ed/nay’ed individually. I
   guess we can do the same this year.
   
Cheers,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From adam at well-typed.com  Wed Oct 11 20:13:59 2023
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 11 Oct 2023 21:13:59 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <4593b331744f499628f20e00d5a844bd62cea0ff.camel@joachim-breitner.de>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <CANsrgPJftSKg7NriKM6Msf2zNRhAhdXYPvukFrmV8fZUZWVRXg@mail.gmail.com>
 <ffc62e81-9dee-f649-cf15-51c9578f7806@well-typed.com>
 <CANsrgPKKg2CUFZNVpUVA-X5cj3XBuNxXzuLDRE+mJ=9Uby9Cjg@mail.gmail.com>
 <624DF0E4-2C49-47EE-8E5F-BEE07B9188D7@chrisdornan.com>
 <CAJKmMz9QAZpoG8=WyhobKAQ=nfUuC9190zHBMuqZ4HQ2VbJE5w@mail.gmail.com>
 <1CBABB47-BDE0-4995-BD92-66A49D9B2179@chrisdornan.com>
 <CAJKmMz_7W-v+somnvJWHS6hBsNofAxhZYDESU-nf4y=jHe4fgw@mail.gmail.com>
 <CANsrgPKzmoP0pFz6C+D4Kuengjwx821aYHf3MRwf2PtvqVpcMQ@mail.gmail.com>
 <7633fbec83765a9c26e8d67e4f1ddbd7976727d4.camel@joachim-breitner.de>
 <CAKfdd-xodyYm15SCkPNamtAxV6zckYmLQRVOMYbwKi6tzYDHew@mail.gmail.com>
 <f7dae457ba241b805996794258e2c46723018fa9.camel@joachim-breitner.de>
 <CANsrgP+mOdSY5=13ABLpwsqDrf7KbEkAHQ4C8rx12iz5Ji0JgA@mail.gmail.com>
 <4593b331744f499628f20e00d5a844bd62cea0ff.camel@joachim-breitner.de>
Message-ID: <b0fd2a18-d271-461d-9d39-1bef72f50ca9@well-typed.com>

On 09/10/2023 16:57, Joachim Breitner wrote:
> 
> Should we send this back for revision? It seems there is plenty of
> discussion going on here and on github. (Is there an equivalent of
> Wadler’s law about “compiler flags” instead of “whitespace”?)

Yes, I think we are clearly not going to reach consensus on this 
proposal as it stands. There are several potential compromise positions 
being discussed, but it seems like we need a revised or alternative 
proposal, so I'm returning this for revision.

Cheers,

Adam


-- 
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


From arnaud.spiwack at tweag.io  Thu Oct 12 08:07:47 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 12 Oct 2023 10:07:47 +0200
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAGwnsnniSGMLd_S8f81vdj9DmEVvKeWuhCLTtNNjWGeSKO0D6g@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>
 <CAGwnsnnhEYHOhuts0N4AoqcRsx3GTJ4fZGNVGjOd1QfQknkDpA@mail.gmail.com>
 <CAKfdd-zqumiE0FWp4vSyJXO8rqugupdXROa93fEBEYimtXYayQ@mail.gmail.com>
 <6ecf13eb-7c08-4f09-5696-deadc830231f@well-typed.com>
 <CAGwnsnkHOsVeDTqo1gTw10ECMQ+QjabRFbcspwCN8xcsN2eEfg@mail.gmail.com>
 <CAKfdd-ziOZdZ=gNpZLU-w-n8V6BFE=uu+jdK5MZyZPMcmgv5Bg@mail.gmail.com>
 <CAJKmMz_MeY4bwub1Dy43jW5A9w+yNf-0vqCdHi-iQ0J4A11EMQ@mail.gmail.com>
 <CAKfdd-yDN2PLX=Wga-tjndXqAGcg+2+u9nnxzHiH5U=iZBTrHw@mail.gmail.com>
 <CAJKmMz_tVcqczQoQ0k6YX4uKwas1KusN18JwxK+BHzjMWSLuLw@mail.gmail.com>
 <CAGwnsnkAvrwUxDZm2+Mfgg7ngJFbugYjZesL=cGgYQPQC1ai7g@mail.gmail.com>
 <CAGwnsnns2kpWamSegWEP1KxzReeni5re=qkK5spAbt0FqUxzFA@mail.gmail.com>
 <CAGwnsnniSGMLd_S8f81vdj9DmEVvKeWuhCLTtNNjWGeSKO0D6g@mail.gmail.com>
Message-ID: <CAGwnsnn=YxZ3BDAaLyPsWxSNHfKnp2F9rYgx=hS2pf2tCp32xg@mail.gmail.com>

I'm now accepting this proposal.

On Mon, 9 Oct 2023 at 10:06, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:

> Dear all,
>
> Absent votes, based on my current understanding of everybody's position,
> I'll mark the proposal as accepted, without modification, on Wednesday
> (11th October).
>
> On Tue, 3 Oct 2023 at 11:52, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Simon votes A above. I vote A too (I think I actually feel pretty
>> strongly about this one).
>>
>> On Tue, 3 Oct 2023 at 11:52, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> Let's do a quick vote. All, which do you prefer?
>>>
>>> A. Introduce the breakage immediately and change the argument order of
>>> setField (current state of the proposal)
>>> B. Introduce a new extension -XOverloadedRecordUpdateNew which would use
>>> a setField with a different argument order, so that it can be used during
>>> the transition period. Eventually OverloadedRecordUpdateNew becomes
>>> deprecated and OverloadedRecordUpdate swaps the argument order. (Moritz's
>>> proposal)
>>> C. Keep the originally proposed setField argument order (nobody have
>>> suggested this yet, but I'm including it for completeness)
>>>
>>> On Tue, 3 Oct 2023 at 10:33, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> Sure.
>>>>
>>>> Just to be clear, I'm not trying to set a precedent here!
>>>>
>>>> Simon
>>>>
>>>> On Tue, 3 Oct 2023 at 09:26, Moritz Angermann <
>>>> moritz.angermann at gmail.com> wrote:
>>>>
>>>>> I’m not going to stay in the way of this proposal. I’hope it’s
>>>>> understandable if I recuse myself.
>>>>>
>>>>> On Tue, 3 Oct 2023 at 4:18 PM, Simon Peyton Jones <
>>>>> simon.peytonjones at gmail.com> wrote:
>>>>>
>>>>>> We have to balance the cost of mitigation against the cost of
>>>>>> breakage.
>>>>>>
>>>>>>    - Cost of breakage.  Adam has identified only two packages that
>>>>>>    woud, both of which can adapt promptly.  It's true that there is more code
>>>>>>    out there, but the absence on Hackage is strongly indicative that there is
>>>>>>    unlikely to be much.
>>>>>>    - Cost of mitigation.  Supporting both behaviours, having extra
>>>>>>    language flags, that must in turn themselves be deprecated away, are real
>>>>>>    costs.  The suck effort away from more productive activity.
>>>>>>    - I completely agree that if we had a classification,
>>>>>>    OverloadedRecordUpdate would have been classified as Experimental, and we
>>>>>>    would not be discussing deprecation cycles.  And signalling what is
>>>>>>    experimental and what is stable is a *primary *goal of the
>>>>>>    stability conversation we are having.  I agree strongly with Moritz on this
>>>>>>    point.
>>>>>>    - However the user manual (Section 6.5.11
>>>>>>    <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/overloaded_record_update.html?highlight=overloaded%20record#overloaded-record-update>)
>>>>>>    says "*EXPERIMENTAL* *This design of this extension may well
>>>>>>    change in the future. It would be inadvisable to start using this extension
>>>>>>    for long-lived libraries just yet*".  Short of an official
>>>>>>    classification mechanism, which we don't have yet, it seems hard to imagine
>>>>>>    a clearer statement than that.
>>>>>>
>>>>>> My judgement: in this case we should forge ahead without introducing
>>>>>> OverloadedRecordNew and supporting both behaviours. (I have not even begun
>>>>>> to think about how hard that would be to implement.)  Let's spend our
>>>>>> precious cycles elsewhere.
>>>>>>
>>>>>> Simon
>>>>>>
>>>>>> On Tue, 3 Oct 2023 at 08:48, Moritz Angermann <
>>>>>> moritz.angermann at gmail.com> wrote:
>>>>>>
>>>>>>> Arnaud,
>>>>>>>
>>>>>>> That is a good argument. Without an opt-in to the new syntax, they
>>>>>>> can't adapt. I guess this brings us to the extension lifecycle. A solution
>>>>>>> could be
>>>>>>> 1. Deprecate OverloadedRecordUpdate in favour of
>>>>>>> OverloadedRecordUpdateNew. The user can adapt their code and use a
>>>>>>> different Extension.
>>>>>>> 2. Eventually Have OverloadedRecordUpdateNew be a synonym for
>>>>>>> changed OverloadedRecordUpdate. And Deprecate OverloadedRecordUpdateNew
>>>>>>>     over a longer period of time.
>>>>>>>
>>>>>>> I think this actually shows the value a `--std=experimental` could
>>>>>>> have. If `OverloadedRecordUpdate` was behind `--std=experimental` breaking
>>>>>>> it would
>>>>>>> be permissible by design. And we would not have this discussion, and
>>>>>>> Adam would not need to try to find all the potential breaking codes. This
>>>>>>> is part
>>>>>>> of the proposal to make `--std=experimental` a thing, allow fast(er)
>>>>>>> paced iteration on the experimental side of the compiler, while being
>>>>>>> extremely
>>>>>>> explicit about it being experimental features that can break at any
>>>>>>> time and without warning.
>>>>>>>
>>>>>>> The deprecation process outlined above would be fore
>>>>>>> non-experimental features. They can still be changed, but with a more
>>>>>>> rigorous change evolution.
>>>>>>>
>>>>>>> I hope this helps to clarify my position?
>>>>>>>
>>>>>>> Best,
>>>>>>>  Moritz
>>>>>>>
>>>>>>>
>>>>>>> On Tue, 3 Oct 2023 at 15:31, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> @Moritz: very clear thank you, though I'd like to understand how
>>>>>>>> one could adapt during the transition period to an argument swap, would you
>>>>>>>> say? Secondary question: if they can't adapt, isn't there a risk of making
>>>>>>>> the breakage more painful by delaying it, and letting more people use
>>>>>>>> -XOverloadedRecordUpdate with the argument order which isn't the final one?
>>>>>>>>
>>>>>>>> @Adam: we have to recognise that Hackage is not all the Haskell
>>>>>>>> code. I expect Hackage to be a little more conservative in extensions than
>>>>>>>> end-user applications. As such we're not guaranteed an absence of breakage
>>>>>>>> (it's still probably quite small, but it's hard to quantify).
>>>>>>>>
>>>>>>>> On Tue, 3 Oct 2023 at 09:21, Adam Gundry <adam at well-typed.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> The backwards compatibility impact here is really extremely small,
>>>>>>>>> because OverloadedRecordUpdate is essentially unusable at present
>>>>>>>>> (as
>>>>>>>>> well as being explicitly documented as subject to change), so
>>>>>>>>> nobody
>>>>>>>>> uses it. While someone could implement a warning when the
>>>>>>>>> extension is
>>>>>>>>> turned on to say that it will change in the future, I'm not sure I
>>>>>>>>> see
>>>>>>>>> much point.
>>>>>>>>>
>>>>>>>>> I used
>>>>>>>>> https://hackage-search.serokell.io/?q=OverloadedRecordUpdate to
>>>>>>>>> look for occurrences of OverloadedRecordUpdate on Hackage, and I
>>>>>>>>> found
>>>>>>>>> precisely one pair of packages using it "for real":
>>>>>>>>>
>>>>>>>>> large-anon-0.3.0
>>>>>>>>> large-records-0.4
>>>>>>>>>
>>>>>>>>> These packages were created by my colleague Edsko in discussion
>>>>>>>>> with me,
>>>>>>>>> and will need to be amended when the proposal is implemented,
>>>>>>>>> because
>>>>>>>>> they want to take advantage of the new functionality.
>>>>>>>>>
>>>>>>>>> The other packages on Hackage containing the string
>>>>>>>>> OverloadedRecordUpdate are tools that reference all extensions:
>>>>>>>>>
>>>>>>>>> Cabal-syntax-3.10.1.0
>>>>>>>>> extensions-0.1.0.0
>>>>>>>>> fourmolu-0.14.0.0
>>>>>>>>> ghc-9.6.3
>>>>>>>>> ghc-boot-th-9.6.3
>>>>>>>>> ghc-exactprint-1.7.0.1
>>>>>>>>> ghc-hs-meta-0.1.2.0
>>>>>>>>> ghc-lib-9.6.2.20230523
>>>>>>>>> ghc-lib-parser-9.6.2.20230523
>>>>>>>>> hackport-0.8.4.0
>>>>>>>>> haskell-src-meta-0.8.12
>>>>>>>>> hindent-6.1.0
>>>>>>>>> hlint-3.6.1
>>>>>>>>> ormolu-0.7.2.0
>>>>>>>>>
>>>>>>>>> plus there are a few references in comments:
>>>>>>>>>
>>>>>>>>> lifx-lan-0.8.2
>>>>>>>>> optics-core-0.4.1.1
>>>>>>>>> pvector-0.1.1
>>>>>>>>> record-dot-preprocessor-0.2.16
>>>>>>>>> tztime-0.1.1.0
>>>>>>>>>
>>>>>>>>> While I generally agree with the "don't abruptly break existing
>>>>>>>>> code"
>>>>>>>>> position, in this case I don't think there is code out there to
>>>>>>>>> break.
>>>>>>>>>
>>>>>>>>> Adam
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 03/10/2023 01:14, Moritz Angermann wrote:
>>>>>>>>> > Arnaud,
>>>>>>>>> >
>>>>>>>>> > thank you for your write up. And sorry that my view seems to be
>>>>>>>>> not
>>>>>>>>> > clear. Let me try to explain.
>>>>>>>>> > My position is: I'm against anything that _abruptly_ breaks
>>>>>>>>> existing
>>>>>>>>> > code. That's basically all there is to it.
>>>>>>>>> > Therefore I'm strongly against breaking changes without an
>>>>>>>>> appropriate
>>>>>>>>> > warning period (from the compiler).
>>>>>>>>> > I also strongly believe that most people do not read
>>>>>>>>> documentation, and
>>>>>>>>> > the authoritative messages are
>>>>>>>>> > the ones the compiler produces. As I've alluded to in a
>>>>>>>>> different email,
>>>>>>>>> > there are lots of people who work
>>>>>>>>> > on software as a 9-5 job, and don't spend their freetime
>>>>>>>>> tinkering and
>>>>>>>>> > playing with languages. They just
>>>>>>>>> > want to get the job done they are assigned. I have a lot of
>>>>>>>>> respect for
>>>>>>>>> > them. In my experience they don't
>>>>>>>>> > read compiler release announcements, or even go and read the
>>>>>>>>> compiler
>>>>>>>>> > documentation. They are given
>>>>>>>>> > the compiler version the company decided on for use in
>>>>>>>>> production.
>>>>>>>>> > That's the tool they use. And that tool
>>>>>>>>> > in my opinion needs to be rock solid, and not break easily
>>>>>>>>> across
>>>>>>>>> > versions. Thus yes, I would very much
>>>>>>>>> > like to see us not have breaking changes at all, but I can see
>>>>>>>>> that we
>>>>>>>>> > may need breaking changes
>>>>>>>>> > occasionally. In those cases I want it to be very visible to the
>>>>>>>>> > consumers that this breaking change is
>>>>>>>>> > coming towards them (compiler warnings). Giving them some time
>>>>>>>>> to adjust
>>>>>>>>> > (migration period), until the
>>>>>>>>> > breaking change happens.  Ultimately we should be able to
>>>>>>>>> compiler
>>>>>>>>> > existing code that compiles today
>>>>>>>>> > with at least the next compiler without it rejecting the code or
>>>>>>>>> needing
>>>>>>>>> > modifications to the code (-Werror
>>>>>>>>> > excluded).
>>>>>>>>> >
>>>>>>>>> > Thus what I'm arguing for is:
>>>>>>>>> > - Let's implement this backwards compatibility.
>>>>>>>>> > - Add compiler warnings about the arguments being swapped in a
>>>>>>>>> future
>>>>>>>>> > GHC version. For _a least_ one major release.
>>>>>>>>> > - Make the breaking change in a subsequent release.
>>>>>>>>> >
>>>>>>>>> > Alternatively I could also see:
>>>>>>>>> > - Adding compiler warnings now that the arguments will be
>>>>>>>>> swapped in a
>>>>>>>>> > future GHC version (for at least one major release).
>>>>>>>>> > - Implement the breaking change in a subsequent release.
>>>>>>>>> >
>>>>>>>>> > Either of those would be ok with me. Implementing a breaking
>>>>>>>>> change from
>>>>>>>>> > one version to the next, without an
>>>>>>>>> > appropriate deprecation/migration period (that is, the compiler
>>>>>>>>> will
>>>>>>>>> > warn loudly that changes are coming) is something
>>>>>>>>> > I am _very_ vehemently against.
>>>>>>>>> >
>>>>>>>>> > If the migration/deprecation warnings would provide a link to a
>>>>>>>>> GitHub
>>>>>>>>> > ticket or something where more information
>>>>>>>>> > can be found and maybe even a discussion could be had would
>>>>>>>>> probably
>>>>>>>>> > also be a good idea.
>>>>>>>>> >
>>>>>>>>> > I hope this helps clarify my position? If not, feel free to ask
>>>>>>>>> more,
>>>>>>>>> > I'm also happy to jump onto a call to explain my
>>>>>>>>> > position if needed.
>>>>>>>>> >
>>>>>>>>> > Best,
>>>>>>>>> >   Moritz
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Mon, 2 Oct 2023 at 23:31, Arnaud Spiwack <
>>>>>>>>> arnaud.spiwack at tweag.io
>>>>>>>>> > <mailto:arnaud.spiwack at tweag.io>> wrote:
>>>>>>>>> >
>>>>>>>>> >     Sorry I took a little bit of time to react to this, it was a
>>>>>>>>> lot to
>>>>>>>>> >     take in and I didn't have the mental space last week.
>>>>>>>>> >
>>>>>>>>> >     The only person that may have spoken against the current
>>>>>>>>> state of
>>>>>>>>> >     the proposal is Moritz. Yet I realise that I don't actually
>>>>>>>>> know,
>>>>>>>>> >     Moritz, what your position is.
>>>>>>>>> >
>>>>>>>>> >     To recap: to use -XOverloadedRecordUpdate in current GHC,
>>>>>>>>> you need
>>>>>>>>> >     to use -XRebindableSyntax and provide a setField function.
>>>>>>>>> In the
>>>>>>>>> >     new proposal you can use -XOverloadedRecordUpdate without
>>>>>>>>> >     -XRebindableSyntax, but when -XRebindableSyntax is on, the
>>>>>>>>> setField
>>>>>>>>> >     function that you have to provide has its argument swapped.
>>>>>>>>> The
>>>>>>>>> >     current documentation of OverloadedRecordUpdate has the
>>>>>>>>> following
>>>>>>>>> >     text at the top “*EXPERIMENTAL* /This design of this
>>>>>>>>> extension may
>>>>>>>>> >     well change in the future. It would be inadvisable to start
>>>>>>>>> using
>>>>>>>>> >     this extension for long-lived libraries just yet./”.
>>>>>>>>> >
>>>>>>>>> >     Now, I don't quite see how we could have a transition period
>>>>>>>>> that
>>>>>>>>> >     would allow a smooth transition there. There is no piece of
>>>>>>>>> code,
>>>>>>>>> >     with RebindableSyntax, that would compile before and after
>>>>>>>>> the
>>>>>>>>> >     change. So unless I'm missing something the position we can
>>>>>>>>> take as
>>>>>>>>> >     a committee can be either
>>>>>>>>> >     - Let's have the breakage without a transition period
>>>>>>>>> >     - Let's not make the breaking change ever and use the earlier
>>>>>>>>> >     argument order for set
>>>>>>>>> >
>>>>>>>>> >     Which one do you argue for, or am I missing another option?
>>>>>>>>> >
>>>>>>>>> >     On Sun, 24 Sept 2023 at 15:36, Eric Seidel <eric at seidel.io
>>>>>>>>> >     <mailto:eric at seidel.io>> wrote:
>>>>>>>>> >
>>>>>>>>> >         I am in favor of this proposal.
>>>>>>>>> >
>>>>>>>>> >         On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
>>>>>>>>> >          > Dear all.
>>>>>>>>> >          >
>>>>>>>>> >          > I submitted my recommendation 3 weeks ago, and only
>>>>>>>>> Simon has
>>>>>>>>> >         commented
>>>>>>>>> >          > yet. Please let me know your thoughts.
>>>>>>>>> >          >
>>>>>>>>> >          > On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack
>>>>>>>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>>>>>>>> wrote:
>>>>>>>>> >          >> Dear all,
>>>>>>>>> >          >>
>>>>>>>>> >          >> Don't forget to opine here. To reiterate, I really
>>>>>>>>> don't
>>>>>>>>> >         expect the proposal to be controversial. The text of the
>>>>>>>>> >         proposal is rather long, but is made easy to read. So it
>>>>>>>>> >         shouldn't take too much of your time.
>>>>>>>>> >          >>
>>>>>>>>> >          >> /Arnaud
>>>>>>>>> >          >>
>>>>>>>>> >          >> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones
>>>>>>>>> >         <simon.peytonjones at gmail.com
>>>>>>>>> >         <mailto:simon.peytonjones at gmail.com>> wrote:
>>>>>>>>> >          >>> I support acceptance.
>>>>>>>>> >          >>>
>>>>>>>>> >          >>> Simon
>>>>>>>>> >          >>>
>>>>>>>>> >          >>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack
>>>>>>>>> >         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>
>>>>>>>>> wrote:
>>>>>>>>> >          >>>> Dear all,
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> [ Proposal #583
>>>>>>>>> >         https://github.com/ghc-proposals/ghc-proposals/pull/583
>>>>>>>>> >         <https://github.com/ghc-proposals/ghc-proposals/pull/583>
>>>>>>>>> ]
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> Our own Adam proposes to amend the design of the
>>>>>>>>> highly
>>>>>>>>> >         experimental OverloadedRecordUpdate extension as had been
>>>>>>>>> >         designed in proposal #158 [
>>>>>>>>> >
>>>>>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>>>>>>>>> <
>>>>>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst>
>>>>>>>>> ] and #405 [
>>>>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/405 <
>>>>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/405> ].
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> Specifically, Adam proposes a modification of the
>>>>>>>>> type
>>>>>>>>> >         classes that would back the extension.
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> In the previous design the HasField class is
>>>>>>>>> defined as a
>>>>>>>>> >         lens:
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>>>>>>>> >          >>>>   hasField :: r -> (a -> r, a)
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> The proposal is to replace it by two classes
>>>>>>>>> (slightly
>>>>>>>>> >         simplified)
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> class HasField (n :: k) r a | r n -> a
>>>>>>>>> >          >>>>   hasField :: r -> a
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> class SetField (n::k) r a | r n -> a
>>>>>>>>> >          >>>>   modifyField :: (a -> a) -> r -> a
>>>>>>>>> >          >>>>   setField :: a -> r -> a
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> This is originally motivated by some performance
>>>>>>>>> >         consideration: the prototype implementation of HasField
>>>>>>>>> as a
>>>>>>>>> >         lens can be very time consuming because instances of
>>>>>>>>> HasFields
>>>>>>>>> >         are generated eagerly at record definition sites,
>>>>>>>>> whereas the
>>>>>>>>> >         simple HasField instances can simply reuse the selectors
>>>>>>>>> already
>>>>>>>>> >         generated by GHC. But a lot of thoughts have been put
>>>>>>>>> into the
>>>>>>>>> >         new design, and my summary can certainly not do it
>>>>>>>>> justice: the
>>>>>>>>> >         proposal is very well argumented.
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> A point I'll make here is that the new design is
>>>>>>>>> actually
>>>>>>>>> >         parametric in the data representation of the field type.
>>>>>>>>> >         Something that wasn't possible in the original design.
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> This proposal is not technically backward
>>>>>>>>> compatible,
>>>>>>>>> >         because the order of argument in which
>>>>>>>>> OverloadedRecordUpdate
>>>>>>>>> >         expects the argument of setField is changed. This is not
>>>>>>>>> >         essential to the proposal, but this is a more consistent
>>>>>>>>> order
>>>>>>>>> >         argument with the rest of Haskell. And considering that
>>>>>>>>> >         OverloadedRecordUpdate is very loudly advertised as
>>>>>>>>> >         experimental, I recommend accepting this breakage.
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> Overall the proposal is actually more backward
>>>>>>>>> compatible
>>>>>>>>> >         with GHC 9.8 than the original design, as the HasField
>>>>>>>>> class is
>>>>>>>>> >         left unchanged.
>>>>>>>>> >          >>>>
>>>>>>>>> >          >>>> Overall, the proposal looks quite reasonable to
>>>>>>>>> me, and
>>>>>>>>> >         well-argued. I recommend acceptance.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Arnaud Spiwack
>>>>>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>>
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>
>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>


-- 
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/20231012/32705e99/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Oct 13 08:45:13 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 13 Oct 2023 10:45:13 +0200
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz9vkMbFwsbYj3A3eiD-XTJE3vx_TXHoSv323CQTmoWRQw@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>
 <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>
 <CAJKmMz9vkMbFwsbYj3A3eiD-XTJE3vx_TXHoSv323CQTmoWRQw@mail.gmail.com>
Message-ID: <CAGwnsnmcj7uSW-ETtzz-CY380aqBuWgnx8YzMYTwJ-VuF0jRLA@mail.gmail.com>

Dear all,

I've been chatting about this with colleagues, and I've come to understand
better why I feel rather dismayed at the turn the conversation is taking.
To be blunt, we seem to be developing a cure without having a diagnosis.
The mandate here is “make Haskell more stable” which is quite commendable,
but it's also very imprecise. I'd like us to have some concrete headline
issues to fix. How has the backward compatibility of Haskell been
compromised in the past, say, 2 years? In particular, how have our current
policies failed (then we'd need to fix them somehow), or where are our
policies blind?

Moritz: you said you were currently experiencing this at work (in fact, as
you probably know, I got some information on this indirectly), could you
share with us, say, the 3 most painful aspects of the migration you're
undertaking? So that they can be analysed? Avoid those related to base
changing because there's little that this committee can do about it (though
see follow-up email).

On Tue, 3 Oct 2023 at 12:08, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> 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
>>>>>>>>
>>>>>>> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


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

From simon.peytonjones at gmail.com  Fri Oct 13 09:15:50 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 13 Oct 2023 10:15:50 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAGwnsnmcj7uSW-ETtzz-CY380aqBuWgnx8YzMYTwJ-VuF0jRLA@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>
 <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>
 <CAJKmMz9vkMbFwsbYj3A3eiD-XTJE3vx_TXHoSv323CQTmoWRQw@mail.gmail.com>
 <CAGwnsnmcj7uSW-ETtzz-CY380aqBuWgnx8YzMYTwJ-VuF0jRLA@mail.gmail.com>
Message-ID: <CAJKmMz92oEwzHgd2zHqxrENNStpVLAW7M1vbgFTLt1W4sp+Liw@mail.gmail.com>

>
> The mandate here is “make Haskell more stable” which is quite commendable,
> but it's also very imprecise
>
Is it imprecise?  I think our goal is pretty simple:* a program that
compiles and runs with GHC 9.8 should also compile and run with GHC 9.10.*
That's it.   I think you subscribe to this as a general goal?

Clearly that is a problem today: many users report that they are using
years-old GHCs because the cost of upgrading to the latest version is so
high.

The General Rules I suggested at the start of this thread do no more than
articulate that goal, and give some general principles that we seek to
follow.  I think that does no more than make *explicit *our *implicit *way
of working (we spend a lot of time on back-compat discussions).  That is,
nothing really new here, just making it more explicit.

Can you be more specific about what you don't like?

Simon


On Fri, 13 Oct 2023 at 09:45, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> I've been chatting about this with colleagues, and I've come to understand
> better why I feel rather dismayed at the turn the conversation is taking.
> To be blunt, we seem to be developing a cure without having a diagnosis.
> The mandate here is “make Haskell more stable” which is quite commendable,
> but it's also very imprecise. I'd like us to have some concrete headline
> issues to fix. How has the backward compatibility of Haskell been
> compromised in the past, say, 2 years? In particular, how have our current
> policies failed (then we'd need to fix them somehow), or where are our
> policies blind?
>
> Moritz: you said you were currently experiencing this at work (in fact, as
> you probably know, I got some information on this indirectly), could you
> share with us, say, the 3 most painful aspects of the migration you're
> undertaking? So that they can be analysed? Avoid those related to base
> changing because there's little that this committee can do about it (though
> see follow-up email).
>
> On Tue, 3 Oct 2023 at 12:08, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> 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
>>>>>>>>>
>>>>>>>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
>
> --
> 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/b121cf2a/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Oct 13 09:25:04 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 13 Oct 2023 11:25:04 +0200
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAGwnsnmcj7uSW-ETtzz-CY380aqBuWgnx8YzMYTwJ-VuF0jRLA@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>
 <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>
 <CAJKmMz9vkMbFwsbYj3A3eiD-XTJE3vx_TXHoSv323CQTmoWRQw@mail.gmail.com>
 <CAGwnsnmcj7uSW-ETtzz-CY380aqBuWgnx8YzMYTwJ-VuF0jRLA@mail.gmail.com>
Message-ID: <CAGwnsnkAhSkWQkHFUJcmkRA3vqp-Fxsn=5HjGVhO70=gjLyaPw@mail.gmail.com>

As I was saying in my previous email (I'm making a second email to avoid
confusion between the serious process question and the more casual musing),
I'd noticed that a lot of the migration issues are due to the base library
changing. Maybe the CLC can have stronger stability policies but the truth
is: it's pretty hard. The details of Haskell makes so many things backward
incompatible:

- It's incompatible to add a new instance for a type (somewhat mitigated by
complaining about orphan instances, but orphan instances aren't always
avoidable)
- It's incompatible to add a member to a type class without a default
implementation
- It's incompatible to remove a member from a type class, even if the
member is replaced by a simple function of the same name (see e.g.
https://github.com/haskell/core-libraries-committee/issues/3 ) in
- It's incompatible to add a function to a module because it may conflict
with a function of the same name in another imported module (this isn't a
theoretical concern:
https://mail.haskell.org/pipermail/haskell-cafe/2023-October/136389.html )

There may be things that Haskell-the-language can do to help
Haskell-the-ecosystem cope with some of these problems. So there may still
be value in analysing the ways in which base or other libraries broke their
downstream, and see how we can act.

We can for instance consider the following issue of adding names: this
isn't specific to Haskell in any way, but maybe it happens more to Haskel
because we idiomatically import everything in the global namespace. This is
one of the reasons why I care a lot about the Local Module proposal, by the
way https://github.com/ghc-proposals/ghc-proposals/pull/283 .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231013/f322dc22/attachment.html>

From arnaud.spiwack at tweag.io  Fri Oct 13 09:38:23 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 13 Oct 2023 11:38:23 +0200
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz92oEwzHgd2zHqxrENNStpVLAW7M1vbgFTLt1W4sp+Liw@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>
 <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>
 <CAJKmMz9vkMbFwsbYj3A3eiD-XTJE3vx_TXHoSv323CQTmoWRQw@mail.gmail.com>
 <CAGwnsnmcj7uSW-ETtzz-CY380aqBuWgnx8YzMYTwJ-VuF0jRLA@mail.gmail.com>
 <CAJKmMz92oEwzHgd2zHqxrENNStpVLAW7M1vbgFTLt1W4sp+Liw@mail.gmail.com>
Message-ID: <CAGwnsnm3xVafQ9DNXiO0YGtHgwfvAv0EqYtT-2vbAaP2W4sWSA@mail.gmail.com>

On Fri, 13 Oct 2023 at 11:16, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> The mandate here is “make Haskell more stable” which is quite commendable,
>> but it's also very imprecise
>>
> Is it imprecise?  I think our goal is pretty simple:* a program that
> compiles and runs with GHC 9.8 should also compile and run with GHC 9.10.*
> That's it.   I think you subscribe to this as a general goal?
>

I fully subscribe to this goal.


> Clearly that is a problem today: many users report that they are using
> years-old GHCs because the cost of upgrading to the latest version is so
> high.
>

Indeed.

The General Rules I suggested at the start of this thread do no more than
> articulate that goal, and give some general principles that we seek to
> follow.  I think that does no more than make *explicit *our *implicit *way
> of working (we spend a lot of time on back-compat discussions).  That is,
> nothing really new here, just making it more explicit.
>
> Can you be more specific about what you don't like?
>

The general rules are perfectly reasonable. I'm much less enthusiastic
about an `experimental` flag of sorts.

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. So anyway, we've been having this policy, have we
failed to apply it? Why? Or maybe the reason why stability is a concern is
because of reasons that aren't caught by this policy, then what is missing?
I'm asking these questions in earnest: I really don't know. And I don't
think we'll actually make significant progress without getting answers to
these questions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231013/77372d94/attachment.html>

From simon.peytonjones at gmail.com  Fri Oct 13 09:52:45 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 13 Oct 2023 10:52:45 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAGwnsnm3xVafQ9DNXiO0YGtHgwfvAv0EqYtT-2vbAaP2W4sWSA@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>
 <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>
 <CAJKmMz9vkMbFwsbYj3A3eiD-XTJE3vx_TXHoSv323CQTmoWRQw@mail.gmail.com>
 <CAGwnsnmcj7uSW-ETtzz-CY380aqBuWgnx8YzMYTwJ-VuF0jRLA@mail.gmail.com>
 <CAJKmMz92oEwzHgd2zHqxrENNStpVLAW7M1vbgFTLt1W4sp+Liw@mail.gmail.com>
 <CAGwnsnm3xVafQ9DNXiO0YGtHgwfvAv0EqYtT-2vbAaP2W4sWSA@mail.gmail.com>
Message-ID: <CAJKmMz9Hu6gqfNmEXb_4xPWe__TJ31cLvi_XK++aer3+Xcv1dw@mail.gmail.com>

>
> 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.   The base-library splitting proposal (now agreed) is another piece
of incremental progress that does not solve the problem, but will help.

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 don't like to see you unhappy, Arnaud!

Simon

On Fri, 13 Oct 2023 at 10:38, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

>
>
> On Fri, 13 Oct 2023 at 11:16, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> The mandate here is “make Haskell more stable” which is quite
>>> commendable, but it's also very imprecise
>>>
>> Is it imprecise?  I think our goal is pretty simple:* a program that
>> compiles and runs with GHC 9.8 should also compile and run with GHC 9.10.*
>> That's it.   I think you subscribe to this as a general goal?
>>
>
> I fully subscribe to this goal.
>
>
>> Clearly that is a problem today: many users report that they are using
>> years-old GHCs because the cost of upgrading to the latest version is so
>> high.
>>
>
> Indeed.
>
> The General Rules I suggested at the start of this thread do no more than
>> articulate that goal, and give some general principles that we seek to
>> follow.  I think that does no more than make *explicit *our *implicit *way
>> of working (we spend a lot of time on back-compat discussions).  That is,
>> nothing really new here, just making it more explicit.
>>
>> Can you be more specific about what you don't like?
>>
>
> The general rules are perfectly reasonable. I'm much less enthusiastic
> about an `experimental` flag of sorts.
>
> 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. So anyway, we've been having this policy, have we
> failed to apply it? Why? Or maybe the reason why stability is a concern is
> because of reasons that aren't caught by this policy, then what is missing?
> I'm asking these questions in earnest: I really don't know. And I don't
> think we'll actually make significant progress without getting answers to
> these questions.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231013/5ea1a78d/attachment-0001.html>

From marlowsd at gmail.com  Fri Oct 13 11:23:19 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 13 Oct 2023 12:23:19 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAGwnsnm3xVafQ9DNXiO0YGtHgwfvAv0EqYtT-2vbAaP2W4sWSA@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>
 <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>
 <CAJKmMz9vkMbFwsbYj3A3eiD-XTJE3vx_TXHoSv323CQTmoWRQw@mail.gmail.com>
 <CAGwnsnmcj7uSW-ETtzz-CY380aqBuWgnx8YzMYTwJ-VuF0jRLA@mail.gmail.com>
 <CAJKmMz92oEwzHgd2zHqxrENNStpVLAW7M1vbgFTLt1W4sp+Liw@mail.gmail.com>
 <CAGwnsnm3xVafQ9DNXiO0YGtHgwfvAv0EqYtT-2vbAaP2W4sWSA@mail.gmail.com>
Message-ID: <CANsrgPLGnLfYwB3RR1-5aAm76eQkHVo8TJbXwGVnDH+1=stoVw@mail.gmail.com>

On Fri, 13 Oct 2023 at 10:39, Arnaud Spiwack <arnaud.spiwack at tweag.io>
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. So anyway, we've been having this policy, have we
> failed to apply it? Why? Or maybe the reason why stability is a concern is
> because of reasons that aren't caught by this policy, then what is missing?
> I'm asking these questions in earnest: I really don't know. And I don't
> think we'll actually make significant progress without getting answers to
> these questions.
>

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.

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.

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.

Cheers
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231013/4496c27e/attachment.html>

From arnaud.spiwack at tweag.io  Fri Oct 13 13:10:04 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 13 Oct 2023 15:10:04 +0200
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz9Hu6gqfNmEXb_4xPWe__TJ31cLvi_XK++aer3+Xcv1dw@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>
 <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>
 <CAJKmMz9vkMbFwsbYj3A3eiD-XTJE3vx_TXHoSv323CQTmoWRQw@mail.gmail.com>
 <CAGwnsnmcj7uSW-ETtzz-CY380aqBuWgnx8YzMYTwJ-VuF0jRLA@mail.gmail.com>
 <CAJKmMz92oEwzHgd2zHqxrENNStpVLAW7M1vbgFTLt1W4sp+Liw@mail.gmail.com>
 <CAGwnsnm3xVafQ9DNXiO0YGtHgwfvAv0EqYtT-2vbAaP2W4sWSA@mail.gmail.com>
 <CAJKmMz9Hu6gqfNmEXb_4xPWe__TJ31cLvi_XK++aer3+Xcv1dw@mail.gmail.com>
Message-ID: <CAGwnsnmZS28RuZRrZJLgbQtV9nE-Azne4_EJsR+xEnj3HHkDGw@mail.gmail.com>

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/a8633bbd/attachment.html>

From simon.peytonjones at gmail.com  Fri Oct 13 14:45:14 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 13 Oct 2023 15:45:14 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAGwnsnmZS28RuZRrZJLgbQtV9nE-Azne4_EJsR+xEnj3HHkDGw@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>
 <CAKfdd-yFkSVx=yH7buUn2UTZ3Z=COtz_tdHkEWzD0eCmw+ru5Q@mail.gmail.com>
 <CAJKmMz9vkMbFwsbYj3A3eiD-XTJE3vx_TXHoSv323CQTmoWRQw@mail.gmail.com>
 <CAGwnsnmcj7uSW-ETtzz-CY380aqBuWgnx8YzMYTwJ-VuF0jRLA@mail.gmail.com>
 <CAJKmMz92oEwzHgd2zHqxrENNStpVLAW7M1vbgFTLt1W4sp+Liw@mail.gmail.com>
 <CAGwnsnm3xVafQ9DNXiO0YGtHgwfvAv0EqYtT-2vbAaP2W4sWSA@mail.gmail.com>
 <CAJKmMz9Hu6gqfNmEXb_4xPWe__TJ31cLvi_XK++aer3+Xcv1dw@mail.gmail.com>
 <CAGwnsnmZS28RuZRrZJLgbQtV9nE-Azne4_EJsR+xEnj3HHkDGw@mail.gmail.com>
Message-ID: <CAJKmMz-BORG9zG6xgBGXq9_N-9EchzEdCa+xoyVoRMtPFMuRCw@mail.gmail.com>

>
> 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>

From vlad.z.4096 at gmail.com  Wed Oct 18 16:30:10 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Wed, 18 Oct 2023 18:30:10 +0200
Subject: [ghc-steering-committee] #536: Type-level literals as a separate
	language extension
Message-ID: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>

Dear Committee,

Back in March I initiated a discussion of #536 "Type-level literals as a
separate language extension" by Ross Paterson. Quick recap: currently
DataKinds controls promotion of ADTs and Symbol/Natural/Char literals. The
proposal is to factor out promotion of literals into their own extension,
TypeLevelLiterals.

I recommended acceptance but received mixed feedback. Summary of opinions:
Vlad: "rec: accept"
SPJ: "content to accept"
Joachim: "unsure how that fits with the overall direction we have for
namespaces"
Arnaud: "unconvinced that it is worth yet one extra extension"
Richard: "pretty strongly against"
Adam: "avoid bundling together distinct features" (i.e. accept)
Chris: "in favour"
Iavor (as ex-member): "strongly in favor"

Haven't yet expressed their opinion: Simon M. and Moritz.

So we have roughly 5 votes in-favor-or-don't-mind and 3 votes
against-or-unconvinced. SPJ suggested that we simply count the votes, but
after reading the discussion, I find that there's a deeper reason for
disagreement. Essentially, we have two camps:

1. "Let a thousand flowers bloom": Haskell should be customizable, built
out of small extensions à la carte. (A necessary implication here is that
this gives rise to dialects of Haskell that depend on the set of enabled
extensions)
2. "More extensions make me wince": Extensions are a necessary evil while
we explore the language design space, and we shouldn't create them
unnecessarily. (Language editions like GHC2021 help with that, allowing the
users to forget about individual extensions and simply use a better/newer
Haskell)

The 1st paradigm suggests that TypeLevelLiterals should be factored
out. TypeLevelLiterals+TypeData
form a dialect different from DataKinds with regards to name resolution,
which some users might prefer. Let them have it, why not?

The 2nd paradigm suggests that breaking DataKinds into smaller extensions
is counterproductive. Do we want fewer extensions or more extensions, after
all? And as a steering committee, don't we have a clear direction in which
we steer?

Unfortunately, we don't have a general policy that would clearly tell us
which camp/paradigm is right. And it's about time that we make a decision
regarding #536, even if we don't have a policy to guide us.

Because of that, my new plan is to reject the proposal out of caution. We
have at least one "strongly against", and it's enough to give me pause.
It's probably better to stick to the status quo, at least until we develop
a concrete stance w.r.t. fine-grained extensions. (Pardon a digression, but
this also calls into question whether 448 is justified in splitting
ScopedTypeVariables into ExtendedForAllScope, MethodTypeVariables,
PatternSignatures. Maybe we don't want fine-grained extensions after all)

The new recommendation is to reject the proposal, but I still can't make
this decision single-handedly. So let's do another round of discussion,
only this time let's stick to practicalities, not general considerations.
Is there anyone on the committee (or do we know someone) who needs
TypeLevelLiterals
for practical reasons, not just as a matter of taste? For example,
1. You are writing a book and you want to introduce TypeLevelLiterals
before DataKinds
2. You are developing or maintaining a library or application that needs
TypeLevelLiterals but cannot use DataKinds
3. You are working on an alternative Haskell implementation and intend to
support TypeLevelLiterals but not DataKinds

If any of the above (or similar) applies, speak up.

Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20231018/6631271a/attachment.html>

From mail at joachim-breitner.de  Wed Oct 18 17:31:37 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 18 Oct 2023 19:31:37 +0200
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension
In-Reply-To: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>
References: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>
Message-ID: <e0ce0a57ae356bf3ceefcc3ba4014833b629e184.camel@joachim-breitner.de>

Hi,

thanks for the well thought through message and helpful
conceptualisation. I agree that it would be good if the Committee as a
whole would commit to one or the other paradigm.

Am Mittwoch, dem 18.10.2023 um 18:30 +0200 schrieb Vladislav Zavialov:
> (Pardon a digression, but this also calls into question whether 448
> is justified in splitting ScopedTypeVariables
> into ExtendedForAllScope, MethodTypeVariables, PatternSignatures.
> Maybe we don't want fine-grained extensions after all)

my understanding with splitting ScopedTypeVariables is not to let a
thousands (or 2³ in this case) flowers bloom, but to slice it into the
parts we want to keep and the parts we (or some of us) want to change.
Maybe not absolutely necessary, as we could have -XTheNewWay with some
overlapping functionality with ScopedTypeVariables, such as annotating
patterns with their types, but maybe even if it only serves to help
communicating the changes it maybe worth it.

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From marlowsd at gmail.com  Thu Oct 19 07:06:53 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 19 Oct 2023 08:06:53 +0100
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension
In-Reply-To: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>
References: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>
Message-ID: <CANsrgPKPaL=J9UDuzJLZ89Jmqvk6hqEGmNqcU2GazdB44+m-tA@mail.gmail.com>

Thanks for the helpful summary Vlad! Admittedly I hadn't grasped the nub of
the issue until now.

Regarding:

Unfortunately, we don't have a general policy that would clearly tell us
> which camp/paradigm is right.
>

I think we actually do have a policy that's relevant here, see "Does not
create a language fork" in
https://github.com/ghc-proposals/ghc-proposals#review-criteria

This essentially says we are biased *against* the "customizable Haskell"
position and in favour of the
monotonically-increasing-set-of-language-features position.

Cheers
Simon

On Wed, 18 Oct 2023 at 17:30, Vladislav Zavialov <vlad.z.4096 at gmail.com>
wrote:

> Dear Committee,
>
> Back in March I initiated a discussion of #536 "Type-level literals as a
> separate language extension" by Ross Paterson. Quick recap: currently
> DataKinds controls promotion of ADTs and Symbol/Natural/Char literals. The
> proposal is to factor out promotion of literals into their own extension,
> TypeLevelLiterals.
>
> I recommended acceptance but received mixed feedback. Summary of opinions:
> Vlad: "rec: accept"
> SPJ: "content to accept"
> Joachim: "unsure how that fits with the overall direction we have for
> namespaces"
> Arnaud: "unconvinced that it is worth yet one extra extension"
> Richard: "pretty strongly against"
> Adam: "avoid bundling together distinct features" (i.e. accept)
> Chris: "in favour"
> Iavor (as ex-member): "strongly in favor"
>
> Haven't yet expressed their opinion: Simon M. and Moritz.
>
> So we have roughly 5 votes in-favor-or-don't-mind and 3 votes
> against-or-unconvinced. SPJ suggested that we simply count the votes, but
> after reading the discussion, I find that there's a deeper reason for
> disagreement. Essentially, we have two camps:
>
> 1. "Let a thousand flowers bloom": Haskell should be customizable, built
> out of small extensions à la carte. (A necessary implication here is that
> this gives rise to dialects of Haskell that depend on the set of enabled
> extensions)
> 2. "More extensions make me wince": Extensions are a necessary evil while
> we explore the language design space, and we shouldn't create them
> unnecessarily. (Language editions like GHC2021 help with that, allowing the
> users to forget about individual extensions and simply use a better/newer
> Haskell)
>
> The 1st paradigm suggests that TypeLevelLiterals should be factored out. TypeLevelLiterals+TypeData
> form a dialect different from DataKinds with regards to name resolution,
> which some users might prefer. Let them have it, why not?
>
> The 2nd paradigm suggests that breaking DataKinds into smaller extensions
> is counterproductive. Do we want fewer extensions or more extensions, after
> all? And as a steering committee, don't we have a clear direction in which
> we steer?
>
> Unfortunately, we don't have a general policy that would clearly tell us
> which camp/paradigm is right. And it's about time that we make a decision
> regarding #536, even if we don't have a policy to guide us.
>
> Because of that, my new plan is to reject the proposal out of caution. We
> have at least one "strongly against", and it's enough to give me pause.
> It's probably better to stick to the status quo, at least until we develop
> a concrete stance w.r.t. fine-grained extensions. (Pardon a digression, but
> this also calls into question whether 448 is justified in splitting
> ScopedTypeVariables into ExtendedForAllScope, MethodTypeVariables,
> PatternSignatures. Maybe we don't want fine-grained extensions after all)
>
> The new recommendation is to reject the proposal, but I still can't make
> this decision single-handedly. So let's do another round of discussion,
> only this time let's stick to practicalities, not general considerations.
> Is there anyone on the committee (or do we know someone) who needs TypeLevelLiterals
> for practical reasons, not just as a matter of taste? For example,
> 1. You are writing a book and you want to introduce TypeLevelLiterals
> before DataKinds
> 2. You are developing or maintaining a library or application that needs
> TypeLevelLiterals but cannot use DataKinds
> 3. You are working on an alternative Haskell implementation and intend to
> support TypeLevelLiterals but not DataKinds
>
> If any of the above (or similar) applies, speak up.
>
> Vlad
> _______________________________________________
> 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/20231019/2b3f4ca2/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Oct 19 07:25:56 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 19 Oct 2023 09:25:56 +0200
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension
In-Reply-To: <CANsrgPKPaL=J9UDuzJLZ89Jmqvk6hqEGmNqcU2GazdB44+m-tA@mail.gmail.com>
References: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>
 <CANsrgPKPaL=J9UDuzJLZ89Jmqvk6hqEGmNqcU2GazdB44+m-tA@mail.gmail.com>
Message-ID: <CAGwnsnmerii47caZit2FuoTVqk4jE3ZOGCrqSd-3ZDpsps6Yog@mail.gmail.com>

I don't think that the non-forking principle informs completely on the
debate at hand. Even if the extensions are monotonic increases on the
current language, even if an extension will either be merged into the next
GHC20xx or scrapped, the question of splitting an extension in two still
has validity. You may say: well, what if we adopt the type-level literals
without adopting data kinds?

I must, at any rate, apologise: it's my role to get to a resolution on the
question of extension policy. This is going slow, and I've paused the
process during the recent discussion on stability (I'm currently at
capacity for committee work). We definitely can't wait until the policy has
been well-defined before we can make a decision on the proposal at hand.

I said I was unconvinced the last time around. I haven't changed opinion,
but I'm happy to revise if presented with a sufficiently strong motivation.

On Thu, 19 Oct 2023 at 09:07, Simon Marlow <marlowsd at gmail.com> wrote:

> Thanks for the helpful summary Vlad! Admittedly I hadn't grasped the nub
> of the issue until now.
>
> Regarding:
>
> Unfortunately, we don't have a general policy that would clearly tell us
>> which camp/paradigm is right.
>>
>
> I think we actually do have a policy that's relevant here, see "Does not
> create a language fork" in
> https://github.com/ghc-proposals/ghc-proposals#review-criteria
>
> This essentially says we are biased *against* the "customizable Haskell"
> position and in favour of the
> monotonically-increasing-set-of-language-features position.
>
> Cheers
> Simon
>
> On Wed, 18 Oct 2023 at 17:30, Vladislav Zavialov <vlad.z.4096 at gmail.com>
> wrote:
>
>> Dear Committee,
>>
>> Back in March I initiated a discussion of #536 "Type-level literals as a
>> separate language extension" by Ross Paterson. Quick recap: currently
>> DataKinds controls promotion of ADTs and Symbol/Natural/Char literals. The
>> proposal is to factor out promotion of literals into their own extension,
>> TypeLevelLiterals.
>>
>> I recommended acceptance but received mixed feedback. Summary of opinions:
>> Vlad: "rec: accept"
>> SPJ: "content to accept"
>> Joachim: "unsure how that fits with the overall direction we have for
>> namespaces"
>> Arnaud: "unconvinced that it is worth yet one extra extension"
>> Richard: "pretty strongly against"
>> Adam: "avoid bundling together distinct features" (i.e. accept)
>> Chris: "in favour"
>> Iavor (as ex-member): "strongly in favor"
>>
>> Haven't yet expressed their opinion: Simon M. and Moritz.
>>
>> So we have roughly 5 votes in-favor-or-don't-mind and 3 votes
>> against-or-unconvinced. SPJ suggested that we simply count the votes, but
>> after reading the discussion, I find that there's a deeper reason for
>> disagreement. Essentially, we have two camps:
>>
>> 1. "Let a thousand flowers bloom": Haskell should be customizable, built
>> out of small extensions à la carte. (A necessary implication here is
>> that this gives rise to dialects of Haskell that depend on the set of
>> enabled extensions)
>> 2. "More extensions make me wince": Extensions are a necessary evil while
>> we explore the language design space, and we shouldn't create them
>> unnecessarily. (Language editions like GHC2021 help with that, allowing the
>> users to forget about individual extensions and simply use a better/newer
>> Haskell)
>>
>> The 1st paradigm suggests that TypeLevelLiterals should be factored out. TypeLevelLiterals+TypeData
>> form a dialect different from DataKinds with regards to name resolution,
>> which some users might prefer. Let them have it, why not?
>>
>> The 2nd paradigm suggests that breaking DataKinds into smaller extensions
>> is counterproductive. Do we want fewer extensions or more extensions, after
>> all? And as a steering committee, don't we have a clear direction in which
>> we steer?
>>
>> Unfortunately, we don't have a general policy that would clearly tell us
>> which camp/paradigm is right. And it's about time that we make a decision
>> regarding #536, even if we don't have a policy to guide us.
>>
>> Because of that, my new plan is to reject the proposal out of caution. We
>> have at least one "strongly against", and it's enough to give me pause.
>> It's probably better to stick to the status quo, at least until we develop
>> a concrete stance w.r.t. fine-grained extensions. (Pardon a digression, but
>> this also calls into question whether 448 is justified in splitting
>> ScopedTypeVariables into ExtendedForAllScope, MethodTypeVariables,
>> PatternSignatures. Maybe we don't want fine-grained extensions after all)
>>
>> The new recommendation is to reject the proposal, but I still can't make
>> this decision single-handedly. So let's do another round of discussion,
>> only this time let's stick to practicalities, not general considerations.
>> Is there anyone on the committee (or do we know someone) who needs TypeLevelLiterals
>> for practical reasons, not just as a matter of taste? For example,
>> 1. You are writing a book and you want to introduce TypeLevelLiterals
>> before DataKinds
>> 2. You are developing or maintaining a library or application that needs
>> TypeLevelLiterals but cannot use DataKinds
>> 3. You are working on an alternative Haskell implementation and intend to
>> support TypeLevelLiterals but not DataKinds
>>
>> If any of the above (or similar) applies, speak up.
>>
>> Vlad
>> _______________________________________________
>> 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
>


-- 
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/20231019/d326ddd3/attachment.html>

From simon.peytonjones at gmail.com  Thu Oct 19 17:32:19 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 19 Oct 2023 19:32:19 +0200
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension
In-Reply-To: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>
References: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>
Message-ID: <CAJKmMz9s-_HhM77cRWuPxzhhtsZPW_gwh0mKdUjxFH9E8MSPGg@mail.gmail.com>

I (now) lean to rejection, but not strongly so.  I have expressed my view
on the discussion
https://github.com/ghc-proposals/ghc-proposals/pull/536#issuecomment-1771422345

Simon

On Wed, 18 Oct 2023 at 18:30, Vladislav Zavialov <vlad.z.4096 at gmail.com>
wrote:

> Dear Committee,
>
> Back in March I initiated a discussion of #536 "Type-level literals as a
> separate language extension" by Ross Paterson. Quick recap: currently
> DataKinds controls promotion of ADTs and Symbol/Natural/Char literals. The
> proposal is to factor out promotion of literals into their own extension,
> TypeLevelLiterals.
>
> I recommended acceptance but received mixed feedback. Summary of opinions:
> Vlad: "rec: accept"
> SPJ: "content to accept"
> Joachim: "unsure how that fits with the overall direction we have for
> namespaces"
> Arnaud: "unconvinced that it is worth yet one extra extension"
> Richard: "pretty strongly against"
> Adam: "avoid bundling together distinct features" (i.e. accept)
> Chris: "in favour"
> Iavor (as ex-member): "strongly in favor"
>
> Haven't yet expressed their opinion: Simon M. and Moritz.
>
> So we have roughly 5 votes in-favor-or-don't-mind and 3 votes
> against-or-unconvinced. SPJ suggested that we simply count the votes, but
> after reading the discussion, I find that there's a deeper reason for
> disagreement. Essentially, we have two camps:
>
> 1. "Let a thousand flowers bloom": Haskell should be customizable, built
> out of small extensions à la carte. (A necessary implication here is that
> this gives rise to dialects of Haskell that depend on the set of enabled
> extensions)
> 2. "More extensions make me wince": Extensions are a necessary evil while
> we explore the language design space, and we shouldn't create them
> unnecessarily. (Language editions like GHC2021 help with that, allowing the
> users to forget about individual extensions and simply use a better/newer
> Haskell)
>
> The 1st paradigm suggests that TypeLevelLiterals should be factored out. TypeLevelLiterals+TypeData
> form a dialect different from DataKinds with regards to name resolution,
> which some users might prefer. Let them have it, why not?
>
> The 2nd paradigm suggests that breaking DataKinds into smaller extensions
> is counterproductive. Do we want fewer extensions or more extensions, after
> all? And as a steering committee, don't we have a clear direction in which
> we steer?
>
> Unfortunately, we don't have a general policy that would clearly tell us
> which camp/paradigm is right. And it's about time that we make a decision
> regarding #536, even if we don't have a policy to guide us.
>
> Because of that, my new plan is to reject the proposal out of caution. We
> have at least one "strongly against", and it's enough to give me pause.
> It's probably better to stick to the status quo, at least until we develop
> a concrete stance w.r.t. fine-grained extensions. (Pardon a digression, but
> this also calls into question whether 448 is justified in splitting
> ScopedTypeVariables into ExtendedForAllScope, MethodTypeVariables,
> PatternSignatures. Maybe we don't want fine-grained extensions after all)
>
> The new recommendation is to reject the proposal, but I still can't make
> this decision single-handedly. So let's do another round of discussion,
> only this time let's stick to practicalities, not general considerations.
> Is there anyone on the committee (or do we know someone) who needs TypeLevelLiterals
> for practical reasons, not just as a matter of taste? For example,
> 1. You are writing a book and you want to introduce TypeLevelLiterals
> before DataKinds
> 2. You are developing or maintaining a library or application that needs
> TypeLevelLiterals but cannot use DataKinds
> 3. You are working on an alternative Haskell implementation and intend to
> support TypeLevelLiterals but not DataKinds
>
> If any of the above (or similar) applies, speak up.
>
> Vlad
> _______________________________________________
> 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/20231019/3db20893/attachment.html>

From adam at well-typed.com  Fri Oct 20 11:16:27 2023
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 20 Oct 2023 12:16:27 +0100
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension
In-Reply-To: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>
References: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>
Message-ID: <735b270b-0407-4c78-8e60-8bbdc89f9059@well-typed.com>

I remain in favour of this proposal. I think minimizing the *number* of 
extensions is fundamentally the wrong approach; instead we should aim to 
minimize *complexity*, both of individual extensions and of the system 
as a whole.

It seems to me that this proposal makes DataKinds less complex, by 
decomposing it into simpler independent pieces. Indeed, as Simon 
mentions on the PR thread, we could reasonably give names to both these 
pieces so that DataKinds = TypeLevelLiterals + DataTypePromotion.

Cheers,

Adam


On 18/10/2023 17:30, Vladislav Zavialov wrote:
> Dear Committee,
> 
> Back in March I initiated a discussion of #536 "Type-level literals as a 
> separate language extension" by Ross Paterson. Quick recap: currently 
> DataKinds controls promotion of ADTs and Symbol/Natural/Char literals. 
> The proposal is to factor out promotion of literals into their own 
> extension, TypeLevelLiterals.
> 
> I recommended acceptance but received mixed feedback. Summary of opinions:
> Vlad: "rec: accept"
> SPJ: "content to accept"
> Joachim: "unsure how that fits with the overall direction we have for 
> namespaces"
> Arnaud: "unconvinced that it is worth yet one extra extension"
> Richard: "pretty strongly against"
> Adam: "avoid bundling together distinct features" (i.e. accept)
> Chris: "in favour"
> Iavor (as ex-member): "strongly in favor"
> 
> Haven't yet expressed their opinion: Simon M. and Moritz.
> 
> So we have roughly 5 votes in-favor-or-don't-mind and 3 votes 
> against-or-unconvinced. SPJ suggested that we simply count the votes, 
> but after reading the discussion, I find that there's a deeper reason 
> for disagreement. Essentially, we have two camps:
> 
> 1. "Let a thousand flowers bloom": Haskell should be customizable, built 
> out of small extensions à la carte. (A necessary implication here is 
> that this gives rise to dialects of Haskell that depend on the set of 
> enabled extensions)
> 2. "More extensions make me wince": Extensions are a necessary evil 
> while we explore the language design space, and we shouldn't create them 
> unnecessarily. (Language editions like GHC2021 help with that, allowing 
> the users to forget about individual extensions and simply use a 
> better/newer Haskell)
> 
> The 1st paradigm suggests that TypeLevelLiterals should be factored out. 
> TypeLevelLiterals+TypeData form a dialect different from DataKinds with 
> regards to name resolution, which some users might prefer. Let them have 
> it, why not?
> 
> The 2nd paradigm suggests that breaking DataKinds into smaller 
> extensions is counterproductive. Do we want fewer extensions or more 
> extensions, after all? And as a steering committee, don't we have a 
> clear direction in which we steer?
> 
> Unfortunately, we don't have a general policy that would clearly tell us 
> which camp/paradigm is right. And it's about time that we make a 
> decision regarding #536, even if we don't have a policy to guide us.
> 
> Because of that, my new plan is to reject the proposal out of caution. 
> We have at least one "strongly against", and it's enough to give me 
> pause. It's probably better to stick to the status quo, at least until 
> we develop a concrete stance w.r.t. fine-grained extensions. (Pardon a 
> digression, but this also calls into question whether 448 is justified 
> in splitting ScopedTypeVariables 
> into ExtendedForAllScope, MethodTypeVariables, PatternSignatures. Maybe 
> we don't want fine-grained extensions after all)
> 
> The new recommendation is to reject the proposal, but I still can't make 
> this decision single-handedly. So let's do another round of discussion, 
> only this time let's stick to practicalities, not general 
> considerations. Is there anyone on the committee (or do we know someone) 
> who needs TypeLevelLiterals for practical reasons, not just as a matter 
> of taste? For example,
> 1. You are writing a book and you want to introduce TypeLevelLiterals 
> before DataKinds
> 2. You are developing or maintaining a library or application that needs 
> TypeLevelLiterals but cannot use DataKinds
> 3. You are working on an alternative Haskell implementation and intend 
> to support TypeLevelLiterals but not DataKinds
> 
> If any of the above (or similar) applies, speak up.
> 
> Vlad
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- 
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


From simon.peytonjones at gmail.com  Fri Oct 20 11:45:08 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 20 Oct 2023 12:45:08 +0100
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension
In-Reply-To: <735b270b-0407-4c78-8e60-8bbdc89f9059@well-typed.com>
References: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>
 <735b270b-0407-4c78-8e60-8bbdc89f9059@well-typed.com>
Message-ID: <CAJKmMz-F=i+GEsoXkzrEuUxo+R0+nk6Knw7JuThjMCcvU0Tu+Q@mail.gmail.com>

>
> It seems to me that this proposal makes DataKinds less complex, by
> decomposing it into simpler independent pieces. Indeed, as Simon
> mentions on the PR thread, we could reasonably give names to both these
> pieces so that DataKinds = TypeLevelLiterals + DataTypePromotion
>

If we accept at all, I would strongly like to accept in this form.

Simon

On Fri, 20 Oct 2023 at 12:16, Adam Gundry <adam at well-typed.com> wrote:

> I remain in favour of this proposal. I think minimizing the *number* of
> extensions is fundamentally the wrong approach; instead we should aim to
> minimize *complexity*, both of individual extensions and of the system
> as a whole.
>
> It seems to me that this proposal makes DataKinds less complex, by
> decomposing it into simpler independent pieces. Indeed, as Simon
> mentions on the PR thread, we could reasonably give names to both these
> pieces so that DataKinds = TypeLevelLiterals + DataTypePromotion.
>
> Cheers,
>
> Adam
>
>
> On 18/10/2023 17:30, Vladislav Zavialov wrote:
> > Dear Committee,
> >
> > Back in March I initiated a discussion of #536 "Type-level literals as a
> > separate language extension" by Ross Paterson. Quick recap: currently
> > DataKinds controls promotion of ADTs and Symbol/Natural/Char literals.
> > The proposal is to factor out promotion of literals into their own
> > extension, TypeLevelLiterals.
> >
> > I recommended acceptance but received mixed feedback. Summary of
> opinions:
> > Vlad: "rec: accept"
> > SPJ: "content to accept"
> > Joachim: "unsure how that fits with the overall direction we have for
> > namespaces"
> > Arnaud: "unconvinced that it is worth yet one extra extension"
> > Richard: "pretty strongly against"
> > Adam: "avoid bundling together distinct features" (i.e. accept)
> > Chris: "in favour"
> > Iavor (as ex-member): "strongly in favor"
> >
> > Haven't yet expressed their opinion: Simon M. and Moritz.
> >
> > So we have roughly 5 votes in-favor-or-don't-mind and 3 votes
> > against-or-unconvinced. SPJ suggested that we simply count the votes,
> > but after reading the discussion, I find that there's a deeper reason
> > for disagreement. Essentially, we have two camps:
> >
> > 1. "Let a thousand flowers bloom": Haskell should be customizable, built
> > out of small extensions à la carte. (A necessary implication here is
> > that this gives rise to dialects of Haskell that depend on the set of
> > enabled extensions)
> > 2. "More extensions make me wince": Extensions are a necessary evil
> > while we explore the language design space, and we shouldn't create them
> > unnecessarily. (Language editions like GHC2021 help with that, allowing
> > the users to forget about individual extensions and simply use a
> > better/newer Haskell)
> >
> > The 1st paradigm suggests that TypeLevelLiterals should be factored out.
> > TypeLevelLiterals+TypeData form a dialect different from DataKinds with
> > regards to name resolution, which some users might prefer. Let them have
> > it, why not?
> >
> > The 2nd paradigm suggests that breaking DataKinds into smaller
> > extensions is counterproductive. Do we want fewer extensions or more
> > extensions, after all? And as a steering committee, don't we have a
> > clear direction in which we steer?
> >
> > Unfortunately, we don't have a general policy that would clearly tell us
> > which camp/paradigm is right. And it's about time that we make a
> > decision regarding #536, even if we don't have a policy to guide us.
> >
> > Because of that, my new plan is to reject the proposal out of caution.
> > We have at least one "strongly against", and it's enough to give me
> > pause. It's probably better to stick to the status quo, at least until
> > we develop a concrete stance w.r.t. fine-grained extensions. (Pardon a
> > digression, but this also calls into question whether 448 is justified
> > in splitting ScopedTypeVariables
> > into ExtendedForAllScope, MethodTypeVariables, PatternSignatures. Maybe
> > we don't want fine-grained extensions after all)
> >
> > The new recommendation is to reject the proposal, but I still can't make
> > this decision single-handedly. So let's do another round of discussion,
> > only this time let's stick to practicalities, not general
> > considerations. Is there anyone on the committee (or do we know someone)
> > who needs TypeLevelLiterals for practical reasons, not just as a matter
> > of taste? For example,
> > 1. You are writing a book and you want to introduce TypeLevelLiterals
> > before DataKinds
> > 2. You are developing or maintaining a library or application that needs
> > TypeLevelLiterals but cannot use DataKinds
> > 3. You are working on an alternative Haskell implementation and intend
> > to support TypeLevelLiterals but not DataKinds
> >
> > If any of the above (or similar) applies, speak up.
> >
> > Vlad
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> --
> 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/20231020/646e70e4/attachment-0001.html>

From marlowsd at gmail.com  Fri Oct 20 14:57:53 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 20 Oct 2023 15:57:53 +0100
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension
In-Reply-To: <CAGwnsnmerii47caZit2FuoTVqk4jE3ZOGCrqSd-3ZDpsps6Yog@mail.gmail.com>
References: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>
 <CANsrgPKPaL=J9UDuzJLZ89Jmqvk6hqEGmNqcU2GazdB44+m-tA@mail.gmail.com>
 <CAGwnsnmerii47caZit2FuoTVqk4jE3ZOGCrqSd-3ZDpsps6Yog@mail.gmail.com>
Message-ID: <CANsrgPLyFqVDLL_PtWo_vGV5xUj9kGodALSKUqsbGVUKHGLk-A@mail.gmail.com>

Arnaud: yes you're right, I was commenting more on the alternate
philosophies identified by Vlad rather than this particular proposal. As
far as this proposal goes, I agree it's not a fork, and I don't have a
strong opinion about it.

Cheers
Simon

On Thu, 19 Oct 2023 at 08:26, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> I don't think that the non-forking principle informs completely on the
> debate at hand. Even if the extensions are monotonic increases on the
> current language, even if an extension will either be merged into the next
> GHC20xx or scrapped, the question of splitting an extension in two still
> has validity. You may say: well, what if we adopt the type-level literals
> without adopting data kinds?
>
> I must, at any rate, apologise: it's my role to get to a resolution on the
> question of extension policy. This is going slow, and I've paused the
> process during the recent discussion on stability (I'm currently at
> capacity for committee work). We definitely can't wait until the policy has
> been well-defined before we can make a decision on the proposal at hand.
>
> I said I was unconvinced the last time around. I haven't changed opinion,
> but I'm happy to revise if presented with a sufficiently strong motivation.
>
> On Thu, 19 Oct 2023 at 09:07, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> Thanks for the helpful summary Vlad! Admittedly I hadn't grasped the nub
>> of the issue until now.
>>
>> Regarding:
>>
>> Unfortunately, we don't have a general policy that would clearly tell us
>>> which camp/paradigm is right.
>>>
>>
>> I think we actually do have a policy that's relevant here, see "Does not
>> create a language fork" in
>> https://github.com/ghc-proposals/ghc-proposals#review-criteria
>>
>> This essentially says we are biased *against* the "customizable Haskell"
>> position and in favour of the
>> monotonically-increasing-set-of-language-features position.
>>
>> Cheers
>> Simon
>>
>> On Wed, 18 Oct 2023 at 17:30, Vladislav Zavialov <vlad.z.4096 at gmail.com>
>> wrote:
>>
>>> Dear Committee,
>>>
>>> Back in March I initiated a discussion of #536 "Type-level literals as a
>>> separate language extension" by Ross Paterson. Quick recap: currently
>>> DataKinds controls promotion of ADTs and Symbol/Natural/Char literals. The
>>> proposal is to factor out promotion of literals into their own extension,
>>> TypeLevelLiterals.
>>>
>>> I recommended acceptance but received mixed feedback. Summary of
>>> opinions:
>>> Vlad: "rec: accept"
>>> SPJ: "content to accept"
>>> Joachim: "unsure how that fits with the overall direction we have for
>>> namespaces"
>>> Arnaud: "unconvinced that it is worth yet one extra extension"
>>> Richard: "pretty strongly against"
>>> Adam: "avoid bundling together distinct features" (i.e. accept)
>>> Chris: "in favour"
>>> Iavor (as ex-member): "strongly in favor"
>>>
>>> Haven't yet expressed their opinion: Simon M. and Moritz.
>>>
>>> So we have roughly 5 votes in-favor-or-don't-mind and 3 votes
>>> against-or-unconvinced. SPJ suggested that we simply count the votes, but
>>> after reading the discussion, I find that there's a deeper reason for
>>> disagreement. Essentially, we have two camps:
>>>
>>> 1. "Let a thousand flowers bloom": Haskell should be customizable,
>>> built out of small extensions à la carte. (A necessary implication here
>>> is that this gives rise to dialects of Haskell that depend on the set of
>>> enabled extensions)
>>> 2. "More extensions make me wince": Extensions are a necessary evil
>>> while we explore the language design space, and we shouldn't create them
>>> unnecessarily. (Language editions like GHC2021 help with that, allowing the
>>> users to forget about individual extensions and simply use a better/newer
>>> Haskell)
>>>
>>> The 1st paradigm suggests that TypeLevelLiterals should be factored
>>> out. TypeLevelLiterals+TypeData form a dialect different from DataKinds
>>> with regards to name resolution, which some users might prefer. Let them
>>> have it, why not?
>>>
>>> The 2nd paradigm suggests that breaking DataKinds into smaller
>>> extensions is counterproductive. Do we want fewer extensions or more
>>> extensions, after all? And as a steering committee, don't we have a clear
>>> direction in which we steer?
>>>
>>> Unfortunately, we don't have a general policy that would clearly tell us
>>> which camp/paradigm is right. And it's about time that we make a decision
>>> regarding #536, even if we don't have a policy to guide us.
>>>
>>> Because of that, my new plan is to reject the proposal out of caution.
>>> We have at least one "strongly against", and it's enough to give me pause.
>>> It's probably better to stick to the status quo, at least until we develop
>>> a concrete stance w.r.t. fine-grained extensions. (Pardon a digression, but
>>> this also calls into question whether 448 is justified in splitting
>>> ScopedTypeVariables into ExtendedForAllScope, MethodTypeVariables,
>>> PatternSignatures. Maybe we don't want fine-grained extensions after all)
>>>
>>> The new recommendation is to reject the proposal, but I still can't make
>>> this decision single-handedly. So let's do another round of discussion,
>>> only this time let's stick to practicalities, not general considerations.
>>> Is there anyone on the committee (or do we know someone) who needs TypeLevelLiterals
>>> for practical reasons, not just as a matter of taste? For example,
>>> 1. You are writing a book and you want to introduce TypeLevelLiterals
>>> before DataKinds
>>> 2. You are developing or maintaining a library or application that needs
>>> TypeLevelLiterals but cannot use DataKinds
>>> 3. You are working on an alternative Haskell implementation and intend
>>> to support TypeLevelLiterals but not DataKinds
>>>
>>> If any of the above (or similar) applies, speak up.
>>>
>>> Vlad
>>> _______________________________________________
>>> 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
>>
>
>
> --
> 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/20231020/c7cfd7cd/attachment.html>

From chris at chrisdornan.com  Fri Oct 20 15:55:44 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 20 Oct 2023 16:55:44 +0100
Subject: [ghc-steering-committee] #536: Type-level literals as a
 separate language extension
In-Reply-To: <735b270b-0407-4c78-8e60-8bbdc89f9059@well-typed.com>
References: <CAHZ0NLoJ2yr9tu+_ONe-Q_eTf3gUXFpbKmgAEhC97XiZvLcpaw@mail.gmail.com>
 <735b270b-0407-4c78-8e60-8bbdc89f9059@well-typed.com>
Message-ID: <276DE00D-D103-41D3-9638-24A0E57313AE@chrisdornan.com>

I agree -- inherent complexity is the issue and this proposal helps with that.

+1 from me.

Chris

> On 20 Oct 2023, at 12:16, Adam Gundry <adam at well-typed.com> wrote:
> 
> I remain in favour of this proposal. I think minimizing the *number* of extensions is fundamentally the wrong approach; instead we should aim to minimize *complexity*, both of individual extensions and of the system as a whole.
> 
> It seems to me that this proposal makes DataKinds less complex, by decomposing it into simpler independent pieces. Indeed, as Simon mentions on the PR thread, we could reasonably give names to both these pieces so that DataKinds = TypeLevelLiterals + DataTypePromotion.
> 
> Cheers,
> 
> Adam
> 
> 
> On 18/10/2023 17:30, Vladislav Zavialov wrote:
>> Dear Committee,
>> Back in March I initiated a discussion of #536 "Type-level literals as a separate language extension" by Ross Paterson. Quick recap: currently DataKinds controls promotion of ADTs and Symbol/Natural/Char literals. The proposal is to factor out promotion of literals into their own extension, TypeLevelLiterals.
>> I recommended acceptance but received mixed feedback. Summary of opinions:
>> Vlad: "rec: accept"
>> SPJ: "content to accept"
>> Joachim: "unsure how that fits with the overall direction we have for namespaces"
>> Arnaud: "unconvinced that it is worth yet one extra extension"
>> Richard: "pretty strongly against"
>> Adam: "avoid bundling together distinct features" (i.e. accept)
>> Chris: "in favour"
>> Iavor (as ex-member): "strongly in favor"
>> Haven't yet expressed their opinion: Simon M. and Moritz.
>> So we have roughly 5 votes in-favor-or-don't-mind and 3 votes against-or-unconvinced. SPJ suggested that we simply count the votes, but after reading the discussion, I find that there's a deeper reason for disagreement. Essentially, we have two camps:
>> 1. "Let a thousand flowers bloom": Haskell should be customizable, built out of small extensions à la carte. (A necessary implication here is that this gives rise to dialects of Haskell that depend on the set of enabled extensions)
>> 2. "More extensions make me wince": Extensions are a necessary evil while we explore the language design space, and we shouldn't create them unnecessarily. (Language editions like GHC2021 help with that, allowing the users to forget about individual extensions and simply use a better/newer Haskell)
>> The 1st paradigm suggests that TypeLevelLiterals should be factored out. TypeLevelLiterals+TypeData form a dialect different from DataKinds with regards to name resolution, which some users might prefer. Let them have it, why not?
>> The 2nd paradigm suggests that breaking DataKinds into smaller extensions is counterproductive. Do we want fewer extensions or more extensions, after all? And as a steering committee, don't we have a clear direction in which we steer?
>> Unfortunately, we don't have a general policy that would clearly tell us which camp/paradigm is right. And it's about time that we make a decision regarding #536, even if we don't have a policy to guide us.
>> Because of that, my new plan is to reject the proposal out of caution. We have at least one "strongly against", and it's enough to give me pause. It's probably better to stick to the status quo, at least until we develop a concrete stance w.r.t. fine-grained extensions. (Pardon a digression, but this also calls into question whether 448 is justified in splitting ScopedTypeVariables into ExtendedForAllScope, MethodTypeVariables, PatternSignatures. Maybe we don't want fine-grained extensions after all)
>> The new recommendation is to reject the proposal, but I still can't make this decision single-handedly. So let's do another round of discussion, only this time let's stick to practicalities, not general considerations. Is there anyone on the committee (or do we know someone) who needs TypeLevelLiterals for practical reasons, not just as a matter of taste? For example,
>> 1. You are writing a book and you want to introduce TypeLevelLiterals before DataKinds
>> 2. You are developing or maintaining a library or application that needs TypeLevelLiterals but cannot use DataKinds
>> 3. You are working on an alternative Haskell implementation and intend to support TypeLevelLiterals but not DataKinds
>> If any of the above (or similar) applies, speak up.
>> Vlad
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> -- 
> 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