Personally, I am not thrilled about this proposal, and I am unlikely to use
it, if it is implemented.
As I said before, I am fine with accepting it, if others would find it
useful, as long as we have the option to not use it---
I realize I am in the minority here, but think Haskell's records actually
work pretty well as they are and I use them all the time
without significant problems.
As for the concrete design question: I agree that `f x.y` should mean `f
(x.y)`.
-Iavor
On Mon, Dec 16, 2019 at 3:48 PM Simon Peyton Jones via
ghc-steering-committee
Dear steering committee
I am keen to prevent the record-syntax debate from spiralling outwards. This has happened before, and is the main reason Haskell has remained stuck with sub-standard records for so long. So I'm playing a more active, even directive, shepherding role than usual.
Vitaly, thanks for your response, but I continue to believe that we should accept some version of this proposal. I can elaborate more if needed, but I think that most of the committee agrees with the direction of travel. (But please say if you want to join Vitaly in outright rejection.)
Assuming that we want to accept some version, *I'd like to propose that we adopt the idea that `f r.x` means `f (r.x)`*, and not the record selection `(f r).x`, nor the function composition `(f r) . x`.
Joachim floated the `(f r).x` idea recently and Richard supported him. I consulted the authors who said "Interestingly, the very first version of the prototype implemented exactly that. That behaviour surprised the heck out of everyone (including you) and we were quickly and overwhelmingly convinced that it was the wrong parse and updated the proposal accordingly." I had a long conversation with Richard, who (I think) finds both alternatives acceptable.
I agree strongly with the authors; I think `(f r).x` would be horrible, and would vote against such a proposal. So, in the interests of making progress, I recommend that we adopt the `f (r.x)` parse. Talking to Richard I realise that a lot depends on your starting point:
1. I regard `M.N.x` and `r.x.y` as a single token, where `.` is punctuation. Space is always significant for dot; `M . x` is quite different to `M.x`. Another example is the unbounded enumeration `[Z ..]` where you must put the space; if you write `[Z..]` you'll get the dot-operator imported from module Z.
From this point of view, Haskell's use of `(.)` as an infix operator for composition is an aberration. And parsing `f r.x` as `f (r.x)` is consistent with our parse of `f M.x`.
1. An alternative point of view is to regard `(.)` as a fully fledged operator, and all the stuff about qualified names, enumerations and so on, as a sad aberration. Under this point of view, record selection just makes the aberration worse.
I realise that one reason I want the `f (r.x)` parse so strongly is my previously-implicit espousal of (A); perhaps making that explicit will help frame the conversation. I’m also very un-keen on making `r.x` illegal, which is another alternative in theory.
TL;DR. Does anyone (who wants to accept the proposal in some form) seriously oppose the `f (r.x)` parse for `f r.x`? I hope that it'll be at least acceptable to everyone, and we can more on.
Thanks
Simon _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee