After voting I feel like writing down the rationale I used, and I'll
probably forget myself if I don't write this down:
1. Of greatest importance to me is the ability to replace an identifier by
a parenthesized expression without changing meaning. So "(f x).y" must mean
the same as "r.y". That rules out C2b and C6. (this rationale doesn't apply
to qualified names because we don't have first-class modules, and maybe one
day if that changes we will want to revisit the syntax for qualified names
too.)
2. I'm downranking proposals where selection binds "like application"
because I think it will end up being confusing. So that's C3, C5, C6.
3. All other things being equal, less whitespace-sensitivity is to be
preferred, so C4 > C2a > C7.
Cheers
Simon
On Thu, 19 Mar 2020 at 11:33, Simon Peyton Jones via ghc-steering-committee
Colleagues
Now that we have agreed a set of alternatives on using dot notation for records, let's vote. We all recognise and respect that syntactic choices are a judgement call, and that reasonable people may diff in their judgements. But we need to come to as resolution and voting is a good way to do that.
*Please put your votes on the Google doc.* I've make a section for that at the end. The document is here https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com%7Ca528b11e503e43cc660308d7cbe97ac1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637202075954123160&sdata=8Wd6L7caSByus%2F8zwmLq6vbRqbifNCjkbYuWaSER0Aw%3D&reserved=0 .
Just write down your preferences, in order, preferred ones first.
Joachim runs an election algorithm that makes it worth specifying a total order on all options, *including ones you don't like*. For any you omit, you are saying "if these ones are the top contenders I have no preference between them". You can specify ties, again meaning "no preference between these". For the over-interested, the algorithm is Condorcet https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCondorcet_method&data=02%7C01%7Csimonpj%40microsoft.com%7Ca528b11e503e43cc660308d7cbe97ac1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637202075954133147&sdata=9HmtR634TMUXHozP81lnvMR0SvYIXlBtfRTiDyUkWq8%3D&reserved=0; in the unlikely case that it does not produce a winner, we revert to Schultze https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSchulze_method&data=02%7C01%7Csimonpj%40microsoft.com%7Ca528b11e503e43cc660308d7cbe97ac1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637202075954133147&sdata=GIzAX0Wvw1lWtUfUGvv3VmdLGLEFX7o8asdeuVbu6U8%3D&reserved=0
Please read the document, including the Notes, carefully! We have ended up with a lot of variations, and their numbering is historical not logical. (I considered renumbering but thought that would be more confusing than helpful.)
As the shepherd I am supposed to make a recommendation; it is below.
Simon
Shepherd's recommendations
Here is my recommendation:
* C6 > C2b > C3 > C2a > C7 > C4 > C5 > C1* I recommend acceptance
Overall, I strongly urge that we accept the proposal in some form; that is, we should not do (C1). I have been unhappy with GHC's story for records for two decades. (E.g. Lightweight extensible records for Haskell, Haskell Workshop, Paris 1999.) But the design space is so complicated that we never found something that felt "obviously right". So we did nothing drastic, and I think that was right.
But there was incremental progress, sketched here:
- DuplicateRecordFields lets you have multiple records with the same field name. - The HasField class lets us define overloaded record selection and update functions.
The proposal we are now discussing has no type-system component; it is *only* about syntactic sugar, allowing you to use dot-notation for field selection. (Various extensions about syntax for update were discussed, but no longer form part of the proposal; what is left is the core.)
I really think this change has vastly higher impact and utility than many other accepted proposals. I know that some members of the committee differ from this view; that's fair enough. Alternatives I like:
- I urge us to adopt (C6). I really really want *(f M.N.x) *to parse the same as *(f M.n.x)**,* where the only difference is the capitalisation of the second-last element of *M.n.x*.
*I'm leaning strongly on the connection with qualified names*. We already have qualified names, and they are incredibly useful. Qualified names already treat “.” specially. Moreover the proposal uses “.” in precisely the same way as qualified names: a qualified name M.x allows you to pick x from the module M; this proposal allows r.x to pick a field x from a value r. I like this uniformity of both concept and syntax.
- (C2b) is a weakened form of (C6) that does not allow naked selectors, thus *(f .x)* where there is a space before the ".". I don't see any difficulty with the postfix operator story, so I prefer (C6). But (C2b) is a little more conservative.
Alternatives I actively dislike:
- I urge against (C1) as I say above. - I dislike (C5) strongly, because it makes *(f M.N.x)* parse completely differently from *(f M.n.x).* The authors of the proposal say that they would withdraw the proposal outright (or at least disassociate themselves) if we adopted (C5). - I dislike (C7) for the same reason: *(f M.N.x)* is legal but *(f M.n.x)* is not. - I dislike (C4) because nothing should bind more tightly than function application. I hate that *(f r .x s .y*) would mean * (f (r.x) (s.y)).* Yes, we already have that *(f r {x=2})* means *(f (r {x=2}))*, but I think that's terrible, and we should not perpetuate it.
Alternatives in the middle
- (C2a) and (C3) are just like (C2b) and (C6), but additionally allow a tightly-binding record selection after a parenthesised expression. Thus *(f (g x).y)* means *(f ((g x).y)).*
Allowing this is a bit tricky to specify, and the link to qualified names is much weaker. I don't think it pays its way.
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee