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

[Moritz Angermann]

>
>

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