From simonpj at microsoft.com Fri Mar 6 17:59:08 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 6 Mar 2020 17:59:08 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps Message-ID: 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 * I've put up a list of choices for us to vote on here, informed by our most recent email exchanges. The first thing is to ensure that this list is * Complete: no choices that people really want are omitted. * 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Fri Mar 6 18:26:08 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 6 Mar 2020 10:26:08 -0800 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: Seems to cover the cases we've been discussing, so "Aye" from me. On Fri, Mar 6, 2020 at 9:59 AM Simon Peyton Jones via ghc-steering-committee wrote: > 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 > > - I’ve put up a list of choices for us to vote on here > , > informed by our most recent email exchanges. The first thing is to ensure > that this list is > 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 > _______________________________________________ > 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: From bravit111 at gmail.com Fri Mar 6 18:42:47 2020 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Fri, 6 Mar 2020 21:42:47 +0300 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: Aye пт, 6 мар. 2020 г. в 20:59, Simon Peyton Jones via ghc-steering-committee < ghc-steering-committee at haskell.org>: > 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 > > - I’ve put up a list of choices for us to vote on here > , > informed by our most recent email exchanges. The first thing is to ensure > that this list is > 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 > _______________________________________________ > 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: From tomjharding at live.co.uk Fri Mar 6 19:30:18 2020 From: tomjharding at live.co.uk (Tom Harding) Date: Fri, 6 Mar 2020 19:30:18 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: <64B9A496-851F-4F6E-8FF6-E315E2729EE3@live.co.uk> Aye! On 6 Mar 2020, at 17:59, Simon Peyton Jones via ghc-steering-committee > wrote: 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 * I’ve put up a list of choices for us to vote on here, informed by our most recent email exchanges. The first thing is to ensure that this list is * Complete: no choices that people really want are omitted. * 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 _______________________________________________ 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: From eric at seidel.io Sat Mar 7 02:05:19 2020 From: eric at seidel.io (Eric Seidel) Date: Fri, 06 Mar 2020 21:05:19 -0500 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: <64B9A496-851F-4F6E-8FF6-E315E2729EE3@live.co.uk> References: <64B9A496-851F-4F6E-8FF6-E315E2729EE3@live.co.uk> Message-ID: I've made two suggested edits to C5. I'm fairly certain they're both typos, but in the first one > the form "r.x" is precisely like "r . x" is a very different claim from > the form "r.x" is precisely like "r .x" which Joachim and I have advocated. (Though I'm now pretty sympathetic to C6 as well.) On Fri, Mar 6, 2020, at 14:30, Tom Harding wrote: > Aye! > > > On 6 Mar 2020, at 17:59, Simon Peyton Jones via ghc-steering-committee wrote: > > > > 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 > > > * I’ve put up a list of choices for us to vote on here , informed by our most recent email exchanges. The first thing is to ensure that this list is > > 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 > > > _______________________________________________ > > ghc-steering-committee mailing list > > 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 > From mail at joachim-breitner.de Sat Mar 7 11:08:19 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 07 Mar 2020 12:08:19 +0100 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: Hi, I took the liberty of adding the table of explanations also to C2, please check that I did it correctly. Otherwise, Aye. Cheers, Joachim Am Freitag, den 06.03.2020, 17:59 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > 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 > I’ve put up a list of choices for us to vote on here, informed by our most recent email exchanges. The first thing is to ensure that this list is > Complete: no choices that people really want are omitted. > 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 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From marlowsd at gmail.com Mon Mar 9 09:36:39 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 9 Mar 2020 09:36:39 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: On Fri, 6 Mar 2020 at 17:59, Simon Peyton Jones via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > 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 > > - I’ve put up a list of choices for us to vote on here > , > informed by our most recent email exchanges. The first thing is to ensure > that this list is > 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! > > The examples are clear, however I find it hard to extrapolate from the examples to a precise description of the changes to the syntax. What I'd really like to see is something that tells me how the syntax would be specified, for example ". is a new lexeme" or "record selection only applies to tight-infix occurrences of the varsym "."". I'm not asking for a full diff of the lexical syntax, just a sentence or two that makes it clear enough that any of us could fill in the details. This would let us answer questions like: C2 says that .x is illegal, yet later we say that (.x) means (\r -> r.x). How would we reconcile those? Cheers Simon > > 1. > > *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 > _______________________________________________ > 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: From simonpj at microsoft.com Mon Mar 9 09:56:24 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 9 Mar 2020 09:56:24 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: 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 Sent: 06 March 2020 17:59 To: ghc-steering-committee Cc: Simon Peyton Jones 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 * I've put up a list of choices for us to vote on here, informed by our most recent email exchanges. The first thing is to ensure that this list is * Complete: no choices that people really want are omitted. * 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon Mar 9 11:03:36 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 9 Mar 2020 11:03:36 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: I am happy with this list: Aye! > On Mar 9, 2020, at 9:56 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > 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 > Sent: 06 March 2020 17:59 > To: ghc-steering-committee > Cc: Simon Peyton Jones > 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 > > I’ve put up a list of choices for us to vote on here , informed by our most recent email exchanges. The first thing is to ensure that this list is > Complete: no choices that people really want are omitted. > 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 > > _______________________________________________ > 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: From eric at seidel.io Mon Mar 9 13:24:55 2020 From: eric at seidel.io (Eric Seidel) Date: Mon, 09 Mar 2020 09:24:55 -0400 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: I made one more correction to the notes, otherwise Aye! On Mon, Mar 9, 2020, at 07:03, Richard Eisenberg wrote: > I am happy with this list: Aye! > > > On Mar 9, 2020, at 9:56 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > > > 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 > > *Sent:* 06 March 2020 17:59 > > *To:* ghc-steering-committee > > *Cc:* Simon Peyton Jones > > *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 > > > * I’ve put up a list of choices for us to vote on here , informed by our most recent email exchanges. The first thing is to ensure that this list is > > 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 > > > _______________________________________________ > > ghc-steering-committee mailing list > > 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 > From arnaud.spiwack at tweag.io Mon Mar 9 18:22:36 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Mon, 9 Mar 2020 19:22:36 +0100 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: I registered my “Aye” On Mon, Mar 9, 2020 at 2:25 PM Eric Seidel wrote: > I made one more correction to the notes, otherwise Aye! > > On Mon, Mar 9, 2020, at 07:03, Richard Eisenberg wrote: > > I am happy with this list: Aye! > > > > > On Mar 9, 2020, at 9:56 AM, Simon Peyton Jones via > ghc-steering-committee wrote: > > > > > > 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 > > > *Sent:* 06 March 2020 17:59 > > > *To:* ghc-steering-committee > > > *Cc:* Simon Peyton Jones > > > *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 > > > > > * I’ve put up a list of choices for us to vote on here < > 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%7Cdf9d9fcc96344d61da8108d7c1f81154%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637191143491204686&sdata=ScGCAmSEiqXCePZcx03YYQXl08Fc38UC7rWx3Zg%2Fz1o%3D&reserved=0>, > informed by our most recent email exchanges. The first thing is to ensure > that this list is > > > 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 > > > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > 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 > > > _______________________________________________ > 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: From mail at joachim-breitner.de Wed Mar 11 18:36:44 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 11 Mar 2020 19:36:44 +0100 Subject: [ghc-steering-committee] #216: Qualified Do, recommendation: accept Message-ID: <1cef7c1ae13722df4147ae583a866718e07b20dc.camel@joachim-breitner.de> Dear Committe, Proposal: https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/216 Summary: last June we looked at a “local do” proposal that would be a more targetted variant of RebindableSyntax, just for “do”. After an initial acceptance recommendation from me we had some good discussion, and eventually sent it back for revision. One problem, among many, was that the story around type inference wasn’t as good as with normal “do”. All attempts to give meaning to “do” via a local value (e.g. a record, or type classes etc.) were unsatisfying in one way or another. (Often something about mumble impredicative types mumble.) Anyways, Facundo Domínguez joined the author team and the discussion steered towards a less ambitious, but simpler and cleaner proposal: Qualified do. The idea is simply to treat a module qualifier on the do keyword as a qualified on all the implicit : M.do { x <- u; stmts } = (M.>>=) u (\x -> M.do { stmts }) and similar for the other monad desugaring rules. Recommendation: This seems simple, convenient and easy to understand, so I recommend accepting the proposal. Comment: There was some discussion if M.do { return x } = M.return x but it seems that changing the meaning of more than `do` it self may be more confusing than helpful, so the proposal as it stands does _not_ propose it (see Alternatives). I wish we had a better story here, and welcome ideas from the committee. WDYAT? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From iavor.diatchki at gmail.com Wed Mar 11 21:06:40 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 11 Mar 2020 14:06:40 -0700 Subject: [ghc-steering-committee] #216: Qualified Do, recommendation: accept In-Reply-To: <1cef7c1ae13722df4147ae583a866718e07b20dc.camel@joachim-breitner.de> References: <1cef7c1ae13722df4147ae583a866718e07b20dc.camel@joachim-breitner.de> Message-ID: I think that the proposal is reasonable and would support accepting it. On Wed, Mar 11, 2020, 11:37 Joachim Breitner wrote: > Dear Committe, > > Proposal: > > https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst > > Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/216 > > > Summary: > > last June we looked at a “local do” proposal that would be a more > targetted variant of RebindableSyntax, just for “do”. After an initial > acceptance recommendation from me we had some good discussion, and > eventually sent it back for revision. One problem, among many, was that > the story around type inference wasn’t as good as with normal “do”. > > All attempts to give meaning to “do” via a local value (e.g. a record, > or type classes etc.) were unsatisfying in one way or another. (Often > something about mumble impredicative types mumble.) > > Anyways, Facundo Domínguez joined the author team and the discussion > steered towards a less ambitious, but simpler and cleaner proposal: > Qualified do. The idea is simply to treat a module qualifier on the do > keyword as a qualified on all the implicit : > > M.do { x <- u; stmts } = (M.>>=) u (\x -> M.do { stmts }) > > and similar for the other monad desugaring rules. > > > Recommendation: > > This seems simple, convenient and easy to understand, so I recommend > accepting the proposal. > > > Comment: > > There was some discussion if > > M.do { return x } = M.return x > > but it seems that changing the meaning of more than `do` it self may be > more confusing than helpful, so the proposal as it stands does _not_ > propose it (see Alternatives). I wish we had a better story here, and > welcome ideas from the committee. > > > WDYAT? > > > Cheers, > Joachim > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > 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: From bravit111 at gmail.com Thu Mar 12 08:16:20 2020 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Thu, 12 Mar 2020 11:16:20 +0300 Subject: [ghc-steering-committee] #216: Qualified Do, recommendation: accept In-Reply-To: <1cef7c1ae13722df4147ae583a866718e07b20dc.camel@joachim-breitner.de> References: <1cef7c1ae13722df4147ae583a866718e07b20dc.camel@joachim-breitner.de> Message-ID: I support this proposal in the current form. I am especially happy with the idea that the 'M.do' qualifier does not affect the 'return' function. It's just fine to affect implicit constructions exclusively. Vitaly ср, 11 мар. 2020 г. в 21:37, Joachim Breitner : > > Dear Committe, > > Proposal: > https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst > > Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/216 > > > Summary: > > last June we looked at a “local do” proposal that would be a more > targetted variant of RebindableSyntax, just for “do”. After an initial > acceptance recommendation from me we had some good discussion, and > eventually sent it back for revision. One problem, among many, was that > the story around type inference wasn’t as good as with normal “do”. > > All attempts to give meaning to “do” via a local value (e.g. a record, > or type classes etc.) were unsatisfying in one way or another. (Often > something about mumble impredicative types mumble.) > > Anyways, Facundo Domínguez joined the author team and the discussion > steered towards a less ambitious, but simpler and cleaner proposal: > Qualified do. The idea is simply to treat a module qualifier on the do > keyword as a qualified on all the implicit : > > M.do { x <- u; stmts } = (M.>>=) u (\x -> M.do { stmts }) > > and similar for the other monad desugaring rules. > > > Recommendation: > > This seems simple, convenient and easy to understand, so I recommend > accepting the proposal. > > > Comment: > > There was some discussion if > > M.do { return x } = M.return x > > but it seems that changing the meaning of more than `do` it self may be > more confusing than helpful, so the proposal as it stands does _not_ > propose it (see Alternatives). I wish we had a better story here, and > welcome ideas from the committee. > > > WDYAT? > > > Cheers, > Joachim > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From rae at richarde.dev Thu Mar 12 13:42:17 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 12 Mar 2020 13:42:17 +0000 Subject: [ghc-steering-committee] #216: Qualified Do, recommendation: accept In-Reply-To: References: <1cef7c1ae13722df4147ae583a866718e07b20dc.camel@joachim-breitner.de> Message-ID: <5D2AB68B-463A-436E-9A76-0B4669C33802@richarde.dev> Sorry to say that I do not like this proposal in its current form, as I elaborate on GitHub: https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-598191928 Richard > On Mar 12, 2020, at 8:16 AM, Vitaly Bragilevsky wrote: > > I support this proposal in the current form. I am especially happy > with the idea that the 'M.do' qualifier does not affect the 'return' > function. It's just fine to affect implicit constructions exclusively. > > Vitaly > > ср, 11 мар. 2020 г. в 21:37, Joachim Breitner : >> >> Dear Committe, >> >> Proposal: >> https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst >> >> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/216 >> >> >> Summary: >> >> last June we looked at a “local do” proposal that would be a more >> targetted variant of RebindableSyntax, just for “do”. After an initial >> acceptance recommendation from me we had some good discussion, and >> eventually sent it back for revision. One problem, among many, was that >> the story around type inference wasn’t as good as with normal “do”. >> >> All attempts to give meaning to “do” via a local value (e.g. a record, >> or type classes etc.) were unsatisfying in one way or another. (Often >> something about mumble impredicative types mumble.) >> >> Anyways, Facundo Domínguez joined the author team and the discussion >> steered towards a less ambitious, but simpler and cleaner proposal: >> Qualified do. The idea is simply to treat a module qualifier on the do >> keyword as a qualified on all the implicit : >> >> M.do { x <- u; stmts } = (M.>>=) u (\x -> M.do { stmts }) >> >> and similar for the other monad desugaring rules. >> >> >> Recommendation: >> >> This seems simple, convenient and easy to understand, so I recommend >> accepting the proposal. >> >> >> Comment: >> >> There was some discussion if >> >> M.do { return x } = M.return x >> >> but it seems that changing the meaning of more than `do` it self may be >> more confusing than helpful, so the proposal as it stands does _not_ >> propose it (see Alternatives). I wish we had a better story here, and >> welcome ideas from the committee. >> >> >> WDYAT? >> >> >> Cheers, >> Joachim >> >> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> 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: From simonpj at microsoft.com Fri Mar 13 10:38:52 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 13 Mar 2020 10:38:52 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: Chris, Cale, Simon I wonder if you might have a moment to respond to this email? Thanks Simon From: Simon Peyton Jones Sent: 09 March 2020 09:56 To: ghc-steering-committee Cc: Simon Peyton Jones 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 > Sent: 06 March 2020 17:59 To: ghc-steering-committee > Cc: Simon Peyton Jones > 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 * I've put up a list of choices for us to vote on here, informed by our most recent email exchanges. The first thing is to ensure that this list is * Complete: no choices that people really want are omitted. * 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Fri Mar 13 17:29:36 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 13 Mar 2020 17:29:36 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: 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 wrote: > Chris, Cale, Simon > > I wonder if you might have a moment to respond to this email? > > Thanks > > Simon > > > > *From:* Simon Peyton Jones > *Sent:* 09 March 2020 09:56 > *To:* ghc-steering-committee > *Cc:* Simon Peyton Jones > *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 > *Sent:* 06 March 2020 17:59 > *To:* ghc-steering-committee > *Cc:* Simon Peyton Jones > *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 > > - I’ve put up a list of choices for us to vote on here > , > informed by our most recent email exchanges. The first thing is to ensure > that this list is > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Mar 13 17:43:52 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 13 Mar 2020 17:43:52 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: 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 Sent: 13 March 2020 17:30 To: Simon Peyton Jones Cc: Christopher Allen ; Cale Gibbard ; ghc-steering-committee 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 > wrote: Chris, Cale, Simon I wonder if you might have a moment to respond to this email? Thanks Simon From: Simon Peyton Jones > Sent: 09 March 2020 09:56 To: ghc-steering-committee > Cc: Simon Peyton Jones > 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 > Sent: 06 March 2020 17:59 To: ghc-steering-committee > Cc: Simon Peyton Jones > 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 * I’ve put up a list of choices for us to vote on here, informed by our most recent email exchanges. The first thing is to ensure that this list is * Complete: no choices that people really want are omitted. * 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Sat Mar 14 16:21:18 2020 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 14 Mar 2020 11:21:18 -0500 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: <12F5023E-004B-47EF-BBFB-42D5136A0D71@bitemyapp.com> Marked myself AYE for the choices. > On Mar 13, 2020, at 12:43 PM, Simon Peyton Jones 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 > Sent: 13 March 2020 17:30 > To: Simon Peyton Jones > Cc: Christopher Allen ; Cale Gibbard ; ghc-steering-committee > 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 > wrote: > > Chris, Cale, Simon > I wonder if you might have a moment to respond to this email? > Thanks > Simon > > From: Simon Peyton Jones > > Sent: 09 March 2020 09:56 > To: ghc-steering-committee > > Cc: Simon Peyton Jones > > 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 > > Sent: 06 March 2020 17:59 > To: ghc-steering-committee > > Cc: Simon Peyton Jones > > 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 > I’ve put up a list of choices for us to vote on here , informed by our most recent email exchanges. The first thing is to ensure that this list is > Complete: no choices that people really want are omitted. > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgibbard at gmail.com Sun Mar 15 02:31:53 2020 From: cgibbard at gmail.com (Cale Gibbard) Date: Sat, 14 Mar 2020 22:31:53 -0400 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: <12F5023E-004B-47EF-BBFB-42D5136A0D71@bitemyapp.com> References: <12F5023E-004B-47EF-BBFB-42D5136A0D71@bitemyapp.com> Message-ID: I registered my "aye" as well, but I'd just like to reiterate that I think the language is already hard enough for beginners and experts alike to parse. The fact that all of these options are probably what *someone* would intuitively expect and that there are so many axes along which we're not sure how to disambiguate various expressions seems like a strong signal that this whole thing is ill-advised. If this makes its way into GHC, it'll be banned where I work for being much too confusing and unnecessary, but that still won't absolve us of needing to deal with it, as it'll much harder to guarantee that none of our dependencies will ever start using it. Actually, I just changed my mind, maybe there's one other option that should make it in as a second option in case we're unable to kill this proposal: none of the ambiguous expressions that are taken as examples there is valid. Take the record-selection-dot to be at the same level of precedence as function application, and therefore it must be parenthesized when used alongside function applications. I still don't like the proposal with that option, but it's better than C2-C6. Should we add it? On Sat, 14 Mar 2020 at 12:21, Christopher Allen wrote: > > Marked myself AYE for the choices. > > On Mar 13, 2020, at 12:43 PM, Simon Peyton Jones 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 > Sent: 13 March 2020 17:30 > To: Simon Peyton Jones > Cc: Christopher Allen ; Cale Gibbard ; ghc-steering-committee > 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 wrote: > > Chris, Cale, Simon > I wonder if you might have a moment to respond to this email? > Thanks > Simon > > From: Simon Peyton Jones > Sent: 09 March 2020 09:56 > To: ghc-steering-committee > Cc: Simon Peyton Jones > 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 > Sent: 06 March 2020 17:59 > To: ghc-steering-committee > Cc: Simon Peyton Jones > 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 > > I’ve put up a list of choices for us to vote on here, informed by our most recent email exchanges. The first thing is to ensure that this list is > > Complete: no choices that people really want are omitted. > 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 > > From trupill at gmail.com Sun Mar 15 10:10:11 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Sun, 15 Mar 2020 11:10:11 +0100 Subject: [ghc-steering-committee] #216: Qualified Do, recommendation: accept In-Reply-To: <5D2AB68B-463A-436E-9A76-0B4669C33802@richarde.dev> References: <1cef7c1ae13722df4147ae583a866718e07b20dc.camel@joachim-breitner.de> <5D2AB68B-463A-436E-9A76-0B4669C33802@richarde.dev> Message-ID: I've added some more comments in the GitHub repo. TL;DR: I like the current proposal because it's an easy term-to-term translation, instead of more complex approaches which involve type checking. However, I don't know whether we should go through the "module + arguments" route, or the "builder" route. El jue., 12 mar. 2020 a las 14:42, Richard Eisenberg () escribió: > Sorry to say that I do not like this proposal in its current form, as I > elaborate on GitHub: > > https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-598191928 > > Richard > > On Mar 12, 2020, at 8:16 AM, Vitaly Bragilevsky > wrote: > > I support this proposal in the current form. I am especially happy > with the idea that the 'M.do' qualifier does not affect the 'return' > function. It's just fine to affect implicit constructions exclusively. > > Vitaly > > ср, 11 мар. 2020 г. в 21:37, Joachim Breitner : > > > Dear Committe, > > Proposal: > > https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst > > Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/216 > > > Summary: > > last June we looked at a “local do” proposal that would be a more > targetted variant of RebindableSyntax, just for “do”. After an initial > acceptance recommendation from me we had some good discussion, and > eventually sent it back for revision. One problem, among many, was that > the story around type inference wasn’t as good as with normal “do”. > > All attempts to give meaning to “do” via a local value (e.g. a record, > or type classes etc.) were unsatisfying in one way or another. (Often > something about mumble impredicative types mumble.) > > Anyways, Facundo Domínguez joined the author team and the discussion > steered towards a less ambitious, but simpler and cleaner proposal: > Qualified do. The idea is simply to treat a module qualifier on the do > keyword as a qualified on all the implicit : > > M.do { x <- u; stmts } = (M.>>=) u (\x -> M.do { stmts }) > > and similar for the other monad desugaring rules. > > > Recommendation: > > This seems simple, convenient and easy to understand, so I recommend > accepting the proposal. > > > Comment: > > There was some discussion if > > M.do { return x } = M.return x > > but it seems that changing the meaning of more than `do` it self may be > more confusing than helpful, so the proposal as it stands does _not_ > propose it (see Alternatives). I wish we had a better story here, and > welcome ideas from the committee. > > > WDYAT? > > > Cheers, > Joachim > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > 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 > > > _______________________________________________ > 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: From trupill at gmail.com Sun Mar 15 10:27:27 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Sun, 15 Mar 2020 11:27:27 +0100 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: <12F5023E-004B-47EF-BBFB-42D5136A0D71@bitemyapp.com> Message-ID: I've been thinking a bit more about the list of choices. First of all, I agree with the spirit of Cale's last comment: having so many "natural" possibilities means that none of them are really "natural". In fact, I found some variation of choice 2b which I feel as "natural" and "useful". I support making .x illegal, but allowing (.x) as a section. The problem is that that does not allow nested record queries, as in (.name.first), which I think is where the strength of this proposal comes from (otherwise, which not just use `x` since it's already a field selector?). Apart from that, I think that we should ban any other possibly-ambiguous choice, by making more use of the "tight operator" rule. I don't think losing the ability to write selector accross multiple lines is so terrible compared to being puzzled about `f r.x` not parsing as `f (r.x)`. Alejandro El dom., 15 mar. 2020 a las 3:32, Cale Gibbard () escribió: > I registered my "aye" as well, but I'd just like to reiterate that I > think the language is already hard enough for beginners and experts > alike to parse. The fact that all of these options are probably what > *someone* would intuitively expect and that there are so many axes > along which we're not sure how to disambiguate various expressions > seems like a strong signal that this whole thing is ill-advised. > > If this makes its way into GHC, it'll be banned where I work for being > much too confusing and unnecessary, but that still won't absolve us of > needing to deal with it, as it'll much harder to guarantee that none > of our dependencies will ever start using it. > > Actually, I just changed my mind, maybe there's one other option that > should make it in as a second option in case we're unable to kill this > proposal: none of the ambiguous expressions that are taken as examples > there is valid. Take the record-selection-dot to be at the same level > of precedence as function application, and therefore it must be > parenthesized when used alongside function applications. I still don't > like the proposal with that option, but it's better than C2-C6. > > Should we add it? > > On Sat, 14 Mar 2020 at 12:21, Christopher Allen wrote: > > > > Marked myself AYE for the choices. > > > > On Mar 13, 2020, at 12:43 PM, Simon Peyton Jones > 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 > > Sent: 13 March 2020 17:30 > > To: Simon Peyton Jones > > Cc: Christopher Allen ; Cale Gibbard < > cgibbard at gmail.com>; ghc-steering-committee < > ghc-steering-committee at 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 > wrote: > > > > Chris, Cale, Simon > > I wonder if you might have a moment to respond to this email? > > Thanks > > Simon > > > > From: Simon Peyton Jones > > Sent: 09 March 2020 09:56 > > To: ghc-steering-committee > > Cc: Simon Peyton Jones > > 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 > > Sent: 06 March 2020 17:59 > > To: ghc-steering-committee > > Cc: Simon Peyton Jones > > 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 > > > > I’ve put up a list of choices for us to vote on here, informed by our > most recent email exchanges. The first thing is to ensure that this list is > > > > Complete: no choices that people really want are omitted. > > 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 > > > > > _______________________________________________ > 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: From marlowsd at gmail.com Sun Mar 15 13:21:50 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Sun, 15 Mar 2020 13:21:50 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: 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 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 > *Sent:* 13 March 2020 17:30 > *To:* Simon Peyton Jones > *Cc:* Christopher Allen ; Cale Gibbard < > cgibbard at gmail.com>; ghc-steering-committee < > ghc-steering-committee at 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 > wrote: > > Chris, Cale, Simon > > I wonder if you might have a moment to respond to this email? > > Thanks > > Simon > > > > *From:* Simon Peyton Jones > *Sent:* 09 March 2020 09:56 > *To:* ghc-steering-committee > *Cc:* Simon Peyton Jones > *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 > *Sent:* 06 March 2020 17:59 > *To:* ghc-steering-committee > *Cc:* Simon Peyton Jones > *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 > > - I’ve put up a list of choices for us to vote on here > , > informed by our most recent email exchanges. The first thing is to ensure > that this list is > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Mar 16 14:28:07 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 16 Mar 2020 14:28:07 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: <12F5023E-004B-47EF-BBFB-42D5136A0D71@bitemyapp.com> Message-ID: | Actually, I just changed my mind, maybe there's one other option that | should make it in as a second option in case we're unable to kill this | proposal: none of the ambiguous expressions that are taken as examples | there is valid. Take the record-selection-dot to be at the same level | of precedence as function application, and therefore it must be | parenthesized when used alongside function applications. Cale, if you'd like to add (C7) by all means do so. But I'm not clear what you have in mind. I understand that all the examples in (C2-6) would be illegal. But what about r .x .y r.x.y r .x.y r.x .y I think you intend that all these would be illegal f r.x f r .x r .x y So somehow postfix record selection has the same precedence as function application, and is left-associative with itself, but is non-associative with function application. That's a new concept. I suspect what you intend is that naked .x is illegal altogether, except in parens, thus (.x). So you would allow r.x.y as a single lexeme, but not have any of this postfix operator stuff. Would you like to add C7 so we all vote for the same thing? Or not -- it's up to you. Thanks Simon | -----Original Message----- | From: Cale Gibbard | Sent: 15 March 2020 02:32 | To: Christopher Allen | Cc: Simon Peyton Jones ; Simon Marlow | ; ghc-steering-committee | Subject: Re: RecordDotSyntax proposal: next steps | | I registered my "aye" as well, but I'd just like to reiterate that I | think the language is already hard enough for beginners and experts | alike to parse. The fact that all of these options are probably what | *someone* would intuitively expect and that there are so many axes | along which we're not sure how to disambiguate various expressions | seems like a strong signal that this whole thing is ill-advised. | | If this makes its way into GHC, it'll be banned where I work for being | much too confusing and unnecessary, but that still won't absolve us of | needing to deal with it, as it'll much harder to guarantee that none | of our dependencies will ever start using it. | | Actually, I just changed my mind, maybe there's one other option that | should make it in as a second option in case we're unable to kill this | proposal: none of the ambiguous expressions that are taken as examples | there is valid. Take the record-selection-dot to be at the same level | of precedence as function application, and therefore it must be | parenthesized when used alongside function applications. I still don't | like the proposal with that option, but it's better than C2-C6. | | Should we add it? | | On Sat, 14 Mar 2020 at 12:21, Christopher Allen wrote: | > | > Marked myself AYE for the choices. | > | > On Mar 13, 2020, at 12:43 PM, Simon Peyton Jones | 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 | > Sent: 13 March 2020 17:30 | > To: Simon Peyton Jones | > Cc: Christopher Allen ; Cale Gibbard | ; ghc-steering-committee | > 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 | wrote: | > | > Chris, Cale, Simon | > I wonder if you might have a moment to respond to this email? | > Thanks | > Simon | > | > From: Simon Peyton Jones | > Sent: 09 March 2020 09:56 | > To: ghc-steering-committee | > Cc: Simon Peyton Jones | > 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 | > Sent: 06 March 2020 17:59 | > To: ghc-steering-committee | > Cc: Simon Peyton Jones | > 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 | > | > I’ve put up a list of choices for us to vote on here, informed by our | most recent email exchanges. The first thing is to ensure that this list | is | > | > Complete: no choices that people really want are omitted. | > 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 | > | > From simonpj at microsoft.com Mon Mar 16 14:43:28 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 16 Mar 2020 14:43:28 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: 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. I agree with that in principle, but I don’t want to ask the authors to work up 6 or 7 different full syntaxes, just to us to accept at most one. If it turns that the one we accept (if indeed we accept any) is hard to define, let’s revisit. * Is (.a.b) legal? Under which alternatives? What about (.a .b)? What about (. .x)? I have added some new words to clarify lexical syntax, which should answer your question. Please say if not. * Does ( .x) mean (.x) or (. x)? Same as any other operator like (+). You can write (+ ) or ( +) or (+) or ( + ). But since (. x) has lexeme for “.” and one for “x”, that’s different. See the new words. * I presume under C2a things like 3.x, "abc".y, and [1,2,3].z would be legal… One of the great disadvantages of C2a and C3 is the awkwardness of defining tight infix for dot. See Note 4. * data R = R { (.) :: Int } This is a good point which applies to the entire proposal. It needs to be addressed. But it’s very much a corner case, and we should not let the tail wag the dog. * Can I use a record selector infix by surrounding it with ``? i.e. is `.x` a legal infix operator? (I'm guessing not) You can clearly say `(.x)`. I would guess that you can’t omit the parens. Again, should ultimately be nailed down but doesn’t really affect our decision making. Do the clarifications in the document allow you enough clarity to make an informed choice? Simon From: Simon Marlow Sent: 15 March 2020 13:22 To: Simon Peyton Jones Cc: Christopher Allen ; Cale Gibbard ; ghc-steering-committee Subject: Re: RecordDotSyntax proposal: next steps 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 > 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 > Sent: 13 March 2020 17:30 To: Simon Peyton Jones > Cc: Christopher Allen >; Cale Gibbard >; ghc-steering-committee > 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 > wrote: Chris, Cale, Simon I wonder if you might have a moment to respond to this email? Thanks Simon From: Simon Peyton Jones > Sent: 09 March 2020 09:56 To: ghc-steering-committee > Cc: Simon Peyton Jones > 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 > Sent: 06 March 2020 17:59 To: ghc-steering-committee > Cc: Simon Peyton Jones > 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 * I’ve put up a list of choices for us to vote on here, informed by our most recent email exchanges. The first thing is to ensure that this list is * Complete: no choices that people really want are omitted. * 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgibbard at gmail.com Mon Mar 16 14:55:59 2020 From: cgibbard at gmail.com (Cale Gibbard) Date: Mon, 16 Mar 2020 10:55:59 -0400 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: <12F5023E-004B-47EF-BBFB-42D5136A0D71@bitemyapp.com> Message-ID: On Mon, 16 Mar 2020 at 10:28, Simon Peyton Jones wrote: > > | Actually, I just changed my mind, maybe there's one other option that > | should make it in as a second option in case we're unable to kill this > | proposal: none of the ambiguous expressions that are taken as examples > | there is valid. Take the record-selection-dot to be at the same level > | of precedence as function application, and therefore it must be > | parenthesized when used alongside function applications. > > Cale, if you'd like to add (C7) by all means do so. But I'm not clear what you have in mind. I understand that all the examples in (C2-6) would be illegal. But what about > > r .x .y > r.x.y > r .x.y > r.x .y Of those, I think only r.x.y should be legal, as I can't guess what the rest would mean. Of course, you could add parens in various ways: (r.x) (.y) would be a valid function application of the function (r.x) to the record selection section (.y) r (.x) (.y) would be a function application of the function r to the arguments (.x) and (.y) which are record selection sections. r (.x.y) I'm not sure about whether to allow, but if so, it's a function application equivalent to r (\t -> t.x.y) > I think you intend that all these would be illegal > f r.x > f r .x > r .x y > > So somehow postfix record selection has the same precedence as function application, and is left-associative with itself, but is non-associative with function application. That's a new concept. > > I suspect what you intend is that naked .x is illegal altogether, except in parens, thus (.x). So you would allow > r.x.y > as a single lexeme, but not have any of this postfix operator stuff. Yes. > Would you like to add C7 so we all vote for the same thing? Or not -- it's up to you. Doing so now :) > Thanks > > Simon > > | -----Original Message----- > | From: Cale Gibbard > | Sent: 15 March 2020 02:32 > | To: Christopher Allen > | Cc: Simon Peyton Jones ; Simon Marlow > | ; ghc-steering-committee | committee at haskell.org> > | Subject: Re: RecordDotSyntax proposal: next steps > | > | I registered my "aye" as well, but I'd just like to reiterate that I > | think the language is already hard enough for beginners and experts > | alike to parse. The fact that all of these options are probably what > | *someone* would intuitively expect and that there are so many axes > | along which we're not sure how to disambiguate various expressions > | seems like a strong signal that this whole thing is ill-advised. > | > | If this makes its way into GHC, it'll be banned where I work for being > | much too confusing and unnecessary, but that still won't absolve us of > | needing to deal with it, as it'll much harder to guarantee that none > | of our dependencies will ever start using it. > | > | Actually, I just changed my mind, maybe there's one other option that > | should make it in as a second option in case we're unable to kill this > | proposal: none of the ambiguous expressions that are taken as examples > | there is valid. Take the record-selection-dot to be at the same level > | of precedence as function application, and therefore it must be > | parenthesized when used alongside function applications. I still don't > | like the proposal with that option, but it's better than C2-C6. > | > | Should we add it? > | > | On Sat, 14 Mar 2020 at 12:21, Christopher Allen wrote: > | > > | > Marked myself AYE for the choices. > | > > | > On Mar 13, 2020, at 12:43 PM, Simon Peyton Jones > | 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 > | > Sent: 13 March 2020 17:30 > | > To: Simon Peyton Jones > | > Cc: Christopher Allen ; Cale Gibbard > | ; ghc-steering-committee | committee at 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 > | wrote: > | > > | > Chris, Cale, Simon > | > I wonder if you might have a moment to respond to this email? > | > Thanks > | > Simon > | > > | > From: Simon Peyton Jones > | > Sent: 09 March 2020 09:56 > | > To: ghc-steering-committee > | > Cc: Simon Peyton Jones > | > 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 > | > Sent: 06 March 2020 17:59 > | > To: ghc-steering-committee > | > Cc: Simon Peyton Jones > | > 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 > | > > | > I’ve put up a list of choices for us to vote on here, informed by our > | most recent email exchanges. The first thing is to ensure that this list > | is > | > > | > Complete: no choices that people really want are omitted. > | > 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 > | > > | > From simonpj at microsoft.com Mon Mar 16 16:59:57 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 16 Mar 2020 16:59:57 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: <12F5023E-004B-47EF-BBFB-42D5136A0D71@bitemyapp.com> Message-ID: Thanks Cale. You’ve made helpful clarifications on the Google doc. I think I understand the proposal now. Simon | -----Original Message----- | From: Cale Gibbard | Sent: 16 March 2020 14:56 | To: Simon Peyton Jones | Cc: Christopher Allen ; Simon Marlow | ; ghc-steering-committee | Subject: Re: RecordDotSyntax proposal: next steps | | On Mon, 16 Mar 2020 at 10:28, Simon Peyton Jones | wrote: | > | > | Actually, I just changed my mind, maybe there's one other option | that | > | should make it in as a second option in case we're unable to kill | this | > | proposal: none of the ambiguous expressions that are taken as | examples | > | there is valid. Take the record-selection-dot to be at the same | level | > | of precedence as function application, and therefore it must be | > | parenthesized when used alongside function applications. | > | > Cale, if you'd like to add (C7) by all means do so. But I'm not | clear what you have in mind. I understand that all the examples in | (C2-6) would be illegal. But what about | > | > r .x .y | > r.x.y | > r .x.y | > r.x .y | | Of those, I think only r.x.y should be legal, as I can't guess what | the rest would mean. Of course, you could add parens in various ways: | | (r.x) (.y) would be a valid function application of the function (r.x) | to the record selection section (.y) | | r (.x) (.y) would be a function application of the function r to the | arguments (.x) and (.y) which are record selection sections. | | r (.x.y) I'm not sure about whether to allow, but if so, it's a | function application equivalent to r (\t -> t.x.y) | | > I think you intend that all these would be illegal | > f r.x | > f r .x | > r .x y | > | > So somehow postfix record selection has the same precedence as | function application, and is left-associative with itself, but is non- | associative with function application. That's a new concept. | > | > I suspect what you intend is that naked .x is illegal altogether, | except in parens, thus (.x). So you would allow | > r.x.y | > as a single lexeme, but not have any of this postfix operator stuff. | | Yes. | | > Would you like to add C7 so we all vote for the same thing? Or not | -- it's up to you. | | Doing so now :) | | > Thanks | > | > Simon | > | > | -----Original Message----- | > | From: Cale Gibbard | > | Sent: 15 March 2020 02:32 | > | To: Christopher Allen | > | Cc: Simon Peyton Jones ; Simon Marlow | > | ; ghc-steering-committee | committee at haskell.org> | > | Subject: Re: RecordDotSyntax proposal: next steps | > | | > | I registered my "aye" as well, but I'd just like to reiterate | that I | > | think the language is already hard enough for beginners and | experts | > | alike to parse. The fact that all of these options are probably | what | > | *someone* would intuitively expect and that there are so many | axes | > | along which we're not sure how to disambiguate various | expressions | > | seems like a strong signal that this whole thing is ill-advised. | > | | > | If this makes its way into GHC, it'll be banned where I work for | being | > | much too confusing and unnecessary, but that still won't absolve | us of | > | needing to deal with it, as it'll much harder to guarantee that | none | > | of our dependencies will ever start using it. | > | | > | Actually, I just changed my mind, maybe there's one other option | that | > | should make it in as a second option in case we're unable to kill | this | > | proposal: none of the ambiguous expressions that are taken as | examples | > | there is valid. Take the record-selection-dot to be at the same | level | > | of precedence as function application, and therefore it must be | > | parenthesized when used alongside function applications. I still | don't | > | like the proposal with that option, but it's better than C2-C6. | > | | > | Should we add it? | > | | > | On Sat, 14 Mar 2020 at 12:21, Christopher Allen | wrote: | > | > | > | > Marked myself AYE for the choices. | > | > | > | > On Mar 13, 2020, at 12:43 PM, Simon Peyton Jones | | > | 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 | > | > Sent: 13 March 2020 17:30 | > | > To: Simon Peyton Jones | > | > Cc: Christopher Allen ; Cale Gibbard | > | ; ghc-steering-committee | committee at 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 | | > | wrote: | > | > | > | > Chris, Cale, Simon | > | > I wonder if you might have a moment to respond to this email? | > | > Thanks | > | > Simon | > | > | > | > From: Simon Peyton Jones | > | > Sent: 09 March 2020 09:56 | > | > To: ghc-steering-committee | > | > Cc: Simon Peyton Jones | > | > 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 | > | > Sent: 06 March 2020 17:59 | > | > To: ghc-steering-committee | > | > Cc: Simon Peyton Jones | > | > 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 | > | > | > | > I’ve put up a list of choices for us to vote on here, informed | by our | > | most recent email exchanges. The first thing is to ensure that | this list | > | is | > | > | > | > Complete: no choices that people really want are omitted. | > | > 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 | > | > | > | > From marlowsd at gmail.com Tue Mar 17 13:31:25 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 17 Mar 2020 13:31:25 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: Should the text "except when parenthesised (.x)" in C2b also be added to C2a? Note 5 should apply to C7 too, now? On Mon, 16 Mar 2020 at 14:43, Simon Peyton Jones wrote: > 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. > > I agree with that in principle, but I don’t want to ask the authors to > work up 6 or 7 different full syntaxes, just to us to accept at most one. > If it turns that the one we accept (if indeed we accept any) is hard to > define, let’s revisit. > OK, sounds reasonable. > > - Is (.a.b) legal? Under which alternatives? What about (.a .b)? What > about (. .x)? > > I have added some new words to clarify lexical syntax, which should answer > your question. Please say if not. > > - Does ( .x) mean (.x) or (. x)? > > Same as any other operator like (+). You can write (+ ) or ( +) or (+) or > ( + ). But since (. x) has lexeme for “.” and one for “x”, that’s > different. See the new words. > > - I presume under C2a things like 3.x, "abc".y, and [1,2,3].z would be > legal… > > One of the great disadvantages of C2a and C3 is the awkwardness of > defining tight infix for dot. See Note 4. > > - data R = R { (.) :: Int } This is a good point which applies to > the entire proposal. It needs to be addressed. But it’s very much a > corner case, and we should not let the tail wag the dog. > > OK. But the misdesign of qualified identifiers led to the situation where no Haskell compiler conforms to the spec, since the spec is silly (eg. the spec says M... lexes as the two lexemes M.. .). We should strive to avoid making that situation worse. > > - > - Can I use a record selector infix by surrounding it with ``? i.e. is > `.x` a legal infix operator? (I'm guessing not) > > You can clearly say `(.x)`. I would guess that you can’t omit the > parens. Again, should ultimately be nailed down but doesn’t really affect > our decision making. > Really? You can't say `(+)` right now in Haskell, so it would be surprising if you could say `(.x)` > Do the clarifications in the document allow you enough clarity to make an > informed choice? > Kind of :) I'm happy to proceed on the basis that we're choosing high-level direction and the details will be worked out later, but it may be that some or all of these proposals lead to significant ugliness in their full specification. Cheers Simon > > > Simon > > > > > > *From:* Simon Marlow > *Sent:* 15 March 2020 13:22 > *To:* Simon Peyton Jones > *Cc:* Christopher Allen ; Cale Gibbard < > cgibbard at gmail.com>; ghc-steering-committee < > ghc-steering-committee at haskell.org> > *Subject:* Re: RecordDotSyntax proposal: next steps > > > > 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 > 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 > *Sent:* 13 March 2020 17:30 > *To:* Simon Peyton Jones > *Cc:* Christopher Allen ; Cale Gibbard < > cgibbard at gmail.com>; ghc-steering-committee < > ghc-steering-committee at 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 > wrote: > > Chris, Cale, Simon > > I wonder if you might have a moment to respond to this email? > > Thanks > > Simon > > > > *From:* Simon Peyton Jones > *Sent:* 09 March 2020 09:56 > *To:* ghc-steering-committee > *Cc:* Simon Peyton Jones > *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 > *Sent:* 06 March 2020 17:59 > *To:* ghc-steering-committee > *Cc:* Simon Peyton Jones > *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 > > - I’ve put up a list of choices for us to vote on here > , > informed by our most recent email exchanges. The first thing is to ensure > that this list is > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Mar 17 15:53:26 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 17 Mar 2020 15:53:26 +0000 Subject: [ghc-steering-committee] RecordDotSyntax proposal: next steps In-Reply-To: References: Message-ID: Should the text "except when parenthesised (.x)" in C2b also be added to C2a? Note 5 should apply to C7 too, now? Yes to both. Thanks. Re Note 5, I’d like to point you all to this part of the proposal, which I had previously missed entirely. It describes how to use SrcSpan in the parser to decide if two lexemes are juxtaposed with no white space whatsoever. I think that’s a pretty interesting thought. For example, we might be able to use it to parse qualified names, rather than have complicated rules in the lexer. But meanwhile, it’s a decent response to Note 5. I think we have all AYEs. Don’t vote yet – I want to review the slate first. Simon From: Simon Marlow Sent: 17 March 2020 13:31 To: Simon Peyton Jones Cc: Christopher Allen ; Cale Gibbard ; ghc-steering-committee Subject: Re: RecordDotSyntax proposal: next steps Should the text "except when parenthesised (.x)" in C2b also be added to C2a? Note 5 should apply to C7 too, now? On Mon, 16 Mar 2020 at 14:43, Simon Peyton Jones > wrote: 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. I agree with that in principle, but I don’t want to ask the authors to work up 6 or 7 different full syntaxes, just to us to accept at most one. If it turns that the one we accept (if indeed we accept any) is hard to define, let’s revisit. OK, sounds reasonable. * Is (.a.b) legal? Under which alternatives? What about (.a .b)? What about (. .x)? I have added some new words to clarify lexical syntax, which should answer your question. Please say if not. * Does ( .x) mean (.x) or (. x)? Same as any other operator like (+). You can write (+ ) or ( +) or (+) or ( + ). But since (. x) has lexeme for “.” and one for “x”, that’s different. See the new words. * I presume under C2a things like 3.x, "abc".y, and [1,2,3].z would be legal… One of the great disadvantages of C2a and C3 is the awkwardness of defining tight infix for dot. See Note 4. * data R = R { (.) :: Int } This is a good point which applies to the entire proposal. It needs to be addressed. But it’s very much a corner case, and we should not let the tail wag the dog. OK. But the misdesign of qualified identifiers led to the situation where no Haskell compiler conforms to the spec, since the spec is silly (eg. the spec says M... lexes as the two lexemes M.. .). We should strive to avoid making that situation worse. * * Can I use a record selector infix by surrounding it with ``? i.e. is `.x` a legal infix operator? (I'm guessing not) You can clearly say `(.x)`. I would guess that you can’t omit the parens. Again, should ultimately be nailed down but doesn’t really affect our decision making. Really? You can't say `(+)` right now in Haskell, so it would be surprising if you could say `(.x)` Do the clarifications in the document allow you enough clarity to make an informed choice? Kind of :) I'm happy to proceed on the basis that we're choosing high-level direction and the details will be worked out later, but it may be that some or all of these proposals lead to significant ugliness in their full specification. Cheers Simon Simon From: Simon Marlow > Sent: 15 March 2020 13:22 To: Simon Peyton Jones > Cc: Christopher Allen >; Cale Gibbard >; ghc-steering-committee > Subject: Re: RecordDotSyntax proposal: next steps 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 > 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 > Sent: 13 March 2020 17:30 To: Simon Peyton Jones > Cc: Christopher Allen >; Cale Gibbard >; ghc-steering-committee > 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 > wrote: Chris, Cale, Simon I wonder if you might have a moment to respond to this email? Thanks Simon From: Simon Peyton Jones > Sent: 09 March 2020 09:56 To: ghc-steering-committee > Cc: Simon Peyton Jones > 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 > Sent: 06 March 2020 17:59 To: ghc-steering-committee > Cc: Simon Peyton Jones > 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 * I’ve put up a list of choices for us to vote on here, informed by our most recent email exchanges. The first thing is to ensure that this list is * Complete: no choices that people really want are omitted. * 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Mar 18 16:20:42 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 18 Mar 2020 17:20:42 +0100 Subject: [ghc-steering-committee] #216: Qualified Do, recommendation: accept In-Reply-To: <1cef7c1ae13722df4147ae583a866718e07b20dc.camel@joachim-breitner.de> References: <1cef7c1ae13722df4147ae583a866718e07b20dc.camel@joachim-breitner.de> Message-ID: Hi, Am Mittwoch, den 11.03.2020, 19:36 +0100 schrieb Joachim Breitner: > Dear Committe, > > Proposal: > https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst > > Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/216 more discussion ensued, back to “under discussion”. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Thu Mar 19 11:33:30 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 19 Mar 2020 11:33:30 +0000 Subject: [ghc-steering-committee] Record dot syntax: time to vote Message-ID: Colleagues Now that we have agreed a set of alternatives on using dot notation for records, let's vote. We all recognise and respect that syntactic choices are a judgement call, and that reasonable people may diff in their judgements. But we need to come to as resolution and voting is a good way to do that. Please put your votes on the Google doc. I've make a section for that at the end. The document is here. Just write down your preferences, in order, preferred ones first. Joachim runs an election algorithm that makes it worth specifying a total order on all options, including ones you don't like. For any you omit, you are saying "if these ones are the top contenders I have no preference between them". You can specify ties, again meaning "no preference between these". For the over-interested, the algorithm is Condorcet; in the unlikely case that it does not produce a winner, we revert to Schultze Please read the document, including the Notes, carefully! We have ended up with a lot of variations, and their numbering is historical not logical. (I considered renumbering but thought that would be more confusing than helpful.) As the shepherd I am supposed to make a recommendation; it is below. Simon Shepherd's recommendations Here is my recommendation: C6 > C2b > C3 > C2a > C7 > C4 > C5 > C1 I recommend acceptance Overall, I strongly urge that we accept the proposal in some form; that is, we should not do (C1). 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<%5d(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.) I really think this change has vastly higher impact and utility than many other accepted proposals. I know that some members of the committee differ from this view; that's fair enough. Alternatives I like: * I urge us to adopt (C6). I really really want (f M.N.x) to parse the same as (f M.n.x), where the only difference is the capitalisation of the second-last element of M.n.x. I'm leaning strongly on the connection with qualified names. We already have qualified names, and they are incredibly useful. Qualified names already treat "." specially. Moreover the proposal uses "." in precisely the same way as qualified names: a qualified name M.x allows you to pick x from the module M; this proposal allows r.x to pick a field x from a value r. I like this uniformity of both concept and syntax. * (C2b) is a weakened form of (C6) that does not allow naked selectors, thus (f .x) where there is a space before the ".". I don't see any difficulty with the postfix operator story, so I prefer (C6). But (C2b) is a little more conservative. Alternatives I actively dislike: * I urge against (C1) as I say above. * I dislike (C5) strongly, because it makes (f M.N.x) parse completely differently from (f M.n.x). The authors of the proposal say that they would withdraw the proposal outright (or at least disassociate themselves) if we adopted (C5). * I dislike (C7) for the same reason: (f M.N.x) is legal but (f M.n.x) is not. * I dislike (C4) because nothing should bind more tightly than function application. I hate that (f r .x s .y) would mean (f (r.x) (s.y)). Yes, we already have that (f r {x=2}) means (f (r {x=2})), but I think that's terrible, and we should not perpetuate it. Alternatives in the middle * (C2a) and (C3) are just like (C2b) and (C6), but additionally allow a tightly-binding record selection after a parenthesised expression. Thus (f (g x).y) means (f ((g x).y)). Allowing this is a bit tricky to specify, and the link to qualified names is much weaker. I don't think it pays its way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Mar 19 13:19:37 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 19 Mar 2020 14:19:37 +0100 Subject: [ghc-steering-committee] Record dot syntax: time to vote In-Reply-To: References: Message-ID: Hi, Am Donnerstag, den 19.03.2020, 11:33 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > For any you omit, you are saying "if these ones are the top > contenders I have no preference between them". Please don’t omit any, that’s just confusing. If you can’t be bothered to write a bunch of the out, at least write * or something. @Chris, you write “C1 (and that’s it)”. I assume that means C1 > *. But assume that C1 was _not_ on the table? Do you _really_ have no opinion about the others? You can rank all the others, below C1, without making C1 any less likely! Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From cgibbard at gmail.com Thu Mar 19 22:40:51 2020 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu, 19 Mar 2020 18:40:51 -0400 Subject: [ghc-steering-committee] Record dot syntax: time to vote In-Reply-To: References: Message-ID: On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via ghc-steering-committee wrote: > Overall, I strongly urge that we accept the proposal in some form; that is, we should not do (C1). 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. I'm not sure any of these proposed options feels "obviously right" either. The fact that we're voting between many different ways to interpret the same syntax sugar should make it clear that this isn't so obvious. > But there was incremental progress, sketched here: > > 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.) > > I really think this change has vastly higher impact and utility than many other accepted proposals. I know that some members of the committee differ from this view; that's fair enough. While I'd agree it has vastly higher impact that a lot of accepted proposals, I'm not sure that impact is actually in the direction of making it easier to read and understand programs that are written in Haskell. It's syntactic sugar that we've pretty reasonably done without for a long time. Piling on yet another option for how to select fields from records amidst a sea of libraries that already help with this in various ways that go far beyond the capabilities of the syntax sugar that's proposed here seems a bit strange to me at this point. It feels like the complaint is "but I want to type exactly this string of characters and no other will do", which seems kind of absurd to me, but other languages exist in the world, and DAML for instance is a thing which exists now and should satisfy those people. I don't particularly get why it's of great importance for Haskell to support accessing fields with *this* syntax, and not dozens of almost-equivalent syntaxes that one could already achieve. If there were no confusion over what the infix dot meant and how it interacted with the rest of Haskell's syntax, then maybe there wouldn't be anything much to be unhappy about in adding in this extra bit of sugar. But it is manifestly confusing or else we wouldn't be having this vote and so many clarifications about what consequences the options had wouldn't have been needed. All these syntactic questions that have been asked and debated in this thread are something that every beginner will have to contend with, and all the consequences of whatever option is selected are something every expert will have to live with. I don't feel that it's worth the extremely meagre benefit of the difference between this and just opting to use lens or otherwise just using the already existing mechanisms. Frankly, I still mostly use Haskell's ordinary field accessors unless there's a real need for abstracting over a lens (at which point I'll switch to using Ed's lens library), or just abstracting over field access (at which point I'll probably define my own class), and DuplicateRecordFields and the associated machinery is not something that I have had a whole lot of love for in the first place. From iavor.diatchki at gmail.com Tue Mar 24 17:32:23 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 24 Mar 2020 10:32:23 -0700 Subject: [ghc-steering-committee] Record dot syntax: time to vote In-Reply-To: References: Message-ID: I just added my vote to the document, apologies for the delay. It is quite interesting looking at the other votes, as some of them seem to be exactly the opposite of what I think should be done :-) Hope everyone is staying healthy! Cheers, -Iavor On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard wrote: > On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via > ghc-steering-committee wrote: > > Overall, I strongly urge that we accept the proposal in some form; that > is, we should not do (C1). 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. > > I'm not sure any of these proposed options feels "obviously right" > either. The fact that we're voting between many different ways to > interpret the same syntax sugar should make it clear that this isn't > so obvious. > > > But there was incremental progress, sketched here: > > > > 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.) > > > > I really think this change has vastly higher impact and utility than > many other accepted proposals. I know that some members of the committee > differ from this view; that's fair enough. > > While I'd agree it has vastly higher impact that a lot of accepted > proposals, I'm not sure that impact is actually in the direction of > making it easier to read and understand programs that are written in > Haskell. It's syntactic sugar that we've pretty reasonably done > without for a long time. Piling on yet another option for how to > select fields from records amidst a sea of libraries that already help > with this in various ways that go far beyond the capabilities of the > syntax sugar that's proposed here seems a bit strange to me at this > point. It feels like the complaint is "but I want to type exactly this > string of characters and no other will do", which seems kind of absurd > to me, but other languages exist in the world, and DAML for instance > is a thing which exists now and should satisfy those people. I don't > particularly get why it's of great importance for Haskell to support > accessing fields with *this* syntax, and not dozens of > almost-equivalent syntaxes that one could already achieve. > > If there were no confusion over what the infix dot meant and how it > interacted with the rest of Haskell's syntax, then maybe there > wouldn't be anything much to be unhappy about in adding in this extra > bit of sugar. But it is manifestly confusing or else we wouldn't be > having this vote and so many clarifications about what consequences > the options had wouldn't have been needed. All these syntactic > questions that have been asked and debated in this thread are > something that every beginner will have to contend with, and all the > consequences of whatever option is selected are something every expert > will have to live with. I don't feel that it's worth the extremely > meagre benefit of the difference between this and just opting to use > lens or otherwise just using the already existing mechanisms. > > Frankly, I still mostly use Haskell's ordinary field accessors unless > there's a real need for abstracting over a lens (at which point I'll > switch to using Ed's lens library), or just abstracting over field > access (at which point I'll probably define my own class), and > DuplicateRecordFields and the associated machinery is not something > that I have had a whole lot of love for in the first place. > _______________________________________________ > 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: From eric at seidel.io Tue Mar 24 18:08:57 2020 From: eric at seidel.io (Eric Seidel) Date: Tue, 24 Mar 2020 14:08:57 -0400 Subject: [ghc-steering-committee] Record dot syntax: time to vote In-Reply-To: References: Message-ID: I noticed the same thing, I don't see anything remotely resembling a consensus in the votes. Just out of curiousity Joachim, does the Schulze method have any metric of how close or far from a consensus the votes are? If so, I'd be very interested to see what it says about the votes here. Let me also take a moment to explain why I voted for C4 as my first choice, since it seems to be particularly polarizing. The two factors that pushed me to favor C4 are its simplicity and its consistency with the rest of Haskell's record syntax. C4 is a very simple rule, it introduces a single new lexeme ('.x') and a single rule for parsing it (it's a postfix operator that binds tighter than application). In my opinion it's the simplest rule after C2b (which I also ranked highly). The other rules all introduce extra complexity into the syntax, often around treating 'r.x' or 'M.r.x' as a single lexeme in constrast to the interpretation of a bare '.x'. The simplest solution is not always the best one, but I believe C4 will at least be easier to learn and become comfortable with, even if it doesn't always produce the parses you would like. C4 is also consistent with Haskell's record creation/update syntax. I know a lot of people dislike the fact that record creation/update binds tighter than application. Simon PJ says he would argue strenuously against it if we were designing Haskell from scratch today, and I'm pretty sympathetic to that position. But we aren't redesigning Haskell's syntax today, we're trying to fit a new piece of syntax into an existing grammar. Given those constraints, I think it makes a lot of sense to lean on the intuitions that people have already built about how record syntax behaves. Hope everyone is well, and not going too stir crazy at home! Eric On Tue, Mar 24, 2020, at 13:32, Iavor Diatchki wrote: > I just added my vote to the document, apologies for the delay. It is > quite interesting looking at the other votes, as some of them seem to > be exactly the opposite of what I think should be done :-) > > Hope everyone is staying healthy! > Cheers, > -Iavor > > On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard wrote: > > On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via > > ghc-steering-committee wrote: > > > Overall, I strongly urge that we accept the proposal in some form; that is, we should not do (C1). 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. > > > > I'm not sure any of these proposed options feels "obviously right" > > either. The fact that we're voting between many different ways to > > interpret the same syntax sugar should make it clear that this isn't > > so obvious. > > > > > But there was incremental progress, sketched here: > > > > > > 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.) > > > > > > I really think this change has vastly higher impact and utility than many other accepted proposals. I know that some members of the committee differ from this view; that's fair enough. > > > > While I'd agree it has vastly higher impact that a lot of accepted > > proposals, I'm not sure that impact is actually in the direction of > > making it easier to read and understand programs that are written in > > Haskell. It's syntactic sugar that we've pretty reasonably done > > without for a long time. Piling on yet another option for how to > > select fields from records amidst a sea of libraries that already help > > with this in various ways that go far beyond the capabilities of the > > syntax sugar that's proposed here seems a bit strange to me at this > > point. It feels like the complaint is "but I want to type exactly this > > string of characters and no other will do", which seems kind of absurd > > to me, but other languages exist in the world, and DAML for instance > > is a thing which exists now and should satisfy those people. I don't > > particularly get why it's of great importance for Haskell to support > > accessing fields with *this* syntax, and not dozens of > > almost-equivalent syntaxes that one could already achieve. > > > > If there were no confusion over what the infix dot meant and how it > > interacted with the rest of Haskell's syntax, then maybe there > > wouldn't be anything much to be unhappy about in adding in this extra > > bit of sugar. But it is manifestly confusing or else we wouldn't be > > having this vote and so many clarifications about what consequences > > the options had wouldn't have been needed. All these syntactic > > questions that have been asked and debated in this thread are > > something that every beginner will have to contend with, and all the > > consequences of whatever option is selected are something every expert > > will have to live with. I don't feel that it's worth the extremely > > meagre benefit of the difference between this and just opting to use > > lens or otherwise just using the already existing mechanisms. > > > > Frankly, I still mostly use Haskell's ordinary field accessors unless > > there's a real need for abstracting over a lens (at which point I'll > > switch to using Ed's lens library), or just abstracting over field > > access (at which point I'll probably define my own class), and > > DuplicateRecordFields and the associated machinery is not something > > that I have had a whole lot of love for in the first place. > > _______________________________________________ > > ghc-steering-committee mailing list > > 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 > From simonpj at microsoft.com Tue Mar 24 19:18:23 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Mar 2020 19:18:23 +0000 Subject: [ghc-steering-committee] Record dot syntax: time to vote In-Reply-To: References: Message-ID: Simon, Alejandro, we are awaiting your votes. https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74/edit Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Eric Seidel | Sent: 24 March 2020 18:09 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote | | I noticed the same thing, I don't see anything remotely resembling a | consensus in the votes. Just out of curiousity Joachim, does the Schulze | method have any metric of how close or far from a consensus the votes are? | If so, I'd be very interested to see what it says about the votes here. | | Let me also take a moment to explain why I voted for C4 as my first | choice, since it seems to be particularly polarizing. The two factors that | pushed me to favor C4 are its simplicity and its consistency with the rest | of Haskell's record syntax. | | C4 is a very simple rule, it introduces a single new lexeme ('.x') and a | single rule for parsing it (it's a postfix operator that binds tighter | than application). In my opinion it's the simplest rule after C2b (which I | also ranked highly). The other rules all introduce extra complexity into | the syntax, often around treating 'r.x' or 'M.r.x' as a single lexeme in | constrast to the interpretation of a bare '.x'. The simplest solution is | not always the best one, but I believe C4 will at least be easier to learn | and become comfortable with, even if it doesn't always produce the parses | you would like. | | C4 is also consistent with Haskell's record creation/update syntax. I know | a lot of people dislike the fact that record creation/update binds tighter | than application. Simon PJ says he would argue strenuously against it if | we were designing Haskell from scratch today, and I'm pretty sympathetic | to that position. But we aren't redesigning Haskell's syntax today, we're | trying to fit a new piece of syntax into an existing grammar. Given those | constraints, I think it makes a lot of sense to lean on the intuitions | that people have already built about how record syntax behaves. | | Hope everyone is well, and not going too stir crazy at home! | Eric | | On Tue, Mar 24, 2020, at 13:32, Iavor Diatchki wrote: | > I just added my vote to the document, apologies for the delay. It is | > quite interesting looking at the other votes, as some of them seem to | > be exactly the opposite of what I think should be done :-) | > | > Hope everyone is staying healthy! | > Cheers, | > -Iavor | > | > On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard wrote: | > > On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via | > > ghc-steering-committee wrote: | > > > Overall, I strongly urge that we accept the proposal in some form; | that is, we should not do (C1). 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. | > > | > > I'm not sure any of these proposed options feels "obviously right" | > > either. The fact that we're voting between many different ways to | > > interpret the same syntax sugar should make it clear that this isn't | > > so obvious. | > > | > > > But there was incremental progress, sketched here: | > > > | > > > 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.) | > > > | > > > I really think this change has vastly higher impact and utility | than many other accepted proposals. I know that some members of the | committee differ from this view; that's fair enough. | > > | > > While I'd agree it has vastly higher impact that a lot of accepted | > > proposals, I'm not sure that impact is actually in the direction of | > > making it easier to read and understand programs that are written in | > > Haskell. It's syntactic sugar that we've pretty reasonably done | > > without for a long time. Piling on yet another option for how to | > > select fields from records amidst a sea of libraries that already | help | > > with this in various ways that go far beyond the capabilities of the | > > syntax sugar that's proposed here seems a bit strange to me at this | > > point. It feels like the complaint is "but I want to type exactly | this | > > string of characters and no other will do", which seems kind of | absurd | > > to me, but other languages exist in the world, and DAML for instance | > > is a thing which exists now and should satisfy those people. I don't | > > particularly get why it's of great importance for Haskell to support | > > accessing fields with *this* syntax, and not dozens of | > > almost-equivalent syntaxes that one could already achieve. | > > | > > If there were no confusion over what the infix dot meant and how it | > > interacted with the rest of Haskell's syntax, then maybe there | > > wouldn't be anything much to be unhappy about in adding in this extra | > > bit of sugar. But it is manifestly confusing or else we wouldn't be | > > having this vote and so many clarifications about what consequences | > > the options had wouldn't have been needed. All these syntactic | > > questions that have been asked and debated in this thread are | > > something that every beginner will have to contend with, and all the | > > consequences of whatever option is selected are something every | expert | > > will have to live with. I don't feel that it's worth the extremely | > > meagre benefit of the difference between this and just opting to use | > > lens or otherwise just using the already existing mechanisms. | > > | > > Frankly, I still mostly use Haskell's ordinary field accessors unless | > > there's a real need for abstracting over a lens (at which point I'll | > > switch to using Ed's lens library), or just abstracting over field | > > access (at which point I'll probably define my own class), and | > > DuplicateRecordFields and the associated machinery is not something | > > that I have had a whole lot of love for in the first place. | > > _______________________________________________ | > > ghc-steering-committee mailing list | > > 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 | > | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From simonpj at microsoft.com Tue Mar 24 19:19:58 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Mar 2020 19:19:58 +0000 Subject: [ghc-steering-committee] Record dot syntax: time to vote In-Reply-To: References: Message-ID: It is quite interesting looking at the other votes, as some of them seem to be exactly the opposite of what I think should be done :-) Indeed. I’m intrigued by how strenuously you dislike C6 (you would prefer to reject the entire proposal than have C6), even though C6 is but a mild variation of qualified names. Would you like to say why? Simon From: Iavor Diatchki Sent: 24 March 2020 17:32 To: Cale Gibbard Cc: Simon Peyton Jones ; ghc-steering-committee Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote I just added my vote to the document, apologies for the delay. It is quite interesting looking at the other votes, as some of them seem to be exactly the opposite of what I think should be done :-) Hope everyone is staying healthy! Cheers, -Iavor On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard > wrote: On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via ghc-steering-committee > wrote: > Overall, I strongly urge that we accept the proposal in some form; that is, we should not do (C1). 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. I'm not sure any of these proposed options feels "obviously right" either. The fact that we're voting between many different ways to interpret the same syntax sugar should make it clear that this isn't so obvious. > But there was incremental progress, sketched here: > > 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.) > > I really think this change has vastly higher impact and utility than many other accepted proposals. I know that some members of the committee differ from this view; that's fair enough. While I'd agree it has vastly higher impact that a lot of accepted proposals, I'm not sure that impact is actually in the direction of making it easier to read and understand programs that are written in Haskell. It's syntactic sugar that we've pretty reasonably done without for a long time. Piling on yet another option for how to select fields from records amidst a sea of libraries that already help with this in various ways that go far beyond the capabilities of the syntax sugar that's proposed here seems a bit strange to me at this point. It feels like the complaint is "but I want to type exactly this string of characters and no other will do", which seems kind of absurd to me, but other languages exist in the world, and DAML for instance is a thing which exists now and should satisfy those people. I don't particularly get why it's of great importance for Haskell to support accessing fields with *this* syntax, and not dozens of almost-equivalent syntaxes that one could already achieve. If there were no confusion over what the infix dot meant and how it interacted with the rest of Haskell's syntax, then maybe there wouldn't be anything much to be unhappy about in adding in this extra bit of sugar. But it is manifestly confusing or else we wouldn't be having this vote and so many clarifications about what consequences the options had wouldn't have been needed. All these syntactic questions that have been asked and debated in this thread are something that every beginner will have to contend with, and all the consequences of whatever option is selected are something every expert will have to live with. I don't feel that it's worth the extremely meagre benefit of the difference between this and just opting to use lens or otherwise just using the already existing mechanisms. Frankly, I still mostly use Haskell's ordinary field accessors unless there's a real need for abstracting over a lens (at which point I'll switch to using Ed's lens library), or just abstracting over field access (at which point I'll probably define my own class), and DuplicateRecordFields and the associated machinery is not something that I have had a whole lot of love for in the first place. _______________________________________________ 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: From trupill at gmail.com Tue Mar 24 19:20:12 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Tue, 24 Mar 2020 20:20:12 +0100 Subject: [ghc-steering-committee] Record dot syntax: time to vote In-Reply-To: References: Message-ID: This is weird, I voted a couple of days ago. Maybe I wrote my votes in Arnaud's place? El mar., 24 mar. 2020 20:18, Simon Peyton Jones escribió: > Simon, Alejandro, we are awaiting your votes. > > https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74/edit > > Simon > > > | -----Original Message----- > | From: ghc-steering-committee < > ghc-steering-committee-bounces at haskell.org> > | On Behalf Of Eric Seidel > | Sent: 24 March 2020 18:09 > | To: ghc-steering-committee at haskell.org > | Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote > | > | I noticed the same thing, I don't see anything remotely resembling a > | consensus in the votes. Just out of curiousity Joachim, does the Schulze > | method have any metric of how close or far from a consensus the votes > are? > | If so, I'd be very interested to see what it says about the votes here. > | > | Let me also take a moment to explain why I voted for C4 as my first > | choice, since it seems to be particularly polarizing. The two factors > that > | pushed me to favor C4 are its simplicity and its consistency with the > rest > | of Haskell's record syntax. > | > | C4 is a very simple rule, it introduces a single new lexeme ('.x') and a > | single rule for parsing it (it's a postfix operator that binds tighter > | than application). In my opinion it's the simplest rule after C2b > (which I > | also ranked highly). The other rules all introduce extra complexity into > | the syntax, often around treating 'r.x' or 'M.r.x' as a single lexeme in > | constrast to the interpretation of a bare '.x'. The simplest solution is > | not always the best one, but I believe C4 will at least be easier to > learn > | and become comfortable with, even if it doesn't always produce the > parses > | you would like. > | > | C4 is also consistent with Haskell's record creation/update syntax. I > know > | a lot of people dislike the fact that record creation/update binds > tighter > | than application. Simon PJ says he would argue strenuously against it if > | we were designing Haskell from scratch today, and I'm pretty sympathetic > | to that position. But we aren't redesigning Haskell's syntax today, > we're > | trying to fit a new piece of syntax into an existing grammar. Given > those > | constraints, I think it makes a lot of sense to lean on the intuitions > | that people have already built about how record syntax behaves. > | > | Hope everyone is well, and not going too stir crazy at home! > | Eric > | > | On Tue, Mar 24, 2020, at 13:32, Iavor Diatchki wrote: > | > I just added my vote to the document, apologies for the delay. It is > | > quite interesting looking at the other votes, as some of them seem to > | > be exactly the opposite of what I think should be done :-) > | > > | > Hope everyone is staying healthy! > | > Cheers, > | > -Iavor > | > > | > On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard > wrote: > | > > On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via > | > > ghc-steering-committee wrote: > | > > > Overall, I strongly urge that we accept the proposal in some > form; > | that is, we should not do (C1). 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. > | > > > | > > I'm not sure any of these proposed options feels "obviously right" > | > > either. The fact that we're voting between many different ways to > | > > interpret the same syntax sugar should make it clear that this > isn't > | > > so obvious. > | > > > | > > > But there was incremental progress, sketched here: > | > > > > | > > > 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.) > | > > > > | > > > I really think this change has vastly higher impact and utility > | than many other accepted proposals. I know that some members of the > | committee differ from this view; that's fair enough. > | > > > | > > While I'd agree it has vastly higher impact that a lot of accepted > | > > proposals, I'm not sure that impact is actually in the direction of > | > > making it easier to read and understand programs that are written > in > | > > Haskell. It's syntactic sugar that we've pretty reasonably done > | > > without for a long time. Piling on yet another option for how to > | > > select fields from records amidst a sea of libraries that already > | help > | > > with this in various ways that go far beyond the capabilities of > the > | > > syntax sugar that's proposed here seems a bit strange to me at this > | > > point. It feels like the complaint is "but I want to type exactly > | this > | > > string of characters and no other will do", which seems kind of > | absurd > | > > to me, but other languages exist in the world, and DAML for > instance > | > > is a thing which exists now and should satisfy those people. I > don't > | > > particularly get why it's of great importance for Haskell to > support > | > > accessing fields with *this* syntax, and not dozens of > | > > almost-equivalent syntaxes that one could already achieve. > | > > > | > > If there were no confusion over what the infix dot meant and how it > | > > interacted with the rest of Haskell's syntax, then maybe there > | > > wouldn't be anything much to be unhappy about in adding in this > extra > | > > bit of sugar. But it is manifestly confusing or else we wouldn't be > | > > having this vote and so many clarifications about what consequences > | > > the options had wouldn't have been needed. All these syntactic > | > > questions that have been asked and debated in this thread are > | > > something that every beginner will have to contend with, and all > the > | > > consequences of whatever option is selected are something every > | expert > | > > will have to live with. I don't feel that it's worth the extremely > | > > meagre benefit of the difference between this and just opting to > use > | > > lens or otherwise just using the already existing mechanisms. > | > > > | > > Frankly, I still mostly use Haskell's ordinary field accessors > unless > | > > there's a real need for abstracting over a lens (at which point > I'll > | > > switch to using Ed's lens library), or just abstracting over field > | > > access (at which point I'll probably define my own class), and > | > > DuplicateRecordFields and the associated machinery is not something > | > > that I have had a whole lot of love for in the first place. > | > > _______________________________________________ > | > > ghc-steering-committee mailing list > | > > 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 > | > > | _______________________________________________ > | 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: From iavor.diatchki at gmail.com Tue Mar 24 19:51:07 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 24 Mar 2020 12:51:07 -0700 Subject: [ghc-steering-committee] Record dot syntax: time to vote In-Reply-To: References: Message-ID: I don't like C6 because `e.x` has completely different meaning when `e` is a variable vs. when it is not. This strikes me as quite an odd wart, and I see no benefits to it whatsoever. In fact, I can see it leading to bugs, as most Haskell programmers I know assume that you can more or less freely name or inline pure expressions without changing the meaning of the program. -Iavor On Tue, Mar 24, 2020 at 12:19 PM Simon Peyton Jones wrote: > It is quite interesting looking at the other votes, as some of them seem > to be exactly the opposite of what I think should be done :-) > > > > Indeed. I’m intrigued by how strenuously you dislike C6 (you would prefer > to reject the entire proposal than have C6), even though C6 is but a mild > variation of qualified names. Would you like to say why? > > > > Simon > > > > *From:* Iavor Diatchki > *Sent:* 24 March 2020 17:32 > *To:* Cale Gibbard > *Cc:* Simon Peyton Jones ; ghc-steering-committee < > ghc-steering-committee at haskell.org> > *Subject:* Re: [ghc-steering-committee] Record dot syntax: time to vote > > > > I just added my vote to the document, apologies for the delay. It is > quite interesting looking at the other votes, as some of them seem to be > exactly the opposite of what I think should be done :-) > > > > Hope everyone is staying healthy! > > Cheers, > > -Iavor > > > > On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard wrote: > > On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via > ghc-steering-committee wrote: > > Overall, I strongly urge that we accept the proposal in some form; that > is, we should not do (C1). 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. > > I'm not sure any of these proposed options feels "obviously right" > either. The fact that we're voting between many different ways to > interpret the same syntax sugar should make it clear that this isn't > so obvious. > > > But there was incremental progress, sketched here: > > > > 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.) > > > > I really think this change has vastly higher impact and utility than > many other accepted proposals. I know that some members of the committee > differ from this view; that's fair enough. > > While I'd agree it has vastly higher impact that a lot of accepted > proposals, I'm not sure that impact is actually in the direction of > making it easier to read and understand programs that are written in > Haskell. It's syntactic sugar that we've pretty reasonably done > without for a long time. Piling on yet another option for how to > select fields from records amidst a sea of libraries that already help > with this in various ways that go far beyond the capabilities of the > syntax sugar that's proposed here seems a bit strange to me at this > point. It feels like the complaint is "but I want to type exactly this > string of characters and no other will do", which seems kind of absurd > to me, but other languages exist in the world, and DAML for instance > is a thing which exists now and should satisfy those people. I don't > particularly get why it's of great importance for Haskell to support > accessing fields with *this* syntax, and not dozens of > almost-equivalent syntaxes that one could already achieve. > > If there were no confusion over what the infix dot meant and how it > interacted with the rest of Haskell's syntax, then maybe there > wouldn't be anything much to be unhappy about in adding in this extra > bit of sugar. But it is manifestly confusing or else we wouldn't be > having this vote and so many clarifications about what consequences > the options had wouldn't have been needed. All these syntactic > questions that have been asked and debated in this thread are > something that every beginner will have to contend with, and all the > consequences of whatever option is selected are something every expert > will have to live with. I don't feel that it's worth the extremely > meagre benefit of the difference between this and just opting to use > lens or otherwise just using the already existing mechanisms. > > Frankly, I still mostly use Haskell's ordinary field accessors unless > there's a real need for abstracting over a lens (at which point I'll > switch to using Ed's lens library), or just abstracting over field > access (at which point I'll probably define my own class), and > DuplicateRecordFields and the associated machinery is not something > that I have had a whole lot of love for in the first place. > _______________________________________________ > 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: From simonpj at microsoft.com Tue Mar 24 20:46:51 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Mar 2020 20:46:51 +0000 Subject: [ghc-steering-committee] Record dot syntax: time to vote In-Reply-To: References: Message-ID: I don't like C6 because `e.x` has completely different meaning when `e` is a variable vs. when it is not. But that is true today! Specifically, qualified names. M.x means something very different to (f y).x What’s attractive to me about C6 is that it simply and uniformly extends qualified names. But I said that before, and your judgement differs, which is fair enough. Simon From: Iavor Diatchki Sent: 24 March 2020 19:51 To: Simon Peyton Jones Cc: Cale Gibbard ; ghc-steering-committee Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote I don't like C6 because `e.x` has completely different meaning when `e` is a variable vs. when it is not. This strikes me as quite an odd wart, and I see no benefits to it whatsoever. In fact, I can see it leading to bugs, as most Haskell programmers I know assume that you can more or less freely name or inline pure expressions without changing the meaning of the program. -Iavor On Tue, Mar 24, 2020 at 12:19 PM Simon Peyton Jones > wrote: It is quite interesting looking at the other votes, as some of them seem to be exactly the opposite of what I think should be done :-) Indeed. I’m intrigued by how strenuously you dislike C6 (you would prefer to reject the entire proposal than have C6), even though C6 is but a mild variation of qualified names. Would you like to say why? Simon From: Iavor Diatchki > Sent: 24 March 2020 17:32 To: Cale Gibbard > Cc: Simon Peyton Jones >; ghc-steering-committee > Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote I just added my vote to the document, apologies for the delay. It is quite interesting looking at the other votes, as some of them seem to be exactly the opposite of what I think should be done :-) Hope everyone is staying healthy! Cheers, -Iavor On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard > wrote: On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via ghc-steering-committee > wrote: > Overall, I strongly urge that we accept the proposal in some form; that is, we should not do (C1). 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. I'm not sure any of these proposed options feels "obviously right" either. The fact that we're voting between many different ways to interpret the same syntax sugar should make it clear that this isn't so obvious. > But there was incremental progress, sketched here: > > 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.) > > I really think this change has vastly higher impact and utility than many other accepted proposals. I know that some members of the committee differ from this view; that's fair enough. While I'd agree it has vastly higher impact that a lot of accepted proposals, I'm not sure that impact is actually in the direction of making it easier to read and understand programs that are written in Haskell. It's syntactic sugar that we've pretty reasonably done without for a long time. Piling on yet another option for how to select fields from records amidst a sea of libraries that already help with this in various ways that go far beyond the capabilities of the syntax sugar that's proposed here seems a bit strange to me at this point. It feels like the complaint is "but I want to type exactly this string of characters and no other will do", which seems kind of absurd to me, but other languages exist in the world, and DAML for instance is a thing which exists now and should satisfy those people. I don't particularly get why it's of great importance for Haskell to support accessing fields with *this* syntax, and not dozens of almost-equivalent syntaxes that one could already achieve. If there were no confusion over what the infix dot meant and how it interacted with the rest of Haskell's syntax, then maybe there wouldn't be anything much to be unhappy about in adding in this extra bit of sugar. But it is manifestly confusing or else we wouldn't be having this vote and so many clarifications about what consequences the options had wouldn't have been needed. All these syntactic questions that have been asked and debated in this thread are something that every beginner will have to contend with, and all the consequences of whatever option is selected are something every expert will have to live with. I don't feel that it's worth the extremely meagre benefit of the difference between this and just opting to use lens or otherwise just using the already existing mechanisms. Frankly, I still mostly use Haskell's ordinary field accessors unless there's a real need for abstracting over a lens (at which point I'll switch to using Ed's lens library), or just abstracting over field access (at which point I'll probably define my own class), and DuplicateRecordFields and the associated machinery is not something that I have had a whole lot of love for in the first place. _______________________________________________ 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: From arnaud.spiwack at tweag.io Wed Mar 25 07:50:54 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 25 Mar 2020 08:50:54 +0100 Subject: [ghc-steering-committee] Record dot syntax: time to vote In-Reply-To: References: Message-ID: Alejandro: most likely what happened indeed. I hadn't voted yet. Now fixed. On Tue, Mar 24, 2020 at 8:20 PM Alejandro Serrano Mena wrote: > This is weird, I voted a couple of days ago. Maybe I wrote my votes in > Arnaud's place? > > El mar., 24 mar. 2020 20:18, Simon Peyton Jones > escribió: > >> Simon, Alejandro, we are awaiting your votes. >> >> https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74/edit >> >> Simon >> >> >> | -----Original Message----- >> | From: ghc-steering-committee < >> ghc-steering-committee-bounces at haskell.org> >> | On Behalf Of Eric Seidel >> | Sent: 24 March 2020 18:09 >> | To: ghc-steering-committee at haskell.org >> | Subject: Re: [ghc-steering-committee] Record dot syntax: time to vote >> | >> | I noticed the same thing, I don't see anything remotely resembling a >> | consensus in the votes. Just out of curiousity Joachim, does the >> Schulze >> | method have any metric of how close or far from a consensus the votes >> are? >> | If so, I'd be very interested to see what it says about the votes here. >> | >> | Let me also take a moment to explain why I voted for C4 as my first >> | choice, since it seems to be particularly polarizing. The two factors >> that >> | pushed me to favor C4 are its simplicity and its consistency with the >> rest >> | of Haskell's record syntax. >> | >> | C4 is a very simple rule, it introduces a single new lexeme ('.x') and >> a >> | single rule for parsing it (it's a postfix operator that binds tighter >> | than application). In my opinion it's the simplest rule after C2b >> (which I >> | also ranked highly). The other rules all introduce extra complexity >> into >> | the syntax, often around treating 'r.x' or 'M.r.x' as a single lexeme >> in >> | constrast to the interpretation of a bare '.x'. The simplest solution >> is >> | not always the best one, but I believe C4 will at least be easier to >> learn >> | and become comfortable with, even if it doesn't always produce the >> parses >> | you would like. >> | >> | C4 is also consistent with Haskell's record creation/update syntax. I >> know >> | a lot of people dislike the fact that record creation/update binds >> tighter >> | than application. Simon PJ says he would argue strenuously against it >> if >> | we were designing Haskell from scratch today, and I'm pretty >> sympathetic >> | to that position. But we aren't redesigning Haskell's syntax today, >> we're >> | trying to fit a new piece of syntax into an existing grammar. Given >> those >> | constraints, I think it makes a lot of sense to lean on the intuitions >> | that people have already built about how record syntax behaves. >> | >> | Hope everyone is well, and not going too stir crazy at home! >> | Eric >> | >> | On Tue, Mar 24, 2020, at 13:32, Iavor Diatchki wrote: >> | > I just added my vote to the document, apologies for the delay. It is >> | > quite interesting looking at the other votes, as some of them seem to >> | > be exactly the opposite of what I think should be done :-) >> | > >> | > Hope everyone is staying healthy! >> | > Cheers, >> | > -Iavor >> | > >> | > On Thu, Mar 19, 2020 at 3:41 PM Cale Gibbard >> wrote: >> | > > On Thu, 19 Mar 2020 at 07:33, Simon Peyton Jones via >> | > > ghc-steering-committee >> wrote: >> | > > > Overall, I strongly urge that we accept the proposal in some >> form; >> | that is, we should not do (C1). 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. >> | > > >> | > > I'm not sure any of these proposed options feels "obviously right" >> | > > either. The fact that we're voting between many different ways to >> | > > interpret the same syntax sugar should make it clear that this >> isn't >> | > > so obvious. >> | > > >> | > > > But there was incremental progress, sketched here: >> | > > > >> | > > > 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.) >> | > > > >> | > > > I really think this change has vastly higher impact and utility >> | than many other accepted proposals. I know that some members of the >> | committee differ from this view; that's fair enough. >> | > > >> | > > While I'd agree it has vastly higher impact that a lot of accepted >> | > > proposals, I'm not sure that impact is actually in the direction >> of >> | > > making it easier to read and understand programs that are written >> in >> | > > Haskell. It's syntactic sugar that we've pretty reasonably done >> | > > without for a long time. Piling on yet another option for how to >> | > > select fields from records amidst a sea of libraries that already >> | help >> | > > with this in various ways that go far beyond the capabilities of >> the >> | > > syntax sugar that's proposed here seems a bit strange to me at >> this >> | > > point. It feels like the complaint is "but I want to type exactly >> | this >> | > > string of characters and no other will do", which seems kind of >> | absurd >> | > > to me, but other languages exist in the world, and DAML for >> instance >> | > > is a thing which exists now and should satisfy those people. I >> don't >> | > > particularly get why it's of great importance for Haskell to >> support >> | > > accessing fields with *this* syntax, and not dozens of >> | > > almost-equivalent syntaxes that one could already achieve. >> | > > >> | > > If there were no confusion over what the infix dot meant and how >> it >> | > > interacted with the rest of Haskell's syntax, then maybe there >> | > > wouldn't be anything much to be unhappy about in adding in this >> extra >> | > > bit of sugar. But it is manifestly confusing or else we wouldn't >> be >> | > > having this vote and so many clarifications about what >> consequences >> | > > the options had wouldn't have been needed. All these syntactic >> | > > questions that have been asked and debated in this thread are >> | > > something that every beginner will have to contend with, and all >> the >> | > > consequences of whatever option is selected are something every >> | expert >> | > > will have to live with. I don't feel that it's worth the extremely >> | > > meagre benefit of the difference between this and just opting to >> use >> | > > lens or otherwise just using the already existing mechanisms. >> | > > >> | > > Frankly, I still mostly use Haskell's ordinary field accessors >> unless >> | > > there's a real need for abstracting over a lens (at which point >> I'll >> | > > switch to using Ed's lens library), or just abstracting over field >> | > > access (at which point I'll probably define my own class), and >> | > > DuplicateRecordFields and the associated machinery is not >> something >> | > > that I have had a whole lot of love for in the first place. >> | > > _______________________________________________ >> | > > ghc-steering-committee mailing list >> | > > 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 >> | > >> | _______________________________________________ >> | ghc-steering-committee mailing list >> | 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: From mail at joachim-breitner.de Wed Mar 25 09:07:12 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 25 Mar 2020 10:07:12 +0100 Subject: [ghc-steering-committee] Record dot syntax: time to vote In-Reply-To: References: Message-ID: <4d21121e88f8460e38258821261bde54033031b5.camel@joachim-breitner.de> Hi, Am Dienstag, den 24.03.2020, 14:08 -0400 schrieb Eric Seidel: > I noticed the same thing, I don't see anything remotely resembling a > consensus in the votes. yes, this is concering. I wondered about putting C1 for the good reason that there obviously is not a good solution. But then I decided to put trust in the voting system, i.e. if an option will beat C1 by a majority, then that option hopefully is better than rejecting. > Just out of curiousity Joachim, does the Schulze method have any > metric of how close or far from a consensus the votes are? If so, I'd > be very interested to see what it says about the votes here. No hard metric, but we will see how “close” the winner will beat each other option. > Let me also take a moment to explain why I voted for C4 as my first > choice, since it seems to be particularly polarizing. The two factors > that pushed me to favor C4 are its simplicity and its consistency > with the rest of Haskell's record syntax. After making my score, I noticed that the three options I put before C1 are precisely the three options that (I belive) are “simple and consistent”, and which could be explained by a short “just like” reference to an existing language feature: * C4: Just like record construction/update * C5: Just like function application * C2a: Just like module-qualified names. Ah, I see Iavor has more or less the same. It always feels good to not have a solitary opinion. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Wed Mar 25 09:35:09 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 25 Mar 2020 10:35:09 +0100 Subject: [ghc-steering-committee] Record dot syntax: tally preview In-Reply-To: References: Message-ID: <3d4e9d4827ffda34cb5d2f9d4db09151be38ed2d.camel@joachim-breitner.de> Hi, if we had a simpler voting scheme, it would be obvious to everyone where wer are standing. But I don’t expect that any of us can just glance at the Google Sheet and see how things are standing. But this obscurity is of course not intended! So to give a preview (with Simon Marlow’s vote still missing, and of course everyone still able to refine their votes) we currently have this result: C2a > C2b > C4 > C6 = C1 > C3 = C7 > C5 where C2a beats all other options by 6:4 or more. In a way, C2a is one of the less bold moves. It is a typical property of ranked voting schemes that they tend to elect more moderate options. Fun fact: While we have a natural Condorcet winner (an option preferred over any other option by a majority), we do not have a Condorcet loser: _Every_ option is preferred over some other option by a majority, because C5 beats C1, C1 beats C3, C3 beats C5. (Now I wonder: did I confuse C2a and C2b in my vote last week? What was my intention back then? Not sure any more… I guess I valued the concept that you can take `x` and replace it with `(f x)` without affecting the surrounding concepts.) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From iavor.diatchki at gmail.com Wed Mar 25 15:56:35 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 25 Mar 2020 08:56:35 -0700 Subject: [ghc-steering-committee] Record dot syntax: tally preview In-Reply-To: <3d4e9d4827ffda34cb5d2f9d4db09151be38ed2d.camel@joachim-breitner.de> References: <3d4e9d4827ffda34cb5d2f9d4db09151be38ed2d.camel@joachim-breitner.de> Message-ID: Interesting. It is quite surprising to me that people prefer C2a to C4, when they are basically the same thing, except C4 is easier to specify/implement. C2a is basically C4 but with some additional work to prohibit white white space between the selector and the preceding expression (whatever that means exactly). On Wed, Mar 25, 2020 at 2:35 AM Joachim Breitner wrote: > Hi, > > if we had a simpler voting scheme, it would be obvious to everyone > where wer are standing. But I don’t expect that any of us can just > glance at the Google Sheet and see how things are standing. > > But this obscurity is of course not intended! > > So to give a preview (with Simon Marlow’s vote still missing, and of > course everyone still able to refine their votes) we currently have > this result: > > C2a > C2b > C4 > C6 = C1 > C3 = C7 > C5 > > where C2a beats all other options by 6:4 or more. > > In a way, C2a is one of the less bold moves. It is a typical property > of ranked voting schemes that they tend to elect more moderate options. > > Fun fact: While we have a natural Condorcet winner (an option preferred > over any other option by a majority), we do not have a Condorcet loser: > _Every_ option is preferred over some other option by a majority, > because C5 beats C1, C1 beats C3, C3 beats C5. > > (Now I wonder: did I confuse C2a and C2b in my vote last week? What was > my intention back then? Not sure any more… I guess I valued the concept > that you can take `x` and replace it with `(f x)` without affecting the > surrounding concepts.) > > > Cheers, > Joachim > > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > 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: From simonpj at microsoft.com Wed Mar 25 16:25:13 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 25 Mar 2020 16:25:13 +0000 Subject: [ghc-steering-committee] Record dot syntax: tally preview In-Reply-To: References: <3d4e9d4827ffda34cb5d2f9d4db09151be38ed2d.camel@joachim-breitner.de> Message-ID: I dislike C4 because * it adds something that binds more tightly than application * it closes the path chained applications, which I expect may prove desirable in future I note that C2b is more conservative than C2a; in particular, C2b does not require the complexity of Note 5. Simon From: ghc-steering-committee On Behalf Of Iavor Diatchki Sent: 25 March 2020 15:57 To: Joachim Breitner Cc: ghc-steering-committee Subject: Re: [ghc-steering-committee] Record dot syntax: tally preview Interesting. It is quite surprising to me that people prefer C2a to C4, when they are basically the same thing, except C4 is easier to specify/implement. C2a is basically C4 but with some additional work to prohibit white white space between the selector and the preceding expression (whatever that means exactly). On Wed, Mar 25, 2020 at 2:35 AM Joachim Breitner > wrote: Hi, if we had a simpler voting scheme, it would be obvious to everyone where wer are standing. But I don’t expect that any of us can just glance at the Google Sheet and see how things are standing. But this obscurity is of course not intended! So to give a preview (with Simon Marlow’s vote still missing, and of course everyone still able to refine their votes) we currently have this result: C2a > C2b > C4 > C6 = C1 > C3 = C7 > C5 where C2a beats all other options by 6:4 or more. In a way, C2a is one of the less bold moves. It is a typical property of ranked voting schemes that they tend to elect more moderate options. Fun fact: While we have a natural Condorcet winner (an option preferred over any other option by a majority), we do not have a Condorcet loser: _Every_ option is preferred over some other option by a majority, because C5 beats C1, C1 beats C3, C3 beats C5. (Now I wonder: did I confuse C2a and C2b in my vote last week? What was my intention back then? Not sure any more… I guess I valued the concept that you can take `x` and replace it with `(f x)` without affecting the surrounding concepts.) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ 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: From marlowsd at gmail.com Mon Mar 30 13:51:25 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 30 Mar 2020 14:51:25 +0100 Subject: [ghc-steering-committee] Record dot syntax: time to vote In-Reply-To: References: Message-ID: After voting I feel like writing down the rationale I used, and I'll probably forget myself if I don't write this down: 1. Of greatest importance to me is the ability to replace an identifier by a parenthesized expression without changing meaning. So "(f x).y" must mean the same as "r.y". That rules out C2b and C6. (this rationale doesn't apply to qualified names because we don't have first-class modules, and maybe one day if that changes we will want to revisit the syntax for qualified names too.) 2. I'm downranking proposals where selection binds "like application" because I think it will end up being confusing. So that's C3, C5, C6. 3. All other things being equal, less whitespace-sensitivity is to be preferred, so C4 > C2a > C7. Cheers Simon On Thu, 19 Mar 2020 at 11:33, Simon Peyton Jones via ghc-steering-committee wrote: > Colleagues > > Now that we have agreed a set of alternatives on using dot notation for > records, let's vote. We all recognise and respect that syntactic choices > are a judgement call, and that reasonable people may diff in their > judgements. But we need to come to as resolution and voting is a good way > to do that. > > *Please put your votes on the Google doc.* I've make a section for that > at the end. The document is here > > . > > Just write down your preferences, in order, preferred ones first. > > Joachim runs an election algorithm that makes it worth specifying a total > order on all options, *including ones you don't like*. For any you omit, > you are saying "if these ones are the top contenders I have no preference > between them". You can specify ties, again meaning "no preference between > these". For the over-interested, the algorithm is Condorcet > ; > in the unlikely case that it does not produce a winner, we revert to > Schultze > > > Please read the document, including the Notes, carefully! We have ended > up with a lot of variations, and their numbering is historical not logical. > (I considered renumbering but thought that would be more confusing than > helpful.) > > As the shepherd I am supposed to make a recommendation; it is below. > > Simon > > > Shepherd's recommendations > > Here is my recommendation: > > * C6 > C2b > C3 > C2a > C7 > C4 > C5 > C1* > I recommend acceptance > > Overall, I strongly urge that we accept the proposal in some form; that > is, we should not do (C1). 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: > > - 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.) > > I really think this change has vastly higher impact and utility than many > other accepted proposals. I know that some members of the committee differ > from this view; that's fair enough. > Alternatives I like: > > - I urge us to adopt (C6). I really really want *(f M.N.x) *to parse > the same as *(f M.n.x)**,* where the only difference is the > capitalisation of the second-last element of *M.n.x*. > > *I'm leaning strongly on the connection with qualified names*. We > already have qualified names, and they are incredibly useful. Qualified > names already treat “.” specially. Moreover the proposal uses “.” in > precisely the same way as qualified names: a qualified name M.x allows you > to pick x from the module M; this proposal allows r.x to pick a field x > from a value r. I like this uniformity of both concept and syntax. > > - (C2b) is a weakened form of (C6) that does not allow naked > selectors, thus *(f .x)* where there is a space before the ".". I > don't see any difficulty with the postfix operator story, so I prefer > (C6). But (C2b) is a little more conservative. > > Alternatives I actively dislike: > > - I urge against (C1) as I say above. > - I dislike (C5) strongly, because it makes *(f M.N.x)* parse > completely differently from *(f M.n.x).* The authors of the proposal > say that they would withdraw the proposal outright (or at least > disassociate themselves) if we adopted (C5). > - I dislike (C7) for the same reason: *(f M.N.x)* is legal but *(f > M.n.x)* is not. > - I dislike (C4) because nothing should bind more tightly than > function application. I hate that *(f r .x s .y*) would mean * (f > (r.x) (s.y)).* Yes, we already have that *(f r {x=2})* means *(f (r > {x=2}))*, but I think that's terrible, and we should not perpetuate it. > > Alternatives in the middle > > - (C2a) and (C3) are just like (C2b) and (C6), but additionally allow > a tightly-binding record selection after a parenthesised expression. Thus *(f > (g x).y)* means *(f ((g x).y)).* > > Allowing this is a bit tricky to specify, and the link to qualified names > is much weaker. I don't think it pays its way. > > > > > _______________________________________________ > 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: From mail at joachim-breitner.de Mon Mar 30 16:48:21 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 30 Mar 2020 18:48:21 +0200 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: Message-ID: 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://www.condorcet.vote/Vote/AB23CE70AC/ So, does this conclude this saga? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From rae at richarde.dev Mon Mar 30 16:58:09 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 30 Mar 2020 17:58:09 +0100 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: Message-ID: <1212A74C-A496-406A-A7C3-B2DE57AB361E@richarde.dev> I think this is a fine conclusion to the saga, personally. C2a is one of the more middle-of-the-ground options, and it's refreshing to have an election that chooses such a candidate. It's been slow, yes, but I think this phase of the saga has highlighted the strengths of the committee process, in that we had a deliberate, carefully reasoned vote. Thanks for running the vote algorithm, Joachim, and for your careful shepherding, Simon. Richard > On Mar 30, 2020, at 5:48 PM, Joachim Breitner wrote: > > 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://www.condorcet.vote/Vote/AB23CE70AC/ > > So, does this conclude this saga? > > Cheers, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From iavor.diatchki at gmail.com Mon Mar 30 17:06:43 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 30 Mar 2020 10:06:43 -0700 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: <1212A74C-A496-406A-A7C3-B2DE57AB361E@richarde.dev> References: <1212A74C-A496-406A-A7C3-B2DE57AB361E@richarde.dev> Message-ID: Thanks Joachim! I'd be curious the hear an opinion from someone who prefers `C2a` to `C4`, about why it is better? To me `C2a` just looks like a more complicated version of `C4`. -Iavor On Mon, Mar 30, 2020 at 9:58 AM Richard Eisenberg wrote: > I think this is a fine conclusion to the saga, personally. C2a is one of > the more middle-of-the-ground options, and it's refreshing to have an > election that chooses such a candidate. > > It's been slow, yes, but I think this phase of the saga has highlighted > the strengths of the committee process, in that we had a deliberate, > carefully reasoned vote. > > Thanks for running the vote algorithm, Joachim, and for your careful > shepherding, Simon. > > Richard > > > On Mar 30, 2020, at 5:48 PM, Joachim Breitner > wrote: > > > > 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://www.condorcet.vote/Vote/AB23CE70AC/ > > > > So, does this conclude this saga? > > > > Cheers, > > Joachim > > > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > > > _______________________________________________ > > ghc-steering-committee mailing list > > 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: From eric at seidel.io Mon Mar 30 18:02:30 2020 From: eric at seidel.io (Eric Seidel) Date: Mon, 30 Mar 2020 14:02:30 -0400 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: <1212A74C-A496-406A-A7C3-B2DE57AB361E@richarde.dev> Message-ID: <957e894f-95fb-4a3e-a69c-e356da557a75@www.fastmail.com> I'd be very interested too. I also think it would be good to summarize our discussion here, in particular the rationale for C2a, and post the summary on the GitHub thread. I noticed some concerns on the GitHub thread about the lack of consensus and the omission of `map .lbl xs` (IIRC we did discuss this option and there actually *was* consensus that we didn't like it), we should address those concerns too. Eric On Mon, Mar 30, 2020, at 13:06, Iavor Diatchki wrote: > Thanks Joachim! I'd be curious the hear an opinion from someone who > prefers `C2a` to `C4`, about why it is better? To me `C2a` just looks > like a more complicated version of `C4`. > > -Iavor > > > On Mon, Mar 30, 2020 at 9:58 AM Richard Eisenberg wrote: > > I think this is a fine conclusion to the saga, personally. C2a is one of the more middle-of-the-ground options, and it's refreshing to have an election that chooses such a candidate. > > > > It's been slow, yes, but I think this phase of the saga has highlighted the strengths of the committee process, in that we had a deliberate, carefully reasoned vote. > > > > Thanks for running the vote algorithm, Joachim, and for your careful shepherding, Simon. > > > > Richard > > > > > On Mar 30, 2020, at 5:48 PM, Joachim Breitner wrote: > > > > > > 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://www.condorcet.vote/Vote/AB23CE70AC/ > > > > > > So, does this conclude this saga? > > > > > > Cheers, > > > Joachim > > > > > > -- > > > Joachim Breitner > > > mail at joachim-breitner.de > > > http://www.joachim-breitner.de/ > > > > > > > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > 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 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From trupill at gmail.com Mon Mar 30 19:27:40 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Mon, 30 Mar 2020 21:27:40 +0200 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: <957e894f-95fb-4a3e-a69c-e356da557a75@www.fastmail.com> References: <1212A74C-A496-406A-A7C3-B2DE57AB361E@richarde.dev> <957e894f-95fb-4a3e-a69c-e356da557a75@www.fastmail.com> Message-ID: Since I voted C2a as first option, let me try to explain what lead me to my vote. Which is one main thing: for me the syntax "r .x", with a space in between the element and the field name, looks completely alien and different from what other languages do [1,2,3]. Even though we can implement that in a clever way by making ".r" a special kind of operator, I think that for most people the notion of "field access" is ingrained as a special part of the syntax of a language. Furthermore, several examples in C4 are very surprising to me. For example, "f r .x" meaning "f (r.x)". Once again, I expect field access be part of the same "joint expression" as in other languages. As a final note, if we have ".b" for fields, what would stop us from making ".f" just special syntax for "post-application of any function"? I mean, we could also have something as "numbers .sum" as meaning "sum numbers", in the same way that "person .age" is equivalent to "age person". I am not arguing at all that we should go that way, but rather that for many reason I think that making "field access" less clever, and more similar to other languages, is the right decision. Alejandro [1] C# Language Spec -> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#member-access [2] F# Language Spec, page 81 -> https://fsharp.org/specs/language-spec/4.1/FSharpSpec-4.1-latest.pdf [3] OCaml syntax, records -> https://caml.inria.fr/pub/docs/manual-ocaml/expr.html#sss:expr-records El lun., 30 mar. 2020 a las 20:03, Eric Seidel () escribió: > I'd be very interested too. > > I also think it would be good to summarize our discussion here, in > particular the rationale for C2a, and post the summary on the GitHub > thread. I noticed some concerns on the GitHub thread about the lack of > consensus and the omission of `map .lbl xs` (IIRC we did discuss this > option and there actually *was* consensus that we didn't like it), we > should address those concerns too. > > Eric > > > On Mon, Mar 30, 2020, at 13:06, Iavor Diatchki wrote: > > Thanks Joachim! I'd be curious the hear an opinion from someone who > > prefers `C2a` to `C4`, about why it is better? To me `C2a` just looks > > like a more complicated version of `C4`. > > > > -Iavor > > > > > > On Mon, Mar 30, 2020 at 9:58 AM Richard Eisenberg > wrote: > > > I think this is a fine conclusion to the saga, personally. C2a is one > of the more middle-of-the-ground options, and it's refreshing to have an > election that chooses such a candidate. > > > > > > It's been slow, yes, but I think this phase of the saga has > highlighted the strengths of the committee process, in that we had a > deliberate, carefully reasoned vote. > > > > > > Thanks for running the vote algorithm, Joachim, and for your careful > shepherding, Simon. > > > > > > Richard > > > > > > > On Mar 30, 2020, at 5:48 PM, Joachim Breitner < > mail at joachim-breitner.de> wrote: > > > > > > > > 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://www.condorcet.vote/Vote/AB23CE70AC/ > > > > > > > > So, does this conclude this saga? > > > > > > > > Cheers, > > > > Joachim > > > > > > > > -- > > > > Joachim Breitner > > > > mail at joachim-breitner.de > > > > http://www.joachim-breitner.de/ > > > > > > > > > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > 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 > > _______________________________________________ > > ghc-steering-committee mailing list > > 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: From mail at joachim-breitner.de Tue Mar 31 09:45:50 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 31 Mar 2020 11:45:50 +0200 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: <1212A74C-A496-406A-A7C3-B2DE57AB361E@richarde.dev> <957e894f-95fb-4a3e-a69c-e356da557a75@www.fastmail.com> Message-ID: <22d45c1d6f9e6e0506e97bd63736970d5631271d.camel@joachim-breitner.de> Hi, Am Montag, den 30.03.2020, 21:27 +0200 schrieb Alejandro Serrano Mena: > for me the syntax "r .x", with a space in between the element and the > field name, looks completely alien and different from what other > languages do [1,2,3]. > Furthermore, several examples in C4 are very surprising to me. For > example, "f r .x" meaning "f (r.x)". you list Ocaml here, but that C4 is _precisely_ what Ocaml does (and in my earlier list of options, where I tired to be more systematic about option names, i was called “Ocaml”): utop # type r = { x : int };; type r = { x : int; } utop # let r = { x = 0 };; val r : r = {x = 0} utop # let f : int -> int = fun n -> n;; val f : int -> int = utop # f r .x;; - : int = 0 Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From trupill at gmail.com Tue Mar 31 09:49:12 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Tue, 31 Mar 2020 11:49:12 +0200 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: <22d45c1d6f9e6e0506e97bd63736970d5631271d.camel@joachim-breitner.de> References: <1212A74C-A496-406A-A7C3-B2DE57AB361E@richarde.dev> <957e894f-95fb-4a3e-a69c-e356da557a75@www.fastmail.com> <22d45c1d6f9e6e0506e97bd63736970d5631271d.camel@joachim-breitner.de> Message-ID: El mar., 31 mar. 2020 11:46, Joachim Breitner escribió: > Hi, > > Am Montag, den 30.03.2020, 21:27 +0200 schrieb Alejandro Serrano Mena: > > for me the syntax "r .x", with a space in between the element and the > > field name, looks completely alien and different from what other > > languages do [1,2,3]. > > Furthermore, several examples in C4 are very surprising to me. For > > example, "f r .x" meaning "f (r.x)". > > you list Ocaml here, but that C4 is _precisely_ what Ocaml does (and in > my earlier list of options, where I tired to be more systematic about > option names, i was called “Ocaml”): > > utop # type r = { x : int };; > type r = { x : int; } > utop # let r = { x = 0 };; > val r : r = {x = 0} > utop # let f : int -> int = fun n -> n;; > val f : int -> int = > utop # f r .x;; > - : int = 0 Interesting. I must have misread the spec. So I guess now I find Ocaml surprising too! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Mar 31 10:08:41 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 31 Mar 2020 10:08:41 +0000 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: Message-ID: 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. 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 | On Behalf Of Joachim Breitner | Sent: 30 March 2020 17:48 | To: ghc-steering-committee | 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&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 | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%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 | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b436e2be | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= | 0 From marlowsd at gmail.com Tue Mar 31 10:40:58 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 31 Mar 2020 11:40:58 +0100 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: Message-ID: On Tue, 31 Mar 2020 at 11:08, Simon Peyton Jones via ghc-steering-committee 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 - Use the “tight infix” mechanism from this (accepted) GHC proposal 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> > | On Behalf Of Joachim Breitner > | Sent: 30 March 2020 17:48 > | To: ghc-steering-committee > | 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&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 > | > | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach > | im- > | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com > %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 > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=02%7C01%7Csimonpj%40microsoft.com > %7Ce27e9c8f455b436e2be > | > e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 > | > 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= > | 0 > _______________________________________________ > 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: From simonpj at microsoft.com Tue Mar 31 11:02:14 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 31 Mar 2020 11:02:14 +0000 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: Message-ID: 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 Sent: 31 March 2020 11:41 To: Simon Peyton Jones Cc: Joachim Breitner ; ghc-steering-committee ; Neil Mitchell ; Shayne Fletcher 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 > 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 * Use the “tight infix” mechanism from this (accepted) GHC proposal 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 > | On Behalf Of Joachim Breitner | Sent: 30 March 2020 17:48 | To: ghc-steering-committee > | 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&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 | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%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 | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b436e2be | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= | 0 _______________________________________________ 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: From rae at richarde.dev Tue Mar 31 11:36:37 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 31 Mar 2020 12:36:37 +0100 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: Message-ID: <0D3D6F19-933F-4ED9-BDF7-E294D8C3751A@richarde.dev> 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 wrote: > > On Tue, 31 Mar 2020 at 11:08, Simon Peyton Jones via ghc-steering-committee > 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 > > Use the “tight infix” mechanism from this (accepted) GHC proposal > > 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 > > | On Behalf Of Joachim Breitner > | Sent: 30 March 2020 17:48 > | To: ghc-steering-committee > > | 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&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 > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach > | im- > | breitner.de %2F&data=02%7C01%7Csimonpj%40microsoft.com %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 > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | kell.org %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=02%7C01%7Csimonpj%40microsoft.com %7Ce27e9c8f455b436e2be > | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 > | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= > | 0 > _______________________________________________ > ghc-steering-committee mailing list > 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: From simonpj at microsoft.com Tue Mar 31 11:48:20 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 31 Mar 2020 11:48:20 +0000 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: <0D3D6F19-933F-4ED9-BDF7-E294D8C3751A@richarde.dev> References: <0D3D6F19-933F-4ED9-BDF7-E294D8C3751A@richarde.dev> Message-ID: What features of the proposal document are actually a part of the proposal? Well, all of it! I had supposed that had been clear for some time; my apologies if not. If are other aspects of the proposal that you don’t like, please say so now! 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 Sent: 31 March 2020 12:37 To: Simon Marlow Cc: Simon Peyton Jones ; Neil Mitchell ; ghc-steering-committee ; Joachim Breitner ; Shayne Fletcher 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 > wrote: On Tue, 31 Mar 2020 at 11:08, Simon Peyton Jones via ghc-steering-committee > 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 * Use the “tight infix” mechanism from this (accepted) GHC proposal 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 > | On Behalf Of Joachim Breitner | Sent: 30 March 2020 17:48 | To: ghc-steering-committee > | 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&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 | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%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 | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b436e2be | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= | 0 _______________________________________________ ghc-steering-committee mailing list 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: From eric at seidel.io Tue Mar 31 12:44:26 2020 From: eric at seidel.io (Eric Seidel) Date: Tue, 31 Mar 2020 08:44:26 -0400 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: Message-ID: <48bc7daa-ed14-45ea-83cc-9fdd15669c40@www.fastmail.com> I've read through the draft and think it does a nice job of addressing the various camps. I like how you've positioned C2a as a conservative initial direction with room for future extensions, and a set of minimal requirements for future extensions. I'm not particularly fond of the existing ideas for parsing `(e).x` but I support the principle behind it. Thanks! On Tue, Mar 31, 2020, at 06:08, Simon Peyton Jones via ghc-steering-committee 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. > > 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 > | On Behalf Of Joachim Breitner > | Sent: 30 March 2020 17:48 > | To: ghc-steering-committee > | 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&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 > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach > | im- > | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%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 > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b436e2be > | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 > | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= > | 0 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From rae at richarde.dev Tue Mar 31 12:52:24 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 31 Mar 2020 13:52:24 +0100 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: <0D3D6F19-933F-4ED9-BDF7-E294D8C3751A@richarde.dev> Message-ID: > On Mar 31, 2020, at 12:48 PM, Simon Peyton Jones 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 ), 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 > Syntax for record selection r.x; this proposal > 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 > Sent: 31 March 2020 12:37 > To: Simon Marlow > Cc: Simon Peyton Jones ; Neil Mitchell ; ghc-steering-committee ; Joachim Breitner ; Shayne Fletcher > 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 > wrote: > > On Tue, 31 Mar 2020 at 11:08, Simon Peyton Jones via ghc-steering-committee > 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 > > > Use the “tight infix” mechanism from this (accepted) GHC proposal > > 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 > > | On Behalf Of Joachim Breitner > | Sent: 30 March 2020 17:48 > | To: ghc-steering-committee > > | 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&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 > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach > | im- > | breitner.de %2F&data=02%7C01%7Csimonpj%40microsoft.com %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 > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | kell.org %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=02%7C01%7Csimonpj%40microsoft.com %7Ce27e9c8f455b436e2be > | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 > | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= > | 0 > _______________________________________________ > ghc-steering-committee mailing list > 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: From simonpj at microsoft.com Tue Mar 31 13:09:15 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 31 Mar 2020 13:09:15 +0000 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: <0D3D6F19-933F-4ED9-BDF7-E294D8C3751A@richarde.dev> Message-ID: 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 Sent: 31 March 2020 13:52 To: Simon Peyton Jones Cc: Simon Marlow ; Neil Mitchell ; ghc-steering-committee ; Joachim Breitner ; Shayne Fletcher Subject: Re: [ghc-steering-committee] Record dot syntax: vote results On Mar 31, 2020, at 12:48 PM, Simon Peyton Jones > 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), 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 > Sent: 31 March 2020 12:37 To: Simon Marlow > Cc: Simon Peyton Jones >; Neil Mitchell >; ghc-steering-committee >; Joachim Breitner >; Shayne Fletcher > 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 > wrote: On Tue, 31 Mar 2020 at 11:08, Simon Peyton Jones via ghc-steering-committee > 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 * Use the “tight infix” mechanism from this (accepted) GHC proposal 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 > | On Behalf Of Joachim Breitner | Sent: 30 March 2020 17:48 | To: ghc-steering-committee > | 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&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 | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%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 | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b436e2be | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= | 0 _______________________________________________ ghc-steering-committee mailing list 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: From rae at richarde.dev Tue Mar 31 14:19:59 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 31 Mar 2020 15:19:59 +0100 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: <0D3D6F19-933F-4ED9-BDF7-E294D8C3751A@richarde.dev> Message-ID: <6A51EA29-40C9-4388-8024-4C00F25467DE@richarde.dev> > On Mar 31, 2020, at 2:09 PM, Simon Peyton Jones wrote: > > 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. Done. Tiny changes, but I think they will avoid the mistakes I made in interpretation. > > > 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. That is interesting, but I say that it is too late. Effectively, we've accepted this proposal (modulo "what happens next"). You're welcome to write a fresh proposal with that idea. :) Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Mar 31 17:08:32 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 31 Mar 2020 19:08:32 +0200 Subject: [ghc-steering-committee] Please review #314: -Wnoncanonical-mumble-instances, Shepherd: Tom Harding Message-ID: Dear Committee, this is your secretary speaking: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default has been proposed by Fumiaki Kinoshita https://github.com/ghc-proposals/ghc-proposals/pull/314 https://github.com/fumieval/ghc-proposals/blob/master/proposals/0000-warn-noncanonical-monad-instance-by-default.md I propose Tom Harding as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From iavor.diatchki at gmail.com Tue Mar 31 22:08:45 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 31 Mar 2020 15:08:45 -0700 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: <6A51EA29-40C9-4388-8024-4C00F25467DE@richarde.dev> References: <0D3D6F19-933F-4ED9-BDF7-E294D8C3751A@richarde.dev> <6A51EA29-40C9-4388-8024-4C00F25467DE@richarde.dev> Message-ID: Hello, I think accepting (C2a) over (C4) is a mistake, and reading Simon's specification of (C2a) does nothing to dispel my uneasiness about this choice. To Alejandro's points: - As Joachim pointed out, (C4) is how OCaml works, not (C2a). I wonder what the additional complexity of the specification buys us? In the draft document Simon describes it as "more conservative", but it actually requires more work to both implement and specify. - Indeed, you could write some expressions that might look confusing at first, but I don't see why would you? After all, one could use the exact same argument for many other notations in pretty much any programming language (e.g., operator precedences can be used to write confusing code---it doesn't mean that they are not very useful sometime). - Using white space in selectors is probably not going to be used a lot, but I could imagine it being useful if you have some nested records, and the field names are long. For example, I could see myself writing something like this: ``` someRecord .outterField .innerField ``` I realize this style could be a matter of taste, but I don't see any reason for us to go out of our way to disallow it. -Iavor On Tue, Mar 31, 2020 at 7:21 AM Richard Eisenberg wrote: > > > On Mar 31, 2020, at 2:09 PM, Simon Peyton Jones > wrote: > > 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. > > > Done. Tiny changes, but I think they will avoid the mistakes I made in > interpretation. > > > > 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. > > > That is interesting, but I say that it is too late. Effectively, we've > accepted this proposal (modulo "what happens next"). You're welcome to > write a fresh proposal with that idea. :) > > Richard > _______________________________________________ > 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: From simonpj at microsoft.com Tue Mar 31 22:38:37 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 31 Mar 2020 22:38:37 +0000 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: <0D3D6F19-933F-4ED9-BDF7-E294D8C3751A@richarde.dev> <6A51EA29-40C9-4388-8024-4C00F25467DE@richarde.dev> Message-ID: I think accepting (C2a) over (C4) is a mistake, and reading Simon's specification of (C2a) does nothing to dispel my uneasiness about this choice. I know! For my part, I would much prefer (C6), which also avoids this entire question, and also allows white space in selectors. But I failed to persuade you all to vote for (C6), and I accept the result. I suppose the same is true for you. Simon From: Iavor Diatchki Sent: 31 March 2020 23:09 To: Richard Eisenberg Cc: Simon Peyton Jones ; Neil Mitchell ; Joachim Breitner ; ghc-steering-committee ; Shayne Fletcher Subject: Re: [ghc-steering-committee] Record dot syntax: vote results Hello, I think accepting (C2a) over (C4) is a mistake, and reading Simon's specification of (C2a) does nothing to dispel my uneasiness about this choice. To Alejandro's points: - As Joachim pointed out, (C4) is how OCaml works, not (C2a). I wonder what the additional complexity of the specification buys us? In the draft document Simon describes it as "more conservative", but it actually requires more work to both implement and specify. - Indeed, you could write some expressions that might look confusing at first, but I don't see why would you? After all, one could use the exact same argument for many other notations in pretty much any programming language (e.g., operator precedences can be used to write confusing code---it doesn't mean that they are not very useful sometime). - Using white space in selectors is probably not going to be used a lot, but I could imagine it being useful if you have some nested records, and the field names are long. For example, I could see myself writing something like this: ``` someRecord .outterField .innerField ``` I realize this style could be a matter of taste, but I don't see any reason for us to go out of our way to disallow it. -Iavor On Tue, Mar 31, 2020 at 7:21 AM Richard Eisenberg > wrote: On Mar 31, 2020, at 2:09 PM, Simon Peyton Jones > wrote: 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. Done. Tiny changes, but I think they will avoid the mistakes I made in interpretation. 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. That is interesting, but I say that it is too late. Effectively, we've accepted this proposal (modulo "what happens next"). You're welcome to write a fresh proposal with that idea. :) Richard _______________________________________________ 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: From tomjharding at live.co.uk Tue Mar 31 22:49:52 2020 From: tomjharding at live.co.uk (Tom Harding) Date: Tue, 31 Mar 2020 22:49:52 +0000 Subject: [ghc-steering-committee] Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default Message-ID: <1810F4C4-3566-4349-BCC8-70B1064F8126@live.co.uk> Friends, This proposal seems very reasonable to me, and the ramifications are minimal. Consequently, I recommend that we accept. I’d now like to open the proposal up to committee discussion. My belief is that the issue be fairly uncontentious (particularly as prior behaviour can be fully restored by explicitly passing the relevant `-Wno-...` flags to the compiler), but I welcome any thoughts either way. Thanks, Tom