The examples are good, but I know from experience it's easy to overlook things if we don't consider what the precise grammar is, both at the lexical and context-free levels. So I wouldn't feel comfortable voting on a proposal where the grammar isn't completely clear. Some questions that come to mind given the current set of proposals:

Is (.a.b) legal? Under which alternatives? What about (.a .b)? What about (. .x)?

Does ( .x) mean (.x) or (. x)?

I presume under C2a things like 3.x, "abc".y, and [1,2,3].z would be legal, given suitable instances for Integral, IsString, or IsList? Which other proposals does that apply to?

If I have a record with a varsym field name, can I use dot syntax with it? e.g.
data R = R { (.) :: Int }
Now can I say r.(.) or r..? (note that the qualified name equivalent of this is M.. which is legal). If r.. is legal, presumably I should be able to use (..)? I suspect there are a lot of worms in this can :)

Can I use a record selector infix by surrounding it with ``? i.e. is `.x` a legal infix operator?  (I'm guessing not)

By the way, I understand the authors of the original proposal are against C5 so if that were the committee's preferred option then someone else would need to adopt the proposal.

Cheers
Simon

On Fri, 13 Mar 2020 at 17:43, Simon Peyton Jones <simonpj@microsoft.com> wrote:

Thanks.   You can’t vote if you don’t understand the alternatives!  And if you can’t maybe others can’t – or will do so based on different understandings of the same thing.  That would be Bad.

 

I’m not well positioned to fix this because I don’t know where the ambiguities are.  Would you like to ask some clarifying questions?

 

Simon

 

From: Simon Marlow <marlowsd@gmail.com>
Sent: 13 March 2020 17:30
To: Simon Peyton Jones <simonpj@microsoft.com>
Cc: Christopher Allen <cma@bitemyapp.com>; Cale Gibbard <cgibbard@gmail.com>; ghc-steering-committee <ghc-steering-committee@haskell.org>
Subject: Re: RecordDotSyntax proposal: next steps

 

It's still a bit hard (IMO) to understand what precise changes each proposal would make to the syntax, but I don't want to hold things up so I've added an AYE.

 

Cheers

Simon

 

On Fri, 13 Mar 2020 at 10:38, Simon Peyton Jones <simonpj@microsoft.com> wrote:

Chris, Cale, Simon

I wonder if you might have a moment to respond to this email?

Thanks

Simon

 

From: Simon Peyton Jones <simonpj@microsoft.com>
Sent: 09 March 2020 09:56
To: ghc-steering-committee <ghc-steering-committee@haskell.org>
Cc: Simon Peyton Jones <simonpj@microsoft.com>
Subject: RE: RecordDotSyntax proposal: next steps

 

Colleagues

Thanks for your various replies.   I have

  • Added a couple more examples (please check)
  • Split (C2a) and (C2b) – thank you Joachim for filling out the list.
  • Add a Notes section that identifies some consequences, hopefully objectively.
  • Added a list  at the end where you can add your AYE when happy.

Can you review, and Christopher, Richard, Cale, Simon, Eric, Alejandro, Arnaud: please add AYE or suggest further changes.

This is painstaking but I think it is clarifying. I have found writing out the examples is quite helpful.  Feel free to suggest more if you think there are some cases that are unclear.

Thanks

Simon

 

From: Simon Peyton Jones <simonpj@microsoft.com>
Sent: 06 March 2020 17:59
To: ghc-steering-committee <ghc-steering-committee@haskell.org>
Cc: Simon Peyton Jones <simonpj@microsoft.com>
Subject: RecordDotSyntax proposal: next steps

 

Colleagues

I’m sorry to have been dragging my feet on the records proposal.   First there was half term holiday, and then the ICFP deadline, so I’ve been out of action for several weeks.

It’s pretty clear that we are not going to achieve 100% consensus, so the right thing to do is to vote, using the single-transferrable-vote scheme that Joachim runs.  It’s worth striving for consensus, because the debate can be clarifying (and has been!).  But I don’t regard non-consensus as a failure.  These things are all judgement calls, and people’s judgement can legitimately differ.   Voting lets us nevertheless reach a conclusion.

So here’s what I propose

    1. Complete: no choices that people really want are omitted.
    2. Clear and unambiguous.  When we vote we must know exactly what we are voting for!  

Can you all respond about that, including “Aye” if you think it is both complete and clear.

  • Once we are all satisfied, I’ll invite you to vote.  The easiest way to do so might be to edit the Google doc directly, so there’s a single point of reference.

Please also let me know if you think we should be doing anything else.

Thanks!

Simon