Since I voted C2a as first option, let me try to explain what lead me to my vote.

Which is one main thing: for me the syntax "r .x", with a space in between the element and the field name, looks completely alien and different from what other languages do [1,2,3]. Even though we can implement that in a clever way by making ".r" a special kind of operator, I think that for most people the notion of "field access" is ingrained as a special part of the syntax of a language.

Furthermore, several examples in C4 are very surprising to me. For example, "f r .x" meaning "f (r.x)". Once again, I expect field access be part of the same "joint expression" as in other languages.

As a final note, if we have ".b" for fields, what would stop us from making ".f" just special syntax for "post-application of any function"? I mean, we could also have something as "numbers .sum" as meaning "sum numbers", in the same way that "person .age" is equivalent to "age person". I am not arguing at all that we should go that way, but rather that for many reason I think that making "field access" less clever, and more similar to other languages, is the right decision.

Alejandro

[1] C# Language Spec -> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#member-access
[2] F# Language Spec, page 81 -> https://fsharp.org/specs/language-spec/4.1/FSharpSpec-4.1-latest.pdf
[3] OCaml syntax, records -> https://caml.inria.fr/pub/docs/manual-ocaml/expr.html#sss:expr-records

El lun., 30 mar. 2020 a las 20:03, Eric Seidel (<eric@seidel.io>) escribió:
I'd be very interested too.

I also think it would be good to summarize our discussion here, in particular the rationale for C2a, and post the summary on the GitHub thread. I noticed some concerns on the GitHub thread about the lack of consensus and the omission of `map .lbl xs` (IIRC we did discuss this option and there actually *was* consensus that we didn't like it), we should address those concerns too.

Eric


On Mon, Mar 30, 2020, at 13:06, Iavor Diatchki wrote:
> Thanks Joachim! I'd be curious the hear an opinion from someone who
> prefers `C2a` to `C4`, about why it is better? To me `C2a` just looks
> like a more complicated version of `C4`.
>
> -Iavor
>
>
> On Mon, Mar 30, 2020 at 9:58 AM Richard Eisenberg <rae@richarde.dev> wrote:
> > I think this is a fine conclusion to the saga, personally. C2a is one of the more middle-of-the-ground options, and it's refreshing to have an election that chooses such a candidate.
> >
> >  It's been slow, yes, but I think this phase of the saga has highlighted the strengths of the committee process, in that we had a deliberate, carefully reasoned vote.
> >
> >  Thanks for running the vote algorithm, Joachim, and for your careful shepherding, Simon.
> >
> >  Richard
> >
> >  > On Mar 30, 2020, at 5:48 PM, Joachim Breitner <mail@joachim-breitner.de> wrote:
> >  >
> >  > Dear Committe,
> >  >
> >  > thanks all for voting. The ranking of votes is now
> >  >
> >  > C2a > C2b > C4 > C1 > C7 > C6 > C3 > C5
> >  >
> >  > In particular C2a beats every other options by 7:4 or more, and is
> >  > therefore the result of this poll.
> >  >
> >  > You can see more statistics at
> >  > https://www.condorcet.vote/Vote/AB23CE70AC/
> >  >
> >  > So, does this conclude this saga?
> >  >
> >  > Cheers,
> >  > Joachim
> >  >
> >  > --
> >  > 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
> >
> >  _______________________________________________
> >  ghc-steering-committee mailing list
> > ghc-steering-committee@haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee@haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee