Re: [ghc-steering-committee] Record dot syntax: vote results

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-s... [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 () 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 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