From atzedijkstra at gmail.com Fri Feb 3 10:59:31 2017 From: atzedijkstra at gmail.com (Atze Dijkstra) Date: Fri, 3 Feb 2017 10:59:31 +0000 Subject: [ghc-steering-committee] GHC steering committee participation Message-ID: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> Dear committee members, as you may have noticed I have not actively participated in proposal reviewing. I can wrap this in a long or short story, but at the core lies lack of time combined with my role at Standard Chartered (SC) evolving in a direction less involved with GHC and Haskell language design/implementation than I originally thought it might be. Privately, outside of SC, I also see little time and energy left for committee activities. The work on proposals seems to have started actively and vigorously and I'd rather not be this silent non-contributing participant. I feel it is important to have somebody from what can likely be called the largest Haskell based industrial development group be in contact with and contribute to what by definition is an important tool for us. After some consultation with colleagues I found Roman Leshchinskiy (rleshchinskiy at gmail.com) to be willing to replace me in the committee. For most of the committee members I guess he is already known from the FP community so I leave further introduction up to himself. Within SC Roman is responsible for GHC related supporting infrastructure and as such is more than I am involved in and confronted with GHC intricacies, which places him at a better position to contribute to the GHC steering committee from an industrial perspective. I am aware that stepping down might cause inconvenience, but also feel that this better can be done now than later when the committee is already on farther on its way in dealing with proposals. I am also aware that it is not really up to me to decide what to do next after me stepping down, but I feel the proposed replacement by Roman is the best option from my perspective. all the best, Atze From simonpj at microsoft.com Fri Feb 3 11:36:22 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 3 Feb 2017 11:36:22 +0000 Subject: [ghc-steering-committee] GHC steering committee participation In-Reply-To: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> References: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> Message-ID: I'd be fine with that, if Roman feels he has enough time to contribute pro-actively. (Hi Roman!) You are quite right to raise this Atze; it's not good having members who are, in practice, unable to contribute. One just ends up with guilt all round :-). So, thank you! Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Atze Dijkstra | Sent: 03 February 2017 11:00 | To: ghc-steering-committee at haskell.org | Cc: Donald Stewart ; rleshchinskiy at gmail.com | Subject: [ghc-steering-committee] GHC steering committee participation | | Dear committee members, | | as you may have noticed I have not actively participated in proposal | reviewing. I can wrap this in a long or short story, but at the core lies | lack of time combined with my role at Standard Chartered (SC) evolving in a | direction less involved with GHC and Haskell language design/implementation | than I originally thought it might be. Privately, outside of SC, I also see | little time and energy left for committee activities. The work on proposals | seems to have started actively and vigorously and I'd rather not be this | silent non-contributing participant. I feel it is important to have somebody | from what can likely be called the largest Haskell based industrial | development group be in contact with and contribute to what by definition is | an important tool for us. After some consultation with colleagues I found | Roman Leshchinskiy (rleshchinskiy at gmail.com) to be willing to replace me in | the committee. For most of the committee members I guess he is already known | from the FP community so I leave further introduction up to himself. Within | SC Roman is responsible for GHC related supporting infrastructure and as | such is more than I am involved in and confronted with GHC intricacies, | which places him at a better position to contribute to the GHC steering | committee from an industrial perspective. I am aware that stepping down | might cause inconvenience, but also feel that this better can be done now | than later when the committee is already on farther on its way in dealing | with proposals. I am also aware that it is not really up to me to decide | what to do next after me stepping down, but I feel the proposed replacement | by Roman is the best option from my perspective. | | all the best, | Atze | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskel | l.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc3d7e811a8c6496eb0d808d44 | c23c313%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636217163861446855&sdat | a=eeW9ValuhSlOb5O9u1Wv76%2FGPNefIHMiyXhs6vl5l98%3D&reserved=0 From rleshchinskiy at gmail.com Fri Feb 3 11:58:00 2017 From: rleshchinskiy at gmail.com (Roman Leschinskiy) Date: Fri, 3 Feb 2017 11:58:00 +0000 Subject: [ghc-steering-committee] GHC steering committee participation In-Reply-To: References: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> Message-ID: <8EDFDD90-942B-4CDB-9407-8CF536BBA843@gmail.com> Hi Simon, hi everyone, I'll find the time to contribute. In general, I feel that we at SC should participate more in the Haskell community. On the other hand, I'll completely understand if you decide that someone who (unfortunately) hasn't been actively involved in GHC development in the last couple of years shouldn't be on the committee. So no pressure! Roman > On 3 Feb 2017, at 11:36, Simon Peyton Jones wrote: > > I'd be fine with that, if Roman feels he has enough time to contribute pro-actively. (Hi Roman!) > > You are quite right to raise this Atze; it's not good having members who are, in practice, unable to contribute. One just ends up with guilt all round :-). So, thank you! > > Simon > > | -----Original Message----- > | From: ghc-steering-committee [mailto:ghc-steering-committee- > | bounces at haskell.org] On Behalf Of Atze Dijkstra > | Sent: 03 February 2017 11:00 > | To: ghc-steering-committee at haskell.org > | Cc: Donald Stewart ; rleshchinskiy at gmail.com > | Subject: [ghc-steering-committee] GHC steering committee participation > | > | Dear committee members, > | > | as you may have noticed I have not actively participated in proposal > | reviewing. I can wrap this in a long or short story, but at the core lies > | lack of time combined with my role at Standard Chartered (SC) evolving in a > | direction less involved with GHC and Haskell language design/implementation > | than I originally thought it might be. Privately, outside of SC, I also see > | little time and energy left for committee activities. The work on proposals > | seems to have started actively and vigorously and I'd rather not be this > | silent non-contributing participant. I feel it is important to have somebody > | from what can likely be called the largest Haskell based industrial > | development group be in contact with and contribute to what by definition is > | an important tool for us. After some consultation with colleagues I found > | Roman Leshchinskiy (rleshchinskiy at gmail.com) to be willing to replace me in > | the committee. For most of the committee members I guess he is already known > | from the FP community so I leave further introduction up to himself. Within > | SC Roman is responsible for GHC related supporting infrastructure and as > | such is more than I am involved in and confronted with GHC intricacies, > | which places him at a better position to contribute to the GHC steering > | committee from an industrial perspective. I am aware that stepping down > | might cause inconvenience, but also feel that this better can be done now > | than later when the committee is already on farther on its way in dealing > | with proposals. I am also aware that it is not really up to me to decide > | what to do next after me stepping down, but I feel the proposed replacement > | by Roman is the best option from my perspective. > | > | all the best, > | Atze > | > | > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskel > | l.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc3d7e811a8c6496eb0d808d44 > | c23c313%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636217163861446855&sdat > | a=eeW9ValuhSlOb5O9u1Wv76%2FGPNefIHMiyXhs6vl5l98%3D&reserved=0 From simonpj at microsoft.com Fri Feb 3 17:38:24 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 3 Feb 2017 17:38:24 +0000 Subject: [ghc-steering-committee] Defaulting rules Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Feb 3 20:55:34 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 03 Feb 2017 15:55:34 -0500 Subject: [ghc-steering-committee] GHC steering committee participation In-Reply-To: <8EDFDD90-942B-4CDB-9407-8CF536BBA843@gmail.com> References: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> <8EDFDD90-942B-4CDB-9407-8CF536BBA843@gmail.com> Message-ID: <1486155334.847.1.camel@joachim-breitner.de> Hi Committee, it is very thoughtful of Atze to suggest a replacement as he steps down, and I have no reasons to doubt Roman’s qualification. But given that one purpose of instantiating the committee is to make governance a bit more transparent, I think it would be nice to publicly announce that we have a spot to fill and solicit nominations. We can mention that we try to maintain our existing nice balance between academics, industry users etc, and surely selecting Roman is a possible, maybe likely, outcome. Nevertheless it would not hurt doing so publicly. Although it would look better if we actually accepted some proposal first, to show that the committee is doing more than just filling seats :-) We had no objections to Simon’s suggestion to adopt - Update levity polymorphism - Constraint vs type so I take that as “the committee agrees”. Ben, as the committee’s de- facto secretary, would you merge and label these proposals? Greetings, Joachim -- -- 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 -------------- 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: From iavor.diatchki at gmail.com Fri Feb 3 23:29:29 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 3 Feb 2017 15:29:29 -0800 Subject: [ghc-steering-committee] Mutable constructor fields Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Feb 3 23:37:03 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 03 Feb 2017 18:37:03 -0500 Subject: [ghc-steering-committee] Mutable constructor fields In-Reply-To: References: Message-ID: <1486165023.847.4.camel@joachim-breitner.de> Hi, Am Freitag, den 03.02.2017, 15:29 -0800 schrieb Iavor Diatchki: > Hello, > > I am not sure what's the process for this, it should be labeled as “under review discussion”, ideally by the author if the author thinks it is ready for that. Greetings, Joachim -- 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 -------------- 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: From chak at justtesting.org Sat Feb 4 02:27:51 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Sat, 4 Feb 2017 13:27:51 +1100 Subject: [ghc-steering-committee] GHC steering committee participation In-Reply-To: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> References: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> Message-ID: <768A705C-0E7B-40DC-8040-DD7868E97088@justtesting.org> Atze, Thank you for bringing this up instead of just staying silent! I agree that it is beneficial to have somebody from SC involved with GHC, and Roman is, as we all know, technically an excellent choice. Cheers, Manuel > Atze Dijkstra : > > Dear committee members, > > as you may have noticed I have not actively participated in proposal reviewing. I can wrap this in a long or short story, but at the core lies lack of time combined with my role at Standard Chartered (SC) evolving in a direction less involved with GHC and Haskell language design/implementation than I originally thought it might be. Privately, outside of SC, I also see little time and energy left for committee activities. The work on proposals seems to have started actively and vigorously and I'd rather not be this silent non-contributing participant. I feel it is important to have somebody from what can likely be called the largest Haskell based industrial development group be in contact with and contribute to what by definition is an important tool for us. After some consultation with colleagues I found Roman Leshchinskiy (rleshchinskiy at gmail.com) to be willing to replace me in the committee. For most of the committee members I guess he is already known from the FP community so I leave further introduction up to himself. Within SC Roman is responsible for GHC related supporting infrastructure and as such is more than I am involved in and confronted with GHC intricacies, which places him at a better position to contribute to the GHC steering committee from an industrial perspective. I am aware that stepping down might cause inconvenience, but also feel that this better can be done now than later when the committee is already on farther on its way in dealing with proposals. I am also aware that it is not really up to me to decide what to do next after me stepping down, but I feel the proposed replacement by Roman is the best option from my perspective. > > all the best, > Atze > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From chak at justtesting.org Sat Feb 4 02:33:17 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Sat, 4 Feb 2017 13:33:17 +1100 Subject: [ghc-steering-committee] GHC steering committee participation In-Reply-To: <1486155334.847.1.camel@joachim-breitner.de> References: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> <8EDFDD90-942B-4CDB-9407-8CF536BBA843@gmail.com> <1486155334.847.1.camel@joachim-breitner.de> Message-ID: Usually, I would agree with what you are writing. However, this is a special situation as Atze never actually started to participate as a member of this committee. The situation is the same as when he had declined Simon and Simon’s original request. In that case, Simon and Simon would just have picked somebody else. Hence, if both Simons are in favour of replacing Atze by Roman, I think, we should just do this and, if they want to pick somebody else, the same applies. Personally, I would love to have somebody from SC involved as they are one of the biggest commercial users of Haskell. That is a very valuable perspective to tap into. Manuel > Joachim Breitner : > > Hi Committee, > > it is very thoughtful of Atze to suggest a replacement as he steps > down, and I have no reasons to doubt Roman’s qualification. But given > that one purpose of instantiating the committee is to make governance a > bit more transparent, I think it would be nice to publicly announce > that we have a spot to fill and solicit nominations. > > We can mention that we try to maintain our existing nice balance > between academics, industry users etc, and surely selecting Roman is a > possible, maybe likely, outcome. Nevertheless it would not hurt doing > so publicly. > > Although it would look better if we actually accepted some proposal > first, to show that the committee is doing more than just filling seats > :-) > > We had no objections to Simon’s suggestion to adopt > > - Update levity polymorphism > - Constraint vs type > > so I take that as “the committee agrees”. Ben, as the committee’s de- > facto secretary, would you merge and label these proposals? > > Greetings, > Joachim > > -- > -- > 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 From ben at well-typed.com Sat Feb 4 03:03:35 2017 From: ben at well-typed.com (Ben Gamari) Date: Fri, 03 Feb 2017 22:03:35 -0500 Subject: [ghc-steering-committee] GHC steering committee participation In-Reply-To: References: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> <8EDFDD90-942B-4CDB-9407-8CF536BBA843@gmail.com> <1486155334.847.1.camel@joachim-breitner.de> Message-ID: <8760kqhd2w.fsf@ben-laptop.smart-cactus.org> Manuel M T Chakravarty writes: > Usually, I would agree with what you are writing. However, this is a > special situation as Atze never actually started to participate as a > member of this committee. The situation is the same as when he had > declined Simon and Simon’s original request. In that case, Simon and > Simon would just have picked somebody else. Hence, if both Simons are > in favour of replacing Atze by Roman, I think, we should just do this > and, if they want to pick somebody else, the same applies. > > Personally, I would love to have somebody from SC involved as they are > one of the biggest commercial users of Haskell. That is a very > valuable perspective to tap into. > I've been sitting on my original reply to Joachim's original email for most of the day as I'm very much on the fence on this. On one hand, we did send out an email officially announcing the composition of the committee and it does feel a bit odd to change things without giving community members another chance at throwing their hat in the ring. On the other hand, I agree that we are still getting started; had this happened a several weeks ago the Simons would have just chosen someone else. Moreover, having Roman on board would be great. On balance I suppose moving ahead with Roman sounds fine. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From marlowsd at gmail.com Mon Feb 6 09:07:12 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 6 Feb 2017 09:07:12 +0000 Subject: [ghc-steering-committee] Mutable constructor fields In-Reply-To: <1486165023.847.4.camel@joachim-breitner.de> References: <1486165023.847.4.camel@joachim-breitner.de> Message-ID: I haven't been pushing this forwards mainly because I don't have the bandwidth myself to work on the implementation, but if someone else is able to do that, that would be great. There are some details of the spec to iron out. One is a syntactic decision - whether to use a new keyword "mutable" to indicate mutable fields or not - I'll request comments on the proposal. There are other details of the spec to iron out related to the implementation, but I think it'll be easier to work through those by starting on a prototype. Cheers Simon On 3 February 2017 at 23:37, Joachim Breitner wrote: > Hi, > > Am Freitag, den 03.02.2017, 15:29 -0800 schrieb Iavor Diatchki: > > Hello, > > > > I am not sure what's the process for this, > > it should be labeled as “under review discussion”, ideally by the > author if the author thinks it is ready for that. > > > > Greetings, > Joachim > -- > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at indiana.edu Tue Feb 7 15:32:41 2017 From: rrnewton at indiana.edu (Ryan Newton) Date: Tue, 7 Feb 2017 09:32:41 -0600 Subject: [ghc-steering-committee] Mutable constructor fields In-Reply-To: References: <1486165023.847.4.camel@joachim-breitner.de> Message-ID: I'm keen to be an early user and tester of this when the implementation work gets underway. Of course, given their interest in this topic Ryan Yates and Ed Kmett are also likely consumers. -Ryan On Mon, Feb 6, 2017 at 3:07 AM, Simon Marlow wrote: > I haven't been pushing this forwards mainly because I don't have the > bandwidth myself to work on the implementation, but if someone else is able > to do that, that would be great. > > There are some details of the spec to iron out. One is a syntactic > decision - whether to use a new keyword "mutable" to indicate mutable > fields or not - I'll request comments on the proposal. There are other > details of the spec to iron out related to the implementation, but I think > it'll be easier to work through those by starting on a prototype. > > Cheers > Simon > > On 3 February 2017 at 23:37, Joachim Breitner > wrote: > >> Hi, >> >> Am Freitag, den 03.02.2017, 15:29 -0800 schrieb Iavor Diatchki: >> > Hello, >> > >> > I am not sure what's the process for this, >> >> it should be labeled as “under review discussion”, ideally by the >> author if the author thinks it is ready for that. >> >> >> >> Greetings, >> Joachim >> -- >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Feb 8 12:37:17 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 8 Feb 2017 12:37:17 +0000 Subject: [ghc-steering-committee] GHC steering committee participation In-Reply-To: References: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> <8EDFDD90-942B-4CDB-9407-8CF536BBA843@gmail.com> <1486155334.847.1.camel@joachim-breitner.de> Message-ID: Simon and I discussed this, and while we see merit in Joachim's point, we're happy to just replacing Adze with Roman forthwith, for the reasons Manual sets out below. Life is short -- we should concentrate on progressing proposals rather than more nomination cycles. There'll be time for that later! OK? Let's just go for it. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Manuel M T Chakravarty | Sent: 04 February 2017 02:33 | To: Joachim Breitner | Cc: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] GHC steering committee participation | | Usually, I would agree with what you are writing. However, this is a special | situation as Atze never actually started to participate as a member of this | committee. The situation is the same as when he had declined Simon and | Simon’s original request. In that case, Simon and Simon would just have | picked somebody else. Hence, if both Simons are in favour of replacing Atze | by Roman, I think, we should just do this and, if they want to pick somebody | else, the same applies. | | Personally, I would love to have somebody from SC involved as they are one | of the biggest commercial users of Haskell. That is a very valuable | perspective to tap into. | | Manuel | | > Joachim Breitner : | > | > Hi Committee, | > | > it is very thoughtful of Atze to suggest a replacement as he steps | > down, and I have no reasons to doubt Roman’s qualification. But given | > that one purpose of instantiating the committee is to make governance | > a bit more transparent, I think it would be nice to publicly announce | > that we have a spot to fill and solicit nominations. | > | > We can mention that we try to maintain our existing nice balance | > between academics, industry users etc, and surely selecting Roman is a | > possible, maybe likely, outcome. Nevertheless it would not hurt doing | > so publicly. | > | > Although it would look better if we actually accepted some proposal | > first, to show that the committee is doing more than just filling | > seats | > :-) | > | > We had no objections to Simon’s suggestion to adopt | > | > - Update levity polymorphism | > - Constraint vs type | > | > so I take that as “the committee agrees”. Ben, as the committee’s de- | > facto secretary, would you merge and label these proposals? | > | > Greetings, | > Joachim | > | > -- | > -- | > Joachim “nomeata” Breitner | > mail at joachim-breitner.de • | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim | - | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C39f082e6eee748e18899 | 08d44ca638d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636217724186010688 | &sdata=EB09eNHo90RmsLaul9P9AlByVmFI9uHnTgvG5N9RyS8%3D&reserved=0 | > 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&da | > ta=02%7C01%7Csimonpj%40microsoft.com%7C39f082e6eee748e1889908d44ca638d | > 3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636217724186010688&sdat | > a=dpAsFCFqBSnb8fCAVYtJAcB6wMF9FngwY68eWhwS0O4%3D&reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskel | l.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C39f082e6eee748e1889908d44 | ca638d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636217724186010688&sdat | a=dpAsFCFqBSnb8fCAVYtJAcB6wMF9FngwY68eWhwS0O4%3D&reserved=0 From ben at well-typed.com Wed Feb 8 17:51:41 2017 From: ben at well-typed.com (Ben Gamari) Date: Wed, 08 Feb 2017 12:51:41 -0500 Subject: [ghc-steering-committee] GHC steering committee participation In-Reply-To: References: <5C93D9A3-08D1-43B6-AE54-4AA457E59897@gmail.com> <8EDFDD90-942B-4CDB-9407-8CF536BBA843@gmail.com> <1486155334.847.1.camel@joachim-breitner.de> Message-ID: <87y3xgd102.fsf@ben-laptop.smart-cactus.org> Simon Peyton Jones writes: > Simon and I discussed this, and while we see merit in Joachim's point, > we're happy to just replacing Adze with Roman forthwith, for the > reasons Manual sets out below. > > Life is short -- we should concentrate on progressing proposals rather > than more nomination cycles. There'll be time for that later! > > OK? Let's just go for it. > Yes, I can see the argument for this. Given how stretched we all are already, I suppose this is the pragmatic way forward. No objection here. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Thu Feb 9 10:50:28 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 9 Feb 2017 10:50:28 +0000 Subject: [ghc-steering-committee] Defaulting rules In-Reply-To: References: Message-ID: 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 at gmail.com] Sent: 09 February 2017 08:59 To: Simon Peyton Jones 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 at 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 > 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 at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 12950 bytes Desc: image001.png URL: From simonpj at microsoft.com Thu Feb 9 11:17:31 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 9 Feb 2017 11:17:31 +0000 Subject: [ghc-steering-committee] Defaulting rules In-Reply-To: References: Message-ID: 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 at gmail.com] Sent: 09 February 2017 11:14 To: Simon Peyton Jones 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 > wrote: Direct to you! From: Simon Marlow [mailto:marlowsd at gmail.com] Sent: 09 February 2017 08:59 To: Simon Peyton Jones > 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 at 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 > 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 at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 12950 bytes Desc: image001.png URL: From simonpj at microsoft.com Fri Feb 10 08:31:23 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 10 Feb 2017 08:31:23 +0000 Subject: [ghc-steering-committee] Defaulting rules In-Reply-To: References: Message-ID: Nobody replied :( I found a much simpler way to do this; it's still a design change, but it's so easy to describe and implement that I decided to adopt it. See comment:14 of #12923. And Phab:D2822 Simon From: Simon Peyton Jones Sent: 03 February 2017 17:38 To: ghc-steering-committee at haskell.org Cc: Simon Peyton Jones Subject: Defaulting rules 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrnewton at gmail.com Sun Feb 19 15:26:08 2017 From: rrnewton at gmail.com (Ryan Newton) Date: Sun, 19 Feb 2017 10:26:08 -0500 Subject: [ghc-steering-committee] Prioritizing proposals for processing? Viewing dates/deadlines? Message-ID: Dear steering committee, How do we see what the deadline is for a given proposal discussion? I know we've discussed process a fair bit, but I seem to quickly forget these things if they're not super simple. I can go here , and see proposals, oldest first. (The PR numbers effectively date them as well.) The labels are super useful too (Under discussion). Richard's original proposal is attached below. SPJ later suggested "2 weeks"->"4 weeks" for the consideration period. I think that corresponds to the "Pending Committee review" label. But right now, *no proposals have that label*. For example, how to judge the stage of PR number 36 ?: - has the "Under discussion" label - was posted Jan 15 (1 month old) - has been commented on by some committee members - doesn't have a corresponding email thread on "ghc-steering-committee" - doesn't have a shepherd, which I *think *would appear as an "Assignee" on the PR/issue, right? For better or worse I live a very deadline driven life ;-). So it would be nice to see which proposals have a decision deadline and act there first. As a small technical point, how do we record the DATE when the "Pending committee review" label is assigned, which is what starts the clock ticking right? Thanks, -Ryan P.S. It seems like the decisions about timing and process haven't filtered through to the front-page / top level README . Which says only: * "Proposals are ultimately evaluated by the GHC Steering Committee based upon a number of criteria and in light of community feedback."* On Fri, Nov 18, 2016 at 8:56 AM, Richard Eisenberg wrote: > ..... > I propose the following: > > - Establish an official ghc-committee at haskell.org mailing list that > reaches just us. It will not be open to the public to join, though I have > no problem making archives public. > - When the author of a proposal (or anyone else, really, if the author > wanders off) deems the proposal ready for a decision, that author emails > the list telling us so. > - We use an organic process to decide on one individual in the committee > who will oversee the discussion on the proposal. If organic doesn’t work, > our chair(s) assign the proposal to a member. It is expected that > membership on the committee means that we will volunteer to handle > proposals as appropriate. The committee member running this discussion > process is hereby titled the Shepherd of the proposal. (NB: This is > slightly different than my understanding of a Shepherd in Rust, who is > assigned earlier in the process.) > - Neither the shepherd nor the committee is *not* responsible for reading > GitHub (or other) commentary. The proposal will be considered on its own. > If the author wishes the committee to consider any commentary, that > commentary should be incorporated into the proposal. > - Once a decision is requested, the shepherd has two weeks (in holiday > times or near the ICFP deadline, 3) to generate consensus. If consensus is > elusive, then we vote, with the Simons retaining veto power. > - If we say no: the shepherd updates the proposal (not just the > commentary) with the reasons for rejection. The proposer is welcome to > revise and try again, but the document should retain this original > rejection information. > - If we say yes: A Trac ticket is created, referring back to the proposal > and commentary. (The shepherd is responsible for making sure this happens.) > At this point, the proposal process is technically complete. I believe it > is outside of our purview to implement, oversee implementation, attract > implementors, etc. Naturally, we will want to do this as individuals, but I > believe it’s not in our remit. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Feb 19 16:16:51 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 19 Feb 2017 11:16:51 -0500 Subject: [ghc-steering-committee] Prioritizing proposals for processing? Viewing dates/deadlines? In-Reply-To: References: Message-ID: <1487521011.2276.3.camel@joachim-breitner.de> Hi, Am Sonntag, den 19.02.2017, 10:26 -0500 schrieb Ryan Newton: > Richard's original proposal is attached below.  SPJ later suggested > "2 weeks"->"4 weeks" for the consideration period.  I think that > corresponds to the "Pending Committee review" label.  Good, then the committee is doing its job, because it has no job to do :-) > But right now, no proposals have that label.  For example, how to > judge the stage of PR number 36?: > has the "Under discussion" label  > was posted Jan 15 (1 month old) > has been commented on by some committee members > doesn't have a corresponding email thread on "ghc-steering-committee" > doesn't have a shepherd, which I think would appear as an "Assignee" > on the PR/issue, right? > For better or worse I live a very deadline driven life ;-).  So it > would be nice to see which proposals have a decision deadline and act > there first.   The author of the PR has to become active: “When you feel that your proposal is ready, … replace the Under discussion label with Pending committee review.” https://github.com/ghc-proposals/ghc-proposals/blob/master/proposal-submission.rst I don’t actually know if random people have the permission to do so, though. But the committee members are strongly encouraged to go through “Under Discussion” proposals and see if they seem to have become somewhat inactive, and ask the author there to either submit it (or, maybe, simply withdraw and close the PR). > As a small technical point, how do we record the DATE when the > "Pending committee review"  label is assigned, which is what starts > the clock ticking right? You can see it in the history of the discussion; not very discoverable though. We could use GitHub’s “Milestone” feature to set a date until something should be handled. It requires a few extra clicks, but might be worth it. Or someone writes a little script that extracts that data and visualizes it. Maybe we need to communicate better that we expect PR authors to bring their PRs forward. Greetings, Joachim -- 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 -------------- 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: From simonpj at microsoft.com Mon Feb 20 11:47:53 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 20 Feb 2017 11:47:53 +0000 Subject: [ghc-steering-committee] Prioritizing proposals for processing? Viewing dates/deadlines? In-Reply-To: References: Message-ID: I rather agree with Ryan. I think we are doing quite well on generating thoughtful debate; but rather badly on bringing those debates to a conclusion. I’d like to suggest: · The author of the proposal is responsible for moving a proposal into “committee review” status. We should make it blindingly clear that it’s the author’s responsibility; and how they should actually make that change. · We need a committee Secretary who o Assigns a “shepherd” for each proposal that is in “committee review”. (I don’t think we need a shepherd before then.) The shepherd is responsible for bringing the committee to consensus within four weeks. o Chivvies the shepherd if s/he doesn’t appear to be making progress. o Perhaps sends regular (fortnightly?) summaries of what proposals are in what state – thought that should be a web link, shouldn’t it? Yes: we should display the date of when it moved into committee review. o Makes sure that the proposals repo is in good shape. For example the submission page does not specify that the author changes status, etc. It looks like a previous version… So the Secretary chivvies the shepherd; and the shepherd chivvies the committee; and we should get decisions actually taken. Now, to date I think Ben has been de-factor Secretary; but he has rather a lot of balls to juggle, and I wonder if you would be interested/willing Joachim? Simon From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Ryan Newton Sent: 19 February 2017 15:26 To: ghc-steering-committee at haskell.org Subject: [ghc-steering-committee] Prioritizing proposals for processing? Viewing dates/deadlines? Dear steering committee, How do we see what the deadline is for a given proposal discussion? I know we've discussed process a fair bit, but I seem to quickly forget these things if they're not super simple. I can go here, and see proposals, oldest first. (The PR numbers effectively date them as well.) The labels are super useful too (Under discussion). Richard's original proposal is attached below. SPJ later suggested "2 weeks"->"4 weeks" for the consideration period. I think that corresponds to the "Pending Committee review" label. But right now, no proposals have that label. For example, how to judge the stage of PR number 36?: * has the "Under discussion" label * was posted Jan 15 (1 month old) * has been commented on by some committee members * doesn't have a corresponding email thread on "ghc-steering-committee" * doesn't have a shepherd, which I think would appear as an "Assignee" on the PR/issue, right? For better or worse I live a very deadline driven life ;-). So it would be nice to see which proposals have a decision deadline and act there first. As a small technical point, how do we record the DATE when the "Pending committee review" label is assigned, which is what starts the clock ticking right? Thanks, -Ryan P.S. It seems like the decisions about timing and process haven't filtered through to the front-page / top level README. Which says only: "Proposals are ultimately evaluated by the GHC Steering Committee based upon a number of criteria and in light of community feedback." On Fri, Nov 18, 2016 at 8:56 AM, Richard Eisenberg > wrote: ..... I propose the following: - Establish an official ghc-committee at haskell.org mailing list that reaches just us. It will not be open to the public to join, though I have no problem making archives public. - When the author of a proposal (or anyone else, really, if the author wanders off) deems the proposal ready for a decision, that author emails the list telling us so. - We use an organic process to decide on one individual in the committee who will oversee the discussion on the proposal. If organic doesn’t work, our chair(s) assign the proposal to a member. It is expected that membership on the committee means that we will volunteer to handle proposals as appropriate. The committee member running this discussion process is hereby titled the Shepherd of the proposal. (NB: This is slightly different than my understanding of a Shepherd in Rust, who is assigned earlier in the process.) - Neither the shepherd nor the committee is *not* responsible for reading GitHub (or other) commentary. The proposal will be considered on its own. If the author wishes the committee to consider any commentary, that commentary should be incorporated into the proposal. - Once a decision is requested, the shepherd has two weeks (in holiday times or near the ICFP deadline, 3) to generate consensus. If consensus is elusive, then we vote, with the Simons retaining veto power. - If we say no: the shepherd updates the proposal (not just the commentary) with the reasons for rejection. The proposer is welcome to revise and try again, but the document should retain this original rejection information. - If we say yes: A Trac ticket is created, referring back to the proposal and commentary. (The shepherd is responsible for making sure this happens.) At this point, the proposal process is technically complete. I believe it is outside of our purview to implement, oversee implementation, attract implementors, etc. Naturally, we will want to do this as individuals, but I believe it’s not in our remit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Sat Feb 25 21:48:49 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Sat, 25 Feb 2017 15:48:49 -0600 Subject: [ghc-steering-committee] Backpack, complete spec Message-ID: https://github.com/ghc-proposals/ghc-proposals/pull/5#issuecomment-280942000 Could I get a quick up/down on this? I'd rather not start making exceptions to the process we laid out. If a proposal is so complicated at the proposer cannot gather a complete specification of the proposal, it should under no circumstances be checked into source control. -- Chris Allen From mail at joachim-breitner.de Sun Feb 26 04:26:43 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 25 Feb 2017 20:26:43 -0800 Subject: [ghc-steering-committee] Redid our documentation Message-ID: <1488083203.8097.2.camel@joachim-breitner.de> [I sent this mail from Monday to the wrong address, second try] Hi, there was a bit confusion about our documentation, so with SPJ’s blessing I went ahead and restructured it a bit. For now, this is only on a branch and not live yet: https://github.com/ghc-proposals/ghc-proposals/tree/wip/docs-restructur ing Note that it starts with a concise timeline of a proposal, and from there has links to section answering specific questions, within the same file. What was three files before (README, process, committee) is now all in here (with the exception of the “detailed instructions” for the Github-novice, which is in a separate file). This should make it easier for everyone involved to know who has to do what when. Our process is, however, flawed: We ask authors to set labels (“Under Discussion” and “Under Committee Review”), but they do not have permissions to do so. So this does not quite work. So I suggest the following change:  * What was “Under Discussion” is now simply any PR that does not have any other label. This way, when opening discussion, nothing concrete has to be done. Which is easier. (GitHub allows to list all PRs that have no label, so there is no loss in functionality here.)  * When the author wants to submit the PR, he sends a mail to this mailinglist (is this set up to accept mails from non-subscribers?) and it its the task of the shephard to set the label to indicate that that the committee has accepted to review the proposal. (At this point, the shephard could for example set the `Out-of-scope` label instead.) If there are no complains I will adjust the docs-restructuring branch accordingly and then move that to master. Greetings, Joachim -- 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 -------------- 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: From rae at cs.brynmawr.edu Sun Feb 26 16:47:47 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sun, 26 Feb 2017 11:47:47 -0500 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: <1488083203.8097.2.camel@joachim-breitner.de> References: <1488083203.8097.2.camel@joachim-breitner.de> Message-ID: > On Feb 25, 2017, at 11:26 PM, Joachim Breitner wrote: > > * What was “Under Discussion” is now simply any PR that does not have > any other label. This way, when opening discussion, nothing concrete > has to be done. Which is easier. (GitHub allows to list all PRs that > have no label, so there is no loss in functionality here.) > > * When the author wants to submit the PR, he sends a mail to this > mailinglist (is this set up to accept mails from non-subscribers?) and > it its the task of the shephard to set the label to indicate that that > the committee has accepted to review the proposal. (At this point, the > shephard could for example set the `Out-of-scope` label instead.) While I have not re-read the documentation changes, this tweak seems sensible to me. I was always skeptical of having us react simply to a label change without an email. Thanks for doing this! Richard From cma at bitemyapp.com Sun Feb 26 17:07:10 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Sun, 26 Feb 2017 11:07:10 -0600 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: References: <1488083203.8097.2.camel@joachim-breitner.de> Message-ID: Label changes are pretty under the radar, which is why my original suggestion included the project board. Messages to the mailing list could work, but I'd prefer we kept this for our discussions and figure out notifications on Github. IIRC, we were supposed to assign helpers to the issues. My prior assumption had been that the proposer would cc them in the Github issue. The helper would then notify the broader committee on the mailing list. On Sun, Feb 26, 2017 at 10:47 AM, Richard Eisenberg wrote: > >> On Feb 25, 2017, at 11:26 PM, Joachim Breitner wrote: >> >> * What was “Under Discussion” is now simply any PR that does not have >> any other label. This way, when opening discussion, nothing concrete >> has to be done. Which is easier. (GitHub allows to list all PRs that >> have no label, so there is no loss in functionality here.) >> >> * When the author wants to submit the PR, he sends a mail to this >> mailinglist (is this set up to accept mails from non-subscribers?) and >> it its the task of the shephard to set the label to indicate that that >> the committee has accepted to review the proposal. (At this point, the >> shephard could for example set the `Out-of-scope` label instead.) > > While I have not re-read the documentation changes, this tweak seems sensible to me. I was always skeptical of having us react simply to a label change without an email. > > Thanks for doing this! > > Richard > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Chris Allen Currently working on http://haskellbook.com From chak at justtesting.org Sun Feb 26 23:16:50 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Mon, 27 Feb 2017 10:16:50 +1100 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: References: <1488083203.8097.2.camel@joachim-breitner.de> Message-ID: Joachim’s suggestion makes sense to me, but I also agree with Chris that if we can use GitHub notifications, that would be more flexible. (Everybody who wants can turn the notifications into emails for just themselves in their own GitHub settings.) > Christopher Allen : > > Label changes are pretty under the radar, which is why my original > suggestion included the project board. > > Messages to the mailing list could work, but I'd prefer we kept this > for our discussions and figure out notifications on Github. > > IIRC, we were supposed to assign helpers to the issues. My prior > assumption had been that the proposer would cc them in the Github > issue. The helper would then notify the broader committee on the > mailing list. > > On Sun, Feb 26, 2017 at 10:47 AM, Richard Eisenberg wrote: >> >>> On Feb 25, 2017, at 11:26 PM, Joachim Breitner wrote: >>> >>> * What was “Under Discussion” is now simply any PR that does not have >>> any other label. This way, when opening discussion, nothing concrete >>> has to be done. Which is easier. (GitHub allows to list all PRs that >>> have no label, so there is no loss in functionality here.) >>> >>> * When the author wants to submit the PR, he sends a mail to this >>> mailinglist (is this set up to accept mails from non-subscribers?) and >>> it its the task of the shephard to set the label to indicate that that >>> the committee has accepted to review the proposal. (At this point, the >>> shephard could for example set the `Out-of-scope` label instead.) >> >> While I have not re-read the documentation changes, this tweak seems sensible to me. I was always skeptical of having us react simply to a label change without an email. >> >> Thanks for doing this! >> >> Richard >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Mon Feb 27 02:29:51 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 26 Feb 2017 18:29:51 -0800 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: References: <1488083203.8097.2.camel@joachim-breitner.de> Message-ID: <1488162591.19719.3.camel@joachim-breitner.de> Hi Manuel, just to make sure I get what you are saying, are you suggesting this approach? * (At least) one committee member, let’s call him the secretary, promises to watch the GitHub repository close enough. * When an author wants to bring a proposal before the committe, he adds a comment to the a pull request, briefly summarizing the major  points raised during the discussion period and stating their belief that the proposal is ready for review.. * The secretary notices that, labels the proposal as “Pending committee review” and notifies the committee. This would be slightly more convenient for the submitters, and slightly more work for the committee. But I guess it makes sense, and we can try this way. Simon already shoved me towards picking up the “secretary” hat, to reduce load on Ben. Ben, unless you protest, I’ll take over this role. I updated https://github.com/ghc-proposals/ghc-proposals/tree/wip/docs-restructuring accordingly Greetings, Joachim Am Montag, den 27.02.2017, 10:16 +1100 schrieb Manuel M T Chakravarty: > Joachim’s suggestion makes sense to me, but I also agree with Chris > that if we can use GitHub notifications, that would be more flexible. > (Everybody who wants can turn the notifications into emails for just > themselves in their own GitHub settings.) > > > Christopher Allen : > > > > Label changes are pretty under the radar, which is why my original > > suggestion included the project board. > > > > Messages to the mailing list could work, but I'd prefer we kept > > this > > for our discussions and figure out notifications on Github. > > > > IIRC, we were supposed to assign helpers to the issues. My prior > > assumption had been that the proposer would cc them in the Github > > issue. The helper would then notify the broader committee on the > > mailing list. > > > > On Sun, Feb 26, 2017 at 10:47 AM, Richard Eisenberg > r.edu> wrote: > > > > > > > On Feb 25, 2017, at 11:26 PM, Joachim Breitner > > > eitner.de> wrote: > > > > > > > > * What was “Under Discussion” is now simply any PR that does > > > > not have > > > > any other label. This way, when opening discussion, nothing > > > > concrete > > > > has to be done. Which is easier. (GitHub allows to list all PRs > > > > that > > > > have no label, so there is no loss in functionality here.) > > > > > > > > * When the author wants to submit the PR, he sends a mail to > > > > this > > > > mailinglist (is this set up to accept mails from non- > > > > subscribers?) and > > > > it its the task of the shephard to set the label to indicate > > > > that that > > > > the committee has accepted to review the proposal. (At this > > > > point, the > > > > shephard could for example set the `Out-of-scope` label > > > > instead.) > > > > > > While I have not re-read the documentation changes, this tweak > > > seems sensible to me. I was always skeptical of having us react > > > simply to a label change without an email. > > > > > > Thanks for doing this! > > > > > > Richard > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-co > > > mmittee > > > > > > > > --  > > Chris Allen > > Currently working on http://haskellbook.com > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-comm > > ittee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit > tee -- 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: From cma at bitemyapp.com Mon Feb 27 05:20:30 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Sun, 26 Feb 2017 23:20:30 -0600 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: <1488162591.19719.3.camel@joachim-breitner.de> References: <1488083203.8097.2.camel@joachim-breitner.de> <1488162591.19719.3.camel@joachim-breitner.de> Message-ID: This sounds good to me, if everyone is comfortable with it. On Sun, Feb 26, 2017 at 8:29 PM, Joachim Breitner wrote: > Hi Manuel, > > just to make sure I get what you are saying, are you suggesting this > approach? > > * (At least) one committee member, let’s call him the secretary, > promises to watch the GitHub repository close enough. > * When an author wants to bring a proposal before the committe, he > adds a comment to the a pull request, briefly summarizing the major > points raised during the discussion period and stating their belief > that the proposal is ready for review.. > * The secretary notices that, labels the proposal as > “Pending committee review” and notifies the committee. > > This would be slightly more convenient for the submitters, and slightly > more work for the committee. But I guess it makes sense, and we can try > this way. > > Simon already shoved me towards picking up the “secretary” hat, to > reduce load on Ben. Ben, unless you protest, I’ll take over this role. > > I updated > https://github.com/ghc-proposals/ghc-proposals/tree/wip/docs-restructuring > accordingly > > Greetings, > Joachim > > > Am Montag, den 27.02.2017, 10:16 +1100 schrieb Manuel M T Chakravarty: >> Joachim’s suggestion makes sense to me, but I also agree with Chris >> that if we can use GitHub notifications, that would be more flexible. >> (Everybody who wants can turn the notifications into emails for just >> themselves in their own GitHub settings.) >> >> > Christopher Allen : >> > >> > Label changes are pretty under the radar, which is why my original >> > suggestion included the project board. >> > >> > Messages to the mailing list could work, but I'd prefer we kept >> > this >> > for our discussions and figure out notifications on Github. >> > >> > IIRC, we were supposed to assign helpers to the issues. My prior >> > assumption had been that the proposer would cc them in the Github >> > issue. The helper would then notify the broader committee on the >> > mailing list. >> > >> > On Sun, Feb 26, 2017 at 10:47 AM, Richard Eisenberg > > r.edu> wrote: >> > > >> > > > On Feb 25, 2017, at 11:26 PM, Joachim Breitner > > > > eitner.de> wrote: >> > > > >> > > > * What was “Under Discussion” is now simply any PR that does >> > > > not have >> > > > any other label. This way, when opening discussion, nothing >> > > > concrete >> > > > has to be done. Which is easier. (GitHub allows to list all PRs >> > > > that >> > > > have no label, so there is no loss in functionality here.) >> > > > >> > > > * When the author wants to submit the PR, he sends a mail to >> > > > this >> > > > mailinglist (is this set up to accept mails from non- >> > > > subscribers?) and >> > > > it its the task of the shephard to set the label to indicate >> > > > that that >> > > > the committee has accepted to review the proposal. (At this >> > > > point, the >> > > > shephard could for example set the `Out-of-scope` label >> > > > instead.) >> > > >> > > While I have not re-read the documentation changes, this tweak >> > > seems sensible to me. I was always skeptical of having us react >> > > simply to a label change without an email. >> > > >> > > Thanks for doing this! >> > > >> > > Richard >> > > _______________________________________________ >> > > ghc-steering-committee mailing list >> > > ghc-steering-committee at haskell.org >> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-co >> > > mmittee >> > >> > >> > >> > -- >> > Chris Allen >> > Currently working on http://haskellbook.com >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-comm >> > ittee >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit >> tee > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- Chris Allen Currently working on http://haskellbook.com From simonpj at microsoft.com Mon Feb 27 10:20:08 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 27 Feb 2017 10:20:08 +0000 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: References: <1488083203.8097.2.camel@joachim-breitner.de> Message-ID: | Joachim’s suggestion makes sense to me, but I also agree with Chris that | if we can use GitHub notifications, that would be more flexible. | (Everybody who wants can turn the notifications into emails for just | themselves in their own GitHub settings.) Fine with me provided someone tells me how (iff we decide to take this approach). S | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Manuel M T Chakravarty | Sent: 26 February 2017 23:17 | To: Christopher Allen | Cc: ghc-steering-committee at haskell.org; Joachim Breitner | Subject: Re: [ghc-steering-committee] Redid our documentation | | Joachim’s suggestion makes sense to me, but I also agree with Chris that | if we can use GitHub notifications, that would be more flexible. | (Everybody who wants can turn the notifications into emails for just | themselves in their own GitHub settings.) | | > Christopher Allen : | > | > Label changes are pretty under the radar, which is why my original | > suggestion included the project board. | > | > Messages to the mailing list could work, but I'd prefer we kept this | > for our discussions and figure out notifications on Github. | > | > IIRC, we were supposed to assign helpers to the issues. My prior | > assumption had been that the proposer would cc them in the Github | > issue. The helper would then notify the broader committee on the | > mailing list. | > | > On Sun, Feb 26, 2017 at 10:47 AM, Richard Eisenberg | wrote: | >> | >>> On Feb 25, 2017, at 11:26 PM, Joachim Breitner wrote: | >>> | >>> * What was “Under Discussion” is now simply any PR that does not | >>> have any other label. This way, when opening discussion, nothing | >>> concrete has to be done. Which is easier. (GitHub allows to list all | >>> PRs that have no label, so there is no loss in functionality here.) | >>> | >>> * When the author wants to submit the PR, he sends a mail to this | >>> mailinglist (is this set up to accept mails from non-subscribers?) | >>> and it its the task of the shephard to set the label to indicate | >>> that that the committee has accepted to review the proposal. (At | >>> this point, the shephard could for example set the `Out-of-scope` | >>> label instead.) | >> | >> While I have not re-read the documentation changes, this tweak seems | sensible to me. I was always skeptical of having us react simply to a | label change without an email. | >> | >> Thanks for doing this! | >> | >> Richard | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee at haskell.org | >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | >> .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee& | >> data=02%7C01%7Csimonpj%40microsoft.com%7C794804e2706940e83cb008d45e9d | >> a111%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636237478497904474& | >> sdata=dgEObMpv0tcZhc%2FFJkgI61nRdE%2Boup4lR8%2Fgw%2BMxwZs%3D&reserved | >> =0 | > | > | > | > -- | > Chris Allen | > Currently working on | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskel | > lbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C794804e2706940e83cb | > 008d45e9da111%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63623747849 | > 7904474&sdata=Hin%2FwBr5RiSh2n9esw54baOxoBbkOMZfBYC43nUZd9I%3D&reserve | > d=0 _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee at haskell.org | > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | > haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&da | > ta=02%7C01%7Csimonpj%40microsoft.com%7C794804e2706940e83cb008d45e9da11 | > 1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636237478497904474&sdat | > a=dgEObMpv0tcZhc%2FFJkgI61nRdE%2Boup4lR8%2Fgw%2BMxwZs%3D&reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C794804e2706940e83cb008d | 45e9da111%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636237478497904474& | sdata=dgEObMpv0tcZhc%2FFJkgI61nRdE%2Boup4lR8%2Fgw%2BMxwZs%3D&reserved=0 From marlowsd at gmail.com Mon Feb 27 10:48:00 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 27 Feb 2017 10:48:00 +0000 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: <1488083203.8097.2.camel@joachim-breitner.de> References: <1488083203.8097.2.camel@joachim-breitner.de> Message-ID: I like the new organisation. One functional difference I noticed: the new description says that we assign a shepherd when the proposal starts the review process, but under the existing process a shepherd is assigned to each proposal when the PR is created (but I guess we haven't been sticking to this?). Ideally I think we'd assign shepherds earlier because it will streamline the review process: the shepherd will spot things that should be clarified or addressed before the rest of the committee gets involved. I think it's likely to be a better use of resources. This also addresses the question about labels: if each proposal has a shepherd, then the shepherd will notice when the proposer adds a comment to the PR requesting review, and can formally start the process with the rest of the committee. Cheers Simon On 26 February 2017 at 04:26, Joachim Breitner wrote: > [I sent this mail from Monday to the wrong address, second try] > > Hi, > > there was a bit confusion about our documentation, so with SPJ’s > blessing I went ahead and restructured it a bit. For now, this is only > on a branch and not live yet: > > https://github.com/ghc-proposals/ghc-proposals/tree/wip/docs-restructur > ing > > Note that it starts with a concise timeline of a proposal, and from > there has links to section answering specific questions, within the > same file. What was three files before (README, process, committee) is > now all in here (with the exception of the “detailed instructions” for > the Github-novice, which is in a separate file). This should make it > easier for everyone involved to know who has to do what when. > > Our process is, however, flawed: We ask authors to set labels (“Under > Discussion” and “Under Committee Review”), but they do not have > permissions to do so. So this does not quite work. > > So I suggest the following change: > > * What was “Under Discussion” is now simply any PR that does not have > any other label. This way, when opening discussion, nothing concrete > has to be done. Which is easier. (GitHub allows to list all PRs that > have no label, so there is no loss in functionality here.) > > * When the author wants to submit the PR, he sends a mail to this > mailinglist (is this set up to accept mails from non-subscribers?) and > it its the task of the shephard to set the label to indicate that that > the committee has accepted to review the proposal. (At this point, the > shephard could for example set the `Out-of-scope` label instead.) > > > If there are no complains I will adjust the docs-restructuring branch > accordingly and then move that to master. > > Greetings, > Joachim > > > > -- > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Mon Feb 27 03:00:01 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Mon, 27 Feb 2017 14:00:01 +1100 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: <1488162591.19719.3.camel@joachim-breitner.de> References: <1488083203.8097.2.camel@joachim-breitner.de> <1488162591.19719.3.camel@joachim-breitner.de> Message-ID: Hi Joachim, No, I don’t think, the secretary should be expected to watch repositories. However, GitHub notifications can be configured to send an email — here is the notifications settings screen If ”Email” is checked under ”Participating” for the secretary, an @mention will send an email to the secretary. Hence, I would suggest to require of proposal authors that they add a comment explicitly @mention’ing the secretary when they want to submit a proposal for review. And, thank you that you are willing to assume the role of the secretary! Cheers, Manuel PS: I haven’t used GitHub project boards myself much, but they may be useful to provide a high-level overview on GitHub itself: https://help.github.com/articles/tracking-the-progress-of-your-work-with-projects/ PPS: Alternatively, if you don’t want to get emails for GitHub conversations you are participating in, you can also always just watch your GitHub notifications on the web interface without any need to actually go into all the repos and check whether somebody wrote a message requesting review. > Joachim Breitner : > > Hi Manuel, > > just to make sure I get what you are saying, are you suggesting this > approach? > > * (At least) one committee member, let’s call him the secretary, > promises to watch the GitHub repository close enough. > * When an author wants to bring a proposal before the committe, he > adds a comment to the a pull request, briefly summarizing the major > points raised during the discussion period and stating their belief > that the proposal is ready for review.. > * The secretary notices that, labels the proposal as > “Pending committee review” and notifies the committee. > > This would be slightly more convenient for the submitters, and slightly > more work for the committee. But I guess it makes sense, and we can try > this way. > > Simon already shoved me towards picking up the “secretary” hat, to > reduce load on Ben. Ben, unless you protest, I’ll take over this role. > > I updated > https://github.com/ghc-proposals/ghc-proposals/tree/wip/docs-restructuring > accordingly > > Greetings, > Joachim > > > Am Montag, den 27.02.2017, 10:16 +1100 schrieb Manuel M T Chakravarty: >> Joachim’s suggestion makes sense to me, but I also agree with Chris >> that if we can use GitHub notifications, that would be more flexible. >> (Everybody who wants can turn the notifications into emails for just >> themselves in their own GitHub settings.) >> >>> Christopher Allen : >>> >>> Label changes are pretty under the radar, which is why my original >>> suggestion included the project board. >>> >>> Messages to the mailing list could work, but I'd prefer we kept >>> this >>> for our discussions and figure out notifications on Github. >>> >>> IIRC, we were supposed to assign helpers to the issues. My prior >>> assumption had been that the proposer would cc them in the Github >>> issue. The helper would then notify the broader committee on the >>> mailing list. >>> >>> On Sun, Feb 26, 2017 at 10:47 AM, Richard Eisenberg >> r.edu> wrote: >>>> >>>>> On Feb 25, 2017, at 11:26 PM, Joachim Breitner >>>> eitner.de> wrote: >>>>> >>>>> * What was “Under Discussion” is now simply any PR that does >>>>> not have >>>>> any other label. This way, when opening discussion, nothing >>>>> concrete >>>>> has to be done. Which is easier. (GitHub allows to list all PRs >>>>> that >>>>> have no label, so there is no loss in functionality here.) >>>>> >>>>> * When the author wants to submit the PR, he sends a mail to >>>>> this >>>>> mailinglist (is this set up to accept mails from non- >>>>> subscribers?) and >>>>> it its the task of the shephard to set the label to indicate >>>>> that that >>>>> the committee has accepted to review the proposal. (At this >>>>> point, the >>>>> shephard could for example set the `Out-of-scope` label >>>>> instead.) >>>> >>>> While I have not re-read the documentation changes, this tweak >>>> seems sensible to me. I was always skeptical of having us react >>>> simply to a label change without an email. >>>> >>>> Thanks for doing this! >>>> >>>> Richard >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-co >>>> mmittee >>> >>> >>> >>> -- >>> Chris Allen >>> Currently working on http://haskellbook.com >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-comm >>> ittee >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-commit >> tee > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-1.png Type: image/png Size: 193927 bytes Desc: not available URL: From mail at joachim-breitner.de Mon Feb 27 19:03:15 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 27 Feb 2017 11:03:15 -0800 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: References: <1488083203.8097.2.camel@joachim-breitner.de> Message-ID: <1488222195.2145.1.camel@joachim-breitner.de> Hi, Am Montag, den 27.02.2017, 10:48 +0000 schrieb Simon Marlow: > I like the new organisation.  One functional difference I noticed: > the new description says that we assign a shepherd when the proposal > starts the review process, but under the existing process a shepherd > is assigned to each proposal when the PR is created I don’t think this is true. The first mention of Shephard is after the bullet point “Once the committee has been notified that a proposal is ready for decision”. > (but I guess we haven't been sticking to this?).  Ideally I think > we'd assign shepherds earlier because it will streamline the review > process: the shepherd will spot things that should be clarified or > addressed before the rest of the committee gets involved.  I think > it's likely to be a better use of resources. I doubt it. Many proposals never seem to reach the state where they are actually submitted for review, e.g. due to negative feedback in the discussion phase. No point in wasting resources on these. Anyways, we can refine the process later. I will merge the current documentation now, including declaring me the Secretary. Greetings, Joachim -- -- 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 -------------- 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: From mail at joachim-breitner.de Mon Feb 27 19:05:50 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 27 Feb 2017 11:05:50 -0800 Subject: [ghc-steering-committee] Review requested: Hex floats, Shephard: Iavor Message-ID: <1488222350.2145.3.camel@joachim-breitner.de> Hi, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/37 was brought before the committee. I propose Iavor as the Shephard. Iavor, 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 “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 -------------- 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: From cma at bitemyapp.com Mon Feb 27 19:13:35 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 27 Feb 2017 13:13:35 -0600 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: <1488222195.2145.1.camel@joachim-breitner.de> References: <1488083203.8097.2.camel@joachim-breitner.de> <1488222195.2145.1.camel@joachim-breitner.de> Message-ID: >Many proposals never seem to reach the state where they are actually submitted for review, e.g. due to negative feedback in the discussion phase. No point in wasting resources on these. Seems like a good thing to me as well, I agree. On Mon, Feb 27, 2017 at 1:03 PM, Joachim Breitner wrote: > Hi, > > Am Montag, den 27.02.2017, 10:48 +0000 schrieb Simon Marlow: >> I like the new organisation. One functional difference I noticed: >> the new description says that we assign a shepherd when the proposal >> starts the review process, but under the existing process a shepherd >> is assigned to each proposal when the PR is created > > I don’t think this is true. The first mention of Shephard is after the > bullet point “Once the committee has been notified that a proposal is > ready for decision”. > >> (but I guess we haven't been sticking to this?). Ideally I think >> we'd assign shepherds earlier because it will streamline the review >> process: the shepherd will spot things that should be clarified or >> addressed before the rest of the committee gets involved. I think >> it's likely to be a better use of resources. > > I doubt it. Many proposals never seem to reach the state where they are > actually submitted for review, e.g. due to negative feedback in the > discussion phase. No point in wasting resources on these. > > > Anyways, we can refine the process later. I will merge the current > documentation now, including declaring me the Secretary. > > Greetings, > Joachim > > -- > -- > 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 > -- Chris Allen Currently working on http://haskellbook.com From iavor.diatchki at gmail.com Mon Feb 27 21:34:27 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 27 Feb 2017 13:34:27 -0800 Subject: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals Message-ID: Hello, I was assigned to be the shepherd for the Hex Float proposal ( https://github.com/ghc-proposals/ghc-proposals/pull/37), so I would like to propose that we accept it for implementation in GHC. This is a small change, which can be summarized as follows: - allow floating point numbers to be written using hex digits. The format is exactly the same as decimal floating point numbers, except for: - the literals start with 0x - the digits are in hex - the exponent symbol is `p` or `P`, instead of `e` or `E` - the exponent is in base 2, rather than base 10 This notation has become popular among people working with floating point numbers, as the numbers you write can be represented exactly, which is not the case for base 10 numbers. The following points were discussed: - the exact format to use, compared to what's allowed by other languages: we decided to just follow Haskell's decimal float notation, for least surprise - should overflow (which becomes `Inf`) result in a warning? We decided that this is an orthogonal issue, also relevant to decimal floating point and made a GHC ticket (#13232) - there is an odd interaction between floating point (both decimal and hex) and -XNegativeLiterals, related to negative 0, see ticket #13211 - changing the Read instances for Float and Double to recognize hex floats could break some programs, although that does not seem all that likely - there is a question of how many extra pretty printing functions to add to `Numeric`: the current thinking is that maybe just one `showHFloat` is sufficient; the alternative is to add 5, mirroring the `show[E,F,G]Float` functions for decimals. I also had a stab at implementing the basic notation here: https://phabricator.haskell.org/D3066 I haven't done the changes to the libraries yet. Please let me know if you have any objections or suggestions on what might needs to be changed. Cheers, -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Feb 27 22:48:08 2017 From: ben at well-typed.com (Ben Gamari) Date: Mon, 27 Feb 2017 17:48:08 -0500 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: <1488162591.19719.3.camel@joachim-breitner.de> References: <1488083203.8097.2.camel@joachim-breitner.de> <1488162591.19719.3.camel@joachim-breitner.de> Message-ID: <87zih7mes7.fsf@ben-laptop.smart-cactus.org> Joachim Breitner writes: > Hi Manuel, > > just to make sure I get what you are saying, are you suggesting this > approach? > > * (At least) one committee member, let’s call him the secretary, > promises to watch the GitHub repository close enough. > * When an author wants to bring a proposal before the committe, he > adds a comment to the a pull request, briefly summarizing the major  > points raised during the discussion period and stating their belief > that the proposal is ready for review.. > * The secretary notices that, labels the proposal as > “Pending committee review” and notifies the committee. > > This would be slightly more convenient for the submitters, and slightly > more work for the committee. But I guess it makes sense, and we can try > this way. > > Simon already shoved me towards picking up the “secretary” hat, to > reduce load on Ben. Ben, unless you protest, I’ll take over this role. > Yes, I think this sounds quite reasonable and I realize I've been woefully remiss in this capacity. Despite a few attempts at trying to get into a rhythm I've so far been unable to do so. I really appreciate your stepping up, Joachim. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mail at joachim-breitner.de Tue Feb 28 00:15:17 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 27 Feb 2017 16:15:17 -0800 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: References: <1488083203.8097.2.camel@joachim-breitner.de> <1488162591.19719.3.camel@joachim-breitner.de> Message-ID: <1488240917.23003.1.camel@joachim-breitner.de> Hi, Am Montag, den 27.02.2017, 14:00 +1100 schrieb Manuel M T Chakravarty: > Hence, I would suggest to require of proposal authors that they add a > comment explicitly @mention’ing the secretary when they want to > submit a proposal for review. yes, this is precisely what the current process documentation ask the authors to do: https://github.com/ghc-proposals/ghc-proposals#how-to-bring-a-proposal-before-the-committee Greetings, Joachim -- 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 -------------- 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: From chak at justtesting.org Tue Feb 28 00:43:44 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 28 Feb 2017 11:43:44 +1100 Subject: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals In-Reply-To: References: Message-ID: <21791CC4-9B06-4C7C-ACAE-FFC0E1FE99DD@justtesting.org> Looks good to me. > Iavor Diatchki : > > Hello, > > I was assigned to be the shepherd for the Hex Float proposal (https://github.com/ghc-proposals/ghc-proposals/pull/37 ), so I would like to propose that we accept it for implementation in GHC. > > This is a small change, which can be summarized as follows: > - allow floating point numbers to be written using hex digits. > > The format is exactly the same as decimal floating point numbers, except for: > - the literals start with 0x > - the digits are in hex > - the exponent symbol is `p` or `P`, instead of `e` or `E` > - the exponent is in base 2, rather than base 10 > > This notation has become popular among people working with floating point numbers, as the numbers you write can be represented exactly, which is not the case for base 10 numbers. > > The following points were discussed: > - the exact format to use, compared to what's allowed by other languages: we decided to just follow Haskell's decimal float notation, for least surprise > - should overflow (which becomes `Inf`) result in a warning? We decided that this is an orthogonal issue, also relevant to decimal floating point and made a GHC ticket (#13232) > - there is an odd interaction between floating point (both decimal and hex) and -XNegativeLiterals, related to negative 0, see ticket #13211 > - changing the Read instances for Float and Double to recognize hex floats could break some programs, although that does not seem all that likely > - there is a question of how many extra pretty printing functions to add to `Numeric`: the current thinking is that maybe just one `showHFloat` is sufficient; the alternative is to add 5, mirroring the `show[E,F,G]Float` functions for decimals. > > I also had a stab at implementing the basic notation here: https://phabricator.haskell.org/D3066 > I haven't done the changes to the libraries yet. > > Please let me know if you have any objections or suggestions on what might needs to be changed. > > Cheers, > -Iavor > > > > > _______________________________________________ > 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: From chak at justtesting.org Tue Feb 28 01:14:06 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 28 Feb 2017 12:14:06 +1100 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: <1488240917.23003.1.camel@joachim-breitner.de> References: <1488083203.8097.2.camel@joachim-breitner.de> <1488162591.19719.3.camel@joachim-breitner.de> <1488240917.23003.1.camel@joachim-breitner.de> Message-ID: Great! One small suggestion that just occurred to me: should we maybe note the GitHub handles of all committee members next to their name in the committee list? That might be useful for authors who want to approach people at some point to ask questions etc. Manuel > Joachim Breitner : > > Hi, > > Am Montag, den 27.02.2017, 14:00 +1100 schrieb Manuel M T Chakravarty: >> Hence, I would suggest to require of proposal authors that they add a >> comment explicitly @mention’ing the secretary when they want to >> submit a proposal for review. > > yes, this is precisely what the current process documentation ask the > authors to do: > https://github.com/ghc-proposals/ghc-proposals#how-to-bring-a-proposal-before-the-committee > > > Greetings, > Joachim > -- > 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 From mail at joachim-breitner.de Tue Feb 28 01:20:28 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 27 Feb 2017 17:20:28 -0800 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: References: <1488083203.8097.2.camel@joachim-breitner.de> <1488162591.19719.3.camel@joachim-breitner.de> <1488240917.23003.1.camel@joachim-breitner.de> Message-ID: <1488244828.23003.5.camel@joachim-breitner.de> Hi, Am Dienstag, den 28.02.2017, 12:14 +1100 schrieb Manuel M T Chakravarty: > Great! One small suggestion that just occurred to me: should we maybe > note the GitHub handles of all committee members next to their name > in the committee list? That might be useful for authors who want to > approach people at some point to ask questions etc. I started that already, by adding mine, as you can see in https://github.com/ghc-proposals/ghc-proposals#who-is-the-committee If you think it is useful to list all GitHub handles, well, I can do that. One moment... Greetings, Joachim -- -- 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 -------------- 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: From chak at justtesting.org Tue Feb 28 02:16:09 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 28 Feb 2017 13:16:09 +1100 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: <1488244828.23003.5.camel@joachim-breitner.de> References: <1488083203.8097.2.camel@joachim-breitner.de> <1488162591.19719.3.camel@joachim-breitner.de> <1488240917.23003.1.camel@joachim-breitner.de> <1488244828.23003.5.camel@joachim-breitner.de> Message-ID: <2BD2181E-03A6-42DA-BCD6-8FE265363325@justtesting.org> Thanks — seeing yours inspired me to make the suggestion :) Manuel > Am 28.02.2017 um 12:20 schrieb Joachim Breitner : > > Hi, > > Am Dienstag, den 28.02.2017, 12:14 +1100 schrieb Manuel M T > Chakravarty: >> Great! One small suggestion that just occurred to me: should we maybe >> note the GitHub handles of all committee members next to their name >> in the committee list? That might be useful for authors who want to >> approach people at some point to ask questions etc. > > I started that already, by adding mine, as you can see in > https://github.com/ghc-proposals/ghc-proposals#who-is-the-committee > > If you think it is useful to list all GitHub handles, well, I can do > that. One moment... > > Greetings, > Joachim > > > -- > -- > 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 From mail at joachim-breitner.de Tue Feb 28 05:48:28 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 27 Feb 2017 21:48:28 -0800 Subject: [ghc-steering-committee] Please review: Eval class, Shephard: Richard Message-ID: <1488260908.32147.6.camel@joachim-breitner.de> Hi, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/27 was brought before the committee. I propose Richard as the Shepherd. Richard, 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/ -------------- 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: From mail at joachim-breitner.de Tue Feb 28 05:48:22 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 27 Feb 2017 21:48:22 -0800 Subject: [ghc-steering-committee] Please review: INCOMPLETE_CONTEXTS, Shephard: Roman Message-ID: <1488260902.32147.5.camel@joachim-breitner.de> Hi, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/34 was brought before the committee. I propose Roman as the Shephard. Roman, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process (or refuse to shepherd and maybe propose someone else – I hand this job out based on who has already commented 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 PS: I could not assign this PR to you on Github. Ben, can you add Roman to the team on Github, remove Atze, and update the list of committee members in the README (and maybe make me, as the secretary, an owner of the GitHub organisation)? -- 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: From simonpj at microsoft.com Tue Feb 28 11:58:14 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 28 Feb 2017 11:58:14 +0000 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: References: <1488083203.8097.2.camel@joachim-breitner.de> Message-ID: Joachim, The new organisation at https://github.com/ghc-proposals/ghc-proposals is so much better. Thank you! How can I edit it in cosmetic ways? I see no edit button. (Defeated by github again.) I agree that we should assign a shepherd when the owner submits a proposal to the committee. Of course committee members can (and I hope will) get involved earlier. Simon From: ghc-steering-committee [mailto:ghc-steering-committee-bounces at haskell.org] On Behalf Of Simon Marlow Sent: 27 February 2017 10:48 To: Joachim Breitner Cc: ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Redid our documentation I like the new organisation. One functional difference I noticed: the new description says that we assign a shepherd when the proposal starts the review process, but under the existing process a shepherd is assigned to each proposal when the PR is created (but I guess we haven't been sticking to this?). Ideally I think we'd assign shepherds earlier because it will streamline the review process: the shepherd will spot things that should be clarified or addressed before the rest of the committee gets involved. I think it's likely to be a better use of resources. This also addresses the question about labels: if each proposal has a shepherd, then the shepherd will notice when the proposer adds a comment to the PR requesting review, and can formally start the process with the rest of the committee. Cheers Simon On 26 February 2017 at 04:26, Joachim Breitner > wrote: [I sent this mail from Monday to the wrong address, second try] Hi, there was a bit confusion about our documentation, so with SPJ’s blessing I went ahead and restructured it a bit. For now, this is only on a branch and not live yet: https://github.com/ghc-proposals/ghc-proposals/tree/wip/docs-restructur ing Note that it starts with a concise timeline of a proposal, and from there has links to section answering specific questions, within the same file. What was three files before (README, process, committee) is now all in here (with the exception of the “detailed instructions” for the Github-novice, which is in a separate file). This should make it easier for everyone involved to know who has to do what when. Our process is, however, flawed: We ask authors to set labels (“Under Discussion” and “Under Committee Review”), but they do not have permissions to do so. So this does not quite work. So I suggest the following change: * What was “Under Discussion” is now simply any PR that does not have any other label. This way, when opening discussion, nothing concrete has to be done. Which is easier. (GitHub allows to list all PRs that have no label, so there is no loss in functionality here.) * When the author wants to submit the PR, he sends a mail to this mailinglist (is this set up to accept mails from non-subscribers?) and it its the task of the shephard to set the label to indicate that that the committee has accepted to review the proposal. (At this point, the shephard could for example set the `Out-of-scope` label instead.) If there are no complains I will adjust the docs-restructuring branch accordingly and then move that to master. Greetings, Joachim -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Feb 28 13:36:45 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 28 Feb 2017 13:36:45 +0000 Subject: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals In-Reply-To: References: Message-ID: No objections from me. Looks useful and not too costly in terms of extra complexity. On 27 February 2017 at 21:34, Iavor Diatchki wrote: > Hello, > > I was assigned to be the shepherd for the Hex Float proposal ( > https://github.com/ghc-proposals/ghc-proposals/pull/37), so I would like > to propose that we accept it for implementation in GHC. > > This is a small change, which can be summarized as follows: > - allow floating point numbers to be written using hex digits. > > The format is exactly the same as decimal floating point numbers, except > for: > - the literals start with 0x > - the digits are in hex > - the exponent symbol is `p` or `P`, instead of `e` or `E` > - the exponent is in base 2, rather than base 10 > > This notation has become popular among people working with floating point > numbers, as the numbers you write can be represented exactly, which is not > the case for base 10 numbers. > > The following points were discussed: > - the exact format to use, compared to what's allowed by other > languages: we decided to just follow Haskell's decimal float notation, for > least surprise > - should overflow (which becomes `Inf`) result in a warning? We > decided that this is an orthogonal issue, also relevant to decimal floating > point and made a GHC ticket (#13232) > - there is an odd interaction between floating point (both decimal and > hex) and -XNegativeLiterals, related to negative 0, see ticket #13211 > - changing the Read instances for Float and Double to recognize hex > floats could break some programs, although that does not seem all that > likely > - there is a question of how many extra pretty printing functions to > add to `Numeric`: the current thinking is that maybe just one `showHFloat` > is sufficient; the alternative is to add 5, mirroring the > `show[E,F,G]Float` functions for decimals. > > I also had a stab at implementing the basic notation here: > https://phabricator.haskell.org/D3066 > I haven't done the changes to the libraries yet. > > Please let me know if you have any objections or suggestions on what might > needs to be changed. > > Cheers, > -Iavor > > > > > > _______________________________________________ > 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: From mail at joachim-breitner.de Tue Feb 28 17:19:08 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 28 Feb 2017 09:19:08 -0800 Subject: [ghc-steering-committee] Redid our documentation In-Reply-To: References: <1488083203.8097.2.camel@joachim-breitner.de> Message-ID: <1488302348.6412.2.camel@joachim-breitner.de> Hi, Am Dienstag, den 28.02.2017, 11:58 +0000 schrieb Simon Peyton Jones:  > How can I edit it in cosmetic ways?  I see no edit button.  (Defeated > by github again.) If you click on the README.rst filename in the directory listing, you end up here: https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and there is a ✏ symbol in the top-right corner. Greetings, Joachim -- 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 -------------- 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: From iavor.diatchki at gmail.com Tue Feb 28 17:30:16 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 28 Feb 2017 09:30:16 -0800 Subject: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals In-Reply-To: References: Message-ID: One tricky bit that occurred to me: we can't really change the behavior of the Read instance depending on the extensions enabled. Thus, we would either have to always parse hex floats, even when the extension is not on, or never parse them. I am leaning towards parsing them always, even without the extension. What do others think? -Iavor On Tue, Feb 28, 2017 at 5:36 AM, Simon Marlow wrote: > No objections from me. Looks useful and not too costly in terms of extra > complexity. > > On 27 February 2017 at 21:34, Iavor Diatchki > wrote: > >> Hello, >> >> I was assigned to be the shepherd for the Hex Float proposal ( >> https://github.com/ghc-proposals/ghc-proposals/pull/37), so I would like >> to propose that we accept it for implementation in GHC. >> >> This is a small change, which can be summarized as follows: >> - allow floating point numbers to be written using hex digits. >> >> The format is exactly the same as decimal floating point numbers, except >> for: >> - the literals start with 0x >> - the digits are in hex >> - the exponent symbol is `p` or `P`, instead of `e` or `E` >> - the exponent is in base 2, rather than base 10 >> >> This notation has become popular among people working with floating point >> numbers, as the numbers you write can be represented exactly, which is not >> the case for base 10 numbers. >> >> The following points were discussed: >> - the exact format to use, compared to what's allowed by other >> languages: we decided to just follow Haskell's decimal float notation, for >> least surprise >> - should overflow (which becomes `Inf`) result in a warning? We >> decided that this is an orthogonal issue, also relevant to decimal floating >> point and made a GHC ticket (#13232) >> - there is an odd interaction between floating point (both decimal >> and hex) and -XNegativeLiterals, related to negative 0, see ticket #13211 >> - changing the Read instances for Float and Double to recognize hex >> floats could break some programs, although that does not seem all that >> likely >> - there is a question of how many extra pretty printing functions to >> add to `Numeric`: the current thinking is that maybe just one `showHFloat` >> is sufficient; the alternative is to add 5, mirroring the >> `show[E,F,G]Float` functions for decimals. >> >> I also had a stab at implementing the basic notation here: >> https://phabricator.haskell.org/D3066 >> I haven't done the changes to the libraries yet. >> >> Please let me know if you have any objections or suggestions on what >> might needs to be changed. >> >> Cheers, >> -Iavor >> >> >> >> >> >> _______________________________________________ >> 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: From mail at joachim-breitner.de Tue Feb 28 17:58:11 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 28 Feb 2017 09:58:11 -0800 Subject: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals In-Reply-To: References: Message-ID: Hi, I think that's fine, and the benefits outweigh the downsides. This is treading on CLC space a bit, though. Should we coordinate with them? Joachim Am 28. Februar 2017 09:30:16 PST schrieb Iavor Diatchki : >One tricky bit that occurred to me: we can't really change the behavior >of >the Read instance depending on the extensions enabled. > >Thus, we would either have to always parse hex floats, even when the >extension is not on, or never parse them. > >I am leaning towards parsing them always, even without the extension. >What >do others think? > >-Iavor > > > >On Tue, Feb 28, 2017 at 5:36 AM, Simon Marlow >wrote: > >> No objections from me. Looks useful and not too costly in terms of >extra >> complexity. >> >> On 27 February 2017 at 21:34, Iavor Diatchki > >> wrote: >> >>> Hello, >>> >>> I was assigned to be the shepherd for the Hex Float proposal ( >>> https://github.com/ghc-proposals/ghc-proposals/pull/37), so I would >like >>> to propose that we accept it for implementation in GHC. >>> >>> This is a small change, which can be summarized as follows: >>> - allow floating point numbers to be written using hex digits. >>> >>> The format is exactly the same as decimal floating point numbers, >except >>> for: >>> - the literals start with 0x >>> - the digits are in hex >>> - the exponent symbol is `p` or `P`, instead of `e` or `E` >>> - the exponent is in base 2, rather than base 10 >>> >>> This notation has become popular among people working with floating >point >>> numbers, as the numbers you write can be represented exactly, which >is not >>> the case for base 10 numbers. >>> >>> The following points were discussed: >>> - the exact format to use, compared to what's allowed by other >>> languages: we decided to just follow Haskell's decimal float >notation, for >>> least surprise >>> - should overflow (which becomes `Inf`) result in a warning? We >>> decided that this is an orthogonal issue, also relevant to decimal >floating >>> point and made a GHC ticket (#13232) >>> - there is an odd interaction between floating point (both >decimal >>> and hex) and -XNegativeLiterals, related to negative 0, see ticket >#13211 >>> - changing the Read instances for Float and Double to recognize >hex >>> floats could break some programs, although that does not seem all >that >>> likely >>> - there is a question of how many extra pretty printing >functions to >>> add to `Numeric`: the current thinking is that maybe just one >`showHFloat` >>> is sufficient; the alternative is to add 5, mirroring the >>> `show[E,F,G]Float` functions for decimals. >>> >>> I also had a stab at implementing the basic notation here: >>> https://phabricator.haskell.org/D3066 >>> I haven't done the changes to the libraries yet. >>> >>> Please let me know if you have any objections or suggestions on what >>> might needs to be changed. >>> >>> Cheers, >>> -Iavor >>> >>> >>> >>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> >https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> >> From iavor.diatchki at gmail.com Tue Feb 28 18:38:41 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 28 Feb 2017 10:38:41 -0800 Subject: [ghc-steering-committee] Please review: Eval class, Shephard: Richard In-Reply-To: <1488260908.32147.6.camel@joachim-breitner.de> References: <1488260908.32147.6.camel@joachim-breitner.de> Message-ID: Hello, I am not very convinced about the utility of this proposal. Also, I think that the current specification could use more details about how the system should work. I wrote a comment on the pull-request thread with more details. -Iavor On Mon, Feb 27, 2017 at 9:48 PM, Joachim Breitner wrote: > Hi, > > this is your secretary speaking: > > https://github.com/ghc-proposals/ghc-proposals/pull/27 > was brought before the committee. I propose Richard as the Shepherd. > > Richard, 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/ > > _______________________________________________ > 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: From cma at bitemyapp.com Tue Feb 28 19:02:55 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 28 Feb 2017 13:02:55 -0600 Subject: [ghc-steering-committee] Please review: Eval class, Shephard: Richard In-Reply-To: References: <1488260908.32147.6.camel@joachim-breitner.de> Message-ID: I'm not convinced either. Generally if a silent `seq` is biting you the problem was partiality and not insufficient lightness of the soul. It seems like it would change sharing behavior as well, which is not good. This affects a lot of code with unreachable branches they can't reasonably get rid of. Often this is code that is performance sensitive and depends on the particulars of how things are getting shared. On Tue, Feb 28, 2017 at 12:38 PM, Iavor Diatchki wrote: > Hello, > > I am not very convinced about the utility of this proposal. Also, I think > that the current specification could use more details about how the system > should work. I wrote a comment on the pull-request thread with more > details. > > -Iavor > > On Mon, Feb 27, 2017 at 9:48 PM, Joachim Breitner > wrote: >> >> Hi, >> >> this is your secretary speaking: >> >> https://github.com/ghc-proposals/ghc-proposals/pull/27 >> was brought before the committee. I propose Richard as the Shepherd. >> >> Richard, 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/ >> >> _______________________________________________ >> 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 > -- Chris Allen Currently working on http://haskellbook.com From cma at bitemyapp.com Tue Feb 28 21:13:23 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 28 Feb 2017 15:13:23 -0600 Subject: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals In-Reply-To: References: Message-ID: This is a well written proposal. Hex float literals as proposed are fine and I am in favor of it. Hex notation for floats has pedagogical benefits as well. The deviation in the proposal is from the C standard, not the IEEE standard and essentially brings the proposal into conformance with the IEEE spec anyway. I'd suggest that we concern ourselves more exclusively with IEEE compliance than mimicking the C spec. This is CLC territory but for backwards compatibility we might suggest that a newtype be offered for re-obtaining the old Read instance for Double as a temporary compatibility affordance. (2-3 releases?) Beyond that, this should be good to go. On Tue, Feb 28, 2017 at 11:58 AM, Joachim Breitner wrote: > Hi, > > I think that's fine, and the benefits outweigh the downsides. > > This is treading on CLC space a bit, though. Should we coordinate with them? > > Joachim > > > > Am 28. Februar 2017 09:30:16 PST schrieb Iavor Diatchki : >>One tricky bit that occurred to me: we can't really change the behavior >>of >>the Read instance depending on the extensions enabled. >> >>Thus, we would either have to always parse hex floats, even when the >>extension is not on, or never parse them. >> >>I am leaning towards parsing them always, even without the extension. >>What >>do others think? >> >>-Iavor >> >> >> >>On Tue, Feb 28, 2017 at 5:36 AM, Simon Marlow >>wrote: >> >>> No objections from me. Looks useful and not too costly in terms of >>extra >>> complexity. >>> >>> On 27 February 2017 at 21:34, Iavor Diatchki >> >>> wrote: >>> >>>> Hello, >>>> >>>> I was assigned to be the shepherd for the Hex Float proposal ( >>>> https://github.com/ghc-proposals/ghc-proposals/pull/37), so I would >>like >>>> to propose that we accept it for implementation in GHC. >>>> >>>> This is a small change, which can be summarized as follows: >>>> - allow floating point numbers to be written using hex digits. >>>> >>>> The format is exactly the same as decimal floating point numbers, >>except >>>> for: >>>> - the literals start with 0x >>>> - the digits are in hex >>>> - the exponent symbol is `p` or `P`, instead of `e` or `E` >>>> - the exponent is in base 2, rather than base 10 >>>> >>>> This notation has become popular among people working with floating >>point >>>> numbers, as the numbers you write can be represented exactly, which >>is not >>>> the case for base 10 numbers. >>>> >>>> The following points were discussed: >>>> - the exact format to use, compared to what's allowed by other >>>> languages: we decided to just follow Haskell's decimal float >>notation, for >>>> least surprise >>>> - should overflow (which becomes `Inf`) result in a warning? We >>>> decided that this is an orthogonal issue, also relevant to decimal >>floating >>>> point and made a GHC ticket (#13232) >>>> - there is an odd interaction between floating point (both >>decimal >>>> and hex) and -XNegativeLiterals, related to negative 0, see ticket >>#13211 >>>> - changing the Read instances for Float and Double to recognize >>hex >>>> floats could break some programs, although that does not seem all >>that >>>> likely >>>> - there is a question of how many extra pretty printing >>functions to >>>> add to `Numeric`: the current thinking is that maybe just one >>`showHFloat` >>>> is sufficient; the alternative is to add 5, mirroring the >>>> `show[E,F,G]Float` functions for decimals. >>>> >>>> I also had a stab at implementing the basic notation here: >>>> https://phabricator.haskell.org/D3066 >>>> I haven't done the changes to the libraries yet. >>>> >>>> Please let me know if you have any objections or suggestions on what >>>> might needs to be changed. >>>> >>>> Cheers, >>>> -Iavor >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 -- Chris Allen Currently working on http://haskellbook.com From mail at joachim-breitner.de Tue Feb 28 21:47:05 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 28 Feb 2017 13:47:05 -0800 Subject: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals In-Reply-To: References: Message-ID: <1488318425.10360.3.camel@joachim-breitner.de> Hi, Am Dienstag, den 28.02.2017, 15:13 -0600 schrieb Christopher Allen: > This is CLC territory but for backwards compatibility we might > suggest that a newtype be offered for re-obtaining the old Read > instance for Double as a temporary compatibility affordance. (2-3 > releases?) not sure how useful that is. It will not easily be used in derived Read instances of datatypes that use Double. I’d like to hear from someone who has an actual use case for this first. Greetings, Joachim -- 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 -------------- 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: