- ghc-steering-committee

Re: [ghc-steering-committee] Defaulting rules
by Simon Peyton Jones 09 Feb '17

09 Feb '17

Well not easy for /me/ to fix. But perhaps easy for the ghc-steering-committee mail forwarding agent to fix? S From: Simon Marlow [mailto:marlowsd@gmail.com] Sent: 09 February 2017 11:14 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: [ghc-steering-committee] Defaulting rules That was fine. Oh well, I guess it's not an easy thing to fix then. On 9 February 2017 at 10:50, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Direct to you! From: Simon Marlow [mailto:marlowsd@gmail.com<mailto:marlowsd@gmail.com>] Sent: 09 February 2017 08:59 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: Re: [ghc-steering-committee] Defaulting rules Hi Simon, email from you is being marked as spam by gmail. I only just discovered this, and I have several of your messages in my spam folder. Gmail shows the following diagnostic: [cid:image001.png@01D282C6.19AF2590] Which suggests that perhaps it's a problem at your end, maybe you could get someone to look into it? Cheers Simon On 3 February 2017 at 17:38, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Dear GHC steering committee Advice needed. • Some time ago amindfv submitted https://ghc.haskell.org/trac/ghc/ticket/12923. He offered a patch 8 weeks ago. • There wasn’t much discussion about the proposed change, nor did anyone ask him to undertake the GHC proposals process • It’s a small change, but it is a user-facing one • The design isn’t obvious to me; see comment:12. • We could change it now and change it again later; it’s a corner case • It matters to him and his customers. So, should we let it in? It’s about the defaulting mechanism. With an unsolved constraint (C alpha) where alpha is otherwise unconstrained, GHC will try a series of types to fill in alpha. We extended the rules with ExtendedDefaultRules. He wants a further extension. I hate slipping things in late, actually after the deadline; but the fault is partly ours for not proactively warning people with open patches. Opinions? Simon _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee(a)haskell.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org…> https://mail.haskell.org/cgi-<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske…>bin/mailman/listinfo/ghc-steering-committee

1 0

Re: [ghc-steering-committee] Defaulting rules
by Simon Peyton Jones 09 Feb '17

09 Feb '17

This usually happens with mail from me via a mailing list, where the mailing list server has failed to do the right thing. So I think it’s the ghc-steering-committee mail forwarder. I’ll send an email direct to you, and you can see if it’s flagged the same way. Simon From: Simon Marlow [mailto:marlowsd@gmail.com] Sent: 09 February 2017 08:59 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: [ghc-steering-committee] Defaulting rules Hi Simon, email from you is being marked as spam by gmail. I only just discovered this, and I have several of your messages in my spam folder. Gmail shows the following diagnostic: [cid:image001.png@01D282C2.52B92F60] Which suggests that perhaps it's a problem at your end, maybe you could get someone to look into it? Cheers Simon On 3 February 2017 at 17:38, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Dear GHC steering committee Advice needed. • Some time ago amindfv submitted https://ghc.haskell.org/trac/ghc/ticket/12923. He offered a patch 8 weeks ago. • There wasn’t much discussion about the proposed change, nor did anyone ask him to undertake the GHC proposals process • It’s a small change, but it is a user-facing one • The design isn’t obvious to me; see comment:12. • We could change it now and change it again later; it’s a corner case • It matters to him and his customers. So, should we let it in? It’s about the defaulting mechanism. With an unsolved constraint (C alpha) where alpha is otherwise unconstrained, GHC will try a series of types to fill in alpha. We extended the rules with ExtendedDefaultRules. He wants a further extension. I hate slipping things in late, actually after the deadline; but the fault is partly ours for not proactively warning people with open patches. Opinions? Simon _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee(a)haskell.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org…> https://mail.haskell.org/cgi-<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske…>bin/mailman/listinfo/ghc-steering-committee

1 0

Mutable constructor fields
by Iavor Diatchki 07 Feb '17

07 Feb '17

