[ghc-steering-committee] Record dot notation

[Iavor Diatchki]

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> 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
> 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/9b3d2f7e/attachment.html>