<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I don't love having a feature that's completely unmentioned in the manual -- too much of a root to trip over. (For example, tooling may run into -XOverloadedRecordUpdate, but now has no official place to look to see what it is.) I'd be fine with a short section in the manual describing that an experimental -XOverloadedRecordUpdate extension exists, is subject to change, and is meant to roughly implement some part of some proposal. This can be done in just a few sentences, with a link to the proposal, but just being silent seems unhelpful to users.<div class=""><br class=""></div><div class="">With that small tweak, I'm quite happy to agree with the proposal here.</div><div class=""><br class=""></div><div class="">In terms of actual official GHC Steering Committee business, this proposal is really just about changing the name of the extension from -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will simply fall short of the entire proposal. Is that accurate?</div><div class=""><br class=""></div><div class="">Richard</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 2, 2021, at 7:45 AM, Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Friends<o:p class=""></o:p></span></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Having consulted the authors, I propose that we do this:<o:p class=""></o:p></span></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><ul type="disc" style="margin-bottom: 0cm; margin-top: 0cm;" class=""><li class="MsoListParagraph" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">Proceed with OverloadedRecordDot for 9.2, exactly as in the original proposal except for the extension name.<o:p class=""></o:p></span></li><li class="MsoListParagraph" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">Record update will remain exactly as now, in 9.2; that is, drawing back from the original proposal.<o:p class=""></o:p></span></li><li class="MsoListParagraph" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">There may be some<span class="Apple-converted-space"> </span><i class="">code</i><span class="Apple-converted-space"> </span>in 9.2 that allows overloaded record update, protected by OverloadedRecordUpdate, but not in the user manual, and not treated as an accepted proposal. I don’t think we should ask the authors to remove it, and it will allow experimentation.<o:p class=""></o:p></span></li><li class="MsoListParagraph" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">Adam is leading on a revised record-update proposal. This will cover<o:p class=""></o:p></span></li><ul type="disc" style="margin-bottom: 0cm; margin-top: 0cm;" class=""><li class="MsoListParagraph" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">the tradeoffs between type-changing and non-type-changing update<o:p class=""></o:p></span></li><li class="MsoListParagraph" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">what the current record-update syntax stands for, and/or any new syntax<o:p class=""></o:p></span></li></ul></ul><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Is that acceptable to everyone?<o:p class=""></o:p></span></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Simon<o:p class=""></o:p></span></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="border-style: none none none solid; border-left-width: 1.5pt; border-left-color: blue; padding: 0cm 0cm 0cm 4pt;" class=""><div class=""><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(225, 225, 225); padding: 3pt 0cm 0cm;" class=""><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span lang="EN-US" class="">From:</span></b><span lang="EN-US" class=""><span class="Apple-converted-space"> </span>ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" class="">ghc-steering-committee-bounces@haskell.org</a>><span class="Apple-converted-space"> </span><b class="">On Behalf Of<span class="Apple-converted-space"> </span></b>Simon Peyton Jones via ghc-steering-committee<br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>01 March 2021 17:51<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" class="">iavor.diatchki@gmail.com</a>>; Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" class="">arnaud.spiwack@tweag.io</a>><br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a>><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [ghc-steering-committee] Modification to record dot syntax propsal<o:p class=""></o:p></span></div></div></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;">I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.<o:p class=""></o:p></p><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">I agree in principle that we can revisit decisions. But we have to be aware that it is potentially very discouraging for proposal authors to<o:p class=""></o:p></span></div><ul type="disc" style="margin-bottom: 0cm; margin-top: 0cm;" class=""><li class="MsoListParagraph" style="margin: 0cm 0cm 0cm 2.7pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">propose something,<o:p class=""></o:p></span></li><li class="MsoListParagraph" style="margin: 0cm 0cm 0cm 2.7pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">have it<span class="Apple-converted-space"> </span><i class="">extensively</i><span class="Apple-converted-space"> </span>debated (including this very point),<span class="Apple-converted-space"> </span><o:p class=""></o:p></span></li><li class="MsoListParagraph" style="margin: 0cm 0cm 0cm 2.7pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">have it accepted,<o:p class=""></o:p></span></li><li class="MsoListParagraph" style="margin: 0cm 0cm 0cm 2.7pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span class="">implement it,<o:p class=""></o:p></span></li></ul><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">and then be told that the committee has changed its mind. That’s pretty bad from their point of view.<o:p class=""></o:p></span></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">Still, Adam is working on a new SetField proposal, so perhaps that’s a figleaf. I’ll consult them.<o:p class=""></o:p></span></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><br class="">Simon<o:p class=""></o:p></span></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="border-style: none none none solid; border-left-width: 1.5pt; border-left-color: blue; padding: 0cm 0cm 0cm 4pt;" class=""><div class=""><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(225, 225, 225); padding: 3pt 0cm 0cm;" class=""><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span lang="EN-US" class="">From:</span></b><span lang="EN-US" class=""><span class="Apple-converted-space"> </span>Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" style="color: blue; text-decoration: underline;" class="">iavor.diatchki@gmail.com</a>><span class="Apple-converted-space"> </span><br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>01 March 2021 17:23<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" style="color: blue; text-decoration: underline;" class="">arnaud.spiwack@tweag.io</a>><br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" style="color: blue; text-decoration: underline;" class="">simonpj@microsoft.com</a>>; ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" style="color: blue; text-decoration: underline;" class="">ghc-steering-committee@haskell.org</a>><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [ghc-steering-committee] Modification to record dot syntax propsal<o:p class=""></o:p></span></div></div></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">Hello,<o:p class=""></o:p></p><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">I think there is a strong motivation to *at least* split the extensions: with the current design, enabling the special `.` notation also *disables* type changing record update, which has nothing to do with the `.` notation.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">My preference would be to:<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"> 1. Split the original proposal into two parts: one about `.` notation, the other about record update (as suggested by this proposal)<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"> 2. Treat the `.` notation part as accepted<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"> 3. Require changes on the record update part, so that you don't have to choose between it and type changing record updates, which are quite useful, and I don't think we should aim for a Haskell without them.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">-Iavor<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div></div><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p><div class=""><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" style="color: blue; text-decoration: underline;" class="">arnaud.spiwack@tweag.io</a>> wrote:<o:p class=""></o:p></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: 5pt 0cm 5pt 4.8pt;" class=""><div class=""><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">Simon, all,<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">After reading more of the PR thread (in particular the fews posts after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">The motivations provided by the modified<span class="Apple-converted-space"> </span><i class="">Alternatives</i><span class="Apple-converted-space"> </span>section is not much more helpful (at the risk of caricaturing a little, it basically reads: “we made two extensions rather than one because we can”). Though it makes it clear that the end goal is to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the extensions that we've decided we like).<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">My starting point is that:<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">- Additional extensions have a maintenance cost<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">- Additional extensions impose a cognitive burden on their use<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">- I expect that a new extension will break my code in the next few releases.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax` is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused on other points of the proposal).<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">I appreciate that I'm in the minority here. Yet, I'm still unconvinced.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">Best,<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">Arnaud<o:p class=""></o:p></p></div></div><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"><o:p class=""> </o:p></p><div class=""><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank" style="color: blue; text-decoration: underline;" class="">simonpj@microsoft.com</a>> wrote:<o:p class=""></o:p></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: 5pt 0cm 5pt 4.8pt;" class=""><div class=""><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;">Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.<o:p class=""></o:p></p><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Arnaud, happily, you don’t have to dig very deep – just read the handful of posts following my recommendation.<o:p class=""></o:p></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">There seem to be two motivations.<o:p class=""></o:p></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><ol start="1" type="1" style="margin-bottom: 0cm;" class=""><li class="MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">There really are two orthogonal extensions, one for r.x notation, and one for overloaded update. Iavor likes the first but not the second. Neil likes both. Having separate extensions lets us experiment.<o:p class=""></o:p></li></ol><p class=""> <o:p class=""></o:p></p><ol start="2" type="1" style="margin-bottom: 0cm;" class=""><li class="MsoNormal" style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;">You suggest that changing the definition of RecordDotSyntax in a subsequent release, e.g. by subsequently making it imply NoFieldSelectors, would be fine. But it certainly imposes pain – some programs would stop compiling. The approach offered by this proposal avoids that problem.<o:p class=""></o:p></li></ol><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Yes, there are lots of extensions surrounding records: NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields, RecordWildCards. It may not be pretty to divide things up so fine, but it’s not new.<o:p class=""></o:p></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">If there are alternative suggestions, let’s hear them.<o:p class=""></o:p></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Simon<o:p class=""></o:p></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><div style="border-style: none none none solid; border-left-width: 1.5pt; padding: 0cm 0cm 0cm 4pt; border-color: currentcolor currentcolor currentcolor blue;" class=""><div class=""><div style="border-style: solid none none; border-top-width: 1pt; padding: 3pt 0cm 0cm; border-color: currentcolor;" class=""><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span lang="EN-US" class="">From:</span></b><span lang="EN-US" class=""><span class="Apple-converted-space"> </span>ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank" style="color: blue; text-decoration: underline;" class="">ghc-steering-committee-bounces@haskell.org</a>><span class="Apple-converted-space"> </span><b class="">On Behalf Of<span class="Apple-converted-space"> </span></b>Spiwack, Arnaud<br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>26 February 2021 22:33<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank" style="color: blue; text-decoration: underline;" class="">iavor.diatchki@gmail.com</a>><br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" style="color: blue; text-decoration: underline;" class="">ghc-steering-committee@haskell.org</a>><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [ghc-steering-committee] Modification to record dot syntax propsal</span><o:p class=""></o:p></div></div></div><div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class=""> <o:p class=""></o:p></div><div class=""><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"> <o:p class=""></o:p></p></div><div class=""><blockquote style="border-style: none none none solid; border-left-width: 1pt; padding: 0cm 0cm 0cm 6pt; margin: 5pt 0cm 5pt 4.8pt; border-color: currentcolor currentcolor currentcolor rgb(204, 204, 204);" class=""><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">I do think that reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.<o:p class=""></o:p></p></div></blockquote><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this split strong enough? I haven't had time to dig into the details.<o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;"> <o:p class=""></o:p></p></div><div class=""><p class="MsoNormal" style="margin: 0cm 0cm 6pt; font-size: 11pt; font-family: Calibri, sans-serif;">I'm not sure that not having the design of the proposal quite finalised is a good reason, extensions mutate in their first iterations, I don't think that it's a problem.<o:p class=""></o:p></p></div></div></div></div></div></div></blockquote></div></blockquote></div></div></div></div><span style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">ghc-steering-committee mailing list</span><br style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a></span><br style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); 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; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class=""><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a></span></div></blockquote></div><br class=""></div></body></html>