On Fri, 7 Feb 2020 at 22:37, Joachim Breitner
I really would prefer a design where all these questions do not even need to be asked…
Me too. Also what about (.x) vs. ( .x), are those the same?
So I think to have the full picture, we need the following option as well on the ballot:
5. .x is a postfix operator, binding exactly like application, whether it is naked or not. (This is option 3, but without the whitespace-sensitivity.)
[...]
Anyways, now for my opinion: Assuming no more options are added, my ranking will be
5 > 4 > 2 > 1 > 3
This puts first the two variants where .x behaves like an existing language feature (either like function application or like record updates), has no whitespace sensitivity, and follows existing languages precedence (JS and OCaml, resp.). Then the compromise solution that simply forbids putting spaces before .x (so at least the program doesn't change semantics silently). I dislike variant 3, which adds a _new_ special rule, and where adding a single space can change the meaning of the program, so I rank that last.
I'm also against whitespace-sensitivity and I lean towards this ordering too. But I'm going with: 5 > 2 > 1 > 4 > 3 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. Cheers Simon
Cheers, Joachim
PS, because its on my mind, and just for fun:
Under variant 3, both foo1 and foo2 typecheck, they do quite different things (well, one loops).
data Stream a = Stream { val :: a, next :: Stream a }
foo1 f s = Stream (s.val) (foo1 (fmap f s).next) foo2 f s = Stream (s.val) (foo2 (fmap f s) .next)
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee