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