From mail at joachim-breitner.de Tue Jul 11 06:58:15 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 11 Jul 2017 08:58:15 +0200 Subject: [ghc-steering-committee] Please review: Lazy unboxed tuples, Shepherd: Ryan Newton Message-ID: <1499756295.1162.6.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/45 was brought before the committee, by our own Richard. I propose Ryan Newton as the Shepherd, just to rotate this role properly. Ryan, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Greetings, 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 Tue Jul 11 07:06:31 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 11 Jul 2017 09:06:31 +0200 Subject: [ghc-steering-committee] Please review: Explicit foralls proposal, Simon Peyton Jones Message-ID: <1499756791.1162.8.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/55 was brought before the committee, again by our own Richard. I propose Simon Peyton Jones as the Shepherd, since he has commented on this proposal already. Simon, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- 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 Tue Jul 11 07:09:36 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 11 Jul 2017 09:09:36 +0200 Subject: [ghc-steering-committee] Status Message-ID: <1499756976.1162.9.camel@joachim-breitner.de> Hi, it has been a while since I sent out a status. Since then, we have rejected the “Eval class” proposal, https://github.com/ghc-proposals/gh c-proposals/pull/27, and two new proposals are up for discussion. Open at the moment are: UNPACK on function arguments https://github.com/ghc-proposals/ghc-proposals/pull/46 Shepherd: Simon Marlow Status: There was more discussion on GitHub. I queried the author (@treeowl) if this needs more work or can go ahead. Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Just now asked the shepherd for a recommendation. Explicit foralls proposal https://github.com/ghc-proposals/ghc-proposals/pull/55 Shepherd: Simon Peyton Jones Status: Just now asked the shepherd for a recommendation. Besides these, there are some proposals actively under discussion. You can always check them out at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no%3Alabel Greetings, 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 Tue Jul 11 15:08:21 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 11 Jul 2017 17:08:21 +0200 Subject: [ghc-steering-committee] Please review: Lazy unboxed tuples, Shepherd: Ryan Newton In-Reply-To: References: <1499756295.1162.6.camel@joachim-breitner.de> Message-ID: <1499785701.11765.1.camel@joachim-breitner.de> Hi, it is by Richard, I just got the URL wrong. The right pull request is https://github.com/ghc-proposals/ghc-proposals/pull/35 sorry for that. Using this thread is fine. Joachim Am Dienstag, den 11.07.2017, 10:58 -0400 schrieb Ryan Newton: > Just to clarify, this is proposed by a user "winterland".  I.e. not > Richard, right? In the process document it is the author that "brings > it before the committee" correct? > > I checked and it looks like our process document does not specify the > means of our committee discussion.  I propose we discuss this one > right here on this thread, which we've already got sitting in our > inboxes. > > Best, >   -Ryan > > > On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner ner.de> wrote: > > Dear Committee, > > > > this is your secretary speaking: > > > > https://github.com/ghc-proposals/ghc-proposals/pull/45 > > was brought before the committee, by our own Richard. > > > > I propose Ryan Newton as the Shepherd, just to rotate this role > > properly. > > > > Ryan, please reach consensus as described in > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > I suggest you make a recommendation about the decision, maybe point > > out > > debatable points, and assume that anyone who stays quiet agrees > > with > > you. > > > > > > Greetings, > > Joachim > > > > > > -- > > Joachim Breitner > >   mail at joachim-breitner.de > >   http://www.joachim-breitner.de/ > > > > -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- 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 rrnewton at indiana.edu Tue Jul 11 21:53:49 2017 From: rrnewton at indiana.edu (Ryan Newton) Date: Tue, 11 Jul 2017 17:53:49 -0400 Subject: [ghc-steering-committee] Committee Discussion : Lazy unboxed tuples Message-ID: Dear Committee, The public discussion for this one has happened, now for 4 weeks of committee discussion and final accept/reject. In that public discussion, you can see on Jan 11 options broken down as (1),(2),(3), with this proposal being (1). This seems to have stopped in a weird place where there was some substantial argument for (2) and (3) in the latter half of the comments, but the proposal is for (1). Richard, one bit that threw me off was this: *"we should require the bang even on bare variables, but that would break a lot of code I think."* Because that makes it seem like in spite of this cleaning-up proposal, GHC still has a basically inconsistent position on how to interpret variable-bindings of unlifted kind in patterns. Discuss? -Ryan On Tue, Jul 11, 2017 at 11:08 AM, Joachim Breitner wrote: > Hi, > > it is by Richard, I just got the URL wrong. The right pull request is > https://github.com/ghc-proposals/ghc-proposals/pull/35 > sorry for that. > > Using this thread is fine. > > Joachim > > Am Dienstag, den 11.07.2017, 10:58 -0400 schrieb Ryan Newton: > > Just to clarify, this is proposed by a user "winterland". I.e. not > > Richard, right? In the process document it is the author that "brings > > it before the committee" correct? > > > > I checked and it looks like our process document does not specify the > > means of our committee discussion. I propose we discuss this one > > right here on this thread, which we've already got sitting in our > > inboxes. > > > > Best, > > -Ryan > > > > > > On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner > ner.de> wrote: > > > Dear Committee, > > > > > > this is your secretary speaking: > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/45 > > > was brought before the committee, by our own Richard. > > > > > > I propose Ryan Newton as the Shepherd, just to rotate this role > > > properly. > > > > > > Ryan, please reach consensus as described in > > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > > > I suggest you make a recommendation about the decision, maybe point > > > out > > > debatable points, and assume that anyone who stays quiet agrees > > > with > > > you. > > > > > > > > > Greetings, > > > Joachim > > > > > > > > > -- > > > Joachim Breitner > > > mail at joachim-breitner.de > > > http://www.joachim-breitner.de/ > > > > > > > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > _______________________________________________ > 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 chak at justtesting.org Wed Jul 12 01:01:36 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Wed, 12 Jul 2017 11:01:36 +1000 Subject: [ghc-steering-committee] Committee Discussion : Lazy unboxed tuples In-Reply-To: References: Message-ID: <8CA10C38-8087-4C59-AA48-E1C4AF34DE64@justtesting.org> Ryan, I am generally in favour of this proposal — it appears to be a useful clean up. However, I like to make two remarks on the process here — sorry if that appears nitpicky, but I think, it makes a difference. (1) To keep the committee discussion smooth and quick, we did agree that the committee discussion is only on the proposal document. If any public discussion is relevant to the committee decision, it ought to be integrated into the proposal document (by the person who wrote the proposal) before the committee discussion. Specifically, I have no idea what you are talking about with Options (1) - (4) on that thread. (2) The Shepherd ought to propose a decision in favour or against the proposal. This is the default decision if nobody on the committee disagrees. I think, this is a useful policy as it serves as a forcing function for the discussion. So, what is your default decision? Manuel > Ryan Newton : > > Dear Committee, > > The public discussion for this one has happened, now for 4 weeks of committee discussion and final accept/reject. > > In that public discussion, you can see on Jan 11 options broken down as (1),(2),(3), with this proposal being (1). This seems to have stopped in a weird place where there was some substantial argument for (2) and (3) in the latter half of the comments, but the proposal is for (1). > > Richard, one bit that threw me off was this: > > "we should require the bang even on bare variables, but that would break a lot of code I think." > > Because that makes it seem like in spite of this cleaning-up proposal, GHC still has a basically inconsistent position on how to interpret variable-bindings of unlifted kind in patterns. > > Discuss? > > -Ryan > > > > On Tue, Jul 11, 2017 at 11:08 AM, Joachim Breitner > wrote: > Hi, > > it is by Richard, I just got the URL wrong. The right pull request is > https://github.com/ghc-proposals/ghc-proposals/pull/35 > sorry for that. > > Using this thread is fine. > > Joachim > > Am Dienstag, den 11.07.2017, 10:58 -0400 schrieb Ryan Newton: > > Just to clarify, this is proposed by a user "winterland". I.e. not > > Richard, right? In the process document it is the author that "brings > > it before the committee" correct? > > > > I checked and it looks like our process document does not specify the > > means of our committee discussion. I propose we discuss this one > > right here on this thread, which we've already got sitting in our > > inboxes. > > > > Best, > > -Ryan > > > > > > On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner > ner.de > wrote: > > > Dear Committee, > > > > > > this is your secretary speaking: > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/45 > > > was brought before the committee, by our own Richard. > > > > > > I propose Ryan Newton as the Shepherd, just to rotate this role > > > properly. > > > > > > Ryan, please reach consensus as described in > > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > > > I suggest you make a recommendation about the decision, maybe point > > > out > > > debatable points, and assume that anyone who stays quiet agrees > > > with > > > you. > > > > > > > > > Greetings, > > > Joachim > > > > > > > > > -- > > > Joachim Breitner > > > mail at joachim-breitner.de > > > http://www.joachim-breitner.de/ > > > > > > > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Wed Jul 12 01:16:26 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 11 Jul 2017 21:16:26 -0400 Subject: [ghc-steering-committee] Committee Discussion : Lazy unboxed tuples In-Reply-To: <8CA10C38-8087-4C59-AA48-E1C4AF34DE64@justtesting.org> References: <8CA10C38-8087-4C59-AA48-E1C4AF34DE64@justtesting.org> Message-ID: Point of process: is it allowed for me to participate in this thread? Most proposal authors would not have this privilege. My own answer to that question is to generally allow committee members to participate in the discussion. The committee will know who the author is and that he is biased, and will take that bias into account when reading the author's comments. But I don't want to respond to the points below if that would seem like an insider's advantage. So, what do we think about this point of process? Thanks, Richard > On Jul 11, 2017, at 9:01 PM, Manuel M T Chakravarty wrote: > > Ryan, > > I am generally in favour of this proposal — it appears to be a useful clean up. > > However, I like to make two remarks on the process here — sorry if that appears nitpicky, but I think, it makes a difference. > > (1) To keep the committee discussion smooth and quick, we did agree that the committee discussion is only on the proposal document. If any public discussion is relevant to the committee decision, it ought to be integrated into the proposal document (by the person who wrote the proposal) before the committee discussion. Specifically, I have no idea what you are talking about with Options (1) - (4) on that thread. > > (2) The Shepherd ought to propose a decision in favour or against the proposal. This is the default decision if nobody on the committee disagrees. I think, this is a useful policy as it serves as a forcing function for the discussion. So, what is your default decision? > > Manuel > >> Ryan Newton >: >> >> Dear Committee, >> >> The public discussion for this one has happened, now for 4 weeks of committee discussion and final accept/reject. >> >> In that public discussion, you can see on Jan 11 options broken down as (1),(2),(3), with this proposal being (1). This seems to have stopped in a weird place where there was some substantial argument for (2) and (3) in the latter half of the comments, but the proposal is for (1). >> >> Richard, one bit that threw me off was this: >> >> "we should require the bang even on bare variables, but that would break a lot of code I think." >> >> Because that makes it seem like in spite of this cleaning-up proposal, GHC still has a basically inconsistent position on how to interpret variable-bindings of unlifted kind in patterns. >> >> Discuss? >> >> -Ryan >> >> >> >> On Tue, Jul 11, 2017 at 11:08 AM, Joachim Breitner > wrote: >> Hi, >> >> it is by Richard, I just got the URL wrong. The right pull request is >> https://github.com/ghc-proposals/ghc-proposals/pull/35 >> sorry for that. >> >> Using this thread is fine. >> >> Joachim >> >> Am Dienstag, den 11.07.2017, 10:58 -0400 schrieb Ryan Newton: >> > Just to clarify, this is proposed by a user "winterland". I.e. not >> > Richard, right? In the process document it is the author that "brings >> > it before the committee" correct? >> > >> > I checked and it looks like our process document does not specify the >> > means of our committee discussion. I propose we discuss this one >> > right here on this thread, which we've already got sitting in our >> > inboxes. >> > >> > Best, >> > -Ryan >> > >> > >> > On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner > > ner.de > wrote: >> > > Dear Committee, >> > > >> > > this is your secretary speaking: >> > > >> > > https://github.com/ghc-proposals/ghc-proposals/pull/45 >> > > was brought before the committee, by our own Richard. >> > > >> > > I propose Ryan Newton as the Shepherd, just to rotate this role >> > > properly. >> > > >> > > Ryan, please reach consensus as described in >> > > https://github.com/ghc-proposals/ghc-proposals#committee-process >> > > >> > > I suggest you make a recommendation about the decision, maybe point >> > > out >> > > debatable points, and assume that anyone who stays quiet agrees >> > > with >> > > you. >> > > >> > > >> > > Greetings, >> > > Joachim >> > > >> > > >> > > -- >> > > Joachim Breitner >> > > mail at joachim-breitner.de >> > > http://www.joachim-breitner.de/ >> > > >> > >> > >> -- >> Joachim “nomeata” Breitner >> mail at joachim-breitner.de • https://www.joachim-breitner.de/ >> XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F >> Debian Developer: nomeata at debian.org >> _______________________________________________ >> 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 chak at justtesting.org Wed Jul 12 01:27:29 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Wed, 12 Jul 2017 11:27:29 +1000 Subject: [ghc-steering-committee] Committee Discussion : Lazy unboxed tuples In-Reply-To: References: <8CA10C38-8087-4C59-AA48-E1C4AF34DE64@justtesting.org> Message-ID: We had that situation before with a proposal by Joachim. IIRC Joachim did respond to technical points in the discussion, but he did not participate in the discussion itself. I think, that is fine. Manuel > Richard Eisenberg : > > Point of process: is it allowed for me to participate in this thread? Most proposal authors would not have this privilege. > > My own answer to that question is to generally allow committee members to participate in the discussion. The committee will know who the author is and that he is biased, and will take that bias into account when reading the author's comments. But I don't want to respond to the points below if that would seem like an insider's advantage. > > So, what do we think about this point of process? > > Thanks, > Richard > >> On Jul 11, 2017, at 9:01 PM, Manuel M T Chakravarty > wrote: >> >> Ryan, >> >> I am generally in favour of this proposal — it appears to be a useful clean up. >> >> However, I like to make two remarks on the process here — sorry if that appears nitpicky, but I think, it makes a difference. >> >> (1) To keep the committee discussion smooth and quick, we did agree that the committee discussion is only on the proposal document. If any public discussion is relevant to the committee decision, it ought to be integrated into the proposal document (by the person who wrote the proposal) before the committee discussion. Specifically, I have no idea what you are talking about with Options (1) - (4) on that thread. >> >> (2) The Shepherd ought to propose a decision in favour or against the proposal. This is the default decision if nobody on the committee disagrees. I think, this is a useful policy as it serves as a forcing function for the discussion. So, what is your default decision? >> >> Manuel >> >>> Ryan Newton >: >>> >>> Dear Committee, >>> >>> The public discussion for this one has happened, now for 4 weeks of committee discussion and final accept/reject. >>> >>> In that public discussion, you can see on Jan 11 options broken down as (1),(2),(3), with this proposal being (1). This seems to have stopped in a weird place where there was some substantial argument for (2) and (3) in the latter half of the comments, but the proposal is for (1). >>> >>> Richard, one bit that threw me off was this: >>> >>> "we should require the bang even on bare variables, but that would break a lot of code I think." >>> >>> Because that makes it seem like in spite of this cleaning-up proposal, GHC still has a basically inconsistent position on how to interpret variable-bindings of unlifted kind in patterns. >>> >>> Discuss? >>> >>> -Ryan >>> >>> >>> >>> On Tue, Jul 11, 2017 at 11:08 AM, Joachim Breitner > wrote: >>> Hi, >>> >>> it is by Richard, I just got the URL wrong. The right pull request is >>> https://github.com/ghc-proposals/ghc-proposals/pull/35 >>> sorry for that. >>> >>> Using this thread is fine. >>> >>> Joachim >>> >>> Am Dienstag, den 11.07.2017, 10:58 -0400 schrieb Ryan Newton: >>> > Just to clarify, this is proposed by a user "winterland". I.e. not >>> > Richard, right? In the process document it is the author that "brings >>> > it before the committee" correct? >>> > >>> > I checked and it looks like our process document does not specify the >>> > means of our committee discussion. I propose we discuss this one >>> > right here on this thread, which we've already got sitting in our >>> > inboxes. >>> > >>> > Best, >>> > -Ryan >>> > >>> > >>> > On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner >> > ner.de > wrote: >>> > > Dear Committee, >>> > > >>> > > this is your secretary speaking: >>> > > >>> > > https://github.com/ghc-proposals/ghc-proposals/pull/45 >>> > > was brought before the committee, by our own Richard. >>> > > >>> > > I propose Ryan Newton as the Shepherd, just to rotate this role >>> > > properly. >>> > > >>> > > Ryan, please reach consensus as described in >>> > > https://github.com/ghc-proposals/ghc-proposals#committee-process >>> > > >>> > > I suggest you make a recommendation about the decision, maybe point >>> > > out >>> > > debatable points, and assume that anyone who stays quiet agrees >>> > > with >>> > > you. >>> > > >>> > > >>> > > Greetings, >>> > > Joachim >>> > > >>> > > >>> > > -- >>> > > Joachim Breitner >>> > > mail at joachim-breitner.de >>> > > http://www.joachim-breitner.de/ >>> > > >>> > >>> > >>> -- >>> Joachim “nomeata” Breitner >>> mail at joachim-breitner.de • https://www.joachim-breitner.de/ >>> XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F >>> Debian Developer: nomeata at debian.org >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Wed Jul 12 01:33:12 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 11 Jul 2017 21:33:12 -0400 Subject: [ghc-steering-committee] Committee Discussion : Lazy unboxed tuples In-Reply-To: References: <8CA10C38-8087-4C59-AA48-E1C4AF34DE64@justtesting.org> Message-ID: > On Jul 11, 2017, at 9:27 PM, Manuel M T Chakravarty wrote: > > We had that situation before with a proposal by Joachim. IIRC Joachim did respond to technical points in the discussion, but he did not participate in the discussion itself. I think, that is fine. Thanks for jogging my memory. No one complained then, so I'll assume the same stance. - On alternatives to the original proposal: Yes, the proposal is for Simon PJ's (1), but (2) is considered in the Alternatives section. It's my understanding that the committee can choose to accept a model put forth in the Alternatives section of a proposal (or make other changes). So, you can suppose that both (1) and (2) are being put forth for a decision. - On Ryan's question about bangs on variables: yes, that's true that the lack of requirement for a bang on a bare variable of unlifted type is an exception to the rule. Note that this inconsistency affects only the warning that GHC might emit about an unlifted-variable binding, not the semantics of the match itself. Richard > > Manuel > >> Richard Eisenberg >: >> >> Point of process: is it allowed for me to participate in this thread? Most proposal authors would not have this privilege. >> >> My own answer to that question is to generally allow committee members to participate in the discussion. The committee will know who the author is and that he is biased, and will take that bias into account when reading the author's comments. But I don't want to respond to the points below if that would seem like an insider's advantage. >> >> So, what do we think about this point of process? >> >> Thanks, >> Richard >> >>> On Jul 11, 2017, at 9:01 PM, Manuel M T Chakravarty > wrote: >>> >>> Ryan, >>> >>> I am generally in favour of this proposal — it appears to be a useful clean up. >>> >>> However, I like to make two remarks on the process here — sorry if that appears nitpicky, but I think, it makes a difference. >>> >>> (1) To keep the committee discussion smooth and quick, we did agree that the committee discussion is only on the proposal document. If any public discussion is relevant to the committee decision, it ought to be integrated into the proposal document (by the person who wrote the proposal) before the committee discussion. Specifically, I have no idea what you are talking about with Options (1) - (4) on that thread. >>> >>> (2) The Shepherd ought to propose a decision in favour or against the proposal. This is the default decision if nobody on the committee disagrees. I think, this is a useful policy as it serves as a forcing function for the discussion. So, what is your default decision? >>> >>> Manuel >>> >>>> Ryan Newton >: >>>> >>>> Dear Committee, >>>> >>>> The public discussion for this one has happened, now for 4 weeks of committee discussion and final accept/reject. >>>> >>>> In that public discussion, you can see on Jan 11 options broken down as (1),(2),(3), with this proposal being (1). This seems to have stopped in a weird place where there was some substantial argument for (2) and (3) in the latter half of the comments, but the proposal is for (1). >>>> >>>> Richard, one bit that threw me off was this: >>>> >>>> "we should require the bang even on bare variables, but that would break a lot of code I think." >>>> >>>> Because that makes it seem like in spite of this cleaning-up proposal, GHC still has a basically inconsistent position on how to interpret variable-bindings of unlifted kind in patterns. >>>> >>>> Discuss? >>>> >>>> -Ryan >>>> >>>> >>>> >>>> On Tue, Jul 11, 2017 at 11:08 AM, Joachim Breitner > wrote: >>>> Hi, >>>> >>>> it is by Richard, I just got the URL wrong. The right pull request is >>>> https://github.com/ghc-proposals/ghc-proposals/pull/35 >>>> sorry for that. >>>> >>>> Using this thread is fine. >>>> >>>> Joachim >>>> >>>> Am Dienstag, den 11.07.2017, 10:58 -0400 schrieb Ryan Newton: >>>> > Just to clarify, this is proposed by a user "winterland". I.e. not >>>> > Richard, right? In the process document it is the author that "brings >>>> > it before the committee" correct? >>>> > >>>> > I checked and it looks like our process document does not specify the >>>> > means of our committee discussion. I propose we discuss this one >>>> > right here on this thread, which we've already got sitting in our >>>> > inboxes. >>>> > >>>> > Best, >>>> > -Ryan >>>> > >>>> > >>>> > On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner >>> > ner.de > wrote: >>>> > > Dear Committee, >>>> > > >>>> > > this is your secretary speaking: >>>> > > >>>> > > https://github.com/ghc-proposals/ghc-proposals/pull/45 >>>> > > was brought before the committee, by our own Richard. >>>> > > >>>> > > I propose Ryan Newton as the Shepherd, just to rotate this role >>>> > > properly. >>>> > > >>>> > > Ryan, please reach consensus as described in >>>> > > https://github.com/ghc-proposals/ghc-proposals#committee-process >>>> > > >>>> > > I suggest you make a recommendation about the decision, maybe point >>>> > > out >>>> > > debatable points, and assume that anyone who stays quiet agrees >>>> > > with >>>> > > you. >>>> > > >>>> > > >>>> > > Greetings, >>>> > > Joachim >>>> > > >>>> > > >>>> > > -- >>>> > > Joachim Breitner >>>> > > mail at joachim-breitner.de >>>> > > http://www.joachim-breitner.de/ >>>> > > >>>> > >>>> > >>>> -- >>>> Joachim “nomeata” Breitner >>>> mail at joachim-breitner.de • https://www.joachim-breitner.de/ >>>> XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F >>>> Debian Developer: nomeata at debian.org >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>>> >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Tue Jul 11 14:58:50 2017 From: rrnewton at gmail.com (Ryan Newton) Date: Tue, 11 Jul 2017 10:58:50 -0400 Subject: [ghc-steering-committee] Please review: Lazy unboxed tuples, Shepherd: Ryan Newton In-Reply-To: <1499756295.1162.6.camel@joachim-breitner.de> References: <1499756295.1162.6.camel@joachim-breitner.de> Message-ID: Ok, I'll shepherd. Just to clarify, this is proposed by a user "winterland". I.e. not Richard, right? In the process document it is the author that "brings it before the committee" correct? I checked and it looks like our process document *does not *specify the means of our committee discussion. I propose we discuss this one right here on this thread, which we've already got sitting in our inboxes. Best, -Ryan On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner wrote: > Dear Committee, > > this is your secretary speaking: > > https://github.com/ghc-proposals/ghc-proposals/pull/45 > was brought before the committee, by our own Richard. > > I propose Ryan Newton as the Shepherd, just to rotate this role > properly. > > Ryan, please reach consensus as described in > https://github.com/ghc-proposals/ghc-proposals#committee-process > > I suggest you make a recommendation about the decision, maybe point out > debatable points, and assume that anyone who stays quiet agrees with > you. > > > Greetings, > Joachim > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Wed Jul 12 14:07:14 2017 From: rrnewton at gmail.com (Ryan Newton) Date: Wed, 12 Jul 2017 10:07:14 -0400 Subject: [ghc-steering-committee] Committee Discussion : Lazy unboxed tuples In-Reply-To: References: <8CA10C38-8087-4C59-AA48-E1C4AF34DE64@justtesting.org> Message-ID: Dear committee, Thanks Manuel, I will try to follow those points of process is the future. On this proposal, I'll discuss further on the github thread and come back to the committee with a default recommendation in a bit. I think we may as well start the timer though -- say, finish with this proposal *by August 8th*. Best, -Ryan erg wrote: > > On Jul 11, 2017, at 9:27 PM, Manuel M T Chakravarty > wrote: > > We had that situation before with a proposal by Joachim. IIRC Joachim did > respond to technical points in the discussion, but he did not participate > in the discussion itself. I think, that is fine. > > > Thanks for jogging my memory. No one complained then, so I'll assume the > same stance. > > - On alternatives to the original proposal: Yes, the proposal is for Simon > PJ's (1), but (2) is considered in the Alternatives section. It's my > understanding that the committee can choose to accept a model put forth in > the Alternatives section of a proposal (or make other changes). So, you can > suppose that both (1) and (2) are being put forth for a decision. > > - On Ryan's question about bangs on variables: yes, that's true that the > lack of requirement for a bang on a bare variable of unlifted type is an > exception to the rule. Note that this inconsistency affects only the > warning that GHC might emit about an unlifted-variable binding, not the > semantics of the match itself. > > Richard > > > Manuel > > Richard Eisenberg : > > Point of process: is it allowed for me to participate in this thread? Most > proposal authors would not have this privilege. > > My own answer to that question is to generally allow committee members to > participate in the discussion. The committee will know who the author is > and that he is biased, and will take that bias into account when reading > the author's comments. But I don't want to respond to the points below if > that would seem like an insider's advantage. > > So, what do we think about this point of process? > > Thanks, > Richard > > On Jul 11, 2017, at 9:01 PM, Manuel M T Chakravarty > wrote: > > Ryan, > > I am generally in favour of this proposal — it appears to be a useful > clean up. > > However, I like to make two remarks on the process here — sorry if that > appears nitpicky, but I think, it makes a difference. > > (1) To keep the committee discussion smooth and quick, we did agree that > the committee discussion is only on the proposal document. If any public > discussion is relevant to the committee decision, it ought to be integrated > into the proposal document (by the person who wrote the proposal) before > the committee discussion. Specifically, I have no idea what you are talking > about with Options (1) - (4) on that thread. > > (2) The Shepherd ought to propose a decision in favour or against the > proposal. This is the default decision if nobody on the committee > disagrees. I think, this is a useful policy as it serves as a forcing > function for the discussion. So, what is your default decision? > > Manuel > > Ryan Newton : > > Dear Committee, > > The public discussion > for this one > > has happened, now for 4 weeks of committee discussion and final > accept/reject. > > In that public discussion, you can see on Jan 11 options broken down as > (1),(2),(3), with this proposal being (1). This seems to have stopped in a > weird place where there was some substantial argument for (2) and (3) in > the latter half of the comments, but the proposal is for (1). > > Richard, one bit that threw me off was this: > > > *"we should require the bang even on bare variables, but that would break > a lot of code I think."* > > Because that makes it seem like in spite of this cleaning-up proposal, GHC > still has a basically inconsistent position on how to interpret > variable-bindings of unlifted kind in patterns. > > Discuss? > > -Ryan > > > > On Tue, Jul 11, 2017 at 11:08 AM, Joachim Breitner < > mail at joachim-breitner.de> wrote: > >> Hi, >> >> it is by Richard, I just got the URL wrong. The right pull request is >> https://github.com/ghc-proposals/ghc-proposals/pull/35 >> sorry for that. >> >> Using this thread is fine. >> >> Joachim >> >> Am Dienstag, den 11.07.2017, 10:58 -0400 schrieb Ryan Newton: >> > Just to clarify, this is proposed by a user "winterland". I.e. not >> > Richard, right? In the process document it is the author that "brings >> > it before the committee" correct? >> > >> > I checked and it looks like our process document does not specify the >> > means of our committee discussion. I propose we discuss this one >> > right here on this thread, which we've already got sitting in our >> > inboxes. >> > >> > Best, >> > -Ryan >> > >> > >> > On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner > > ner.de> wrote: >> > > Dear Committee, >> > > >> > > this is your secretary speaking: >> > > >> > > https://github.com/ghc-proposals/ghc-proposals/pull/45 >> > > was brought before the committee, by our own Richard. >> > > >> > > I propose Ryan Newton as the Shepherd, just to rotate this role >> > > properly. >> > > >> > > Ryan, please reach consensus as described in >> > > https://github.com/ghc-proposals/ghc-proposals#committee-process >> > > >> > > I suggest you make a recommendation about the decision, maybe point >> > > out >> > > debatable points, and assume that anyone who stays quiet agrees >> > > with >> > > you. >> > > >> > > >> > > Greetings, >> > > Joachim >> > > >> > > >> > > -- >> > > Joachim Breitner >> > > mail at joachim-breitner.de >> > > http://www.joachim-breitner.de/ >> > > >> > >> > >> -- >> Joachim “nomeata” Breitner >> mail at joachim-breitner.de • https://www.joachim-breitner.de/ >> XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F >> Debian Developer: nomeata at debian.org >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Jul 14 12:17:40 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 14 Jul 2017 08:17:40 -0400 Subject: [ghc-steering-committee] Please review: Mutable constructor fields, Shepherd: Ryan Newton Message-ID: <1500034660.7133.5.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/8 was brought before the committee, by our own Simon Marlow. I propose Ryan Newton as the Shepherd, because he asked for it :-) Ryan, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Greetings, 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: