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

Sat May 5 21:08:18 UTC 2018

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 <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 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 <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
> > 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
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: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180505/e051e228/attachment.sig>