<div dir="auto">I haven’t talked too much because I did not follow the original discussion in depth. However, a change of what record syntax can do seems undesirable to me, too; and I think just the “getter” part is an improvements over the current status quo. So I am happy with Simon’s wording of the situation.</div><div dir="auto"><br></div><div dir="auto">Alejandro</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El El vie, 5 mar 2021 a las 18:36, Richard Eisenberg <<a href="mailto:rae@richarde.dev">rae@richarde.dev</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">I have one disagreement with what Simon says below:<div><br></div><div><blockquote type="cite"><div><ol start="1" type="1" style="margin-bottom:0cm;margin-top:0cm"><li style="margin:6pt 0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">However, the loss of type-changing updates is a real concern, so the committee want to express doubt about the OverloadedRecordUpdate part, even though we previously accepted it. Sorry about that. It’s a change in our stance.</span></li></ol></div></blockquote><div><br></div><div>I don't see this result from this thread. Instead, I see that one member of the committee has expressed doubt about this. This is a valid concern and one that we could continue to discuss, but I don't feel comfortable stating that the "committee" expresses doubt. If there are others on the committee who share similar doubts and want to un-accept part of the original proposal, please speak up -- I may have misread the room. Otherwise, I don't think this point accurately represents the discussion we have had here.</div><div><br></div><div>I'm happy with the other points.</div><div><br></div><div>Thanks,</div><div>Richard</div><div><br><blockquote type="cite"><div>On Mar 5, 2021, at 12:19 PM, Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><p class="MsoNormal" style="margin:0cm 0cm 12pt 36pt;font-size:11pt;font-family:Calibri,sans-serif">So, why the hurry to add this to GHC now, when we know from experience how painful it is to remove things, once they are out in the wild?<u></u><u></u></p><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span>I thought had agreed the following:<u></u><u></u></span></div><ol start="1" type="1" style="margin-bottom:0cm;margin-top:0cm"><li style="margin:6pt 0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">We accept the proposal.<u></u><u></u></span></li></ol></div></div></blockquote></div></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><ol start="1" type="1" style="margin-bottom:0cm;margin-top:0cm"><li style="margin:6pt 0cm;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:11pt">It’s fine for the authors to continue with the implementation. If OverloadedRecordUpdate in GHC’s code base, it should be documented in the user manual. They should signal in that documentation that this part of the design may well change in the future, so it would be inadvisable to start using it for long-lived libraries.</span></li><li style="margin:6pt 0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">Arnaud wanted clarification in Alternatives, section 7.7. To avoid confusion about what “clarify” means,<span> </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1GbWAC8URaVRmj6Lkj1b10okNsVuUfO6U0qq-lrSpses%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C2f00be7cdc504b92fcc708d8df229562%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504686911684988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bWQMb8whuhbQamUYbMReDvrCEjhJtX1oG2tQZcCwE6k%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank">Arnaud and I drafted this</a>. They have already adopted this wording.<u></u><u></u></span></li><li style="margin:6pt 0cm;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">We’ll look forward to a new record-update proposal soon, which Adam is working on.<u></u><u></u></span></li></ol><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span>I think this is fine. We discussed the original proposal for months, and this modification draws back on that accepted proposal, and so should be even easier to agree.<u></u><u></u></span></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span>Please yell now (today) if you really think this is a mistake. I have checked with the authors and this is acceptable to them. I think if we say no, we want to back to the drawing board for the entire design they’ll just give up, and with some justification.<u></u><u></u></span></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span>OK?<u></u><u></u></span></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span>Simon<u></u><u></u></span></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div><div style="border-style:none none none solid;border-left-width:1.5pt;border-left-color:blue;padding:0cm 0cm 0cm 4pt"><div><div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0cm 0cm"><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><b><span lang="EN-US">From:</span></b><span lang="EN-US"><span> </span>ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>><span> </span><b>On Behalf Of<span> </span></b>Iavor Diatchki<br><b>Sent:</b><span> </span>05 March 2021 16:03<br><b>To:</b><span> </span>Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>>; ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br><b>Subject:</b><span> </span>Re: [ghc-steering-committee] Modification to record dot syntax propsal<u></u><u></u></span></div></div></div><div style="margin:0cm;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">I find that this committee is having less and less technical discussion on concrete issues, and there is a lot of talk of process, rules, and definitions, that I do not find useful.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">It is extremely difficult to anticipate all aspects of a design without implementing it and using it for a while, so I completely disagree that we should not revisit accepted proposals.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">While "experimental" extensions are totally fine in my book, I really do think we should avoid intentionally introducing things that we know now are likely to change. The overloaded records update is such an extension: it changes a useful, standardized, and in my experience, not uncommonly used feature, into a less general version (in one dimension, anyway). Furthermore, we are aware that there is already work by Adam to address this, so the extension will likely change (or perhaps we are going to have yet another record related extension).<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 12pt;font-size:11pt;font-family:Calibri,sans-serif">So, why the hurry to add this to GHC now, when we know from experience how painful it is to remove things, once they are out in the wild?<u></u><u></u></p><div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">On Fri, Mar 5, 2021, 02:50 Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" style="color:blue;text-decoration:underline" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<u></u><u></u></p></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">Iavor,<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">I concur with Simon and Eric. Accepting a proposal is a promise that the proposal will not be debated on the design front in the future. That is, when the implementation comes up it is out of scope to discuss design. That's the deal. GHC proposals are a process. The goal of this process is to foster participation of the wider community to the evolution of GHC, by reducing stress and uncertainty, and focusing productivity. This is why changing the design of an accepted proposal requires another proposal, submitted to the same level of scrutiny as the original proposal. Even, and in particular, by members of the steering committee.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">In this particular case, the authors have agreed to the change, and this is something that we feel is important enough to press forward quickly. So in the interest of everybody's time, I suggest that we move on. But, generally, the point stands.<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">/Arnaud<u></u><u></u></p></div></div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p><div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">On Thu, Mar 4, 2021 at 8:45 PM Eric Seidel <<a href="mailto:eric@seidel.io" style="color:blue;text-decoration:underline" target="_blank">eric@seidel.io</a>> wrote:<u></u><u></u></p></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><div><p class="MsoNormal" style="margin:0cm 0cm 12pt;font-size:11pt;font-family:Calibri,sans-serif">I agree it’s more important to get things right than to look good, but we should aim to do both of course. As Simon mentioned earlier, this will erode the community’s confidence if it happens too often. So I’m ok with reversing our decision on this point (happily it sounds like there’s already work underway on an improved design), but I think we should reflect on why we didn’t have this discussion back when we were discussing the original proposal. <u></u><u></u></p><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">Sent from my iPhone<u></u><u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><br><br><u></u><u></u></p><blockquote style="margin-top:5pt;margin-bottom:5pt"><p class="MsoNormal" style="margin:0cm 0cm 12pt;font-size:11pt;font-family:Calibri,sans-serif">On Mar 4, 2021, at 14:04, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" style="color:blue;text-decoration:underline" target="_blank">iavor.diatchki@gmail.com</a>> wrote:<u></u><u></u></p></blockquote></div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u><u></u></p><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">Bad look or not, it seems better to me to change our mind than accept something "to save face" :) It seems hard to imagine that I am the only one here who uses type changing updates in records. How are other members of the committee reconciling this change? Are you planning to change your code to use record wild cards as Neil suggested---this seems a lot worse than the status quo? Or is the plan the plan to just fork the language and use the pragma to disambiguate?<u></u><u></u></p><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">I don't mind if the extension is in GHC's code, but I think that if we add it to the GHC manual, people will use it, and it will be a much bigger deal to change later.<u></u><u></u></p></div></div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></p><div><div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">On Thu, Mar 4, 2021 at 9:59 AM Eric Seidel <<a href="mailto:eric@seidel.io" style="color:blue;text-decoration:underline" target="_blank">eric@seidel.io</a>> wrote:<u></u><u></u></p></div><blockquote style="border-style:none none none solid;border-left-width:1pt;border-left-color:rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">Yes that clears up the current situation. And from the current email chain it looks like the authors are aware of the plan to send record updates back for revision? I'd just want to make sure that the updated proposal reflects that split on which parts have been accepted.<br><br>For what it's worth, I do recall the loss of type-changing update being part of the original proposal and thought the proposal was still good on balance. The tradeoffs were definitely discussed in the giant Github thread, I don't recall if we discussed that aspect here though.. Regardless, I think it's a bad look for us to walk back a decision on account of not having read the proposal closely enough!<br><br>On Thu, Mar 4, 2021, at 09:53, Simon Peyton Jones wrote:<br>> | That being said, I don't see anything in the revised proposal about<br>> | the stability of OverloadedRecordUpdate. Are you saying that as part<br>> | of this revision, we'll explicitly accept OverloadedRecordDot and send<br>> | OverloadedRecordUpdate back for revision?<br>><span> </span><br>> We *already* accepted both, as part of accepting the earlier<span> </span><br>> RecordDotSyntax proposal. But in this round, Iavor has pushed back<span> </span><br>> against OverloadedRecordUpdate. No one else has expressed a view on<span> </span><br>> this point.<br>><span> </span><br>> But rather than debate it at length I proposed to explicitly un-accept<span> </span><br>> the OverloadedRecordUpdate part of the proposal. It'll return as part<span> </span><br>> of a new record-update proposal that Adam is working on.<br>><span> </span><br>> In the meantime OverloadedRecordUpdate will be in GHC's codebase, and<span> </span><br>> (assuming that's what the majority wants) documented in the user<span> </span><br>> manual, with a prominent "may change" caveat.<br>><span> </span><br>> Does that make it clear?<br>><span> </span><br>> Simon<span> </span><br>><span> </span><br>> | -----Original Message-----<br>> | From: ghc-steering-committee <ghc-steering-committee-<br>> | <span> </span><a href="mailto:bounces@haskell.org" style="color:blue;text-decoration:underline" target="_blank">bounces@haskell.org</a>> On Behalf Of Eric Seidel<br>> | Sent: 04 March 2021 14:38<br>> | To:<span> </span><a href="mailto:ghc-steering-committee@haskell.org" style="color:blue;text-decoration:underline" target="_blank">ghc-steering-committee@haskell.org</a><br>> | Subject: Re: [ghc-steering-committee] Modification to record dot<br>> | syntax propsal<br>> | <span> </span><br>> | I agree with Richard and Joachim that it should be documented in the<br>> | user guide. It's much better to document features with the expected<br>> | level of support than to let users stumble upon them and make their<br>> | own assumptions about stability.<br>> | <span> </span><br>> | That being said, I don't see anything in the revised proposal about<br>> | the stability of OverloadedRecordUpdate. Are you saying that as part<br>> | of this revision, we'll explicitly accept OverloadedRecordDot and send<br>> | OverloadedRecordUpdate back for revision?<br>> | <span> </span><br>> | On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-<br>> | committee wrote:<br>> | ><br>> | > Friends<br>> | ><br>> | ><br>> | ><br>> | > We've agree to accept my suggestion below.<br>> | ><br>> | ><br>> | ><br>> | > But there is one point at issue: should OverloadedRecordUpdate be<br>> | > documented in the user manual, albeit identified as a not-yet-<br>> | accepted<br>> | > feature?<br>> | ><br>> | ><br>> | ><br>> | > * Richard positively wants it in the manual<br>> | > * Iavor positively doesn't want it there.<br>> | ><br>> | ><br>> | > I don't mind either way.<br>> | ><br>> | ><br>> | ><br>> | > What do others think? It's not a big deal, but we owe the authors a<br>> | > decision. Answer by the end of the week please, and I'll make a<br>> | > shepherd decision based on the opinions I get.<br>> | ><br>> | ><br>> | ><br>> | > Simon<br>> | ><br>> | ><br>> | ><br>> | ><br>> | ><br>> | > *From:* Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">simonpj@microsoft.com</a>><br>> | > *Sent:* 02 March 2021 12:45<br>> | > *To:* ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" style="color:blue;text-decoration:underline" target="_blank">ghc-steering-committee@haskell.org</a>><br>> | > *Cc:* Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">simonpj@microsoft.com</a>><br>> | > *Subject:* RE: [ghc-steering-committee] Modification to record dot<br>> | > syntax propsal<br>> | ><br>> | ><br>> | ><br>> | > Friends<br>> | ><br>> | ><br>> | ><br>> | > Having consulted the authors, I propose that we do this:<br>> | ><br>> | ><br>> | ><br>> | > * Proceed with OverloadedRecordDot for 9.2, exactly as in the<br>> | > original proposal except for the extension name.<br>> | > * Record update will remain exactly as now, in 9.2; that is,<br>> | drawing<br>> | > back from the original proposal.<br>> | > * There may be some *code* in 9.2 that allows overloaded record<br>> | > update, protected by OverloadedRecordUpdate, but not in the user<br>> | > manual, and not treated as an accepted proposal. I don't think we<br>> | > should ask the authors to remove it, and it will allow<br>> | experimentation.<br>> | > * Adam is leading on a revised record-update proposal. This will<br>> | cover<br>> | > * the tradeoffs between type-changing and non-type-changing<br>> | update<br>> | > * what the current record-update syntax stands for, and/or any<br>> | new<br>> | > syntax<br>> | ><br>> | ><br>> | > Is that acceptable to everyone?<br>> | ><br>> | ><br>> | ><br>> | > Simon<br>> | ><br>> | ><br>> | ><br>> | > *From:* ghc-steering-committee<br>> | > <<a href="mailto:ghc-steering-committee-bounces@haskell.org" style="color:blue;text-decoration:underline" target="_blank">ghc-steering-committee-bounces@haskell.org</a>> *On Behalf Of *Simon<br>> | > Peyton Jones via ghc-steering-committee<br>> | > *Sent:* 01 March 2021 17:51<br>> | > *To:* Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" style="color:blue;text-decoration:underline" target="_blank">iavor.diatchki@gmail.com</a>>; Spiwack, Arnaud<br>> | > <<a href="mailto:arnaud.spiwack@tweag.io" style="color:blue;text-decoration:underline" target="_blank">arnaud.spiwack@tweag.io</a>><br>> | > *Cc:* ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" style="color:blue;text-decoration:underline" target="_blank">ghc-steering-committee@haskell.org</a>><br>> | > *Subject:* Re: [ghc-steering-committee] Modification to record dot<br>> | > syntax propsal<br>> | ><br>> | ><br>> | ><br>> | > I don't buy the argument of "this is already accepted", as I don't<br>> | > think many of us had noticed that part of the proposal (I certainly<br>> | > didn't), and I think we should be flexible enough to revisit<br>> | previous<br>> | > decisions when we notice problems with them.<br>> | ><br>> | > I agree in principle that we can revisit decisions. But we have to<br>> | be<br>> | > aware that it is potentially very discouraging for proposal authors<br>> | to<br>> | ><br>> | > * propose something,<br>> | > * have it *extensively* debated (including this very point),<br>> | > * have it accepted,<br>> | > * implement it,<br>> | > and then be told that the committee has changed its mind. That's<br>> | > pretty bad from their point of view.<br>> | ><br>> | ><br>> | ><br>> | > Still, Adam is working on a new SetField proposal, so perhaps that's<br>> | a<br>> | > figleaf. I'll consult them.<br>> | ><br>> | ><br>> | > Simon<br>> | ><br>> | ><br>> | ><br>> | ><br>> | ><br>> | > *From:* Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" style="color:blue;text-decoration:underline" target="_blank">iavor.diatchki@gmail.com</a>><br>> | > *Sent:* 01 March 2021 17:23<br>> | > *To:* Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" style="color:blue;text-decoration:underline" target="_blank">arnaud.spiwack@tweag.io</a>><br>> | > *Cc:* Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">simonpj@microsoft.com</a>>;<br>> | > ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" style="color:blue;text-decoration:underline" target="_blank">ghc-steering-committee@haskell.org</a>><br>> | > *Subject:* Re: [ghc-steering-committee] Modification to record dot<br>> | > syntax propsal<br>> | ><br>> | ><br>> | ><br>> | > Hello,<br>> | ><br>> | ><br>> | ><br>> | > I think there is a strong motivation to *at least* split the<br>> | > extensions: with the current design, enabling the special `.`<br>> | notation<br>> | > also *disables* type changing record update, which has nothing to do<br>> | > with the `.` notation.<br>> | ><br>> | ><br>> | ><br>> | > My preference would be to:<br>> | ><br>> | > 1. Split the original proposal into two parts: one about `.`<br>> | > notation, the other about record update (as suggested by this<br>> | proposal)<br>> | ><br>> | > 2. Treat the `.` notation part as accepted<br>> | ><br>> | > 3. Require changes on the record update part, so that you don't<br>> | have<br>> | > to choose between it and type changing record updates, which are<br>> | quite<br>> | > useful, and I don't think we should aim for a Haskell without them.<br>> | ><br>> | ><br>> | ><br>> | > I don't buy the argument of "this is already accepted", as I don't<br>> | > think many of us had noticed that part of the proposal (I certainly<br>> | > didn't), and I think we should be flexible enough to revisit<br>> | previous<br>> | > decisions when we notice problems with them.<br>> | ><br>> | ><br>> | ><br>> | > -Iavor<br>> | ><br>> | ><br>> | ><br>> | ><br>> | ><br>> | ><br>> | ><br>> | > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud<br>> | <<a href="mailto:arnaud.spiwack@tweag.io" style="color:blue;text-decoration:underline" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br>> | ><br>> | > > Simon, all,<br>> | ><br>> | > ><br>> | ><br>> | > > After reading more of the PR thread (in particular the fews posts<br>> | after Simon's recommendation), I have to admit: I am thoroughly<br>> | confused. I'm not sure that two people in that thread have the same<br>> | motivation, end goal, or design in mind.<br>> | ><br>> | > ><br>> | ><br>> | > > The motivations provided by the modified *Alternatives* section is<br>> | not much more helpful (at the risk of caricaturing a little, it<br>> | basically reads: "we made two extensions rather than one because we<br>> | can"). Though it makes it clear that the end goal is to fold a bunch<br>> | of record-related extensions into one glorious record extension (well,<br>> | probably not fold them, but make a meta-extension that implies all the<br>> | extensions that we've decided we like).<br>> | ><br>> | > ><br>> | ><br>> | > > My starting point is that:<br>> | ><br>> | > > - Additional extensions have a maintenance cost<br>> | ><br>> | > > - Additional extensions impose a cognitive burden on their use<br>> | ><br>> | > > - I expect that a new extension will break my code in the next few<br>> | releases.<br>> | ><br>> | > ><br>> | ><br>> | > > Based on this, I don't care how this extension or the glorious<br>> | record extension are named; but if we want to have two extensions we<br>> | should have a serious reason. Right now, the one reason that I see<br>> | (and Iavor raised), is that the update part of `RecordDotSyntax` is<br>> | not backward compatible. Is it a strong enough reason? I don't know.<br>> | The only data point that I can provide is that when we discussed the<br>> | original proposal, I brought it up several times, and it didn't seem<br>> | very important at the time (the conversation focused on other points<br>> | of the proposal).<br>> | ><br>> | > ><br>> | ><br>> | > > So, I'm still reluctant. I feel that, at the very least, the<br>> | motivations are not well-enough articulated in the proposal (I'll make<br>> | a comment to this effect on Github when I'm done composing this<br>> | email).<br>> | ><br>> | > ><br>> | ><br>> | > > I appreciate that I'm in the minority here. Yet, I'm still<br>> | unconvinced.<br>> | ><br>> | > ><br>> | ><br>> | > > Best,<br>> | ><br>> | > > Arnaud<br>> | ><br>> | > ><br>> | ><br>> | > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones<br>> | <<a href="mailto:simonpj@microsoft.com" style="color:blue;text-decoration:underline" target="_blank">simonpj@microsoft.com</a>> wrote:<br>> | ><br>> | > >> Generally, I'm not in favour in proposals which split extensions<br>> | though: we already have so many extensions. Are the reasons for this<br>> | split strong enough? I haven't had time to dig into the details.<br>> | ><br>> | > >> Arnaud, happily, you don't have to dig very deep - just read the<br>> | handful of posts following my recommendation.<br>> | ><br>> | > >><br>> | ><br>> | > >> There seem to be two motivations.<br>> | ><br>> | > >><br>> | ><br>> | > >> 1. There really are two orthogonal extensions, one for r.x<br>> | notation, and one for overloaded update. Iavor likes the first but<br>> | not the second. Neil likes both. Having separate extensions lets us<br>> | experiment.<br>> | > >><br>> | ><br>> | > >> 1. You suggest that changing the definition of RecordDotSyntax<br>> | in a subsequent release, e.g. by subsequently making it imply<br>> | NoFieldSelectors, would be fine. But it certainly imposes pain - some<br>> | programs would stop compiling. The approach offered by this proposal<br>> | avoids that problem.<br>> | > >><br>> | ><br>> | > >> Yes, there are lots of extensions surrounding records:<br>> | NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,<br>> | DisambiguateRecordFields, RecordWildCards. It may not be pretty to<br>> | divide things up so fine, but it's not new.<br>> | ><br>> | > >><br>> | ><br>> | > >><br>> | ><br>> | > >> If there are alternative suggestions, let's hear them.<br>> | ><br>> | > >><br>> | ><br>> | > >> Simon<br>> | ><br>> | > >><br>> | ><br>> | > >> *From:* ghc-steering-committee <ghc-steering-committee-<br>> | <span> </span><a href="mailto:bounces@haskell.org" style="color:blue;text-decoration:underline" target="_blank">bounces@haskell.org</a>> *On Behalf Of *Spiwack, Arnaud<br>> | > >> *Sent:* 26 February 2021 22:33<br>> | > >> *To:* Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" style="color:blue;text-decoration:underline" target="_blank">iavor.diatchki@gmail.com</a>><br>> | > >> *Cc:* ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" style="color:blue;text-decoration:underline" target="_blank">ghc-steering-committee@haskell.org</a>><br>> | > >> *Subject:* Re: [ghc-steering-committee] Modification to record<br>> | dot syntax propsal<br>> | ><br>> | > >><br>> | ><br>> | > >><br>> | ><br>> | > >>> I do think that reusing the record update syntax for the<br>> | overloaded monomorphic update is a mistake---it is not something I had<br>> | noticed during our original discussion.<br>> | ><br>> | > >><br>> | ><br>> | > >> This is the one reason I can see for cutting this extension in<br>> | smaller pieces. But, then again, -XOverloadedRecordUpdate would be a<br>> | fork-like extension.<br>> | ><br>> | > >><br>> | ><br>> | > >> Generally, I'm not in favour in proposals which split extensions<br>> | though: we already have so many extensions. Are the reasons for this<br>> | split strong enough? I haven't had time to dig into the details.<br>> | ><br>> | > >><br>> | ><br>> | > >> I'm not sure that not having the design of the proposal quite<br>> | finalised is a good reason, extensions mutate in their first<br>> | iterations, I don't think that it's a problem.<br>> | ><br>> | > _______________________________________________<br>> | > ghc-steering-committee mailing list<br>> | ><span> </span><a href="mailto:ghc-steering-committee@haskell.org" style="color:blue;text-decoration:underline" target="_blank">ghc-steering-committee@haskell.org</a><br>> | ><br>> | <span> </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail" style="color:blue;text-decoration:underline" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail</a><br>> | .<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335600745%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=s8rfn2SfP1OFefRGDsd%2FmqTI%2FLu3z7qMkFNhZBlZDbc%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank">haskell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-<br>> | committee&data=04%7C01%7Csimonpj%<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335610744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0iayJnlnpm5mchQpMmPgRY5bw2t%2FSrHkYmfnXamfgjQ%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank">40microsoft.com</a>%7C8abc00434aa94b7<br>> | fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046<br>> | 55938142566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz<br>> | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9DGVl6oJc0%2BIQekuXf<br>> | zwqviiaT%2FaHZIlIk3R5aMZssA%3D&reserved=0<br>> | ><br>> | _______________________________________________<br>> | ghc-steering-committee mailing list<br>> | <span> </span><a href="mailto:ghc-steering-committee@haskell.org" style="color:blue;text-decoration:underline" target="_blank">ghc-steering-committee@haskell.org</a><br>> | <span> </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail" style="color:blue;text-decoration:underline" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail</a><br>> | .<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335620741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ba9awmAYQ%2BPEtLYOlw2Mu8irB%2FGwmvv2OM30ofAMCmA%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank">haskell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-<br>> | committee&data=04%7C01%7Csimonpj%<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335620741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BikTVk4HLF4Gey%2BgOoWnbhGKbYhUADxIfZNAzEBtFp8%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank">40microsoft.com</a>%7C8abc00434aa94b7<br>> | fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046<br>> | 55938152562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz<br>> | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QZlV0RrRttaiDdrQNiRB<br>> | vUhS6il1DydPX5cyl%2BdILbI%3D&reserved=0<br>><br>_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" style="color:blue;text-decoration:underline" target="_blank">ghc-steering-committee@haskell.org</a><br><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><u></u><u></u></p></blockquote></div></div></blockquote></div><p class="MsoNormal" style="margin:0cm 0cm 6pt;font-size:11pt;font-family:Calibri,sans-serif">_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" style="color:blue;text-decoration:underline" target="_blank">ghc-steering-committee@haskell.org</a><br><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ce0e7e14d1ba74d216e9e08d8dff055dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637505571335630737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6A2TJygA2WZ29GqX4kBSJmZi5kX2O2Tmawv4SvpNZuk%3D&reserved=0" style="color:blue;text-decoration:underline" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><u></u><u></u></p></blockquote></div></blockquote></div></div></div></div></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">ghc-steering-committee mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important"><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a></span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important"><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a></span></div></blockquote></div><br></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>