<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
.MsoPapDefault
{mso-style-type:export-only;
margin-top:6.0pt;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:36.0pt">
Just wanted to chime in, that if we are to accept this, I also think that we should use the explicit section notation for selector functions.<o:p></o:p></p>
<p class="MsoNormal">To be clear, you prefer that (.foo) is the selector function, and .foo (sans parens) is illegal? Or do you have something else in mind for .foo?<o:p></o:p></p>
<p class="MsoNormal"><br>
Simon<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-steering-committee <ghc-steering-committee-bounces@haskell.org>
<b>On Behalf Of </b>Iavor Diatchki<br>
<b>Sent:</b> 10 December 2019 18:08<br>
<b>To:</b> Joachim Breitner <mail@joachim-breitner.de><br>
<b>Cc:</b> ghc-steering-committee <ghc-steering-committee@haskell.org><br>
<b>Subject:</b> Re: [ghc-steering-committee] RecordDotSyntax: please express a view<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Just wanted to chime in, that if we are to accept this, I also think that we should use the explicit section notation for selector functions.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
I don't think we should split this into multiple proposals, even though it introduces many features.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
In fact, for me, the most useful part of the proposal is the ability to do nested updates, which is quite orthogonal to using "dot" as a selector.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Tue, Dec 10, 2019 at 8:25 AM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
Hi,<br>
<br>
also, thinking about it, is (\x->x.foo) too bad? At least initially?<br>
<br>
Maybe people come up with a nice name for (\x->x.…) (similar to “happy<br>
monkey” for (:[]) ) then maybe they will warm up to it :-)<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
Am Dienstag, den 10.12.2019, 11:14 -0500 schrieb Eric Seidel:<br>
> I agree with Richard, I think it would be valuable to think of this<br>
> as two separate proposals. <br>
> <br>
> 1. Introduce the dot syntax for projection and nested<br>
> matching/update. Projection is written ‘foo.lbl’ (no white space<br>
> allowed) and a bare .lbl is a syntax error. This piece seems largely<br>
> uncontroversial. <br>
> <br>
> 2. Give a meaning to a bare ‘.lbl’. The controversy entirely<br>
> surrounds what this form should mean. <br>
> <br>
> I think (1) is a perfectly good proposal on its own, so I’d much<br>
> prefer us to accept (1) and defer a decision on (2) over rejecting<br>
> the entire proposal. <br>
> <br>
> Sent from my iPhone<br>
> <br>
> > On Dec 10, 2019, at 10:26, Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>> wrote:<br>
> > <br>
> > Thanks for your comments!<br>
> > <br>
> > > On Dec 10, 2019, at 2:54 PM, Christopher Allen <<a href="mailto:cma@bitemyapp.com" target="_blank">cma@bitemyapp.com</a>> wrote:<br>
> > > <br>
> > > This proposal should be rejected.<br>
> > > <br>
> > > The contention over what whitespace around the dot operator should<br>
> > > make it clear that even expert Haskellers aren't sure what to expect<br>
> > > from this proposal in an intuitive way.<br>
> > <br>
> > Then there is an easy solution: just don't allow unparenthesized .foo -- that is, make it a parse error. I don't think there is any contention over what (.foo) should mean, and if plain .foo is a parse error, then there is no fork.<br>
> > <br>
> > > You can achieve the same with<br>
> > > libraries now.<br>
> > <br>
> > True -- but at significant cost, both in the effort to learn the (complex) libraries and in the need for Template Haskell, which cannot be used in cross-compilation, for example. I think the warm reception of this proposal suggests that, despite the library-based
solution, something more is wanted.<br>
> > <br>
> > > That the existing extensions aren't as useful as they<br>
> > > ought as compared with using a lens library is symptomatic of<br>
> > > half-baked proposals being incorporated into GHC.<br>
> > <br>
> > I'm curious which proposals you're thinking of here. The strangest one, I think, is DisambiguateRecordFields. That was added before the proposals process. I don't think it would have survived the current process -- at least, not in the form in which it
has appeared. I would welcome exploring ways of removing it.<br>
> > <br>
> > > We can wait until the juice is worth the squeeze and avoid an unforced<br>
> > > error here.<br>
> > <br>
> > This is tempting. But I worry that this may be the best we get, and I think inaction is hurting us.<br>
> > <br>
> > Richard<br>
> > <br>
> > > > On Mon, Dec 9, 2019 at 4:58 PM Simon Peyton Jones via<br>
> > > > ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>> wrote:<br>
> > > > <br>
> > > > Dear steering committee<br>
> > > > <br>
> > > > I'm the shepherd for the RecordDotSyntax proposal.<br>
> > > > <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021935354&sdata=YMrBWZyrnmy%2FcJ2e5x3TAmvTo7DQamaxZu5IQzkRPS8%3D&reserved=0" target="_blank">
https://github.com/ghc-proposals/ghc-proposals/pull/282</a><br>
> > > > <br>
> > > > I recommend acceptance:<br>
> > > > <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282%23issuecomment-563477691&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021935354&sdata=MLMWuA10JgKqndNIg2gufvvsuMxtKLTiOzHZOBScsLc%3D&reserved=0" target="_blank">
https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477691</a><br>
> > > > <br>
> > > > Please reads the proposal, and as much of the discussion as you feel able, and respond in the next week or two to indicate your views.<br>
> > > > <br>
> > > > Remember: ask technical questions on the Github discussion thread, and use this mailing list for more evaluative discussion of judgement or opinion.<br>
> > > > <br>
> > > > I'd love every member of the committee to express a view. This proposal has attracted a lot of interest.<br>
> > > > <br>
> > > > Thanks<br>
> > > > <br>
> > > > Simon<br>
> > > > <br>
> > > > > -----Original Message-----<br>
> > > > > From: ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>><br>
> > > > > On Behalf Of Joachim Breitner<br>
> > > > > Sent: 28 November 2019 10:11<br>
> > > > > To: <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">
ghc-steering-committee@haskell.org</a><br>
> > > > > Subject: [EXTERNAL] [ghc-steering-committee] Please review #282:<br>
> > > > > RecordDotSyntax, Shepherd: Simon PJ<br>
> > > > > <br>
> > > > > Dear Committee,<br>
> > > > > <br>
> > > > > this is your secretary speaking:<br>
> > > > > <br>
> > > > > RecordDotSyntax language extension proposal has been proposed by Neil<br>
> > > > > Mitchell and Shayne Fletcher<br>
> > > > > <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F282&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021945348&sdata=seXtl%2FufSwR3Yx6O1KdRNTL9jn9Gdh378Dh69czXORo%3D&reserved=0" target="_blank">
https://github.com/ghc-proposals/ghc-proposals/pull/282</a><br>
> > > > > <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021955345&sdata=zc73B6VSW9yzhUlwPU7vcTVb115ZSMoOE%2FDa0APlDhE%3D&reserved=0" target="_blank">
https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-</a><br>
> > > > > syntax/proposals/0000-record-dot-syntax.md<br>
> > > > > <br>
> > > > > This is going to be a tricky one. It is partly about whitespace, so it<br>
> > > > > has attracted a _lot_ of community interest, by far the most so far. To<br>
> > > > > navigate that ship, I propose Simon PJ as the shepherd, because he is a<br>
> > > > > excellent moderator and community manager, and because he has the<br>
> > > > > necessary authority to hopefully get a verdict accepted.<br>
> > > > > <br>
> > > > > Please reach consensus as described in<br>
> > > > > <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021955345&sdata=SrIQa28Rtyx7evKGUK850hI8banF7HDEiMZ%2FJjShEC4%3D&reserved=0" target="_blank">
https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br>
> > > > > I suggest you make a recommendation, in a new e-mail thread with the<br>
> > > > > proposal number in the subject, about the decision, maybe point out<br>
> > > > > debatable points, and assume that anyone who stays quiet agrees with you.<br>
> > > > > <br>
> > > > > Thanks,<br>
> > > > > Joachim<br>
> > > > > --<br>
> > > > > Joachim Breitner<br>
> > > > > <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
> > > > > <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021965332&sdata=n195w9oPoKziOv7zBQ6KpPoi3NRwXYe%2BbzSxl%2FUlo1Q%3D&reserved=0" target="_blank">http://www.joachim-breitner.de/</a><br>
> > > > > <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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021975327&sdata=2GxTlecHJQEngX7dEd7RXbqU%2FcOud%2BuuqacsrPTdkZE%3D&reserved=0" 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021975327&sdata=2GxTlecHJQEngX7dEd7RXbqU%2FcOud%2BuuqacsrPTdkZE%3D&reserved=0" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> > > <br>
> > > <br>
> > > -- <br>
> > > Chris Allen<br>
> > > Currently working on <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021985324&sdata=6LiqHhWXBwozb2Tsdmu0XF93XzNrCUf3tZEqHGa%2BqjQ%3D&reserved=0" target="_blank">
http://haskellbook.com</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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021985324&sdata=j9JRF42QBPvEWM4ZF0quDoPFRr1TgCN2GPBXgWNKMa8%3D&reserved=0" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> > <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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981021995336&sdata=ask0ZPCDBtLB6XkE3BeeFuTE2%2Be0QOcgkifDpNDhC7E%3D&reserved=0" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> <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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022005321&sdata=Z898U%2B2wyaLpqEoSwQ8RBjgxiGkQfSoiCPL2Ftki2OE%3D&reserved=0" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022005321&sdata=Xnqi8KguWWaNazTwElo1qfddKAyEAJR9n1UmPZ3rqk8%3D&reserved=0" target="_blank">
http://www.joachim-breitner.de/</a><br>
<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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C3b27c5d4d5294a70dd2308d77d9bf0bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637115981022015315&sdata=qJuM%2FqqR3gFjlHh2u00murQ3Xf64n9vactZht19lDSI%3D&reserved=0" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>