[ghc-steering-committee] Record dot notation

[Chris Allen]

1, 2, (and that's it)

On 2/7/20 1:06 PM, Iavor Diatchki wrote:
> Those seem like reasonable options to me.
>
> I think my preference would be:  2,4,3,1.
>
> My justification is that I find the naked selectors a bit odd, but if 
> we are going to have them I find (4)
> a bit easier to explain:  the rule is that record selection has higher 
> precedence than function application,
> and white space does not need to be discussed at all.
>
> I agree that this might not be the most elegant of proposals, but 
> having recently tried to use the `getField`
> class method in anger without the syntactic sugar, I think that my 
> code would be a lot more readable with this extension
> than without.
>
> -Iavor
>
>
>
>
>
>
>
> On Fri, Feb 7, 2020 at 9:13 AM Simon Peyton Jones via 
> ghc-steering-committee <ghc-steering-committee at haskell.org 
> <mailto:ghc-steering-committee at haskell.org>> wrote:
>
>     Colleagues
>
>     I've been slow on the records front; apologies.
>
>     I think Joachim is right: we've discussed a lot of options, but in the
>     end much of this is a judgement call with no perfect answers, and it
>     now seems simplest to express our judgement through voting. I think
>     we are all keen to decide this and move on.
>
>     Proposal:
>     https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/proposals/0000-record-dot-syntax.md
>     Lengthy discussion:
>     https://github.com/ghc-proposals/ghc-proposals/pull/282
>
>     Here are the alternatives I propose we vote on.  The first order of
>     business is to check that they are all clear; and that I haven't
>     omitted
>     a worthy alternative.  Here they are:
>
>     1. Reject the proposal
>
>     2. Naked .x is illegal
>
>     3. Naked .x is a postfix operator, binding exactly
>        like application:  f r .x   means (f r).x
>
>     4. Naked .x is a postfix operator, binding more tightly
>        than application: f r .x   means   f (r.x)
>
>     Under all of (2,3,4) I think we are content that
>       - (f r.x) means  (f (r.x))
>       - (.x)    means  (\r -> r.x)
>
>     By "naked .x" I mean "not preceded by an identifier (e.g. r.x),
>     or an open paren (e.g. (.x)), or a close paren (e.g. (f 3).x)
>
>     We could re-open more of this, but I'd prefer to keep it to 1-4.
>
>     Let's just check everyone is happy with these alternatives. Then
>     we can
>     vote by putting in rank order, and Joachim can run his STV algorithm.
>
>
>     I'm the shepherd for this proposal, so let me add my recommendations.
>
>     I strongly urge that we do not adopt (1); that is, we accept the
>     proposal in some form.  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:
>     https://gitlab.haskell.org/ghc/ghc/wikis/records/overloaded-record-fields
>
>     * 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, which
>     has a particularly high benefit/cost ratio.
>
>     Now, judgements may differ about the importance of syntactic sugar --
>     that's why we have a committee with a diversity of views -- but I
>     believe that dot-notation for record selection is super-important.
>     I've wanted it for ages.  Every other language has it.  We have
>     accepted other syntactic sugar with much lower utility.  And
>     the dot is already a special case, via qualified names.
>
>     I respect the fact that others may differ, but I really think
>     think this is worth it.  It would be a crying shame to reject
>     this.  Unlike Chris, I don't think anything better is going to
>     emerge, however long we wait.
>
>     I am more relaxed about 2/3/4.  Personally I hate (4) because
>     I don't like *any* notation in which something binds more tightly
>     than function application.  e.g. I cordially dislike (f K {x=3})
>     meaning (f (K {x=3})).
>
>     My preference is for (3), which allows record selection with
>     spaces (which some argue for).  But (2) represents at most a lost
>     opportunity, not a bad thing.
>
>     Thanks
>
>     Simon
>
>     _______________________________________________
>     ghc-steering-committee mailing list
>     ghc-steering-committee at haskell.org
>     <mailto:ghc-steering-committee at haskell.org>
>     https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200207/996bd3c7/attachment-0001.html>