<div dir="ltr">In light of the recent discussion, I take that back. It turns out that type inference is not the only problem with type-changing updates. There's also an issue with multi-field type-changing updates, and it's more severe (I don't see a clear way forward).<div><br></div><div>So now I'm now (weakly) in favor of the proposal as it is. SetField can't handle type-changing updates -- so be it. We need a bigger hammer to deal with type-changing updates.</div><div><br></div><div>Vlad</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 21, 2023 at 11:12 AM Vladislav Zavialov <<a href="mailto:vlad.z.4096@gmail.com">vlad.z.4096@gmail.com</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"><div dir="ltr"><div>I'm against the proposal in its current form because it does not support type-changing update and is not forward-compatible with it. Fortunately, it is not hard to fix this, as Adam points out in a GitHub comment:</div><div><br></div><div>> I suppose one thing we could do now would be to add the parameters for type-changing update already, but restrict the constraint solver behaviour, e.g. define the classes SetField x s t a b and type SetField' x r a = SetField x r r a a, but have the constraint solver always unify s ~ t and a ~ b when solving constraints. That would limit (but not necessarily eliminate) the breakage when generalising the constraint solver.</div><div><br></div><div>Let's do it this way to avoid a breaking change in the future!</div><div><br></div><div>Vlad</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 21, 2023 at 10:35 AM Chris Dornan <<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</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"><div dir="auto">+1 from me</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 Sep 2023 at 08:37, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.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"><div dir="ltr"><div>Dear all.</div><div><br></div><div>I submitted my recommendation 3 weeks ago, and only Simon has commented yet. Please let me know your thoughts.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Dear all,</div><div><br></div><div>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.</div><div><br></div><div>/Arnaud<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:tahoma,sans-serif">I support acceptance.</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Dear all,</div><div><br></div><div>[ Proposal #583 <a href="https://github.com/ghc-proposals/ghc-proposals/pull/583" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/583</a> ]<br></div><div><br></div><div>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" 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" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/405</a> ].</div><div><br></div><div>Specifically, Adam proposes a modification of the type classes that would back the extension.</div><div><br></div><div>In the previous design the HasField class is defined as a lens:</div><div><br></div><div>class HasField (n :: k) r a | r n -> a<br></div><div> hasField :: r -> (a -> r, a)<br></div><div><br></div><div>The proposal is to replace it by two classes (slightly simplified)<br></div><div><br></div><div><div>class HasField (n :: k) r a | r n -> a<br></div><div> hasField :: r -> a</div><div><br></div><div>class SetField (n::k) r a | r n -> a</div><div> modifyField :: (a -> a) -> r -> a</div><div> setField :: a -> r -> a</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Overall the proposal is actually more backward compatible with GHC 9.8 than the original design, as the HasField class is left unchanged.</div><div><br></div><div>Overall, the proposal looks quite reasonable to me, and well-argued. I recommend acceptance.<br></div></div><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>
_______________________________________________<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>
</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>
</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>
_______________________________________________<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></div>
_______________________________________________<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></div>
</blockquote></div>