<div dir="ltr"><div dir="ltr">On Fri, 7 Feb 2020 at 22:37, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I really would prefer a design where all these questions do not even<br>
need to be asked…<br></blockquote><div><br></div><div>Me too. Also what about (.x) vs. ( .x), are those the same?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.)<br></blockquote><div> <br></div><div>[...]<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Anyways, now for my opinion: Assuming no more options are added, my<br>
ranking will be<br>
<br>
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.<br></blockquote><div><br></div><div>I'm also against whitespace-sensitivity and I lean towards this ordering too. </div>But I'm going with:<br><div><br></div><div>5 > 2 > 1 > 4 > 3 </div></div><div class="gmail_quote"><div><br></div><div>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.</div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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>
data Stream a = Stream { val :: a, next :: Stream a }<br>
<br>
foo1 f s = Stream (s.val) (foo1 (fmap f s).next)<br>
foo2 f s = Stream (s.val) (foo2 (fmap f s) .next)<br>
<br>
<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" 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" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div>