<div dir="ltr">Dear committee,<div><br></div><div>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.  </div><div><br></div><div>I think we may as well start the timer though -- say, finish with this proposal <b>by August 8th</b>.</div><div><br></div><div>Best,</div><div>  -Ryan</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">erg <span dir="ltr"><<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Jul 11, 2017, at 9:27 PM, Manuel M T Chakravarty <<a href="mailto:chak@justtesting.org" target="_blank">chak@justtesting.org</a>> wrote:</div><br class="m_-4822322460473069033m_1378545661849689635Apple-interchange-newline"><div><div style="word-wrap:break-word">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.</div></div></blockquote><div><br></div></span><div>Thanks for jogging my memory. No one complained then, so I'll assume the same stance.</div><div><br></div><div>- 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.</div><div><br></div><div>- 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.</div><span class="m_-4822322460473069033HOEnZb"><font color="#888888"><div><br></div><div>Richard</div></font></span><div><div class="m_-4822322460473069033h5"><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div><br></div><div>Manuel</div><div><br><div><blockquote type="cite"><div>Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>>:</div><br class="m_-4822322460473069033m_1378545661849689635Apple-interchange-newline"><div><div style="word-wrap:break-word"><div>Point of process: is it allowed for me to participate in this thread? Most proposal authors would not have this privilege.</div><div><br></div><div>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.</div><div><br></div><div>So, what do we think about this point of process?</div><div><br></div><div>Thanks,</div><div>Richard</div><br><div><blockquote type="cite"><div>On Jul 11, 2017, at 9:01 PM, Manuel M T Chakravarty <<a href="mailto:chak@justtesting.org" target="_blank">chak@justtesting.org</a>> wrote:</div><br class="m_-4822322460473069033m_1378545661849689635Apple-interchange-newline"><div><div style="word-wrap:break-word"><div>Ryan,</div><div><br></div><div>I am generally in favour of this proposal — it appears to be a useful clean up.</div><div><br></div><div>However, I like to make two remarks on the process here — sorry if that appears nitpicky, but I think, it makes a difference.</div><div><br></div><div>(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.</div><div><br></div><div>(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?</div><div><br></div><div>Manuel</div><br><div><blockquote type="cite"><div>Ryan Newton <<a href="mailto:rrnewton@indiana.edu" target="_blank">rrnewton@indiana.edu</a>>:</div><br class="m_-4822322460473069033m_1378545661849689635Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_extra"><div><div class="m_-4822322460473069033m_1378545661849689635gmail_signature"><div dir="ltr"><div><div>Dear Committee,</div></div><div><br></div><div>The <a href="https://github.com/ghc-proposals/ghc-proposals/pull/35" target="_blank">public discussion</a> for <a href="https://github.com/goldfirere/ghc-proposals/blob/unbanged-strict-patterns/proposals/0000-unbanged-strict-patterns.rst" target="_blank">this one</a> has happened, now for 4 weeks of committee discussion and final accept/reject.</div><div><br></div><div>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).</div><div><br></div><div>Richard, one bit that threw me off was this:</div><div><br></div><div><i><span style="color:rgb(36,41,46);font-family:-apple-system,system-ui,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:14px">"we should require the bang even on bare variables, but that would break a lot of code I think."</span><br></i></div><div><br></div><div>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.</div><div><br></div><div>Discuss?</div><div><br></div><div>  -Ryan<br></div><div><br></div><div><br></div></div></div></div>
<br><div class="gmail_quote">On Tue, Jul 11, 2017 at 11:08 AM, Joachim Breitner <span dir="ltr"><<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
it is by Richard, I just got the URL wrong. The right pull request is<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/35" rel="noreferrer" target="_blank">https://github.com/ghc-proposa<wbr>ls/ghc-proposals/pull/35</a><br>
sorry for that.<br>
<br>
Using this thread is fine.<br>
<br>
Joachim<br>
<div class="m_-4822322460473069033m_1378545661849689635gmail-HOEnZb"><div class="m_-4822322460473069033m_1378545661849689635gmail-h5"><br>
Am Dienstag, den 11.07.2017, 10:58 -0400 schrieb Ryan Newton:<br>
> Just to clarify, this is proposed by a user "winterland".  I.e. not<br>
> Richard, right? In the process document it is the author that "brings<br>
> it before the committee" correct?<br>
><br>
> I checked and it looks like our process document does not specify the<br>
> means of our committee discussion.  I propose we discuss this one<br>
> right here on this thread, which we've already got sitting in our<br>
> inboxes.<br>
><br>
> Best,<br>
>   -Ryan<br>
><br>
><br>
> On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner <mail@joachim-breit<br>
> <a href="http://ner.de/" rel="noreferrer" target="_blank">ner.de</a>> wrote:<br>
> > Dear Committee,<br>
> ><br>
> > this is your secretary speaking:<br>
> ><br>
> > <a href="https://github.com/ghc-proposals/ghc-proposals/pull/45" rel="noreferrer" target="_blank">https://github.com/ghc-proposa<wbr>ls/ghc-proposals/pull/45</a><br>
> > was brought before the committee, by our own Richard.<br>
> ><br>
> > I propose Ryan Newton as the Shepherd, just to rotate this role<br>
> > properly.<br>
> ><br>
> > Ryan, please reach consensus as described in<br>
> > <a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank">https://github.com/ghc-proposa<wbr>ls/ghc-proposals#committee-pro<wbr>cess</a><br>
> ><br>
> > I suggest you make a recommendation about the decision, maybe point<br>
> > out<br>
> > debatable points, and assume that anyone who stays quiet agrees<br>
> > with<br>
> > you.<br>
> ><br>
> ><br>
> > Greetings,<br>
> > Joachim<br>
> ><br>
> ><br>
> > --<br>
> > Joachim Breitner<br>
> >   <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
> >   <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de<wbr>/</a><br>
> ><br>
><br>
><br>
</div></div><span class="m_-4822322460473069033m_1378545661849689635gmail-HOEnZb"><font color="#888888">--<br>
Joachim “nomeata” Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a> • <a href="https://www.joachim-breitner.de/" rel="noreferrer" target="_blank">https://www.joachim-breitner.d<wbr>e/</a><br>
  XMPP: <a href="mailto:nomeata@joachim-breitner.de" target="_blank">nomeata@joachim-breitner.de</a> • OpenPGP-Key: 0xF0FBF51F<br>
  Debian Developer: <a href="mailto:nomeata@debian.org" target="_blank">nomeata@debian.org</a></font></span><br>______________________________<wbr>_________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell<wbr>.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-b<wbr>in/mailman/listinfo/ghc-steeri<wbr>ng-committee</a><br>
<br></blockquote></div><br></div></div>
______________________________<wbr>_________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell<wbr>.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-b<wbr>in/mailman/listinfo/ghc-steeri<wbr>ng-committee</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div>______________________________<wbr>_________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell<wbr>.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-b<wbr>in/mailman/listinfo/ghc-steeri<wbr>ng-committee</a><br></div></blockquote></div><br></div></div></div></div></blockquote></div></div></div><br></div><br>______________________________<wbr>_________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell<wbr>.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-b<wbr>in/mailman/listinfo/ghc-steeri<wbr>ng-committee</a><br>
<br></blockquote></div><br></div></div>