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

[Simon Peyton Jones]

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