<div dir="ltr"><div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 “<b>EXPERIMENTAL</b>
<i>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.</i>”.</div><div><br></div><div>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<br></div><div>- Let's have the breakage without a transition period</div><div>- Let's not make the breaking change ever and use the earlier argument order for set</div><div><br></div><div>Which one do you argue for, or am I missing another option?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 24 Sept 2023 at 15:36, Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I am in favor of this proposal.<br>
<br>
On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:<br>
> Dear all.<br>
><br>
> I submitted my recommendation 3 weeks ago, and only Simon has commented <br>
> yet. Please let me know your thoughts.<br>
><br>
> On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br>
>> Dear all,<br>
>> <br>
>> 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.<br>
>> <br>
>> /Arnaud<br>
>> <br>
>> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br>
>>> I support acceptance.<br>
>>> <br>
>>> Simon<br>
>>> <br>
>>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br>
>>>> Dear all,<br>
>>>> <br>
>>>> [ Proposal #583 <a href="https://github.com/ghc-proposals/ghc-proposals/pull/583" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/583</a> ]<br>
>>>> <br>
>>>> Our own Adam proposes to amend the design of the highly experimental OverloadedRecordUpdate extension as had been designed in proposal #158 [ <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst</a> ] and #405 [ <a href="https://github.com/ghc-proposals/ghc-proposals/pull/405" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/405</a> ].<br>
>>>> <br>
>>>> Specifically, Adam proposes a modification of the type classes that would back the extension.<br>
>>>> <br>
>>>> In the previous design the HasField class is defined as a lens:<br>
>>>> <br>
>>>> class HasField (n :: k) r a | r n -> a<br>
>>>>   hasField :: r -> (a -> r, a)<br>
>>>> <br>
>>>> The proposal is to replace it by two classes (slightly simplified)<br>
>>>> <br>
>>>> class HasField (n :: k) r a | r n -> a<br>
>>>>   hasField :: r -> a<br>
>>>> <br>
>>>> class SetField (n::k) r a | r n -> a<br>
>>>>   modifyField :: (a -> a) -> r -> a<br>
>>>>   setField :: a -> r -> a<br>
>>>> <br>
>>>> 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.<br>
>>>> <br>
>>>> 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.<br>
>>>> <br>
>>>> 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.<br>
>>>> <br>
>>>> Overall the proposal is actually more backward compatible with GHC 9.8 than the original design, as the HasField class is left unchanged.<br>
>>>> <br>
>>>> Overall, the proposal looks quite reasonable to me, and well-argued. I recommend acceptance.<br>
>>>> <br>
>>>> -- <br>
>>>> Arnaud Spiwack<br>
>>>> Director, Research at <a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
>>>> _______________________________________________<br>
>>>> ghc-steering-committee mailing list<br>
>>>> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>>>> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
>> <br>
>> <br>
>> -- <br>
>> Arnaud Spiwack<br>
>> Director, Research at <a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
><br>
><br>
> -- <br>
> Arnaud Spiwack<br>
> Director, Research at <a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div></div>