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 mailto:rrnewton@indiana.edu>:

Dear Committee,

The public discussion https://github.com/ghc-proposals/ghc-proposals/pull/35 for this one https://github.com/goldfirere/ghc-proposals/blob/unbanged-strict-patterns/pr... 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 mailto:mail@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 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 http://ner.de/> wrote:

...

Dear Committee,

this is your secretary speaking:

https://github.com/ghc-proposals/ghc-proposals/pull/45 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 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@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

-- Joachim “nomeata” Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de • https://www.joachim-breitner.de/ https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de mailto:nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org mailto:nomeata@debian.org _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 mailto:rae@cs.brynmawr.edu>:

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 mailto:chak@justtesting.org> 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 mailto:rrnewton@indiana.edu>:

Dear Committee,

The public discussion https://github.com/ghc-proposals/ghc-proposals/pull/35 for this one https://github.com/goldfirere/ghc-proposals/blob/unbanged-strict-patterns/pr... 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 mailto:mail@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 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 http://ner.de/> wrote:

...

Dear Committee,

this is your secretary speaking:

https://github.com/ghc-proposals/ghc-proposals/pull/45 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 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@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

-- Joachim “nomeata” Breitner mail@joachim-breitner.de mailto:mail@joachim-breitner.de • https://www.joachim-breitner.de/ https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de mailto:nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org mailto:nomeata@debian.org _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi Ryan, maybe this fell of your plate, but we should finish this almost year old proposal. I believe you have not actually made a recommendation yet. Cheers, Joachim Am Mittwoch, den 12.07.2017, 10:07 -0400 schrieb Ryan Newton:

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 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@joachim-breitner.de > > > http://www.joachim-breitner.de/ > > > > > > > > -- > Joachim “nomeata” Breitner > mail@joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata@debian.org > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/