Before we accept the proposal I think we should have a precise description of the changes to the syntax. For example, we don't address the question of whether a field name can be an operator or not. We explicitly left these questions until later; wouldn't now be the right time to address them?

 

Yes I put that under “What happens next”.   You are right about operators – I’ve added that.  Anything else to add?

 

Also worth bringing up at this point, since we landed on C2a: Note 5 says

Yes this is why I argued for (C6) which avoids all this difficulty 😊.   But the consensus was otherwise.

 

I think the right thing is to ask the authors to elaborate this point.

 

Simon

 

From: Simon Marlow <marlowsd@gmail.com>
Sent: 31 March 2020 11:41
To: Simon Peyton Jones <simonpj@microsoft.com>
Cc: Joachim Breitner <mail@joachim-breitner.de>; ghc-steering-committee <ghc-steering-committee@haskell.org>; Neil Mitchell <ndmitchell@gmail.com>; Shayne Fletcher <shayne.fletcher@daml.com>
Subject: Re: [ghc-steering-committee] Record dot syntax: vote results

 

On Tue, 31 Mar 2020 at 11:08, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@haskell.org> wrote:

Thanks Joachim.

Everyone: I have extended our choices document with a draft post to the Github thread.
https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74/edit?usp=sharing

Can you review it, for both tone and content?  You have edit permission, so by all means improve the wording.  Look for omissions.  I want to bring the discussion to a close, not re-ignite further debate, but be respectful of those who disagree.

 

Before we accept the proposal I think we should have a precise description of the changes to the syntax. For example, we don't address the question of whether a field name can be an operator or not. We explicitly left these questions until later; wouldn't now be the right time to address them?

 

Also worth bringing up at this point, since we landed on C2a: Note 5 says

 

One mechanism for handling this is given in the proposal.  It involves no changes to the lexer, but instead an adjacency test one production of the parser.

 

I'm not sure about this as a language design. (1) it's an ad-hoc side-condition that can't be expressed in the lexical or context-free grammar (however there's precedent for this kind of thing in the form of the layout rule of course), and (2) it's quite a costly feature in terms of implementation effort to add to the language, because your AST needs complete and accurate source-span information. We can do it in GHC, and haskell-src-exts can do it nowadays, but earlier versions of haskell-src-exts before complete SrcSpanInfo was added wouldn't have been able to implement this rule. Arguably we're only accepting this as a GHC extension and not a Haskell extension in general, but as we know GHC is the testbed for future language extensions, so it's a good time to consider these issues.

 

The alternative of course is to go with some variant of



 

which is also an ad-hoc side-condition sadly, but could be implemented in the lexer.  Nevertheless, all this needs to be nailed down before the proposal can be accepted, IMO.

 

Cheers

Simon

 

 


Could you do so this week, by end Friday?   I propose to leave the votes recorded there, but when posting I'll move the post from the document (deleting it from there) to GitHub.

I'm cc'ing Neil and Shayne, the authors.  Neil, Shayne: I think (and desperately hope!) you'll be content with this outcome.  Can you review my draft post too?

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-bounces@haskell.org>
|  On Behalf Of Joachim Breitner
|  Sent: 30 March 2020 17:48
|  To: ghc-steering-committee <ghc-steering-committee@haskell.org>
|  Subject: Re: [ghc-steering-committee] Record dot syntax: vote results
| 
|  Dear Committe,
| 
|  thanks all for voting. The ranking of votes is now
| 
|        C2a > C2b > C4 > C1 > C7 > C6 > C3 > C5
| 
|  In particular C2a beats every other options by 7:4 or more, and is
|  therefore the result of this poll.
| 
|  You can see more statistics at
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cond
|  orcet.vote%2FVote%2FAB23CE70AC%2F&amp;data=02%7C01%7Csimonpj%40microsoft.c
|  om%7Ce27e9c8f455b436e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7
|  C1%7C0%7C637211837260982595&amp;sdata=LLWCxVjXxyLqcJUZ9iMgB%2B5QYGMuHFzJga
|  u9agTakiQ%3D&amp;reserved=0
| 
|  So, does this conclude this saga?
| 
|  Cheers,
|  Joachim
| 
|  --
|  Joachim Breitner
|    mail@joachim-breitner.de
| 
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
|  im-
|  breitner.de%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b43
|  6e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372118372
|  60982595&amp;sdata=GE%2BBYN7rA7zWgwuKlArv4PR%2Fm3IlmZ7PqWbGpgXUyms%3D&amp;
|  reserved=0
| 
| 
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee@haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b436e2be
|  e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982
|  595&amp;sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&amp;reserved=
|  0
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee