[ghc-steering-committee] Record dot syntax: vote results

Simon Peyton Jones simonpj at microsoft.com
Tue Mar 31 13:09:15 UTC 2020 

But: if you agree (and it sounds like you do) that the proposal's text is definitive, I can update the text above to try to iron out these potential sources of confusion.

Yes I do.  Please do!   And, it’s terribly late in the day, but if anyone wants to raise a new issue, please do so.


I do wonder about explicitly calling out the possibility of having (a) the syntactic sugar of this proposal with (b) no overloading.   So that
    r.x   desugars to   (x r)
    e { x = e2 }    desugars to   case e of K { .. } -> K { x=e2, .. }
or something like that.  That is strictly beyond what the proposal currently does, which is to *always* use setField/getField.  But that means that for records with polymorphic fields you simply can’t use the proposal at all.

Simon

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




On Mar 31, 2020, at 12:48 PM, Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:

What features of the proposal document are actually a part of the proposal?

Well, all of it!

Good -- that's very clear, then. And it had been clear for some time (to me) -- it's just that I find it disagrees with the proposed text on the document, which reads:

> The proposal is entirely about syntax; and specifically about
  introducing the form `r.x` for record field selection.  No changes
  to the type system, or any other aspect of the language, are
  proposed.  The original proposal was more elaborate, providing ways
  to update fields as well as set them, but was simplified to focus on
  the essentials.

If we look at the proposal (https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/proposals/0000-record-dot-syntax.md#211-syntax<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-syntax%2Fproposals%2F0000-record-dot-syntax.md%23211-syntax&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520732428&sdata=ET%2BCsjDS8EjsUysIIqvE9%2F5OvA1EVnI91kvjbHqy2Nc%3D&reserved=0>), we see a range of syntactic transformations. One of these repurposes record-update syntax, and assigns it new typing rules. To me, this changes the type system. Some of these rules propose new ways to update fields. (I see now you were thinking of the fact that syntax like `+=` has been abandoned. That's true, but I read the text above is referring to record-update.) So my reading of the rules leads to a different picture than the text above.

But: if you agree (and it sounds like you do) that the proposal's text is definitive, I can update the text above to try to iron out these potential sources of confusion.

Richard


There are two pretty much orthogonal things going on

  1.  Syntax for record selection  r.x; this proposal
  2.  Using overloading to resolve duplicate record labels, via getField/setField
It’s true (2) pretty much precludes selection/update for records with polymorphic fields (unless we have impredicativity, which I think we should ignore for now).  That has always been true.

If you don’t want (2) then (1) is still useful.   Maybe the proposal should have different desugaring rules with and without OverloadedRecordFields.   That would be an additional box in the matrix, which I suppose we might want to fill in.

Including Shayne and Neil in this conversation.



Simon

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

Quoting from the document:

> The proposal is entirely about syntax; and specifically about
  introducing the form `r.x` for record field selection.  No changes
  to the type system, or any other aspect of the language, are
  proposed.  The original proposal was more elaborate, providing ways
  to update fields as well as set them, but was simplified to focus on
  the essentials.

Is this fact enshrined in the proposal document? I view that as ground truth. And it describes, e.g., that (e { field = val }) now means (setField ...), which means that polymorphic record update is incompatible with -XRecordDotSyntax. What features of the proposal document are actually a part of the proposal?

Otherwise, I am happy with the tone and content of the post.

Thanks,
Richard



On Mar 31, 2020, at 11:40 AM, Simon Marlow <marlowsd at gmail.com<mailto:marlowsd at gmail.com>> wrote:

On Tue, 31 Mar 2020 at 11:08, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fedit%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520742428&sdata=W4hHo9WZaOANfbjfI9DOE5zwAgyAm%2BJjcKBrcLV8Dyw%3D&reserved=0>

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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshayne-fletcher-da%2Fghc-proposals%2Fblob%2Frecord-dot-syntax%2Fproposals%2F0000-record-dot-syntax.md%232322-parsing-of-field-selections&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520752420&sdata=culW9AOiRxeFt0BhYpfHIfrPBdyG4Y%2Bnkd%2B4oWweoFA%3D&reserved=0>.  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




     *   Use the “tight infix” mechanism from this (accepted) GHC proposal<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F229&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520752420&sdata=UCCPvDoBPnWdYW6GvmVGA1RxMuXxJnuHMEB5qsbRMlY%3D&reserved=0>

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 at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>>
|  On Behalf Of Joachim Breitner
|  Sent: 30 March 2020 17:48
|  To: ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Forcet.vote%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520762414&sdata=qvWZwZHab3%2Bl%2FO%2B8NNhjQoUdkFZrnytynA6vhf%2BtRgA%3D&reserved=0>%2FVote%2FAB23CE70AC%2F&data=02%7C01%7Csimonpj%40microsoft.c
|  om%7Ce27e9c8f455b436e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7
|  C1%7C0%7C637211837260982595&sdata=LLWCxVjXxyLqcJUZ9iMgB%2B5QYGMuHFzJga
|  u9agTakiQ%3D&reserved=0
|
|  So, does this conclude this saga?
|
|  Cheers,
|  Joachim
|
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
|
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach
|  im-
|  breitner.de<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520772409&sdata=fkEUbbqDLSs4SFvGZ3aL4QCs4nfkH1Ix44Ec7bbFX8g%3D&reserved=0>%2F&data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520782404&sdata=5Mq5i%2Fn98FWwwK8b3ySXY5X6NEiFx8QAl6cgOWDkU3A%3D&reserved=0>%7Ce27e9c8f455b43
|  6e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372118372
|  60982595&sdata=GE%2BBYN7rA7zWgwuKlArv4PR%2Fm3IlmZ7PqWbGpgXUyms%3D&
|  reserved=0
|
|
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
|  kell.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520782404&sdata=7K%2B%2F6daWxe9rrJjsupSB7AtnnQSJfoaJUv2Bvs7ep5g%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&data=02%7C01%7Csimonpj%40microsoft.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520792402&sdata=roywGXR%2Fxe53OFW60wrqvaWqJ57KNjDL5DCkK8YCOv8%3D&reserved=0>%7Ce27e9c8f455b436e2be
|  e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982
|  595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved=
|  0
_______________________________________________
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520802397&sdata=Z3ygxZmFZ9Pwv1zkPijWD8PkUEYaIcd5BnbK3PN3B8I%3D&reserved=0>
_______________________________________________
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cabd695271d33488b3a5008d7d5725f2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212559520802397&sdata=Z3ygxZmFZ9Pwv1zkPijWD8PkUEYaIcd5BnbK3PN3B8I%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200331/1e61c352/attachment-0001.html>

More information about the ghc-steering-committee mailing list