Hello, I am not sure what's the process for this, but I am really keen on Simon M's "Mutable constructor fields" proposal ( https://github.com/ghc-proposals/ghc-proposals/pull/8) so I'd like to propose that we adopt it. I'd be happy to volunteer time to work on the implementation too, if there's need for that. -Iavor

4 3

Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Lazy unboxed tuples / warn on unbanged strict patterns (#35)
by Simon Peyton Jones 27 Jan '17

27 Jan '17

| The limited discussion period was a suggestion that entered the process | only rather late as a suggestion from Richard (or least my interpretation | thereof). The hope is that it makes things a bit more manageable by | keeping the number of proposals at the focus of the communities attention | small. Authors are of course able to continue working with collaborators | to hone their proposals outside of the discussion phase, but we want to | avoid having idle proposals accumulate over time. OK. I propose that we change this. Remove the four-week language. Instead: * At any time the author of a proposal can transition from "Discussion" to "Decision", by changing the status of the proposal [link to explain how], and by sending email to the committee to signal the change. The author should do this only when there has been adequate opportunity for the community to respond to the proposal. It would be unusual to consider adequate any period less than four weeks from the last substantial change to the proposal. But this is not a hard and fast rule. It's the intent that matters. * Any proposal in "Discussion" that has had no input for more than four weeks may be moved "Dormant" status (by anyone). The goal here is simply to keep manageable the list of proposals that are being actively worked on. The author is free to resurrect it to "Discussion" status. Simon | -----Original Message----- | From: Ben Gamari [mailto:ben@well-typed.com] | Sent: 26 January 2017 16:25 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Lazy | unboxed tuples / warn on unbanged strict patterns (#35) | | Simon Peyton Jones <simonpj(a)microsoft.com> writes: | | > Colleagues | > | > I didn’t think we had any 4-week discussion period. I thought that it | > was up to the author to press the button, saying “I think the proposal | > is in its final form, and the community has had enough time to | > respond”. At that point it moves from “Discussion” to “Committee | > decision” phase. | > | The limited discussion period was a suggestion that entered the process | only rather late as a suggestion from Richard (or least my interpretation | thereof). The hope is that it makes things a bit more manageable by | keeping the number of proposals at the focus of the communities attention | small. Authors are of course able to continue working with collaborators | to hone their proposals outside of the discussion phase, but we want to | avoid having idle proposals accumulate over time. | > | > I guess there could be a minimum period: the author can’t press the | > button until the community really has had time. But if they don’t want | > to push the button, fine. | > | > I’m trying put the author in control as much as possible. | > | > In decision mode we need a shepherd from the committee to push the | > discussion forward. Ben, as our current secretary, should suggest who. | > | Sure. | | | > Incidentally the “proposals process” link in the opening sentence | > https://github.com/ghc-proposals/ghc-proposals leads back to the same | > page, which is unhelpful. It should lead to | > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposal-su | > bmission.rst (which is about the whole process, not just about | > submission despite the URL). | > | I'll have a look at this. | | Cheers, | | - Ben

4 3

What should we start with?
by Joachim Breitner 26 Jan '17

26 Jan '17

Hi, good to have a mailing list, thanks to whoever set it up. I would like to see us warming up by handling a first proposal before all of us forget that we are on this committee. Which should we get started on? There are two that have the “Pending review” label: Levity Polymorphism and OverloadedRecordFields https://github.com/ghc-proposals/ghc-proposals/labels/Pending%20committee%2… According to our process documents, this label setting should have already triggered our part of the process! We could also look for proposals that have not been updated in a while (you can sort by that in the issue list) for example * Optional tuple parenthesization <https://github.com/ghc-proposals/ghc-proposals/pull/19> * Stack pointer stuff <https://github.com/ghc-proposals/ghc-proposals/pull/17> and others. I pinged a few random old proposals and asked them to maybe move forward (or abandon). Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

7 13

Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Lazy unboxed tuples / warn on unbanged strict patterns (#35)
by Simon Peyton Jones 25 Jan '17

25 Jan '17

Colleagues I didn’t think we had any 4-week discussion period. I thought that it was up to the author to press the button, saying “I think the proposal is in its final form, and the community has had enough time to respond”. At that point it moves from “Discussion” to “Committee decision” phase. I guess there could be a minimum period: the author can’t press the button until the community really has had time. But if they don’t want to push the button, fine. I’m trying put the author in control as much as possible. In decision mode we need a shepherd from the committee to push the discussion forward. Ben, as our current secretary, should suggest who. Incidentally the “proposals process” link in the opening sentence https://github.com/ghc-proposals/ghc-proposals leads back to the same page, which is unhelpful. It should lead to https://github.com/ghc-proposals/ghc-proposals/blob/master/proposal-submiss… (which is about the whole process, not just about submission despite the URL). Simon From: Ben Gamari [mailto:notifications@github.com] Sent: 24 January 2017 04:35 To: ghc-proposals/ghc-proposals <ghc-proposals(a)noreply.github.com> Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; Comment <comment(a)noreply.github.com> Subject: Re: [ghc-proposals/ghc-proposals] Lazy unboxed tuples / warn on unbanged strict patterns (#35) Note that this proposal is now half-way through its four week discussion period. At the end of this period we ask @goldfirere<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> to summarize the discussion and bring the proposal to the GHC committee for consideration. Thanks! — You are receiving this because you commented. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>.

1 0