From mail at joachim-breitner.de Wed May 1 18:51:20 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 01 May 2019 20:51:20 +0200 Subject: [ghc-steering-committee] Procedural change vote Message-ID: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> Dear committee, quick recap: one of our valued proposal writers, Matthew, expressed unhappiness about our discussion proposal, with two important (but not the only complains) issues the inability to react to a looming rejection, and general bad insight into the discussion. Based on that feedback (thanks again, Matt!) we discussed various options. Discussion has ebbed down, and because it affects our policies, I’d like to hold a formal vote. There are three possible changes to consider, plus the option of doing nothing. The options are A. All discussion on GitHub. Our process essentially stays the same, but all discussion happens on GitHub. The mailing list is used only for status messages (new proposal, new recommendation, result, regular summary messages). During the deliberation phase, we will ask bystanders (non-members, non-authors) to refrain from making the discussion noisy. Pros: Best visibility. Easy to get feedback from authors. No fragmented discussion places. Cons: Less separation of discussion, less of a “protected space” for us”, possibly more noise, can’t technically enforce that nobody else comments B. Shepherd discussion looming rejection with the authors first. This keeps the discussion on the mailing list, but the shepherd, before recommending to reject a proposal, needs to _first_ lay out their reasons on GitHub, wait for the authors to rebut, and possibly discusses with them. I spelled out possible wording of this already on https://github.com/ghc-proposals/ghc-proposals/pull/221 Pros: Authors are taken more serious, have a say, while keeping our discussion separate Cons: More work for shepherd. Incentives are set to lean towards just recommending acceptance. Authors don't get to rebut if shepherd wants to accept, but then the committee leans towards rejection. AB. The combination of the two above I.e. author rebuttal before shepherd recommends rejection but then _also_ the committee discussion on GitHub Also spelled out already on https://github.com/ghc-proposals/ghc-proposals/pull/225 0. Do nothing. Please vote by responding to this thread with a linear ordering of your preferences. For example, my vote is AB > B > A > 0 Please cast a vote until Sunday May 5th. You can change your vote any time until voting is concluded. Voting will be concluded when no votes have been cast, but not before Sunday May 5th. We will accept the option that is preferred over any other option by a majority of the votes. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Wed May 1 18:56:28 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 01 May 2019 20:56:28 +0200 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: <9868312E-68E9-4EC9-873A-D6F6154FD67C@cs.brynmawr.edu> References: <87zhunv09p.fsf@smart-cactus.org> <828C422B-7CFB-45A0-96DD-66C14AC3A2E1@cs.brynmawr.edu> <592230B0-33F9-468F-8676-F6DED97E49CE@seidel.io> <1545190628.935552.1613138120.0DE606A9@webmail.messagingengine.com> <1545216599.1040104.1613362848.19A543DA@webmail.messagingengine.com> <5152A0BE-E7B9-489A-A7C7-8C5BCAE01E0C@cs.brynmawr.edu> <1547917186.2586273.1638789112.522284A4@webmail.messagingengine.com> <9868312E-68E9-4EC9-873A-D6F6154FD67C@cs.brynmawr.edu> Message-ID: Hi, I am bit lost here. Richard, do you feel confident to talk to the authors about the changes we are still waiting for (or just do them on the PR branch yourself), so that we can merge this accepted proposal? Cheers, Joachim Am Montag, den 11.02.2019, 16:20 -0500 schrieb Richard Eisenberg: > I see that you've posted acceptance, Ben. Thanks. But my understanding is that the accepted version was the one without `lift` in the class. Is that your understanding, too? If so, would you mind posting to the proposal author? (I think it's cleaner to have communication on this come from the shepherd.) > > Thanks! > Richard > > > On Jan 30, 2019, at 8:09 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > > > I'm content with liftTyped. And while (2) is nicer ab-initio, it's not a big deal having two members of the class, so I'm fine with (1). > > > > Simon > > > > > -----Original Message----- > > > From: ghc-steering-committee > > > On Behalf Of Eric Seidel > > > Sent: 19 January 2019 17:00 > > > To: ghc-steering-committee at haskell.org > > > Subject: Re: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped > > > (recommendation: accept) > > > > > > Let's try to pick this discussion back up. The proposal has been > > > lingering on our end for a couple months now! > > > > > > We all seem to be in agreement that the basic proposal of adding > > > `liftTyped` should be accepted. The discussion has mostly focused on > > > backwards-compatibility concerns around the default implementation of > > > `Lift`, specifically that the new mutually-recursive definitions of > > > `lift` and `liftTyped` could break **clients** of libraries that use TH > > > without even issuing a warning in the libraries themselves. > > > > > > There are two proposed solutions that seem to have some support. > > > > > > 1. I suggested a targeted warning/error about empty `Lift` instances that > > > could be bundled with GHC. TH is bundled with GHC, so this would > > > guarantee that we notify (or break) libraries before client code is > > > affected. It would also let library authors avoid CPP while supporting > > > multiple versions of TH. Joachim expressed his support for this solution. > > > > > > 2. The proposal suggests an alternative that replaces `lift` with > > > `liftTyped` as the sole method of `Lift`. This is probably how we would > > > design the `Lift` class today if we were starting from scratch. On the > > > other hand, it forces library authors to use CPP to support multiple > > > versions of TH, which people often try to avoid (e.g. due to tooling > > > issues). Simon and Richard have expressed support for this solution. > > > > > > I would actually be happy with either solution. > > > > > > Joachim, are you happy with option 2? If so, perhaps we should just agree > > > on it and move forward with the proposal. > > > > > > On Fri, Dec 21, 2018, at 22:04, Richard Eisenberg wrote: > > > > I favor Simon's suggestion. Just rip out `lift` from the class and > > > > define it as a top-level function. This breaks backward-compat, but in > > > > an inescapable way. And TH users are accustomed to breakage. My > > > > problem earlier wasn't just that it wasn't backward-compatible, but > > > > that it was incompatible in such a terrible way. Simon's suggestion > > > > leads to a better incompatibility. > > > > > > > > Richard > > > > > > > > > On Dec 19, 2018, at 5:49 AM, Eric Seidel wrote: > > > > > > > > > > Joachim wrote: > > > > >> I think 1. is at odds in GHC – we allow partiality in other places > > > > >> as well (partially initialized records, for example). Disallowing > > > > >> it feels like a too fundamental change to the language for the > > > > >> problem we need to solve here. > > > > > > > > > > Yes, I agree that changing the semantics of MINIMAL solely to fix > > > this issue is not a great idea. But having a MINIMAL violation be a > > > warning instead of an error generally feels shady to me. > > > > > > > > > > The only use of MINIMAL pragmas I've seen is to break mutually > > > recursive definitions. That means there's an important difference between > > > MINIMAL pragmas and other sources of partiality. In a partial record > > > construction, your program will be fine so long as you don't access the > > > uninitialized fields. This is dangerous, so we warn you about it, but > > > it's still possible that your program will be correct. With a MINIMAL > > > violation, it seems like the programmer is telling us that an instance > > > *cannot* be correct unless it provides the minimal definitions. > > > > > > > > > > But I shouldn't derail the conversation.. Perhaps I'll write up a > > > separate proposal about MINIMAL. > > > > > > > > > >> 3. is a neat idea, but again a very big cannon for a niche problem. > > > > >> If we _had_ ghc-fix, then this might be a good approach, and we can > > > > >> keep this in mind as additional evidence that ghc-fix would be good > > > > >> (GSOC anyone), but let's not wait for that here. > > > > > > > > > > Indeed, I wouldn't make this wait on ghc-fix either, but it would be > > > a very nice thing to have right now! > > > > > > > > > >> 2. is good, I think. We have had plenty of such kludges, e.g. > > > > >> around the Monad refactoring. > > > > > > > > > > If we're ok with kludges like this to ease the migration, I think > > > it's clearly the simplest solution. > > > > > > > > > > --- > > > > > > > > > > Simon wrote: > > > > > > > > > >> Is there any reason for not adopting the second alternative in > > > section 5: make liftTyped the sole method of Lift? > > > > > > > > > > I suspect this would break more code than the current proposal, since > > > you do sometimes have to write a manual `lift` instance (eg if you have a > > > field like Text that doesn't have an instance). Fixing such code would > > > also require CPP, which we usually try to avoid. > > > > > _______________________________________________ > > > > > ghc-steering-committee mailing list > > > > > ghc-steering-committee at haskell.org > > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commi > > > > > ttee > > > > > > > _______________________________________________ > > > 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 -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From bravit111 at gmail.com Wed May 1 19:11:26 2019 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Wed, 1 May 2019 22:11:26 +0300 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> Message-ID: Hi Joachim, my vote is AB > A > B > 0 Regards, Vitaly ср, 1 мая 2019 г. в 21:51, Joachim Breitner : > Dear committee, > > quick recap: one of our valued proposal writers, Matthew, expressed > unhappiness about our discussion proposal, with two important (but not > the only complains) issues the inability to react to a looming > rejection, and general bad insight into the discussion. Based on that > feedback (thanks again, Matt!) we discussed various options. Discussion > has ebbed down, and because it affects our policies, I’d like to hold a > formal vote. > > There are three possible changes to consider, plus the option of doing > nothing. The options are > > A. All discussion on GitHub. > > Our process essentially stays the same, but all discussion happens > on GitHub. The mailing list is used only for status messages (new > proposal, new recommendation, result, regular summary messages). > During the deliberation phase, we will ask bystanders (non-members, > non-authors) to refrain from making the discussion noisy. > > Pros: Best visibility. Easy to get feedback from authors. No > fragmented discussion places. > > Cons: Less separation of discussion, less of a “protected space” for > us”, possibly more noise, can’t technically enforce that nobody else > comments > > B. Shepherd discussion looming rejection with the authors first. > > This keeps the discussion on the mailing list, but the shepherd, > before recommending to reject a proposal, needs to _first_ lay out > their reasons on GitHub, wait for the authors to rebut, and possibly > discusses with them. > > I spelled out possible wording of this already on > https://github.com/ghc-proposals/ghc-proposals/pull/221 > > Pros: Authors are taken more serious, have a say, while keeping our > discussion separate > > Cons: More work for shepherd. Incentives are set to lean towards > just recommending acceptance. Authors don't get to rebut if shepherd > wants to accept, but then the committee leans towards rejection. > > AB. The combination of the two above > > I.e. author rebuttal before shepherd recommends rejection > but then _also_ the committee discussion on GitHub > > Also spelled out already on > https://github.com/ghc-proposals/ghc-proposals/pull/225 > > 0. Do nothing. > > > Please vote by responding to this thread with a linear ordering of your > preferences. For example, my vote is > > AB > B > A > 0 > > Please cast a vote until Sunday May 5th. You can change your vote any > time until voting is concluded. Voting will be concluded when no votes > have been cast, but not before Sunday May 5th. We will accept the > option that is preferred over any other option by a majority of the > votes. > > > 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 May 1 19:41:22 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 1 May 2019 19:41:22 +0000 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> Message-ID: AB > B > A > 0 Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 01 May 2019 19:51 | To: ghc-steering-committee | Subject: [ghc-steering-committee] Procedural change vote | | Dear committee, | | quick recap: one of our valued proposal writers, Matthew, expressed | unhappiness about our discussion proposal, with two important (but not the | only complains) issues the inability to react to a looming rejection, and | general bad insight into the discussion. Based on that feedback (thanks | again, Matt!) we discussed various options. Discussion has ebbed down, and | because it affects our policies, I’d like to hold a formal vote. | | There are three possible changes to consider, plus the option of doing | nothing. The options are | | A. All discussion on GitHub. | | Our process essentially stays the same, but all discussion happens | on GitHub. The mailing list is used only for status messages (new | proposal, new recommendation, result, regular summary messages). | During the deliberation phase, we will ask bystanders (non-members, | non-authors) to refrain from making the discussion noisy. | | Pros: Best visibility. Easy to get feedback from authors. No | fragmented discussion places. | | Cons: Less separation of discussion, less of a “protected space” for | us”, possibly more noise, can’t technically enforce that nobody else | comments | | B. Shepherd discussion looming rejection with the authors first. | | This keeps the discussion on the mailing list, but the shepherd, | before recommending to reject a proposal, needs to _first_ lay out | their reasons on GitHub, wait for the authors to rebut, and possibly | discusses with them. | | I spelled out possible wording of this already on | https://github.com/ghc-proposals/ghc-proposals/pull/221 | | Pros: Authors are taken more serious, have a say, while keeping our | discussion separate | | Cons: More work for shepherd. Incentives are set to lean towards | just recommending acceptance. Authors don't get to rebut if shepherd | wants to accept, but then the committee leans towards rejection. | | AB. The combination of the two above | | I.e. author rebuttal before shepherd recommends rejection | but then _also_ the committee discussion on GitHub | | Also spelled out already on | https://github.com/ghc-proposals/ghc-proposals/pull/225 | | 0. Do nothing. | | | Please vote by responding to this thread with a linear ordering of your | preferences. For example, my vote is | | AB > B > A > 0 | | Please cast a vote until Sunday May 5th. You can change your vote any time | until voting is concluded. Voting will be concluded when no votes have | been cast, but not before Sunday May 5th. We will accept the option that | is preferred over any other option by a majority of the votes. | | | Cheers, | Joachim | | -- | Joachim Breitner | mail at joachim-breitner.de | http://www.joachim-breitner.de/ From cma at bitemyapp.com Wed May 1 20:13:08 2019 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 1 May 2019 15:13:08 -0500 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> Message-ID: AB > B > A > 0 I don't believe we should do nothing when someone has protested in good faith. I don't think GitHub discussion alone properly addresses their concerns and objections as well as the "B" option, but the best option overall seems to be AB to my mind. Transparency + responsiveness. On Wed, May 1, 2019 at 2:41 PM Simon Peyton Jones via ghc-steering-committee wrote: > > AB > B > A > 0 > > Simon > > | -----Original Message----- > | From: ghc-steering-committee > | On Behalf Of Joachim Breitner > | Sent: 01 May 2019 19:51 > | To: ghc-steering-committee > | Subject: [ghc-steering-committee] Procedural change vote > | > | Dear committee, > | > | quick recap: one of our valued proposal writers, Matthew, expressed > | unhappiness about our discussion proposal, with two important (but not the > | only complains) issues the inability to react to a looming rejection, and > | general bad insight into the discussion. Based on that feedback (thanks > | again, Matt!) we discussed various options. Discussion has ebbed down, and > | because it affects our policies, I’d like to hold a formal vote. > | > | There are three possible changes to consider, plus the option of doing > | nothing. The options are > | > | A. All discussion on GitHub. > | > | Our process essentially stays the same, but all discussion happens > | on GitHub. The mailing list is used only for status messages (new > | proposal, new recommendation, result, regular summary messages). > | During the deliberation phase, we will ask bystanders (non-members, > | non-authors) to refrain from making the discussion noisy. > | > | Pros: Best visibility. Easy to get feedback from authors. No > | fragmented discussion places. > | > | Cons: Less separation of discussion, less of a “protected space” for > | us”, possibly more noise, can’t technically enforce that nobody else > | comments > | > | B. Shepherd discussion looming rejection with the authors first. > | > | This keeps the discussion on the mailing list, but the shepherd, > | before recommending to reject a proposal, needs to _first_ lay out > | their reasons on GitHub, wait for the authors to rebut, and possibly > | discusses with them. > | > | I spelled out possible wording of this already on > | https://github.com/ghc-proposals/ghc-proposals/pull/221 > | > | Pros: Authors are taken more serious, have a say, while keeping our > | discussion separate > | > | Cons: More work for shepherd. Incentives are set to lean towards > | just recommending acceptance. Authors don't get to rebut if shepherd > | wants to accept, but then the committee leans towards rejection. > | > | AB. The combination of the two above > | > | I.e. author rebuttal before shepherd recommends rejection > | but then _also_ the committee discussion on GitHub > | > | Also spelled out already on > | https://github.com/ghc-proposals/ghc-proposals/pull/225 > | > | 0. Do nothing. > | > | > | Please vote by responding to this thread with a linear ordering of your > | preferences. For example, my vote is > | > | AB > B > A > 0 > | > | Please cast a vote until Sunday May 5th. You can change your vote any time > | until voting is concluded. Voting will be concluded when no votes have > | been cast, but not before Sunday May 5th. We will accept the option that > | is preferred over any other option by a majority of the votes. > | > | > | 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 -- Chris Allen Currently working on http://haskellbook.com From eric at seidel.io Wed May 1 21:30:07 2019 From: eric at seidel.io (Eric Seidel) Date: Wed, 01 May 2019 17:30:07 -0400 Subject: [ghc-steering-committee] =?utf-8?b?W1Byb3Bvc2FsXSAjMTc1OiBMaWZ0?= =?utf-8?q?=2EliftTyped_=28recommendation=3A_accept=29?= In-Reply-To: References: <87zhunv09p.fsf@smart-cactus.org> <828C422B-7CFB-45A0-96DD-66C14AC3A2E1@cs.brynmawr.edu> <592230B0-33F9-468F-8676-F6DED97E49CE@seidel.io> <1545190628.935552.1613138120.0DE606A9@webmail.messagingengine.com> <1545216599.1040104.1613362848.19A543DA@webmail.messagingengine.com> <5152A0BE-E7B9-489A-A7C7-8C5BCAE01E0C@cs.brynmawr.edu> <1547917186.2586273.1638789112.522284A4@webmail.messagingengine.com> <9868312E-68E9-4EC9-873A-D6F6154FD67C@cs.brynmawr.edu> Message-ID: I think this proposal has been subsumed by https://github.com/ghc-proposals/ghc-proposals/pull/209. On Wed, May 1, 2019, at 14:56, Joachim Breitner wrote: > Hi, > > I am bit lost here. Richard, do you feel confident to talk to the > authors about the changes we are still waiting for (or just do them on > the PR branch yourself), so that we can merge this accepted proposal? > > Cheers, > Joachim > > Am Montag, den 11.02.2019, 16:20 -0500 schrieb Richard Eisenberg: > > I see that you've posted acceptance, Ben. Thanks. But my understanding is that the accepted version was the one without `lift` in the class. Is that your understanding, too? If so, would you mind posting to the proposal author? (I think it's cleaner to have communication on this come from the shepherd.) > > > > Thanks! > > Richard > > > > > On Jan 30, 2019, at 8:09 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > > > > > I'm content with liftTyped. And while (2) is nicer ab-initio, it's not a big deal having two members of the class, so I'm fine with (1). > > > > > > Simon > > > > > > > -----Original Message----- > > > > From: ghc-steering-committee > > > > On Behalf Of Eric Seidel > > > > Sent: 19 January 2019 17:00 > > > > To: ghc-steering-committee at haskell.org > > > > Subject: Re: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped > > > > (recommendation: accept) > > > > > > > > Let's try to pick this discussion back up. The proposal has been > > > > lingering on our end for a couple months now! > > > > > > > > We all seem to be in agreement that the basic proposal of adding > > > > `liftTyped` should be accepted. The discussion has mostly focused on > > > > backwards-compatibility concerns around the default implementation of > > > > `Lift`, specifically that the new mutually-recursive definitions of > > > > `lift` and `liftTyped` could break **clients** of libraries that use TH > > > > without even issuing a warning in the libraries themselves. > > > > > > > > There are two proposed solutions that seem to have some support. > > > > > > > > 1. I suggested a targeted warning/error about empty `Lift` instances that > > > > could be bundled with GHC. TH is bundled with GHC, so this would > > > > guarantee that we notify (or break) libraries before client code is > > > > affected. It would also let library authors avoid CPP while supporting > > > > multiple versions of TH. Joachim expressed his support for this solution. > > > > > > > > 2. The proposal suggests an alternative that replaces `lift` with > > > > `liftTyped` as the sole method of `Lift`. This is probably how we would > > > > design the `Lift` class today if we were starting from scratch. On the > > > > other hand, it forces library authors to use CPP to support multiple > > > > versions of TH, which people often try to avoid (e.g. due to tooling > > > > issues). Simon and Richard have expressed support for this solution. > > > > > > > > I would actually be happy with either solution. > > > > > > > > Joachim, are you happy with option 2? If so, perhaps we should just agree > > > > on it and move forward with the proposal. > > > > > > > > On Fri, Dec 21, 2018, at 22:04, Richard Eisenberg wrote: > > > > > I favor Simon's suggestion. Just rip out `lift` from the class and > > > > > define it as a top-level function. This breaks backward-compat, but in > > > > > an inescapable way. And TH users are accustomed to breakage. My > > > > > problem earlier wasn't just that it wasn't backward-compatible, but > > > > > that it was incompatible in such a terrible way. Simon's suggestion > > > > > leads to a better incompatibility. > > > > > > > > > > Richard > > > > > > > > > > > On Dec 19, 2018, at 5:49 AM, Eric Seidel wrote: > > > > > > > > > > > > Joachim wrote: > > > > > >> I think 1. is at odds in GHC – we allow partiality in other places > > > > > >> as well (partially initialized records, for example). Disallowing > > > > > >> it feels like a too fundamental change to the language for the > > > > > >> problem we need to solve here. > > > > > > > > > > > > Yes, I agree that changing the semantics of MINIMAL solely to fix > > > > this issue is not a great idea. But having a MINIMAL violation be a > > > > warning instead of an error generally feels shady to me. > > > > > > > > > > > > The only use of MINIMAL pragmas I've seen is to break mutually > > > > recursive definitions. That means there's an important difference between > > > > MINIMAL pragmas and other sources of partiality. In a partial record > > > > construction, your program will be fine so long as you don't access the > > > > uninitialized fields. This is dangerous, so we warn you about it, but > > > > it's still possible that your program will be correct. With a MINIMAL > > > > violation, it seems like the programmer is telling us that an instance > > > > *cannot* be correct unless it provides the minimal definitions. > > > > > > > > > > > > But I shouldn't derail the conversation.. Perhaps I'll write up a > > > > separate proposal about MINIMAL. > > > > > > > > > > > >> 3. is a neat idea, but again a very big cannon for a niche problem. > > > > > >> If we _had_ ghc-fix, then this might be a good approach, and we can > > > > > >> keep this in mind as additional evidence that ghc-fix would be good > > > > > >> (GSOC anyone), but let's not wait for that here. > > > > > > > > > > > > Indeed, I wouldn't make this wait on ghc-fix either, but it would be > > > > a very nice thing to have right now! > > > > > > > > > > > >> 2. is good, I think. We have had plenty of such kludges, e.g. > > > > > >> around the Monad refactoring. > > > > > > > > > > > > If we're ok with kludges like this to ease the migration, I think > > > > it's clearly the simplest solution. > > > > > > > > > > > > --- > > > > > > > > > > > > Simon wrote: > > > > > > > > > > > >> Is there any reason for not adopting the second alternative in > > > > section 5: make liftTyped the sole method of Lift? > > > > > > > > > > > > I suspect this would break more code than the current proposal, since > > > > you do sometimes have to write a manual `lift` instance (eg if you have a > > > > field like Text that doesn't have an instance). Fixing such code would > > > > also require CPP, which we usually try to avoid. > > > > > > _______________________________________________ > > > > > > ghc-steering-committee mailing list > > > > > > ghc-steering-committee at haskell.org > > > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commi > > > > > > ttee > > > > > > > > > _______________________________________________ > > > > 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 > -- > 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 > > Attachments: > * signature.asc From eric at seidel.io Wed May 1 22:54:23 2019 From: eric at seidel.io (Eric Seidel) Date: Wed, 01 May 2019 18:54:23 -0400 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> Message-ID: <6db1974c-cfeb-4b83-bbb8-3b8d4266c9eb@www.fastmail.com> AB > B > A > 0 On Wed, May 1, 2019, at 16:13, Christopher Allen wrote: > AB > B > A > 0 > > I don't believe we should do nothing when someone has protested in good faith. > > I don't think GitHub discussion alone properly addresses their > concerns and objections as well as the "B" option, but the best option > overall seems to be AB to my mind. Transparency + responsiveness. > > On Wed, May 1, 2019 at 2:41 PM Simon Peyton Jones via > ghc-steering-committee wrote: > > > > AB > B > A > 0 > > > > Simon > > > > | -----Original Message----- > > | From: ghc-steering-committee > > | On Behalf Of Joachim Breitner > > | Sent: 01 May 2019 19:51 > > | To: ghc-steering-committee > > | Subject: [ghc-steering-committee] Procedural change vote > > | > > | Dear committee, > > | > > | quick recap: one of our valued proposal writers, Matthew, expressed > > | unhappiness about our discussion proposal, with two important (but not the > > | only complains) issues the inability to react to a looming rejection, and > > | general bad insight into the discussion. Based on that feedback (thanks > > | again, Matt!) we discussed various options. Discussion has ebbed down, and > > | because it affects our policies, I’d like to hold a formal vote. > > | > > | There are three possible changes to consider, plus the option of doing > > | nothing. The options are > > | > > | A. All discussion on GitHub. > > | > > | Our process essentially stays the same, but all discussion happens > > | on GitHub. The mailing list is used only for status messages (new > > | proposal, new recommendation, result, regular summary messages). > > | During the deliberation phase, we will ask bystanders (non-members, > > | non-authors) to refrain from making the discussion noisy. > > | > > | Pros: Best visibility. Easy to get feedback from authors. No > > | fragmented discussion places. > > | > > | Cons: Less separation of discussion, less of a “protected space” for > > | us”, possibly more noise, can’t technically enforce that nobody else > > | comments > > | > > | B. Shepherd discussion looming rejection with the authors first. > > | > > | This keeps the discussion on the mailing list, but the shepherd, > > | before recommending to reject a proposal, needs to _first_ lay out > > | their reasons on GitHub, wait for the authors to rebut, and possibly > > | discusses with them. > > | > > | I spelled out possible wording of this already on > > | https://github.com/ghc-proposals/ghc-proposals/pull/221 > > | > > | Pros: Authors are taken more serious, have a say, while keeping our > > | discussion separate > > | > > | Cons: More work for shepherd. Incentives are set to lean towards > > | just recommending acceptance. Authors don't get to rebut if shepherd > > | wants to accept, but then the committee leans towards rejection. > > | > > | AB. The combination of the two above > > | > > | I.e. author rebuttal before shepherd recommends rejection > > | but then _also_ the committee discussion on GitHub > > | > > | Also spelled out already on > > | https://github.com/ghc-proposals/ghc-proposals/pull/225 > > | > > | 0. Do nothing. > > | > > | > > | Please vote by responding to this thread with a linear ordering of your > > | preferences. For example, my vote is > > | > > | AB > B > A > 0 > > | > > | Please cast a vote until Sunday May 5th. You can change your vote any time > > | until voting is concluded. Voting will be concluded when no votes have > > | been cast, but not before Sunday May 5th. We will accept the option that > > | is preferred over any other option by a majority of the votes. > > | > > | > > | 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 > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > 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 Thu May 2 07:43:28 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 02 May 2019 09:43:28 +0200 Subject: [ghc-steering-committee] [Proposal] #175: Lift.liftTyped (recommendation: accept) In-Reply-To: References: <87zhunv09p.fsf@smart-cactus.org> <828C422B-7CFB-45A0-96DD-66C14AC3A2E1@cs.brynmawr.edu> <592230B0-33F9-468F-8676-F6DED97E49CE@seidel.io> <1545190628.935552.1613138120.0DE606A9@webmail.messagingengine.com> <1545216599.1040104.1613362848.19A543DA@webmail.messagingengine.com> <5152A0BE-E7B9-489A-A7C7-8C5BCAE01E0C@cs.brynmawr.edu> <1547917186.2586273.1638789112.522284A4@webmail.messagingengine.com> <9868312E-68E9-4EC9-873A-D6F6154FD67C@cs.brynmawr.edu> Message-ID: Hi, Am Mittwoch, den 01.05.2019, 17:30 -0400 schrieb Eric Seidel: > I think this proposal has been subsumed by https://github.com/ghc-proposals/ghc-proposals/pull/209. thanks. In this case I’ll close #175. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Thu May 2 07:51:21 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 02 May 2019 09:51:21 +0200 Subject: [ghc-steering-committee] #190: Module qualified syntax, recommendation: accept In-Reply-To: References: <784cd5209a8ff3d18341b524ae95e0cc671797fb.camel@joachim-breitner.de> <2A4CEC6F-5A55-43D8-9714-F507AE1A8CBC@cs.brynmawr.edu> <7e2210851b53e68fb08f81da78ad22039816f517.camel@joachim-breitner.de> Message-ID: <5c4a7f6cf3ef00dc37877277533c275d2ee67ac6.camel@joachim-breitner.de> Hi, accepted and merged. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From marlowsd at gmail.com Thu May 2 08:08:58 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 2 May 2019 09:08:58 +0100 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: <6db1974c-cfeb-4b83-bbb8-3b8d4266c9eb@www.fastmail.com> References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> <6db1974c-cfeb-4b83-bbb8-3b8d4266c9eb@www.fastmail.com> Message-ID: AB > B > A > 0 On Wed, 1 May 2019 at 23:54, Eric Seidel wrote: > AB > B > A > 0 > > On Wed, May 1, 2019, at 16:13, Christopher Allen wrote: > > AB > B > A > 0 > > > > I don't believe we should do nothing when someone has protested in good > faith. > > > > I don't think GitHub discussion alone properly addresses their > > concerns and objections as well as the "B" option, but the best option > > overall seems to be AB to my mind. Transparency + responsiveness. > > > > On Wed, May 1, 2019 at 2:41 PM Simon Peyton Jones via > > ghc-steering-committee wrote: > > > > > > AB > B > A > 0 > > > > > > Simon > > > > > > | -----Original Message----- > > > | From: ghc-steering-committee < > ghc-steering-committee-bounces at haskell.org> > > > | On Behalf Of Joachim Breitner > > > | Sent: 01 May 2019 19:51 > > > | To: ghc-steering-committee > > > | Subject: [ghc-steering-committee] Procedural change vote > > > | > > > | Dear committee, > > > | > > > | quick recap: one of our valued proposal writers, Matthew, expressed > > > | unhappiness about our discussion proposal, with two important (but > not the > > > | only complains) issues the inability to react to a looming > rejection, and > > > | general bad insight into the discussion. Based on that feedback > (thanks > > > | again, Matt!) we discussed various options. Discussion has ebbed > down, and > > > | because it affects our policies, I’d like to hold a formal vote. > > > | > > > | There are three possible changes to consider, plus the option of > doing > > > | nothing. The options are > > > | > > > | A. All discussion on GitHub. > > > | > > > | Our process essentially stays the same, but all discussion happens > > > | on GitHub. The mailing list is used only for status messages (new > > > | proposal, new recommendation, result, regular summary messages). > > > | During the deliberation phase, we will ask bystanders > (non-members, > > > | non-authors) to refrain from making the discussion noisy. > > > | > > > | Pros: Best visibility. Easy to get feedback from authors. No > > > | fragmented discussion places. > > > | > > > | Cons: Less separation of discussion, less of a “protected space” > for > > > | us”, possibly more noise, can’t technically enforce that nobody > else > > > | comments > > > | > > > | B. Shepherd discussion looming rejection with the authors first. > > > | > > > | This keeps the discussion on the mailing list, but the shepherd, > > > | before recommending to reject a proposal, needs to _first_ lay out > > > | their reasons on GitHub, wait for the authors to rebut, and > possibly > > > | discusses with them. > > > | > > > | I spelled out possible wording of this already on > > > | https://github.com/ghc-proposals/ghc-proposals/pull/221 > > > | > > > | Pros: Authors are taken more serious, have a say, while keeping our > > > | discussion separate > > > | > > > | Cons: More work for shepherd. Incentives are set to lean towards > > > | just recommending acceptance. Authors don't get to rebut if > shepherd > > > | wants to accept, but then the committee leans towards rejection. > > > | > > > | AB. The combination of the two above > > > | > > > | I.e. author rebuttal before shepherd recommends rejection > > > | but then _also_ the committee discussion on GitHub > > > | > > > | Also spelled out already on > > > | https://github.com/ghc-proposals/ghc-proposals/pull/225 > > > | > > > | 0. Do nothing. > > > | > > > | > > > | Please vote by responding to this thread with a linear ordering of > your > > > | preferences. For example, my vote is > > > | > > > | AB > B > A > 0 > > > | > > > | Please cast a vote until Sunday May 5th. You can change your vote > any time > > > | until voting is concluded. Voting will be concluded when no votes > have > > > | been cast, but not before Sunday May 5th. We will accept the option > that > > > | is preferred over any other option by a majority of the votes. > > > | > > > | > > > | 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 > > > > > > > > -- > > Chris Allen > > Currently working on http://haskellbook.com > > _______________________________________________ > > 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 Thu May 2 18:01:36 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 2 May 2019 11:01:36 -0700 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> Message-ID: Of the given options I'll pick: AB > A > B > 0 Qualifier: I like option A, with the modification that since we are discussing things on Github, the proposer can jump in and clarify stuff, if they feel that the committee is misunderstanding something. -Iavor On Wed, May 1, 2019 at 11:51 AM Joachim Breitner wrote: > > Dear committee, > > quick recap: one of our valued proposal writers, Matthew, expressed > unhappiness about our discussion proposal, with two important (but not > the only complains) issues the inability to react to a looming > rejection, and general bad insight into the discussion. Based on that > feedback (thanks again, Matt!) we discussed various options. Discussion > has ebbed down, and because it affects our policies, I’d like to hold a > formal vote. > > There are three possible changes to consider, plus the option of doing > nothing. The options are > > A. All discussion on GitHub. > > Our process essentially stays the same, but all discussion happens > on GitHub. The mailing list is used only for status messages (new > proposal, new recommendation, result, regular summary messages). > During the deliberation phase, we will ask bystanders (non-members, > non-authors) to refrain from making the discussion noisy. > > Pros: Best visibility. Easy to get feedback from authors. No > fragmented discussion places. > > Cons: Less separation of discussion, less of a “protected space” for > us”, possibly more noise, can’t technically enforce that nobody else > comments > > B. Shepherd discussion looming rejection with the authors first. > > This keeps the discussion on the mailing list, but the shepherd, > before recommending to reject a proposal, needs to _first_ lay out > their reasons on GitHub, wait for the authors to rebut, and possibly > discusses with them. > > I spelled out possible wording of this already on > https://github.com/ghc-proposals/ghc-proposals/pull/221 > > Pros: Authors are taken more serious, have a say, while keeping our > discussion separate > > Cons: More work for shepherd. Incentives are set to lean towards > just recommending acceptance. Authors don't get to rebut if shepherd > wants to accept, but then the committee leans towards rejection. > > AB. The combination of the two above > > I.e. author rebuttal before shepherd recommends rejection > but then _also_ the committee discussion on GitHub > > Also spelled out already on > https://github.com/ghc-proposals/ghc-proposals/pull/225 > > 0. Do nothing. > > > Please vote by responding to this thread with a linear ordering of your > preferences. For example, my vote is > > AB > B > A > 0 > > Please cast a vote until Sunday May 5th. You can change your vote any > time until voting is concluded. Voting will be concluded when no votes > have been cast, but not before Sunday May 5th. We will accept the > option that is preferred over any other option by a majority of the > votes. > > > 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 Fri May 3 01:24:44 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 2 May 2019 21:24:44 -0400 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> Message-ID: I'll go with AB > B > A > 0 Thanks for organizing this! Richard > On May 2, 2019, at 2:01 PM, Iavor Diatchki wrote: > > Of the given options I'll pick: AB > A > B > 0 > > Qualifier: I like option A, with the modification that since we are > discussing things on Github, the proposer can jump in and clarify > stuff, if they feel that the committee is misunderstanding something. > > -Iavor > > > > > On Wed, May 1, 2019 at 11:51 AM Joachim Breitner > wrote: >> >> Dear committee, >> >> quick recap: one of our valued proposal writers, Matthew, expressed >> unhappiness about our discussion proposal, with two important (but not >> the only complains) issues the inability to react to a looming >> rejection, and general bad insight into the discussion. Based on that >> feedback (thanks again, Matt!) we discussed various options. Discussion >> has ebbed down, and because it affects our policies, I’d like to hold a >> formal vote. >> >> There are three possible changes to consider, plus the option of doing >> nothing. The options are >> >> A. All discussion on GitHub. >> >> Our process essentially stays the same, but all discussion happens >> on GitHub. The mailing list is used only for status messages (new >> proposal, new recommendation, result, regular summary messages). >> During the deliberation phase, we will ask bystanders (non-members, >> non-authors) to refrain from making the discussion noisy. >> >> Pros: Best visibility. Easy to get feedback from authors. No >> fragmented discussion places. >> >> Cons: Less separation of discussion, less of a “protected space” for >> us”, possibly more noise, can’t technically enforce that nobody else >> comments >> >> B. Shepherd discussion looming rejection with the authors first. >> >> This keeps the discussion on the mailing list, but the shepherd, >> before recommending to reject a proposal, needs to _first_ lay out >> their reasons on GitHub, wait for the authors to rebut, and possibly >> discusses with them. >> >> I spelled out possible wording of this already on >> https://github.com/ghc-proposals/ghc-proposals/pull/221 >> >> Pros: Authors are taken more serious, have a say, while keeping our >> discussion separate >> >> Cons: More work for shepherd. Incentives are set to lean towards >> just recommending acceptance. Authors don't get to rebut if shepherd >> wants to accept, but then the committee leans towards rejection. >> >> AB. The combination of the two above >> >> I.e. author rebuttal before shepherd recommends rejection >> but then _also_ the committee discussion on GitHub >> >> Also spelled out already on >> https://github.com/ghc-proposals/ghc-proposals/pull/225 >> >> 0. Do nothing. >> >> >> Please vote by responding to this thread with a linear ordering of your >> preferences. For example, my vote is >> >> AB > B > A > 0 >> >> Please cast a vote until Sunday May 5th. You can change your vote any >> time until voting is concluded. Voting will be concluded when no votes >> have been cast, but not before Sunday May 5th. We will accept the >> option that is preferred over any other option by a majority of the >> votes. >> >> >> 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 From rae at richarde.dev Fri May 3 02:28:49 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 2 May 2019 22:28:49 -0400 Subject: [ghc-steering-committee] Linear types design decisions Message-ID: <524CED7E-7351-483D-82C1-DBD3B25FAFB5@richarde.dev> Hi committee, As the shepherd for the Linear Types proposal (https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst ), I've been asked to forward a few design decisions to this committee. These are outlined in https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-476276874 , but this email is meant to be mostly self-contained on the issues to consider. We have three main issues before us. I describe the issues first, and then make recommendations separately. 1. The concrete syntax for linear types. The current proposal is: - `arg # mult -> res` for arrow types. That is, `... # ... -> ...` essentially becomes a ternary operator in the language. There is a proposed BNF of this syntax at https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst#id26 , but as of this writing, that BNF is, I believe, ambiguous for an input like `Int # Omega -> Int -> Int`, where the first arrow might or might not be part of the multiplicity. We clearly want "not", but the BNF does not currently reflect that. I am asking for Arnaud to take another stab. There is no treatment that I see of what to do if an upstream module declares a type operator named (#), but that shouldn't be hard to resolve, either by using prefix notation (#) or a qualified name Int Foo.# Bool. - `field # mult :: ty` for record field declarations and `pat # mult :: ty` for pattern bindings. This reverses the previous order. Also, because the `:: ty` is optional for a pattern binding, there is a potential ambiguity there, too, for `x # One = blah`: is that a pattern binding for x or a function binding for the term-level (#)? Presumably, the latter, and perhaps the former should require parentheses. (But note that `x :: Int = 5` is allowed today, without parens.) - The abbreviation #-> (one lexeme) for `# One ->`. I suppose this could just be an ordinary type-level operator exported from some module, but the proposal does not address this point. (Indeed, the proposal does not really propose this abbreviation -- only the commentary does. But we have been asked to decide on how to update the proposal.) - NB: The proposal introduces FUN :: Multiplicity -> forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). TYPE r1 -> TYPE r2 for the full raw function type. Some alternatives are at https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst#id58 2. How to update Template Haskell. - Should ArrowT be updated somehow? Or should we have a new MulArrowT (that presumably takes three arguments), leaving ArrowT alone? - What happens when we reify a constructor? TH's Info type contains `DataConI Name Type ParentName`, which is returned when reifying a constructor. Recall that, with linear types, constructors are multiplicity-polymorphic. Should that be reflected in the Type in the DataConI? Or do we keep things simpler? Does it depend on whether -XLinearTypes is on? - What happens when we reify a function? If the function is, say, multiplicity-polymorphic and we reify it in a module without -XLinearTypes, what do we see? Do we see the multiplicity polymorphism? 3. What to name the unrestricted multiplicity. Is it Omega or Many? -------------------- Recommendations: 1. I recommend accepting the new syntax (provided we can sort out the BNF). I don't think I can top the argument in favor of this syntax at https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-437512457 so I won't try. 2. - I would leave ArrowT as-is and introduce a new three-paramater MulArrowT in TH's Type datatype. ArrowT is heavily used in TH code, and it seems willfully destructive to change it. TH's syntax is already not-orthogonal in countless ways, and I think this is a fine time to add another. - I recommend that the behavior of reification be independent of what extensions are enabled. Otherwise, the possibilities for confusion and mistakes abound. - The subtleties of constructor types are described at https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst#id29 If I understand this correctly, this section means that constructors cannot be classified by normal Haskell types any more, but instead need some other descriptor. The best route forward, then, is to update DataConI to be able to describe data constructors correctly, perhaps by using TH's `Con` type. This would be a breaking change, but it seems worthwhile. - Functions should be reified with their multiplicities intact. It's unclear how much the change in reification would break existing code. I recommend that, once this is implemented, we run smoke tests (compiling all of Stackage is a good way to do this) to determine the extent of the breakage. If things are bad, we can reconsider. 3. Many. It's very easy for us pointy-headed types to use fancy Greek things that look, well, Greek to everyone else. `Many` is potentially misleading is that something used `Many` times might actually be used 0 times. `Unrestricted` is really a mouthful though, and I don't think it will be hard for users to internalize that `Many` just means an undetermined amount. Let me know your thoughts on these points. As usual, silence will be taken to mean that you agree with my recommendations. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Fri May 3 18:08:37 2019 From: eric at seidel.io (Eric Seidel) Date: Fri, 03 May 2019 14:08:37 -0400 Subject: [ghc-steering-committee] Linear types design decisions In-Reply-To: <524CED7E-7351-483D-82C1-DBD3B25FAFB5@richarde.dev> References: <524CED7E-7351-483D-82C1-DBD3B25FAFB5@richarde.dev> Message-ID: Agreed on all points. I would just add as a point in favor of 'Many' that interpreting "many" as zero-or-more is already fairly common in Haskell (e.g. in parser combinators and the Alternative class), so it feels pretty natural here as well. On Thu, May 2, 2019, at 22:29, Richard Eisenberg wrote: > Hi committee, > > As the shepherd for the Linear Types proposal > (https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst), I've been asked to forward a few design decisions to this committee. These are outlined in https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-476276874, but this email is meant to be mostly self-contained on the issues to consider. We have three main issues before us. I describe the issues first, and then make recommendations separately. > > 1. The concrete syntax for linear types. The current proposal is: > > - `arg # mult -> res` for arrow types. That is, `... # ... -> ...` > essentially becomes a ternary operator in the language. There is a > proposed BNF of this syntax at > https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst#id26, but as of this writing, that BNF is, I believe, ambiguous for an input like `Int # Omega -> Int -> Int`, where the first arrow might or might not be part of the multiplicity. We clearly want "not", but the BNF does not currently reflect that. I am asking for Arnaud to take another stab. There is no treatment that I see of what to do if an upstream module declares a type operator named (#), but that shouldn't be hard to resolve, either by using prefix notation (#) or a qualified name Int Foo.# Bool. > > - `field # mult :: ty` for record field declarations and `pat # mult :: > ty` for pattern bindings. This reverses the previous order. Also, > because the `:: ty` is optional for a pattern binding, there is a > potential ambiguity there, too, for `x # One = blah`: is that a pattern > binding for x or a function binding for the term-level (#)? Presumably, > the latter, and perhaps the former should require parentheses. (But > note that `x :: Int = 5` is allowed today, without parens.) > > - The abbreviation #-> (one lexeme) for `# One ->`. I suppose this > could just be an ordinary type-level operator exported from some > module, but the proposal does not address this point. (Indeed, the > proposal does not really propose this abbreviation -- only the > commentary does. But we have been asked to decide on how to update the > proposal.) > > - NB: The proposal introduces FUN :: Multiplicity -> forall (r1 :: > RuntimeRep) (r2 :: RuntimeRep). TYPE r1 -> TYPE r2 for the full raw > function type. > > Some alternatives are at > https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst#id58 > > 2. How to update Template Haskell. > > - Should ArrowT be updated somehow? Or should we have a new MulArrowT > (that presumably takes three arguments), leaving ArrowT alone? > > - What happens when we reify a constructor? TH's Info type contains > `DataConI Name Type ParentName`, which is returned when reifying a > constructor. Recall that, with linear types, constructors are > multiplicity-polymorphic. Should that be reflected in the Type in the > DataConI? Or do we keep things simpler? Does it depend on whether > -XLinearTypes is on? > > - What happens when we reify a function? If the function is, say, > multiplicity-polymorphic and we reify it in a module without > -XLinearTypes, what do we see? Do we see the multiplicity polymorphism? > > 3. What to name the unrestricted multiplicity. Is it Omega or Many? > > -------------------- > Recommendations: > > 1. I recommend accepting the new syntax (provided we can sort out the > BNF). I don't think I can top the argument in favor of this syntax at > https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-437512457 so I won't try. > > 2. > - I would leave ArrowT as-is and introduce a new three-paramater > MulArrowT in TH's Type datatype. ArrowT is heavily used in TH code, and > it seems willfully destructive to change it. TH's syntax is already > not-orthogonal in countless ways, and I think this is a fine time to > add another. > - I recommend that the behavior of reification be independent of what > extensions are enabled. Otherwise, the possibilities for confusion and > mistakes abound. > - The subtleties of constructor types are described at > https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst#id29 If I understand this correctly, this section means that constructors cannot be classified by normal Haskell types any more, but instead need some other descriptor. The best route forward, then, is to update DataConI to be able to describe data constructors correctly, perhaps by using TH's `Con` type. This would be a breaking change, but it seems worthwhile. > - Functions should be reified with their multiplicities intact. > > It's unclear how much the change in reification would break existing > code. I recommend that, once this is implemented, we run smoke tests > (compiling all of Stackage is a good way to do this) to determine the > extent of the breakage. If things are bad, we can reconsider. > > 3. Many. It's very easy for us pointy-headed types to use fancy Greek > things that look, well, Greek to everyone else. `Many` is potentially > misleading is that something used `Many` times might actually be used 0 > times. `Unrestricted` is really a mouthful though, and I don't think it > will be hard for users to internalize that `Many` just means an > undetermined amount. > > Let me know your thoughts on these points. As usual, silence will be > taken to mean that you agree with my recommendations. > > Thanks, > Richard > _______________________________________________ > 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 May 4 11:13:12 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 04 May 2019 13:13:12 +0200 Subject: [ghc-steering-committee] Please review #194: Updated partial type signatures, Shepherd: Vitaly Message-ID: Dear Committee, this is your secretary speaking: Updated partial type signatures have been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/194 https://github.com/goldfirere/ghc-proposals/blob/updated-partial-type-sigs/proposals/0000-updated-partial-type-sigs.rst I propose Vitaly as the Shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From chak at justtesting.org Sat May 4 12:15:33 2019 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Sat, 4 May 2019 14:15:33 +0200 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> Message-ID: B > 0 > A > AB (It’s boring if everybody votes the same way. No, seriously. I have trouble finding the time to follow the discussion anyway. If it is in my mailbox, I go through the emails that catch my attention. If it is on GitHub, I’ll probably completely forget about it. GitHub email notifications seems not very helpful here as I get so many of them already, so they go into a special dev-related mailbox…) Manuel > Am 01.05.2019 um 20:51 schrieb Joachim Breitner : > > Dear committee, > > quick recap: one of our valued proposal writers, Matthew, expressed > unhappiness about our discussion proposal, with two important (but not > the only complains) issues the inability to react to a looming > rejection, and general bad insight into the discussion. Based on that > feedback (thanks again, Matt!) we discussed various options. Discussion > has ebbed down, and because it affects our policies, I’d like to hold a > formal vote. > > There are three possible changes to consider, plus the option of doing > nothing. The options are > > A. All discussion on GitHub. > > Our process essentially stays the same, but all discussion happens > on GitHub. The mailing list is used only for status messages (new > proposal, new recommendation, result, regular summary messages). > During the deliberation phase, we will ask bystanders (non-members, > non-authors) to refrain from making the discussion noisy. > > Pros: Best visibility. Easy to get feedback from authors. No > fragmented discussion places. > > Cons: Less separation of discussion, less of a “protected space” for > us”, possibly more noise, can’t technically enforce that nobody else > comments > > B. Shepherd discussion looming rejection with the authors first. > > This keeps the discussion on the mailing list, but the shepherd, > before recommending to reject a proposal, needs to _first_ lay out > their reasons on GitHub, wait for the authors to rebut, and possibly > discusses with them. > > I spelled out possible wording of this already on > https://github.com/ghc-proposals/ghc-proposals/pull/221 > > Pros: Authors are taken more serious, have a say, while keeping our > discussion separate > > Cons: More work for shepherd. Incentives are set to lean towards > just recommending acceptance. Authors don't get to rebut if shepherd > wants to accept, but then the committee leans towards rejection. > > AB. The combination of the two above > > I.e. author rebuttal before shepherd recommends rejection > but then _also_ the committee discussion on GitHub > > Also spelled out already on > https://github.com/ghc-proposals/ghc-proposals/pull/225 > > 0. Do nothing. > > > Please vote by responding to this thread with a linear ordering of your > preferences. For example, my vote is > > AB > B > A > 0 > > Please cast a vote until Sunday May 5th. You can change your vote any > time until voting is concluded. Voting will be concluded when no votes > have been cast, but not before Sunday May 5th. We will accept the > option that is preferred over any other option by a majority of the > votes. > > > 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 eric at seidel.io Sat May 4 12:28:27 2019 From: eric at seidel.io (Eric Seidel) Date: Sat, 4 May 2019 08:28:27 -0400 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> Message-ID: The difficulty of keeping up with GitHub discussions is something a few of us have raised concerns about. On the GitHub discussion, someone suggested editing the title of a proposal once it’s been submitted to the committee (eg to add “under review”). This would let us create an email filter for committee-related notifications. Would that work for you? Sent from my iPhone > On May 4, 2019, at 08:15, Manuel M T Chakravarty wrote: > > B > 0 > A > AB > > (It’s boring if everybody votes the same way. No, seriously. I have trouble finding the time to follow the discussion anyway. If it is in my mailbox, I go through the emails that catch my attention. If it is on GitHub, I’ll probably completely forget about it. GitHub email notifications seems not very helpful here as I get so many of them already, so they go into a special dev-related mailbox…) > > Manuel > >> Am 01.05.2019 um 20:51 schrieb Joachim Breitner : >> >> Dear committee, >> >> quick recap: one of our valued proposal writers, Matthew, expressed >> unhappiness about our discussion proposal, with two important (but not >> the only complains) issues the inability to react to a looming >> rejection, and general bad insight into the discussion. Based on that >> feedback (thanks again, Matt!) we discussed various options. Discussion >> has ebbed down, and because it affects our policies, I’d like to hold a >> formal vote. >> >> There are three possible changes to consider, plus the option of doing >> nothing. The options are >> >> A. All discussion on GitHub. >> >> Our process essentially stays the same, but all discussion happens >> on GitHub. The mailing list is used only for status messages (new >> proposal, new recommendation, result, regular summary messages). >> During the deliberation phase, we will ask bystanders (non-members, >> non-authors) to refrain from making the discussion noisy. >> >> Pros: Best visibility. Easy to get feedback from authors. No >> fragmented discussion places. >> >> Cons: Less separation of discussion, less of a “protected space” for >> us”, possibly more noise, can’t technically enforce that nobody else >> comments >> >> B. Shepherd discussion looming rejection with the authors first. >> >> This keeps the discussion on the mailing list, but the shepherd, >> before recommending to reject a proposal, needs to _first_ lay out >> their reasons on GitHub, wait for the authors to rebut, and possibly >> discusses with them. >> >> I spelled out possible wording of this already on >> https://github.com/ghc-proposals/ghc-proposals/pull/221 >> >> Pros: Authors are taken more serious, have a say, while keeping our >> discussion separate >> >> Cons: More work for shepherd. Incentives are set to lean towards >> just recommending acceptance. Authors don't get to rebut if shepherd >> wants to accept, but then the committee leans towards rejection. >> >> AB. The combination of the two above >> >> I.e. author rebuttal before shepherd recommends rejection >> but then _also_ the committee discussion on GitHub >> >> Also spelled out already on >> https://github.com/ghc-proposals/ghc-proposals/pull/225 >> >> 0. Do nothing. >> >> >> Please vote by responding to this thread with a linear ordering of your >> preferences. For example, my vote is >> >> AB > B > A > 0 >> >> Please cast a vote until Sunday May 5th. You can change your vote any >> time until voting is concluded. Voting will be concluded when no votes >> have been cast, but not before Sunday May 5th. We will accept the >> option that is preferred over any other option by a majority of the >> votes. >> >> >> 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 From chak at justtesting.org Sat May 4 15:06:29 2019 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Sat, 4 May 2019 17:06:29 +0200 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> Message-ID: <3B0FFC05-360A-4972-9954-6C151ABCBF23@justtesting.org> If we decide to move the discussion to GitHub, I will certainly try that. It can usually only serve as a reminder to hop onto GitHub again, though, as the GitHub comment notifications usually lack context. In a long thread over a longer timespan, it is annoying to keep track of what you have read already and what’s new. I also find that a lot of people are not very consistent about citing the comments they are replying to, which makes it hard to disentangle multiple interleaved subthreads. I like GitHub for code, but for the discussion we are having, I don’t think the UI is really made for that. Cheers, Manuel > Am 04.05.2019 um 14:28 schrieb Eric Seidel : > > The difficulty of keeping up with GitHub discussions is something a few of us have raised concerns about. On the GitHub discussion, someone suggested editing the title of a proposal once it’s been submitted to the committee (eg to add “under review”). This would let us create an email filter for committee-related notifications. > > Would that work for you? > > Sent from my iPhone > >> On May 4, 2019, at 08:15, Manuel M T Chakravarty wrote: >> >> B > 0 > A > AB >> >> (It’s boring if everybody votes the same way. No, seriously. I have trouble finding the time to follow the discussion anyway. If it is in my mailbox, I go through the emails that catch my attention. If it is on GitHub, I’ll probably completely forget about it. GitHub email notifications seems not very helpful here as I get so many of them already, so they go into a special dev-related mailbox…) >> >> Manuel >> >>> Am 01.05.2019 um 20:51 schrieb Joachim Breitner : >>> >>> Dear committee, >>> >>> quick recap: one of our valued proposal writers, Matthew, expressed >>> unhappiness about our discussion proposal, with two important (but not >>> the only complains) issues the inability to react to a looming >>> rejection, and general bad insight into the discussion. Based on that >>> feedback (thanks again, Matt!) we discussed various options. Discussion >>> has ebbed down, and because it affects our policies, I’d like to hold a >>> formal vote. >>> >>> There are three possible changes to consider, plus the option of doing >>> nothing. The options are >>> >>> A. All discussion on GitHub. >>> >>> Our process essentially stays the same, but all discussion happens >>> on GitHub. The mailing list is used only for status messages (new >>> proposal, new recommendation, result, regular summary messages). >>> During the deliberation phase, we will ask bystanders (non-members, >>> non-authors) to refrain from making the discussion noisy. >>> >>> Pros: Best visibility. Easy to get feedback from authors. No >>> fragmented discussion places. >>> >>> Cons: Less separation of discussion, less of a “protected space” for >>> us”, possibly more noise, can’t technically enforce that nobody else >>> comments >>> >>> B. Shepherd discussion looming rejection with the authors first. >>> >>> This keeps the discussion on the mailing list, but the shepherd, >>> before recommending to reject a proposal, needs to _first_ lay out >>> their reasons on GitHub, wait for the authors to rebut, and possibly >>> discusses with them. >>> >>> I spelled out possible wording of this already on >>> https://github.com/ghc-proposals/ghc-proposals/pull/221 >>> >>> Pros: Authors are taken more serious, have a say, while keeping our >>> discussion separate >>> >>> Cons: More work for shepherd. Incentives are set to lean towards >>> just recommending acceptance. Authors don't get to rebut if shepherd >>> wants to accept, but then the committee leans towards rejection. >>> >>> AB. The combination of the two above >>> >>> I.e. author rebuttal before shepherd recommends rejection >>> but then _also_ the committee discussion on GitHub >>> >>> Also spelled out already on >>> https://github.com/ghc-proposals/ghc-proposals/pull/225 >>> >>> 0. Do nothing. >>> >>> >>> Please vote by responding to this thread with a linear ordering of your >>> preferences. For example, my vote is >>> >>> AB > B > A > 0 >>> >>> Please cast a vote until Sunday May 5th. You can change your vote any >>> time until voting is concluded. Voting will be concluded when no votes >>> have been cast, but not before Sunday May 5th. We will accept the >>> option that is preferred over any other option by a majority of the >>> votes. >>> >>> >>> 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 > From simonpj at microsoft.com Mon May 6 16:25:54 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 6 May 2019 16:25:54 +0000 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: <3B0FFC05-360A-4972-9954-6C151ABCBF23@justtesting.org> References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> <3B0FFC05-360A-4972-9954-6C151ABCBF23@justtesting.org> Message-ID: | I like GitHub for code, but for the discussion we are having, I don’t | think the UI is really made for that. Why do you think email is better? I suppose that each email often includes a complete copy of the thread, which seems useful, if wasteful. Is it that that makes the difference for you? Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Manuel M T Chakravarty | Sent: 04 May 2019 16:06 | To: Eric Seidel | Cc: ghc-steering-committee at haskell.org; Joachim Breitner | Subject: Re: [ghc-steering-committee] Procedural change vote | | If we decide to move the discussion to GitHub, I will certainly try that. | | It can usually only serve as a reminder to hop onto GitHub again, though, | as the GitHub comment notifications usually lack context. | | In a long thread over a longer timespan, it is annoying to keep track of | what you have read already and what’s new. I also find that a lot of | people are not very consistent about citing the comments they are replying | to, which makes it hard to disentangle multiple interleaved subthreads. | | I like GitHub for code, but for the discussion we are having, I don’t | think the UI is really made for that. | | Cheers, | Manuel | | > Am 04.05.2019 um 14:28 schrieb Eric Seidel : | > | > The difficulty of keeping up with GitHub discussions is something a few | of us have raised concerns about. On the GitHub discussion, someone | suggested editing the title of a proposal once it’s been submitted to the | committee (eg to add “under review”). This would let us create an email | filter for committee-related notifications. | > | > Would that work for you? | > | > Sent from my iPhone | > | >> On May 4, 2019, at 08:15, Manuel M T Chakravarty | wrote: | >> | >> B > 0 > A > AB | >> | >> (It’s boring if everybody votes the same way. No, seriously. I have | >> trouble finding the time to follow the discussion anyway. If it is in | >> my mailbox, I go through the emails that catch my attention. If it is | >> on GitHub, I’ll probably completely forget about it. GitHub email | >> notifications seems not very helpful here as I get so many of them | >> already, so they go into a special dev-related mailbox…) | >> | >> Manuel | >> | >>> Am 01.05.2019 um 20:51 schrieb Joachim Breitner : | >>> | >>> Dear committee, | >>> | >>> quick recap: one of our valued proposal writers, Matthew, expressed | >>> unhappiness about our discussion proposal, with two important (but | >>> not the only complains) issues the inability to react to a looming | >>> rejection, and general bad insight into the discussion. Based on | >>> that feedback (thanks again, Matt!) we discussed various options. | >>> Discussion has ebbed down, and because it affects our policies, I’d | >>> like to hold a formal vote. | >>> | >>> There are three possible changes to consider, plus the option of | >>> doing nothing. The options are | >>> | >>> A. All discussion on GitHub. | >>> | >>> Our process essentially stays the same, but all discussion happens | >>> on GitHub. The mailing list is used only for status messages (new | >>> proposal, new recommendation, result, regular summary messages). | >>> During the deliberation phase, we will ask bystanders (non-members, | >>> non-authors) to refrain from making the discussion noisy. | >>> | >>> Pros: Best visibility. Easy to get feedback from authors. No | >>> fragmented discussion places. | >>> | >>> Cons: Less separation of discussion, less of a “protected space” for | >>> us”, possibly more noise, can’t technically enforce that nobody else | >>> comments | >>> | >>> B. Shepherd discussion looming rejection with the authors first. | >>> | >>> This keeps the discussion on the mailing list, but the shepherd, | >>> before recommending to reject a proposal, needs to _first_ lay out | >>> their reasons on GitHub, wait for the authors to rebut, and possibly | >>> discusses with them. | >>> | >>> I spelled out possible wording of this already on | >>> https://github.com/ghc-proposals/ghc-proposals/pull/221 | >>> | >>> Pros: Authors are taken more serious, have a say, while keeping our | >>> discussion separate | >>> | >>> Cons: More work for shepherd. Incentives are set to lean towards | >>> just recommending acceptance. Authors don't get to rebut if shepherd | >>> wants to accept, but then the committee leans towards rejection. | >>> | >>> AB. The combination of the two above | >>> | >>> I.e. author rebuttal before shepherd recommends rejection but then | >>> _also_ the committee discussion on GitHub | >>> | >>> Also spelled out already on | >>> https://github.com/ghc-proposals/ghc-proposals/pull/225 | >>> | >>> 0. Do nothing. | >>> | >>> | >>> Please vote by responding to this thread with a linear ordering of | >>> your preferences. For example, my vote is | >>> | >>> AB > B > A > 0 | >>> | >>> Please cast a vote until Sunday May 5th. You can change your vote | >>> any time until voting is concluded. Voting will be concluded when no | >>> votes have been cast, but not before Sunday May 5th. We will accept | >>> the option that is preferred over any other option by a majority of | >>> the votes. | >>> | >>> | >>> 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-commi | >>> ttee | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee at haskell.org | >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit | >> tee | > | | _______________________________________________ | 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 Mon May 6 16:32:30 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 06 May 2019 18:32:30 +0200 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> Message-ID: <8d68824b25eb4eb983f45560898fdd79f034fb9e.camel@joachim-breitner.de> Hi, Am Mittwoch, den 01.05.2019, 20:51 +0200 schrieb Joachim Breitner: > There are three possible changes to consider, plus the option of doing > nothing. The options are > > A. All discussion on GitHub. > B. Shepherd discussion looming rejection with the authors first. > AB. The combination of the two above > 0. Do nothing. Votes so far: AB > B > A > 0 Joachim, Simon, Simon, Chris, Eric, Richard AB > A > B > 0 Vitaly, Iavor B > 0 > A > AB Manuel No vote from Ben, but I think we can go ahead with AB, which is already ready to be merged at https://github.com/ghc-proposals/ghc-proposals/pull/225 Everybody who enjoys copy editing and improving phrasing is invited to refine that text (just commit directly to the branch) or discuss minor tweaks there. I’ll merge it in a few days. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From chak at justtesting.org Mon May 6 19:58:56 2019 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Mon, 6 May 2019 21:58:56 +0200 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> <3B0FFC05-360A-4972-9954-6C151ABCBF23@justtesting.org> Message-ID: > Am 06.05.2019 um 18:25 schrieb Simon Peyton Jones : > > | I like GitHub for code, but for the discussion we are having, I don’t > | think the UI is really made for that. > > Why do you think email is better? Because people are much better at providing context in email and my mail reader keeps track of what I have read and what I haven’t read yet. It is a lot harder to see on GitHub what comment another comment is referring to. > I suppose that each email often includes a complete copy of the thread, which seems useful, if wasteful. Is it that that makes the difference for you? I haven’t quoted everything, but just the bits I am responding to. GitHub allows you to quote, too, but you need to explicitly do it (by copying text and adding markup or by highlighting it and pressing ’r’). People often don’t do that, but in email it is the default and done by your email reader. Manuel From simonpj at microsoft.com Tue May 7 11:56:23 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 7 May 2019 11:56:23 +0000 Subject: [ghc-steering-committee] Procedural change vote In-Reply-To: References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> <3B0FFC05-360A-4972-9954-6C151ABCBF23@justtesting.org> Message-ID: | Because people are much better at providing context in email and my mail | reader keeps track of what I have read and what I haven’t read yet. Yes, those are good points. Specifically, perhaps they'd be good suggestions for improving GitHub (or GitLab)'s interface. Simon | -----Original Message----- | From: Manuel M T Chakravarty | Sent: 06 May 2019 20:59 | To: Simon Peyton Jones | Cc: Eric Seidel ; ghc-steering-committee at haskell.org; | Joachim Breitner | Subject: Re: [ghc-steering-committee] Procedural change vote | | > Am 06.05.2019 um 18:25 schrieb Simon Peyton Jones | : | > | > | I like GitHub for code, but for the discussion we are having, I | > | don’t think the UI is really made for that. | > | > Why do you think email is better? | | Because people are much better at providing context in email and my mail | reader keeps track of what I have read and what I haven’t read yet. | | It is a lot harder to see on GitHub what comment another comment is | referring to. | | > I suppose that each email often includes a complete copy of the thread, | which seems useful, if wasteful. Is it that that makes the difference for | you? | | I haven’t quoted everything, but just the bits I am responding to. | | GitHub allows you to quote, too, but you need to explicitly do it (by | copying text and adding markup or by highlighting it and pressing ’r’). | People often don’t do that, but in email it is the default and done by | your email reader. | | Manuel From simonpj at microsoft.com Tue May 7 21:37:40 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 7 May 2019 21:37:40 +0000 Subject: [ghc-steering-committee] Linear types design decisions In-Reply-To: <524CED7E-7351-483D-82C1-DBD3B25FAFB5@richarde.dev> References: <524CED7E-7351-483D-82C1-DBD3B25FAFB5@richarde.dev> Message-ID: I'm content with Richard's recommendations. Simon From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 03 May 2019 03:29 To: Simon Peyton Jones via ghc-steering-committee Subject: [ghc-steering-committee] Linear types design decisions Hi committee, As the shepherd for the Linear Types proposal (https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst), I've been asked to forward a few design decisions to this committee. These are outlined in https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-476276874, but this email is meant to be mostly self-contained on the issues to consider. We have three main issues before us. I describe the issues first, and then make recommendations separately. 1. The concrete syntax for linear types. The current proposal is: - `arg # mult -> res` for arrow types. That is, `... # ... -> ...` essentially becomes a ternary operator in the language. There is a proposed BNF of this syntax at https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst#id26, but as of this writing, that BNF is, I believe, ambiguous for an input like `Int # Omega -> Int -> Int`, where the first arrow might or might not be part of the multiplicity. We clearly want "not", but the BNF does not currently reflect that. I am asking for Arnaud to take another stab. There is no treatment that I see of what to do if an upstream module declares a type operator named (#), but that shouldn't be hard to resolve, either by using prefix notation (#) or a qualified name Int Foo.# Bool. - `field # mult :: ty` for record field declarations and `pat # mult :: ty` for pattern bindings. This reverses the previous order. Also, because the `:: ty` is optional for a pattern binding, there is a potential ambiguity there, too, for `x # One = blah`: is that a pattern binding for x or a function binding for the term-level (#)? Presumably, the latter, and perhaps the former should require parentheses. (But note that `x :: Int = 5` is allowed today, without parens.) - The abbreviation #-> (one lexeme) for `# One ->`. I suppose this could just be an ordinary type-level operator exported from some module, but the proposal does not address this point. (Indeed, the proposal does not really propose this abbreviation -- only the commentary does. But we have been asked to decide on how to update the proposal.) - NB: The proposal introduces FUN :: Multiplicity -> forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). TYPE r1 -> TYPE r2 for the full raw function type. Some alternatives are at https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst#id58 2. How to update Template Haskell. - Should ArrowT be updated somehow? Or should we have a new MulArrowT (that presumably takes three arguments), leaving ArrowT alone? - What happens when we reify a constructor? TH's Info type contains `DataConI Name Type ParentName`, which is returned when reifying a constructor. Recall that, with linear types, constructors are multiplicity-polymorphic. Should that be reflected in the Type in the DataConI? Or do we keep things simpler? Does it depend on whether -XLinearTypes is on? - What happens when we reify a function? If the function is, say, multiplicity-polymorphic and we reify it in a module without -XLinearTypes, what do we see? Do we see the multiplicity polymorphism? 3. What to name the unrestricted multiplicity. Is it Omega or Many? -------------------- Recommendations: 1. I recommend accepting the new syntax (provided we can sort out the BNF). I don't think I can top the argument in favor of this syntax at https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-437512457 so I won't try. 2. - I would leave ArrowT as-is and introduce a new three-paramater MulArrowT in TH's Type datatype. ArrowT is heavily used in TH code, and it seems willfully destructive to change it. TH's syntax is already not-orthogonal in countless ways, and I think this is a fine time to add another. - I recommend that the behavior of reification be independent of what extensions are enabled. Otherwise, the possibilities for confusion and mistakes abound. - The subtleties of constructor types are described at https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-linear-types.rst#id29 If I understand this correctly, this section means that constructors cannot be classified by normal Haskell types any more, but instead need some other descriptor. The best route forward, then, is to update DataConI to be able to describe data constructors correctly, perhaps by using TH's `Con` type. This would be a breaking change, but it seems worthwhile. - Functions should be reified with their multiplicities intact. It's unclear how much the change in reification would break existing code. I recommend that, once this is implemented, we run smoke tests (compiling all of Stackage is a good way to do this) to determine the extent of the breakage. If things are bad, we can reconsider. 3. Many. It's very easy for us pointy-headed types to use fancy Greek things that look, well, Greek to everyone else. `Many` is potentially misleading is that something used `Many` times might actually be used 0 times. `Unrestricted` is really a mouthful though, and I don't think it will be hard for users to internalize that `Many` just means an undetermined amount. Let me know your thoughts on these points. As usual, silence will be taken to mean that you agree with my recommendations. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Thu May 9 18:26:02 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 9 May 2019 11:26:02 -0700 Subject: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas In-Reply-To: References: <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com> <5b7eb5a6-d961-43b2-a93d-96d23798413a@www.fastmail.com> <7f2af94c1df8d825ea414cd354e77c247f482c91.camel@joachim-breitner.de> Message-ID: Hello, we've been contemplating this for a while and the discussion does not seem to be making significant progress, so I thinking we are probably ready to make a decision. It seems that at least a few people on the committee find this feature useful, and nobody is strongly against, so I'll mark this one as ACCEPT. -Iavor On Wed, Apr 24, 2019 at 4:59 AM Vitaly Bragilevsky wrote: > > Hello, > > I actually like this proposal. I see it as a relatively simple (limited, but that's ok) way to express some of System F features in Haskell. By the way, it makes it easier to teach about Haskell to Core translation (I did that several times): we could present it step by step without leaving Haskell while being able to use GHC for checking code. Getting rid of Proxy and providing an alternative to the less-intuitive ScopedTypeVariables extension is a big plus either. > > Regards, > Vitaly > > ср, 24 апр. 2019 г. в 01:46, Simon Peyton Jones via ghc-steering-committee : >> >> I’m puzzled why other members of the committee have not expressed a view. Would you consider doing so? >> >> >> Simon >> >> >> >> From: ghc-steering-committee On Behalf Of Iavor Diatchki >> Sent: 23 April 2019 17:56 >> To: Joachim Breitner >> Cc: ghc-steering-committee >> Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas >> >> >> >> Well there wasn't really any discussion after my message, to summarize: >> >> * Simon said that he is still on the fence, and would like more input from the rest of the committee, >> >> * An you (Joachim) said that you are on the fence, but you think that we should do it because people may use the feature in surprising ways. >> >> >> >> So I am still unconvinced, especially if we don't have a good motivation beyond expecting to be surprised by the users :-) >> >> >> >> As far as I see, the main benefit is the ability to name the type when passing in polymorphic parameters, where the type variable >> >> does not appear in any of the arguments of to the parameter. >> >> >> >> To me this seems as a rather niche case to warrant a new language construct to make it more convenient. In addition, >> >> the notation certainly looks like "big lambda" and I bet there will be some confusion about why it doesn't work as one would expect (yet?). >> >> >> >> So my recommendation would be to shelve this for the moment, and spend some effort to make it behave more like "big lambda", >> >> which I think would be a potentially useful feature. >> >> >> >> -Iavor >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Apr 17, 2019 at 12:16 AM Joachim Breitner wrote: >> >> Hi, >> >> there is lots of fence-sitting here (and I am also on that particular >> fence). But to make shake the fence: Let’s do it! I think people will >> find good and surprising uses for this feature. >> >> Iavor, your original message did not carry a concrete recommendation. >> Did the discussion help you to form an opinion? >> >> Cheers, >> Joachim >> >> >> Am Donnerstag, den 04.04.2019, 10:10 +0000 schrieb Simon Peyton Jones >> via ghc-steering-committee: >> > I really am on the fence. Good things: >> > >> > Richard’s first motivating example, where we still need Proxy, is quite convincing. >> > >> > It fills out an obvious gap, with the right sort of intro/elim duality with visible type application. >> > >> > And I like that it gives us a language in which to talk about System F elaboration of the program, if and when we want to. E.g. we can say: if you write >> > >> > f x = Just x >> > >> > it is as if you had written >> > >> > f :: forall a. a -> Maybe a >> > f = \@a \(x::a). Just x >> > >> > Less good: >> > It’s still incomplete concerning (B) because we can’t talk about dictionary bindings. >> > It adds more complexity. >> > We are not under real pressure to do this now. >> > >> > I’d like to hear from a broader range of opinion. >> > >> > Simon >> > >> > From: ghc-steering-committee On Behalf Of Iavor Diatchki >> > Sent: 03 April 2019 17:46 >> > To: Eric Seidel >> > Cc: ghc-steering-committee >> > Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas >> > >> > Hello, >> > >> > perhaps it is time to come up with some sort of decision here. Based on the replies to this thread we seem to have the following opinions: >> > 1. Eric and Richard seem to be quite keen on the feature >> > 2. Simon is on the fence, but likes it because it introduces System F vocabulary to Haskell >> > 3. I am skeptical of the proposal as is, as I think it adds additional complexity to the language (more non-orthogonal features) without significant payoff. >> > >> > Does anyone else have anything else to add? >> > >> > -Iavor >> > >> > >> > >> > On Tue, Mar 26, 2019 at 6:48 PM Eric Seidel wrote: >> > > On Tue, Mar 26, 2019, at 13:17, Iavor Diatchki wrote: >> > > > My concern is that the notation certainly suggests that you are binding >> > > > types with the @ syntax, but in really it is still the type signature >> > > > that guides the binding of the variables and the @ parameters just >> > > > duplicate the information from the type signature. >> > > >> > > But you are binding types with the @ syntax. The proposal gives a number of examples where the @-bound type variable is bound by a different name (or not at all) in the type signature. Many are contrived, to demonstrate where the binders are allowed, but the higher-rank and proxy-eliding examples look compelling to me. >> > > >> > > We also already allow repeated value binders in Haskell. When I write a function in equational style, I have to rebind each argument in each alternate equation. Sometimes this is noisy and I'll prefer a single equation with an explicit `case`. But for functions where the body is sizable, I find the repeated binders to be quite helpful because the scopes are smaller. I can easily see the same benefit applying to type binders. Ultimately, I think this comes down to a matter of style, and I favor letting Haskell programmers pick the style that works best for them. >> > > >> > > Eric >> > > _______________________________________________ >> > > 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 >> -- >> 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 From simonpj at microsoft.com Thu May 9 21:44:14 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 9 May 2019 21:44:14 +0000 Subject: [ghc-steering-committee] Discussion on #155 Type Variable in Labmdas In-Reply-To: References: <97925ba8-c5f9-4309-ac8c-6f1a271d20d9@www.fastmail.com> <5b7eb5a6-d961-43b2-a93d-96d23798413a@www.fastmail.com> <7f2af94c1df8d825ea414cd354e77c247f482c91.camel@joachim-breitner.de> Message-ID: This proposal is more than a simple syntactic tweak like extra-commas or where to place 'qualified'. For those things both costs and benefits are small; there are judgements of taste but I can live with any outcome. Far at the other end of the spectrum is something like linear types: a big, expensive, pervasive change -- but one that is part of Haskell's goal of being a laboratory for growing cool ideas, and one from which we will, I hope, learn a lot. This proposal is in the middle. It's "filling out the envelope" of the system we now have, as are many other proposals on table at the moment, trying to make the language we have as consistent, predictable and coherent as possible. So I like the fact that this proposal lets us write the System F terms that Haskell elaborates too. It gives us a language in which to explain to our users a model of what is "really happening", and what the type inference system fills in. I like that it gives the lambda part of visible type application (we should call it "visible type abstraction" perhaps!). But it does add yet another piece to our language; and it's a piece that few people really need. While there is no substantial opposition, support is pretty muted. I'd really be more comfortable if there were lots of people saying "yes we really want this". On balance I'm happy to support Iavor's "accept" proposal. But only just! Simon | -----Original Message----- | From: Iavor Diatchki | Sent: 09 May 2019 19:26 | To: Vitaly Bragilevsky | Cc: Simon Peyton Jones ; Joachim Breitner | ; ghc-steering-committee | Subject: Re: [ghc-steering-committee] Discussion on #155 Type Variable in | Labmdas | | Hello, | | we've been contemplating this for a while and the discussion does not seem | to be making significant progress, so I thinking we are probably ready to | make a decision. | | It seems that at least a few people on the committee find this feature | useful, and nobody is strongly against, so I'll mark this one as ACCEPT. | | -Iavor | | On Wed, Apr 24, 2019 at 4:59 AM Vitaly Bragilevsky | wrote: | > | > Hello, | > | > I actually like this proposal. I see it as a relatively simple (limited, | but that's ok) way to express some of System F features in Haskell. By the | way, it makes it easier to teach about Haskell to Core translation (I did | that several times): we could present it step by step without leaving | Haskell while being able to use GHC for checking code. Getting rid of | Proxy and providing an alternative to the less-intuitive | ScopedTypeVariables extension is a big plus either. | > | > Regards, | > Vitaly | > | > ср, 24 апр. 2019 г. в 01:46, Simon Peyton Jones via ghc-steering- | committee : | >> | >> I’m puzzled why other members of the committee have not expressed a | view. Would you consider doing so? | >> | >> | >> Simon | >> | >> | >> | >> From: ghc-steering-committee | >> On Behalf Of Iavor | >> Diatchki | >> Sent: 23 April 2019 17:56 | >> To: Joachim Breitner | >> Cc: ghc-steering-committee | >> Subject: Re: [ghc-steering-committee] Discussion on #155 Type | >> Variable in Labmdas | >> | >> | >> | >> Well there wasn't really any discussion after my message, to summarize: | >> | >> * Simon said that he is still on the fence, and would like more | >> input from the rest of the committee, | >> | >> * An you (Joachim) said that you are on the fence, but you think | that we should do it because people may use the feature in surprising | ways. | >> | >> | >> | >> So I am still unconvinced, especially if we don't have a good | >> motivation beyond expecting to be surprised by the users :-) | >> | >> | >> | >> As far as I see, the main benefit is the ability to name the type | >> when passing in polymorphic parameters, where the type variable | >> | >> does not appear in any of the arguments of to the parameter. | >> | >> | >> | >> To me this seems as a rather niche case to warrant a new language | >> construct to make it more convenient. In addition, | >> | >> the notation certainly looks like "big lambda" and I bet there will be | some confusion about why it doesn't work as one would expect (yet?). | >> | >> | >> | >> So my recommendation would be to shelve this for the moment, and | >> spend some effort to make it behave more like "big lambda", | >> | >> which I think would be a potentially useful feature. | >> | >> | >> | >> -Iavor | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> On Wed, Apr 17, 2019 at 12:16 AM Joachim Breitner wrote: | >> | >> Hi, | >> | >> there is lots of fence-sitting here (and I am also on that particular | >> fence). But to make shake the fence: Let’s do it! I think people will | >> find good and surprising uses for this feature. | >> | >> Iavor, your original message did not carry a concrete recommendation. | >> Did the discussion help you to form an opinion? | >> | >> Cheers, | >> Joachim | >> | >> | >> Am Donnerstag, den 04.04.2019, 10:10 +0000 schrieb Simon Peyton Jones | >> via ghc-steering-committee: | >> > I really am on the fence. Good things: | >> > | >> > Richard’s first motivating example, where we still need Proxy, is | quite convincing. | >> > | >> > It fills out an obvious gap, with the right sort of intro/elim | duality with visible type application. | >> > | >> > And I like that it gives us a language in which to talk about | >> > System F elaboration of the program, if and when we want to. E.g. | >> > we can say: if you write | >> > | >> > f x = Just x | >> > | >> > it is as if you had written | >> > | >> > f :: forall a. a -> Maybe a | >> > f = \@a \(x::a). Just x | >> > | >> > Less good: | >> > It’s still incomplete concerning (B) because we can’t talk about | dictionary bindings. | >> > It adds more complexity. | >> > We are not under real pressure to do this now. | >> > | >> > I’d like to hear from a broader range of opinion. | >> > | >> > Simon | >> > | >> > From: ghc-steering-committee | >> > On Behalf Of Iavor | >> > Diatchki | >> > Sent: 03 April 2019 17:46 | >> > To: Eric Seidel | >> > Cc: ghc-steering-committee | >> > Subject: Re: [ghc-steering-committee] Discussion on #155 Type | >> > Variable in Labmdas | >> > | >> > Hello, | >> > | >> > perhaps it is time to come up with some sort of decision here. Based | on the replies to this thread we seem to have the following opinions: | >> > 1. Eric and Richard seem to be quite keen on the feature | >> > 2. Simon is on the fence, but likes it because it introduces System | F vocabulary to Haskell | >> > 3. I am skeptical of the proposal as is, as I think it adds | additional complexity to the language (more non-orthogonal features) | without significant payoff. | >> > | >> > Does anyone else have anything else to add? | >> > | >> > -Iavor | >> > | >> > | >> > | >> > On Tue, Mar 26, 2019 at 6:48 PM Eric Seidel wrote: | >> > > On Tue, Mar 26, 2019, at 13:17, Iavor Diatchki wrote: | >> > > > My concern is that the notation certainly suggests that you are | >> > > > binding types with the @ syntax, but in really it is still the | >> > > > type signature that guides the binding of the variables and the | >> > > > @ parameters just duplicate the information from the type | signature. | >> > > | >> > > But you are binding types with the @ syntax. The proposal gives a | number of examples where the @-bound type variable is bound by a different | name (or not at all) in the type signature. Many are contrived, to | demonstrate where the binders are allowed, but the higher-rank and proxy- | eliding examples look compelling to me. | >> > > | >> > > We also already allow repeated value binders in Haskell. When I | write a function in equational style, I have to rebind each argument in | each alternate equation. Sometimes this is noisy and I'll prefer a single | equation with an explicit `case`. But for functions where the body is | sizable, I find the repeated binders to be quite helpful because the | scopes are smaller. I can easily see the same benefit applying to type | binders. Ultimately, I think this comes down to a matter of style, and I | favor letting Haskell programmers pick the style that works best for them. | >> > > | >> > > Eric | >> > > _______________________________________________ | >> > > ghc-steering-committee mailing list | >> > > ghc-steering-committee at haskell.org | >> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2 | >> > > Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-c | >> > > ommittee&data=01%7C01%7Csimonpj%40microsoft.com%7Cf6979d8c314 | >> > > b47c1133c08d6d4abd337%7C72f988bf86f141af91ab2d7cd011db47%7C1& | >> > > sdata=UFzBeDE2vfeqnbJYpXHG%2FbnM2PJsYOLiqFlVuSYELcg%3D&reserv | >> > > ed=0 | >> > | >> > _______________________________________________ | >> > ghc-steering-committee mailing list | >> > ghc-steering-committee at haskell.org | >> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm | >> > ail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi | >> > ttee&data=01%7C01%7Csimonpj%40microsoft.com%7Cf6979d8c314b47c11 | >> > 33c08d6d4abd337%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=UF | >> > zBeDE2vfeqnbJYpXHG%2FbnM2PJsYOLiqFlVuSYELcg%3D&reserved=0 | >> -- | >> Joachim Breitner | >> mail at joachim-breitner.de | >> | >> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. | >> joachim-breitner.de%2F&data=01%7C01%7Csimonpj%40microsoft.com%7Cf | >> 6979d8c314b47c1133c08d6d4abd337%7C72f988bf86f141af91ab2d7cd011db47%7C | >> 1&sdata=Spw%2F2dNnY8edtps1c3uBA4fTRybn0dCtvqQkoKiX8eQ%3D&rese | >> rved=0 | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee at haskell.org | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai | >> l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee | >> &data=01%7C01%7Csimonpj%40microsoft.com%7Cf6979d8c314b47c1133c08d | >> 6d4abd337%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=UFzBeDE2vf | >> eqnbJYpXHG%2FbnM2PJsYOLiqFlVuSYELcg%3D&reserved=0 | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee at haskell.org | >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai | >> l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee | >> &data=01%7C01%7Csimonpj%40microsoft.com%7Cf6979d8c314b47c1133c08d | >> 6d4abd337%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=UFzBeDE2vf | >> eqnbJYpXHG%2FbnM2PJsYOLiqFlVuSYELcg%3D&reserved=0 From mail at joachim-breitner.de Mon May 20 08:39:07 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 20 May 2019 10:39:07 +0200 Subject: [ghc-steering-committee] New Github process now in place In-Reply-To: <8d68824b25eb4eb983f45560898fdd79f034fb9e.camel@joachim-breitner.de> References: <683761989b68a0e47482d7df8020fb4e3575d5f0.camel@joachim-breitner.de> <8d68824b25eb4eb983f45560898fdd79f034fb9e.camel@joachim-breitner.de> Message-ID: <472a164afd9c99fec80304a9d3a42306bd9fd7bc.camel@joachim-breitner.de> Hi, Am Montag, den 06.05.2019, 18:32 +0200 schrieb Joachim Breitner: > Am Mittwoch, den 01.05.2019, 20:51 +0200 schrieb Joachim Breitner: > > There are three possible changes to consider, plus the option of doing > > nothing. The options are > > > > A. All discussion on GitHub. > > B. Shepherd discussion looming rejection with the authors first. > > AB. The combination of the two above > > 0. Do nothing. > > Votes so far: > AB > B > A > 0 Joachim, Simon, Simon, Chris, Eric, Richard > AB > A > B > 0 Vitaly, Iavor > B > 0 > A > AB Manuel > > No vote from Ben, but I think we can go ahead with AB, which is already > ready to be merged at > https://github.com/ghc-proposals/ghc-proposals/pull/225 Merged, this is now official. Please review the section https://github.com/ghc-proposals/ghc-proposals#committee-process to have an overview of the new process, and start discussing things on Github. We can re-evaluate whether this was a good idea in a few months. I re-labeled the following proposal as waiting for shepherd recommendation: Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Type-annotated Quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Shepherd: Manuel Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Mon May 20 08:52:25 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 20 May 2019 10:52:25 +0200 Subject: [ghc-steering-committee] Status Message-ID: Dear committee, let’s see what happened in the last months. I still wonder if we should do another call for new members, to get fresh momentum here. Simons, as Chairs, what do you think? This has happened since the last status: * Triggered by input from Matthew Pickering, we refined our proposal; discussions are now supposed to be happening on GitHub and shepherd talk to authors before proposing to reject. The mail I just sent had an incomplete list of proposals that I relabeled “Pending shepherd recommendation”. See below for the full list. Dear shepherd (Iavor, Vitaly, Ben, Manuel), please follow the new process for the open proposals listed below. * were asked to review these proposals: #213 Namespace specifiers (Shepherd: Iavor) #194 Updated partial type signatures (Shepherd: Vitaly) * got a recommendation from shepherds about: - none - * returned for revision by shepherd #177 Simple constrained type families * decided about the following proposals #209 Levity-polymorphic Lift (accept) #179 Printing of foralls (accept) #190 Module qualified syntax (accept) #155 Ty vars in lambdas (accept) We currently have to act on the following 5 proposals, 3 down since last stats: Namespace Specifiers https://github.com/ghc-proposals/ghc-proposals/pull/214 Shepherd: Iavor Status: Waiting for Iavor to make a recommendation. Updated partial type signatures https://github.com/ghc-proposals/ghc-proposals/pull/194 Shepherd: Vitaly Status: Waiting for Vitaly to make a recommendation. Type annotated quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Shepherd: Manuel Status: Still waiting for recommendation. Manuel? Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Status: Still waiting for recommendation. Ben, this is pretty old! ExtraCommas https://github.com/ghc-proposals/ghc-proposals/pull/87 Shepherd: Chris Recommendation: accept Status: More discussion happened, no clear consensus emerging. Maybe we should just do do a vote (with fine-grained ranked options)? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Wed May 22 14:51:31 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 22 May 2019 14:51:31 +0000 Subject: [ghc-steering-committee] Status In-Reply-To: References: Message-ID: | I still wonder if we should do another call for new members, to get fresh | momentum here. Simons, as Chairs, what do you think? It's hard for all of us to make time to review proposals. Seeking more members would help with that, as well as keeping us open to fresh people and ideas. Are you thinking about simply having a bigger committee, or are some of us about to rotate off? Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 20 May 2019 09:52 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Status | | Dear committee, | | let’s see what happened in the last months. | | I still wonder if we should do another call for new members, to get fresh | momentum here. Simons, as Chairs, what do you think? | | | This has happened since the last status: | | * Triggered by input from Matthew Pickering, we | refined our proposal; discussions are now supposed to be happening | on GitHub and shepherd talk to authors before proposing to reject. | | The mail I just sent had an incomplete list of proposals that I | relabeled “Pending shepherd recommendation”. See below for | the full list. | | Dear shepherd (Iavor, Vitaly, Ben, Manuel), please follow the | new process for the open proposals listed below. | | * were asked to review these proposals: | #213 Namespace specifiers (Shepherd: Iavor) | #194 Updated partial type signatures (Shepherd: Vitaly) | | * got a recommendation from shepherds about: | - none - | | * returned for revision by shepherd | #177 Simple constrained type families | | * decided about the following proposals | #209 Levity-polymorphic Lift (accept) | #179 Printing of foralls (accept) | #190 Module qualified syntax (accept) | #155 Ty vars in lambdas (accept) | | | We currently have to act on the following 5 proposals, 3 down since last | stats: | | Namespace Specifiers | https://github.com/ghc-proposals/ghc-proposals/pull/214 | Shepherd: Iavor | Status: Waiting for Iavor to make a recommendation. | | Updated partial type signatures | https://github.com/ghc-proposals/ghc-proposals/pull/194 | Shepherd: Vitaly | Status: Waiting for Vitaly to make a recommendation. | | Type annotated quoters | https://github.com/ghc-proposals/ghc-proposals/pull/125 | Shepherd: Manuel | Status: Still waiting for recommendation. Manuel? | | Provenance-Qualified Package Imports | https://github.com/ghc-proposals/ghc-proposals/pull/115 | Shepherd: Ben | Status: Still waiting for recommendation. Ben, this is pretty old! | | ExtraCommas | https://github.com/ghc-proposals/ghc-proposals/pull/87 | Shepherd: Chris | Recommendation: accept | Status: More discussion happened, no clear consensus emerging. | Maybe we should just do do a vote (with fine-grained ranked options)? | | | | Cheers, | Joachim | | -- | Joachim Breitner | mail at joachim-breitner.de | http://www.joachim-breitner.de/ From rae at richarde.dev Wed May 22 17:28:06 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 22 May 2019 19:28:06 +0200 Subject: [ghc-steering-committee] Status In-Reply-To: References: Message-ID: <5C339329-7B66-4535-B849-FD95A5CC952B@richarde.dev> > On May 22, 2019, at 4:51 PM, Simon Peyton Jones via ghc-steering-committee wrote: > > It's hard for all of us to make time to review proposals. Seeking more members would help with that, as well as keeping us open to fresh people and ideas. > > Are you thinking about simply having a bigger committee, or are some of us about to rotate off? I wonder if we should think about having specific term limits on the committee (excepting, perhaps -- and at their permission -- the Simons). Members could renominate themselves when their term expires. This would serve several functions: - It's a forcing function to make sure we consider the possibility of new people on a regular basis. - A fixed term might incentivize individuals to work harder, given that the burden is time-limited. (Though a multi-year term doesn't feel very limited. To support this point, we might want to allow individuals to choose the length of their term, say an integer in the range 1-3, measured in years. There is theoretically a possibility of many people getting "in phase" and making high rollover, but we can just fix that if it happens.) - Right now, without terms, a member may feel awkward leaving, even if their interests have moved on somewhat. Term limits make a natural point at which to leave the table. - A member who wants to stay on past their term end (via self-renomination) will have an incentive to be responsive. - Though I would be thrilled to have Joachim remain Secretary in perpetuity (our BSFL -- Benevolent Secretary For Life), perhaps we should extend this idea to the secretary position, to give Joachim a natural time to renew his commitment and stave off resentment. :) Open question: if a member in good standing renominates themselves, do we still run an open nomination process? I tend to say "no", but that that opens two more questions: what is "good standing", and what if other members of the community want in? I don't have the answers here. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Wed May 22 17:30:32 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 22 May 2019 19:30:32 +0200 Subject: [ghc-steering-committee] new process on GitHub Message-ID: <0EFCF3EA-13BD-49BD-A54F-9FB2DCAC057C@richarde.dev> Hi Joachim, Might I make a small suggestion: for the next 3 (arbitrary number) times a committee comes up for discussion on GitHub, could you send an email to the list, in addition to the other steps taken? This would help make sure that no proposal gets lost while we work out any notification bugs. Committee members should, ideally, be aware of the proposal discussion without this email, but it's good to be doubly sure. Thanks! Richard From eric at seidel.io Wed May 22 17:55:27 2019 From: eric at seidel.io (Eric Seidel) Date: Wed, 22 May 2019 13:55:27 -0400 Subject: [ghc-steering-committee] Status In-Reply-To: <5C339329-7B66-4535-B849-FD95A5CC952B@richarde.dev> References: <5C339329-7B66-4535-B849-FD95A5CC952B@richarde.dev> Message-ID: <4170bb8d-4778-4c81-8722-ff50c7fc51b2@www.fastmail.com> Having a defined term length makes sense, and according to GitHub[1] we already have that. > Members have terms of 3, 4, and 5 years. Though I don't recall being given a specific term length when I joined :) Are you suggesting that, beyond well-defined term lengths, we should also have a limit on the number of terms a member can serve? > Open question: if a member in good standing renominates themselves, do > we still run an open nomination process? I think we should still have an open nomination process. It could help keep new members coming in and spread the load across the community, which seems especially important for a volunteer group. For example, I might renominate myself even though I have less and less time to serve, because I care about the community. If we then cutoff the nomination process, I serve another term even though there may be someone else who has more time and energy to devote. On the other hand, if we keep an open nomination process, I'll be able to see that other people want to serve, and could choose to withdraw my nomination with peace of mind. [1]: https://github.com/ghc-proposals/ghc-proposals/#who-is-the-committee On Wed, May 22, 2019, at 13:28, Richard Eisenberg wrote: > > > > On May 22, 2019, at 4:51 PM, Simon Peyton Jones via ghc-steering-committee wrote: > > > > It's hard for all of us to make time to review proposals. Seeking more members would help with that, as well as keeping us open to fresh people and ideas. > > > > Are you thinking about simply having a bigger committee, or are some of us about to rotate off? > > I wonder if we should think about having specific term limits on the > committee (excepting, perhaps -- and at their permission -- the > Simons). Members could renominate themselves when their term expires. > This would serve several functions: > > - It's a forcing function to make sure we consider the possibility of > new people on a regular basis. > - A fixed term might incentivize individuals to work harder, given that > the burden is time-limited. (Though a multi-year term doesn't feel very > limited. To support this point, we might want to allow individuals to > choose the length of their term, say an integer in the range 1-3, > measured in years. There is theoretically a possibility of many people > getting "in phase" and making high rollover, but we can just fix that > if it happens.) > - Right now, without terms, a member may feel awkward leaving, even if > their interests have moved on somewhat. Term limits make a natural > point at which to leave the table. > - A member who wants to stay on past their term end (via > self-renomination) will have an incentive to be responsive. > - Though I would be thrilled to have Joachim remain Secretary in > perpetuity (our BSFL -- Benevolent Secretary For Life), perhaps we > should extend this idea to the secretary position, to give Joachim a > natural time to renew his commitment and stave off resentment. :) > > Open question: if a member in good standing renominates themselves, do > we still run an open nomination process? I tend to say "no", but that > that opens two more questions: what is "good standing", and what if > other members of the community want in? I don't have the answers here. > > Richard > > > _______________________________________________ > 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 Wed May 22 18:10:05 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 22 May 2019 20:10:05 +0200 Subject: [ghc-steering-committee] new process on GitHub In-Reply-To: <0EFCF3EA-13BD-49BD-A54F-9FB2DCAC057C@richarde.dev> References: <0EFCF3EA-13BD-49BD-A54F-9FB2DCAC057C@richarde.dev> Message-ID: Hi, Am Mittwoch, den 22.05.2019, 19:30 +0200 schrieb Richard Eisenberg: > Might I make a small suggestion: for the next 3 (arbitrary number) > times a committee comes up for discussion on GitHub, could you send > an email to the list, in addition to the other steps taken? This > would help make sure that no proposal gets lost while we work out any > notification bugs. Committee members should, ideally, be aware of the > proposal discussion without this email, but it's good to be doubly > sure. shouldn’t be necessary; the process says (see last point): Now the shepherd proposes to accept or reject the proposal. To do so, they * post their recommendation, with a rationale, on the GitHub discussion thread, * label the pull request as Pending committee review, * notify the committee by mentioning @ghc-proposals/ghc-steering-committee, * include the sentence “This proposal will now be discussed by the committee. We welcome all authors to join the discussion, but kindly ask others to refrain from posting.” in the comment * drop a short mail to the mailing list informing the committee that discussion has started. In general we want messages on the list for all relevant status changes. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Wed May 22 18:18:15 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 22 May 2019 20:18:15 +0200 Subject: [ghc-steering-committee] Status In-Reply-To: <5C339329-7B66-4535-B849-FD95A5CC952B@richarde.dev> References: <5C339329-7B66-4535-B849-FD95A5CC952B@richarde.dev> Message-ID: <3cccb16a1c83340901905a705c566f240ce39ccf.camel@joachim-breitner.de> Hi, Am Mittwoch, den 22.05.2019, 19:28 +0200 schrieb Richard Eisenberg: > > > > On May 22, 2019, at 4:51 PM, Simon Peyton Jones via ghc-steering-committee wrote: > > > > It's hard for all of us to make time to review proposals. Seeking > > more members would help with that, as well as keeping us open to > > fresh people and ideas. > > > > Are you thinking about simply having a bigger committee, or are > > some of us about to rotate off? Some of us have become less involved recently, so I expect some voluntary off-rotation once it is clear that there are capable candidates to fill the spots. I don’t think we need to extend the commitee, but the shepherding process means that less active members slow things down. > I wonder if we should think about having specific term limits on the > committee (excepting, perhaps -- and at their permission -- the > Simons). The README says > Members have terms of 3, 4, and 5 years. but this has never been acted upon. > Members could renominate themselves when their term expires. This > would serve several functions: > > - It's a forcing function to make sure we consider the possibility of > new people on a regular basis. > - A fixed term might incentivize individuals to work harder, given > that the burden is time-limited. (Though a multi-year term doesn't > feel very limited. To support this point, we might want to allow > individuals to choose the length of their term, say an integer in the > range 1-3, measured in years. There is theoretically a possibility of > many people getting "in phase" and making high rollover, but we can > just fix that if it happens.) > - Right now, without terms, a member may feel awkward leaving, even > if their interests have moved on somewhat. Term limits make a natural > point at which to leave the table. > - A member who wants to stay on past their term end (via self- > renomination) will have an incentive to be responsive. > - Though I would be thrilled to have Joachim remain Secretary in > perpetuity (our BSFL -- Benevolent Secretary For Life), perhaps we > should extend this idea to the secretary position, to give Joachim a > natural time to renew his commitment and stave off resentment. :) > > Open question: if a member in good standing renominates themselves, > do we still run an open nomination process? I tend to say "no", but > that that opens two more questions: what is "good standing", and what > if other members of the community want in? I don't have the answers > here. I am leaning against a more formal process here. We have people who show very consistent and reliable interest over many years (thinking of Iavor here, to just give one example). Others naturally have a phase of high activity and then lose interest for whatever reason – but this unlikely aligns with term limits. So I’d be happy to keep playing it by ear, asking for new people when we feel that we need new energy on the committee. Cheers, Joachim BTW: I know my status mails have become slightly less often, but right now I am happy to keep doing that job. That said: should at some point in the future someone think “Joachim has become too distracted, and I think I can do that job better” then please tell me that, I won’t be offended (and, at that point in the future, likely happy to pass the job on). -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Thu May 23 10:47:18 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 23 May 2019 10:47:18 +0000 Subject: [ghc-steering-committee] Status In-Reply-To: <3cccb16a1c83340901905a705c566f240ce39ccf.camel@joachim-breitner.de> References: <5C339329-7B66-4535-B849-FD95A5CC952B@richarde.dev> <3cccb16a1c83340901905a705c566f240ce39ccf.camel@joachim-breitner.de> Message-ID: OK, here's a suggestion for how to proceed: * Ask each existing member in to indicate their current state: a) I am happy as a member, feel I am contributing. b) I am willing to continue, but would also to be content to stand down c) I would quite like to stand down * In the light of that, and the balance of stakeholder-group representation, invite nominations for new members. In general I quite like term limits, because they remove the presumption that once you are a member you are always a member. It's easy to say "at the end of your term you can re-nominate yourself" and then be considered as part of that round. If we decide to do this we should write down whose current term ends when. I'd like to invite Joachim to continue as Secretary. You are doing a great job and we would be much less effective without you. As for Simon and myself, I think there's a case for leaving us in place as figureheads that everyone will recognise, at least for now. Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 22 May 2019 19:18 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Status | | Hi, | | Am Mittwoch, den 22.05.2019, 19:28 +0200 schrieb Richard Eisenberg: | > | > | > > On May 22, 2019, at 4:51 PM, Simon Peyton Jones via ghc-steering- | committee wrote: | > > | > > It's hard for all of us to make time to review proposals. Seeking | > > more members would help with that, as well as keeping us open to | > > fresh people and ideas. | > > | > > Are you thinking about simply having a bigger committee, or are some | > > of us about to rotate off? | | Some of us have become less involved recently, so I expect some voluntary | off-rotation once it is clear that there are capable candidates to fill | the spots. I don’t think we need to extend the commitee, but the | shepherding process means that less active members slow things down. | | | > I wonder if we should think about having specific term limits on the | > committee (excepting, perhaps -- and at their permission -- the | > Simons). | | The README says | | > Members have terms of 3, 4, and 5 years. | | but this has never been acted upon. | | > Members could renominate themselves when their term expires. This | > would serve several functions: | > | > - It's a forcing function to make sure we consider the possibility of | > new people on a regular basis. | > - A fixed term might incentivize individuals to work harder, given | > that the burden is time-limited. (Though a multi-year term doesn't | > feel very limited. To support this point, we might want to allow | > individuals to choose the length of their term, say an integer in the | > range 1-3, measured in years. There is theoretically a possibility of | > many people getting "in phase" and making high rollover, but we can | > just fix that if it happens.) | > - Right now, without terms, a member may feel awkward leaving, even if | > their interests have moved on somewhat. Term limits make a natural | > point at which to leave the table. | > - A member who wants to stay on past their term end (via self- | > renomination) will have an incentive to be responsive. | > - Though I would be thrilled to have Joachim remain Secretary in | > perpetuity (our BSFL -- Benevolent Secretary For Life), perhaps we | > should extend this idea to the secretary position, to give Joachim a | > natural time to renew his commitment and stave off resentment. :) | > | > Open question: if a member in good standing renominates themselves, do | > we still run an open nomination process? I tend to say "no", but that | > that opens two more questions: what is "good standing", and what if | > other members of the community want in? I don't have the answers here. | | I am leaning against a more formal process here. We have people who show | very consistent and reliable interest over many years (thinking of Iavor | here, to just give one example). Others naturally have a phase of high | activity and then lose interest for whatever reason – but this unlikely | aligns with term limits. | | So I’d be happy to keep playing it by ear, asking for new people when we | feel that we need new energy on the committee. | | Cheers, | Joachim | | BTW: I know my status mails have become slightly less often, but right now | I am happy to keep doing that job. That said: should at some point in the | future someone think “Joachim has become too distracted, and I think I can | do that job better” then please tell me that, I won’t be offended (and, at | that point in the future, likely happy to pass the job on). | | | -- | Joachim Breitner | mail at joachim-breitner.de | http://www.joachim-breitner.de/ From mail at joachim-breitner.de Sun May 26 08:42:25 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 26 May 2019 10:42:25 +0200 Subject: [ghc-steering-committee] Status In-Reply-To: References: <5C339329-7B66-4535-B849-FD95A5CC952B@richarde.dev> <3cccb16a1c83340901905a705c566f240ce39ccf.camel@joachim-breitner.de> Message-ID: <9d1a5cdb7336053ba34672caa481c3789ac28a72.camel@joachim-breitner.de> Hi, Am Donnerstag, den 23.05.2019, 10:47 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > OK, here's a suggestion for how to proceed: > > * Ask each existing member in to indicate their current state: > a) I am happy as a member, feel I am contributing. > b) I am willing to continue, but would also to be content to stand down > c) I would quite like to stand down good idea. I will do that in individual private messages (to encourage more honest replies), and summarize the results here. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Wed May 29 10:10:55 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 29 May 2019 12:10:55 +0200 Subject: [ghc-steering-committee] Please review #228: Function result type signatures, Shepherd: Simon PJ Message-ID: <35538689a7606a8e3703aace1e9a5d7014ae534e.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: Function result type signatures have been proposed by Vladislav Zavialov https://github.com/ghc-proposals/ghc-proposals/pull/228 https://github.com/int-index/ghc-proposals/blob/fn-res-sig/proposals/0000-function-result-sigs.rst I propose Simon PJ as the Shepherd, for having commented on it before. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Wed May 29 14:58:43 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 29 May 2019 16:58:43 +0200 Subject: [ghc-steering-committee] Please review #229: Parsing of (~) and (!), Shepherd: Richard Message-ID: Dear Committee, this is your secretary speaking: Simplify parsing of (~) and (!) have been proposed by Vladislav Zavialov https://github.com/ghc-proposals/ghc-proposals/pull/229 https://github.com/int-index/ghc-proposals/blob/whitespace-bang-patterns/proposals/0000-whitespace-bang-patterns.rst I propose Richard as the Shepherd, has he already has groomed the proposal. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From iavor.diatchki at gmail.com Fri May 31 18:15:23 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 31 May 2019 11:15:23 -0700 Subject: [ghc-steering-committee] Discussion on #214, Namespace specifiers Message-ID: Hello, let's have a discussion about proposal #214, Namespace specifiers. https://github.com/ghc-proposals/ghc-proposals/pull/214 I believe our new process is to have the discussion on Github, so please share your thoughts over there. I am a bit unclear about the steps in the new process (even though I voted for it :-), but as the shepherd I think I am supposed to make an initial? recommendation. If so, at the moment I am leaning towards a "reject": I do think that the proposal has identified a valid area for improvement, but I don't quite like the currently proposed solution---I wrote some comments on GIthub as to why. Obviously, that's just my opinion, and the discussion would benefit from more input from the committee. Cheers, -Iavor From rae at richarde.dev Fri May 31 18:21:29 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 31 May 2019 14:21:29 -0400 Subject: [ghc-steering-committee] Please discuss: new lexing for (~) and (!), #229 Message-ID: Hi all, I have started committee discussion on #229 by recommending acceptance. Please see https://github.com/ghc-proposals/ghc-proposals/pull/229#issuecomment-497811793 Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri May 31 18:23:59 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 31 May 2019 20:23:59 +0200 Subject: [ghc-steering-committee] Discussion on #214, Namespace specifiers In-Reply-To: References: Message-ID: <047eebee0e2fcbaebcc5b05a38469a92c6b81f86.camel@joachim-breitner.de> Hi, Am Freitag, den 31.05.2019, 11:15 -0700 schrieb Iavor Diatchki: > I believe our new process is to have the discussion on Github, so > please share your thoughts over there. > > I am a bit unclear about the steps in the new process (even though I > voted for it :-), but as the shepherd I think I am supposed to make an > initial? recommendation. > > If so, at the moment I am leaning towards a "reject": I do think > that the proposal has identified a valid area for improvement, but I > don't quite like the currently proposed solution---I wrote some > comments on GIthub as to why. > > Obviously, that's just my opinion, and the discussion would benefit > from more input from the committee. if you think it should be rejected, the idea is that you first discuss this with the authors (on Github), to make sure that they had a chance to respond to your criticism and make sure they feel understood. Once that is settled, you follow the steps under “Now the shepherd proposes to accept or reject the proposal” on https://github.com/ghc-proposals/ghc-proposals#committee-process HTH, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: