[ghc-steering-committee] #583: HasField redesign, rec: accept

Fri Sep 22 08:59:30 UTC 2023

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

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.

Best,
 Moritz

On Fri, 22 Sept 2023 at 16:33, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> The General Rules outlined in
>> https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305
>> can be a good first step.
>
>
> I think that articulating some General Rules like this would help us a lot.
>
> If we had #601 <https://github.com/ghc-proposals/ghc-proposals/pull/601>in
> some form (it is back with the author for review), we would have a list of
> extensions designated "stable", which we might treat differently to
> extensions designated "experimental".  That would help too.
>
> I realise that (GR1) is stronger than I intended: I think we need to allow
> room to modify extensions designated "experimental" -- that's what
> "experimental" means!
>
>    - General rule (GR1): a GHC proposal should ensure that code that
>    invokes only extensions designated "stable", and that compiles before the
>    change, will continue compile after the change, given the same compiler
>    flags
>       - We exclude -Werror because otherwise (GR1) would be broken
>       whenever we add a warning.
>       - We exclude experimental extensions because those are (by
>       definition) subject to change.
>       - (GR1) is trivially satisfied if the change is gated behind an
>       extension flag.
>       - (GR1) is broken if, say, we turn a warning into an error
>
> Is that acceptable?
>
> 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`.
>
> Moritz quotes Simon M saying
>
> when considering the cost/benefit tradeoff adding a migration cycle
>> doesn't reduce the cost, it just defers it.
>
>
> I understood that as saying "don't bother with a deprecation cycle".  But
> I understand Moritz as saying "please give us a deprecation cycle".  I
> don't have a strong view myself but it would be good to achieve consensus
> on this point.  I *think *(but I am not sure) that the consensus is:
>
>    - 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.
>
> Simon
>
> On Fri, 22 Sept 2023 at 09:13, Moritz Angermann <
> moritz.angermann at gmail.com> wrote:
>
>>
>>
>>> As there is supposedly a backwards compatible implementation for this,
>>>> I’d like to ask for this to be considered in two steps:
>>>> - backwards compatible change first.
>>>> - deprecation and change of syntax second.
>>>>
>>>
>>> If that's possible, it sounds plausible.  Perhaps you can make the
>>> suggestion on the main discussion thread, and Adam can respond?
>>>
>>
>> The proposal already contains this suggestion if my reading is correct.
>> The breaking change is the reordering of parameters of setField. And lists
>> under the section “Order of arguments to setField”, that this proposal can
>> work without the reordering.
>>
>> I am feeling quit uneasy arguing for this, as this option only came up
>> due to the proposal being written so thoroughly. The proposal also
>> explicitly notes that OverloadedRecordUpdate has been marked as
>> experimental. In the “Backward Compatibility” section.
>>
>> While I still disagree that there can be any experimental features in a
>> stable release, I can see myself supporting this proposal if we
>> collectively work towards preventing this going forward. The General Rules
>> outlined in
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305
>> can be a good first step.
>>
>> I’d still like to hear Simon Marlow’s thoughts on this after his plea for
>> a culture shift recently
>>
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html
>>
>> Best,
>>   Moritz
>>
>> On Fri, 22 Sept 2023 at 02:07, Moritz Angermann <
>>> moritz.angermann at gmail.com> wrote:
>>>
>>>> I’m tempted to recuse myself as well on the technical merits of this
>>>> proposal. As others might already expect, I am concerned about this
>>>> breaking existing code. Do we have a rough estimate how much this will
>>>> break?
>>>>
>>>> It also surfaces a topic we discussed just a short while ago. We have a
>>>> feature in a stable compiler release, which we consider experimental, and
>>>> thus reserve the right to break? I find this concept still fundamentally
>>>> flawed. Anything that is part of stable compiler releases has to be
>>>> considered stable by extension and thus needs to be treated with utmost
>>>> care.
>>>>
>>>> I can see and fully support the wish to have a language reactor where
>>>> things can be experimented with. But if we have this in our stable
>>>> releases, it needs to be guarded in a way that users of those features have
>>>> to actively opt in to it. I have people seen adopting this feature already,
>>>> and I do not believe all of them are aware that this is a bleeding edge
>>>> feature that can break without notice at any point in time.
>>>>
>>>> As there is supposedly a backwards compatible implementation for this,
>>>> I’d like to ask for this to be considered in two steps:
>>>> - backwards compatible change first.
>>>> - deprecation and change of syntax second.
>>>>
>>>> Yes, this will be more work on behalf of the implementors. The burden
>>>> of change is on the implementors, we can’t expect our users to cover the
>>>> costs.
>>>>
>>>> For the second part, we should also have a thorough justification for
>>>> the need to break.
>>>>
>>>> I’ll leave this with two links:
>>>> Simon Marlow’s recent comment:
>>>>
>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html
>>>> Dimitriis Tweet contrasting OCaml to Haskell:
>>>> https://x.com/chshersh/status/1704886633856696831?s=46
>>>>
>>>> Best
>>>>  Moritz
>>>>
>>>> On Fri, 22 Sep 2023 at 1:21 AM, Joachim Breitner <
>>>> mail at joachim-breitner.de> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Am Donnerstag, dem 21.09.2023 um 09:37 +0200 schrieb Arnaud Spiwack:
>>>>> > Dear all.
>>>>> >
>>>>> > I submitted my recommendation 3 weeks ago, and only Simon has
>>>>> > commented yet. Please let me know your thoughts.
>>>>>
>>>>> I am essentially ignorant about anything related to records in Haskell,
>>>>> and will recuse myself, trusting y’all about this.
>>>>>
>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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/20230922/0d7b1998/attachment-0001.html>