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

[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 <rae at cs.brynmawr.edu> wrote:

>
> On Jul 11, 2017, at 9:27 PM, Manuel M T Chakravarty <chak at justtesting.org>
> 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 <rae at 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 <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>:
>
> 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> 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 <mail at joachim-breit
>> > 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: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170712/f28fb93a/attachment-0001.html>