<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.pl-k
{mso-style-name:pl-k;}
span.pl-c
{mso-style-name:pl-c;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle24
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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="margin-left:36.0pt">My point here is that option (5) is no more or less whitespace sensitive than option (3). Both need the same cases to figure what the period character in your code means. I think this is why Simon PJ has keyed
this part of the debate to module qualification: that existing feature (not under debate) essentially breaks the symmetry here, meaning that we have more room to work with without breaking symmetry further.<o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">You’ve put it very well. Indeed, we could key it even more tightly to module qualification, by making the lexical rule exactly the same: just as M.x is treated as binding super-tightly, so is r.x.
If you like, M.x is a lexeme, and so is r.x. They even have the same connotation (the x component of M or r respectively).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">What about (f e).y, or f{-blah-}.y? Well, you can’t write qualified modules that way; it becomes two or more lexemes. I’d be perfectly content to do the same for record selections, using Joachim’s
rule 5 for every case *<b>except</b>* the case that parses exactly like module qualifiers (modulo upper case vs lower case).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">TL;DR: I’m arguing that (f r.x) means (f (r.x)) just as (f M.x) means (f (M.x)).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">But I don’t care about<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> f (blah blah blah).x<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I’d be quite content with that meaning<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> f (bla blha blah) .x<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">as Joachim suggests.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Would that help to resolve this debate? I had not thought of it in that way before, but Joachim and Richard have helped met to do so, thank you.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></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>Richard Eisenberg<br>
<b>Sent:</b> 10 February 2020 12:14<br>
<b>To:</b> Simon Marlow <marlowsd@gmail.com><br>
<b>Cc:</b> ghc-steering-committee <ghc-steering-committee@haskell.org>; Joachim Breitner <mail@joachim-breitner.de><br>
<b>Subject:</b> Re: [ghc-steering-committee] Record dot notation<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Upon careful consideration, I think the whitespace concerns here are somewhat ill-founded.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">First, please see <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst#proposed-change-specification">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst#proposed-change-specification</a>,
where (among other points), a careful description of "loose infix" vs "prefix" vs "suffix" vs "tight infix" is discussed. Here is a set of examples:<o:p></o:p></p>
</div>
<div>
<pre>a <span class="pl-k">!</span> b <span class="pl-c">-- a loose infix occurrence</span><o:p></o:p></pre>
<pre>a<span class="pl-k">!</span>b <span class="pl-c">-- a tight infix occurrence</span><o:p></o:p></pre>
<pre>a <span class="pl-k">!</span>b <span class="pl-c">-- a prefix occurrence</span><o:p></o:p></pre>
<pre>a<span class="pl-k">!</span> b <span class="pl-c">-- a suffix occurrence</span><o:p></o:p></pre>
<div>
<p class="MsoNormal">This distinction is *not* just made by example, but that proposal (which has been accepted) defines these precisely. So, the comments on this thread about what counts as a naked selector are addressed: a naked selector is one where the
dot is a prefix occurrence.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Other whitespace-wariness comes from worrying about the distinction between prefix and tight infix occurrences. That is, should we differentiate between the interpretation of `f r.x` and `f r .x`. Yet in all versions of any of this, we
differentiate between loose infix and the others. Thus there is *always* whitespace-sensitivity around dot. Note that this is true, as Simon PJ pointed out, regardless of this proposal, where a tight-infix usage of a dot with a capitalized identifier on the
left is taken as a module qualification. In all of its versions, this proposal *increases* the whitespace sensitivity, by further distinguishing between prefix occurrences of dot and other usages.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Let's compare options 3 and 5 with this analysis then:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Option 3:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">loose-infix: whatever (.) is in scope<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">tight-infix:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - if left-hand is a capitalized identifier: module qualification<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - otherwise: record selection, binding tighter than function application<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">prefix: postfix record selection, binding like function application<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">suffix: presumably, whatever (.) is in scope<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Option 5:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">loose-infix: whatever (.) is in scope<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">tight-infix:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - if left-hand is a capitalized identifier: module qualification<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - otherwise: postfix record selection, binding like function application<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">prefix: postfix record selection, binding like function application<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">suffix: presumably, whatever (.) is in scope<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My point here is that option (5) is no more or less whitespace sensitive than option (3). Both need the same cases to figure what the period character in your code means. I think this is why Simon PJ has keyed this part of the debate to
module qualification: that existing feature (not under debate) essentially breaks the symmetry here, meaning that we have more room to work with without breaking symmetry further.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My vote is thus:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">3 > 5 > 2 > 4 > 1<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Other points of motivation:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- Despite my argument above, I see the merit in (5). I just think that an argument "we don't want dot to be whitespace-sensitive" isn't really effective.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- I want to accept this proposal. We're not going to get another go at this.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- I really don't like the way record-update binds, and (4) reminds me too much of that.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Richard<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Feb 10, 2020, at 9:58 AM, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">On Fri, 7 Feb 2020 at 22:37, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<o:p></o:p></span></p>
</div>
<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"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
I really would prefer a design where all these questions do not even<br>
need to be asked…<o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Me too. Also what about (.x) vs. ( .x), are those the same?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> <o:p></o:p></span></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"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">So I think to have the full picture, we need the following option as<br>
well on the ballot:<br>
<br>
5. .x is a postfix operator, binding exactly like application,<br>
whether it is naked or not.<br>
(This is option 3, but without the whitespace-sensitivity.)<o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">[...]<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> <o:p></o:p></span></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"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Anyways, now for my opinion: Assuming no more options are added, my<br>
ranking will be<br>
<br>
<span class="apple-converted-space"> </span>5 > 4 > 2 > 1 > 3<br>
<br>
This puts first the two variants where .x behaves like an existing<br>
language feature (either like function application or like record<br>
updates), has no whitespace sensitivity, and follows existing languages<br>
precedence (JS and OCaml, resp.).<br>
Then the compromise solution that simply forbids putting spaces before<br>
.x (so at least the program doesn't change semantics silently).<br>
I dislike variant 3, which adds a _new_ special rule, and where adding<br>
a single space can change the meaning of the program, so I rank that<br>
last.<o:p></o:p></span></p>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">I'm also against whitespace-sensitivity and I lean towards this ordering too.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">But I'm going with:<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">5 > 2 > 1 > 4 > 3<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Rationale: (5) seems the easiest to explain and has the fewest special cases, yet covers the use-cases we're interested in. Beyond that I want to be conservative because I
find it hard to predict the ramifications of the more-complex alternatives 4/3, so I've put 2/1 ahead of those. I've made my peace with the current record selection syntax binding more tightly than application, and indeed I often rely on it to avoid a $, so
I'm OK with 4 over 3.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Cheers<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Simon<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> <o:p></o:p></span></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"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
PS, because its on my mind, and just for fun:<br>
<br>
Under variant 3, both foo1 and foo2 typecheck, they do quite different<br>
things (well, one loops).<br>
<br>
<span class="apple-converted-space"> </span>data Stream a = Stream { val :: a, next :: Stream a }<br>
<br>
<span class="apple-converted-space"> </span>foo1 f s = Stream (s.val) (foo1 (fmap f s).next)<br>
<span class="apple-converted-space"> </span>foo2 f s = Stream (s.val) (foo2 (fmap f s) .next)<br>
<br>
<br>
--<span class="apple-converted-space"> </span><br>
Joachim Breitner<br>
<span class="apple-converted-space"> </span><a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<span class="apple-converted-space"> </span><a href="http://www.joachim-breitner.de/" target="_blank">http://www.joachim-breitner.de/</a><br>
<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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></span></p>
</blockquote>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
ghc-steering-committee mailing list<br>
</span><a href="mailto:ghc-steering-committee@haskell.org"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">ghc-steering-committee@haskell.org</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>