I don't like C6 because `e.x` has completely different meaning when `e` is a variable vs. when it is not.
But that is true today! Specifically, qualified names. M.x means something very different to (f y).x
What’s attractive to me about C6 is that it simply and uniformly extends qualified names. But I said that before, and your judgement differs, which is fair enough.
Simon
From: Iavor Diatchki
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.
I'm not sure any of these proposed options feels "obviously right" either. The fact that we're voting between many different ways to interpret the same syntax sugar should make it clear that this isn't so obvious.
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.
While I'd agree it has vastly higher impact that a lot of accepted proposals, I'm not sure that impact is actually in the direction of making it easier to read and understand programs that are written in Haskell. It's syntactic sugar that we've pretty reasonably done without for a long time. Piling on yet another option for how to select fields from records amidst a sea of libraries that already help with this in various ways that go far beyond the capabilities of the syntax sugar that's proposed here seems a bit strange to me at this point. It feels like the complaint is "but I want to type exactly this string of characters and no other will do", which seems kind of absurd to me, but other languages exist in the world, and DAML for instance is a thing which exists now and should satisfy those people. I don't particularly get why it's of great importance for Haskell to support accessing fields with *this* syntax, and not dozens of almost-equivalent syntaxes that one could already achieve. If there were no confusion over what the infix dot meant and how it interacted with the rest of Haskell's syntax, then maybe there wouldn't be anything much to be unhappy about in adding in this extra bit of sugar. But it is manifestly confusing or else we wouldn't be having this vote and so many clarifications about what consequences the options had wouldn't have been needed. All these syntactic questions that have been asked and debated in this thread are something that every beginner will have to contend with, and all the consequences of whatever option is selected are something every expert will have to live with. I don't feel that it's worth the extremely meagre benefit of the difference between this and just opting to use lens or otherwise just using the already existing mechanisms. Frankly, I still mostly use Haskell's ordinary field accessors unless there's a real need for abstracting over a lens (at which point I'll switch to using Ed's lens library), or just abstracting over field access (at which point I'll probably define my own class), and DuplicateRecordFields and the associated machinery is not something that I have had a whole lot of love for in the first place. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cb584cb955faa458e38b808d7d02cb8b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637206762802861085&sdata=xfd76JSbk1LMcql5RrRjdNgepcZf5PTuKL4DT0QdU4A%3D&reserved=0