[ghc-steering-committee] Committee Discussion : Lazy unboxed tuples

Wed Jul 12 01:16:26 UTC 2017

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 <chak at 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 <rrnewton at indiana.edu <mailto:rrnewton at 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/proposals/0000-unbanged-strict-patterns.rst> 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 <mailto: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 <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 <mail at joachim-breit
>> > ner.de <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 at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>> > >   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
>> > >
>> >
>> >
>> --
>> Joachim “nomeata” Breitner
>>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de> • https://www.joachim-breitner.de/ <https://www.joachim-breitner.de/>
>>   XMPP: nomeata at joachim-breitner.de <mailto:nomeata at joachim-breitner.de> • OpenPGP-Key: 0xF0FBF51F
>>   Debian Developer: nomeata at debian.org <mailto:nomeata at debian.org>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto: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: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170711/e6eb6e98/attachment.html>