From mail at joachim-breitner.de Mon Jul 1 12:39:58 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 01 Jul 2019 14:39:58 +0200 Subject: [ghc-steering-committee] Request for Nominations to the GHC Steering Committee In-Reply-To: <8096141b2e043b8a2c85254ccd52c65a14c91dd2.camel@joachim-breitner.de> References: <90af96bdb996b5ab7e826281cbb6a5b10653538b.camel@joachim-breitner.de> <8096141b2e043b8a2c85254ccd52c65a14c91dd2.camel@joachim-breitner.de> Message-ID: Dear people watching this list, in the interest of transparency: Internal deliberations are happening; current ETA for a vote result is next Sunday, but that is not a promise. Cheers, 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 Wed Jul 3 07:55:04 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 03 Jul 2019 09:55:04 +0200 Subject: [ghc-steering-committee] Please review #220: QualifiedImports, Shepherd: Simon M Message-ID: Dear Committee, this is your secretary speaking: QualifiedImports has been proposed by Arnaud Spiwack and Guillaume Bouchard https://github.com/ghc-proposals/ghc-proposals/pull/220 https://github.com/tweag/ghc-proposals/blob/qualified-import/proposals/0000-default-qualified-import.rst I propose Simon M as the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link. Thanks, 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 marlowsd at gmail.com Fri Jul 5 07:19:41 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 5 Jul 2019 08:19:41 +0100 Subject: [ghc-steering-committee] Please review #220: QualifiedImports, Shepherd: Simon M In-Reply-To: References: Message-ID: Dear steering committee - I am inclined to reject this proposal, so as per the new committee process I posted the rationale on the github thread: https://github.com/ghc-proposals/ghc-proposals/pull/220#issuecomment-508414602 You may want to consider the proposal and offer opinions while we wait for the authors' rebuttal. It's a very simple proposal. Cheers Simon On Wed, 3 Jul 2019 at 08:55, Joachim Breitner wrote: > Dear Committee, > > this is your secretary speaking: > > QualifiedImports > has been proposed by Arnaud Spiwack and Guillaume Bouchard > https://github.com/ghc-proposals/ghc-proposals/pull/220 > > https://github.com/tweag/ghc-proposals/blob/qualified-import/proposals/0000-default-qualified-import.rst > > I propose Simon M as the shepherd. > > Please reach consensus as described in > https://github.com/ghc-proposals/ghc-proposals#committee-process > In particular, talk to the authors before, if you think this should be > rejected, and kick off the discussion on Github, following the steps > described under “Now the shepherd proposes to accept or reject the > proposal” in the above link. > > Thanks, > 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 rae at richarde.dev Fri Jul 5 16:04:07 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 5 Jul 2019 12:04:07 -0400 Subject: [ghc-steering-committee] Recommendation made for {-# AMBIGUOUS #-}, #232 Message-ID: <93E44369-2ADE-4CBB-95E7-09F92B6971DA@richarde.dev> Hi all, I have made my recommendation for #232 here: https://github.com/ghc-proposals/ghc-proposals/pull/232#issuecomment-508803496 Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Jul 8 06:47:48 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 08 Jul 2019 08:47:48 +0200 Subject: [ghc-steering-committee] Please review #240: Threaded RTS by default, Shepherd: Simon M Message-ID: <7dd58522cc45fd74f061d69ae5961f483d035222.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: Compile with threaded RTS by default has been proposed by Artem Pelenitsyn https://github.com/ghc-proposals/ghc-proposals/pull/240 https://github.com/ulysses4ever/ghc-proposals/blob/master/proposals/0000-threaded-by-default.rst I propose Simon M as the shepherd (yes, you just got another one last week, but you already haven an opinion about this one, so I think this is more efficient.) Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link. Thanks, 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 cma at bitemyapp.com Mon Jul 8 18:05:23 2019 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 8 Jul 2019 13:05:23 -0500 Subject: [ghc-steering-committee] Extra Commas In-Reply-To: References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de> Message-ID: To reiterate nobody wants that or is interested in a partial solution. The original proposer included. Neither of us are interested in editing or implementing the post-modification proposal. I'd like to return to the original proposer's final intent: closing the issue as rejected. I'd sooner sit on it and wait for a time when it won't get mutilated. A partial solution means a full implementation has zero chance of getting accepted. If there are no objections, I will re-close the proposal as rejected. On Mon, Jul 8, 2019 at 5:23 AM Simon Peyton Jones via ghc-steering-committee wrote: > > I’m ok with accepting, but excluding tuples, including constraint tuples. > > > > I’m be ok with excluding list literals too. > > > > We should ask the author if s/he feels that these exclusions would unacceptably eviscerate the proposal i.e. make it not worth doing. > > > > The upside is that it’s clearly a superficial, syntax-only issue. Nothing deep is at stake here. > > > > Simon > > > > From: ghc-steering-committee On Behalf Of Vitaly Bragilevsky > Sent: 24 April 2019 20:20 > To: ghc-steering-committee at haskell.org > Subject: Re: [ghc-steering-committee] Extra Commas > > > > I am next voting to accept this proposal, not covering tuples. > > > > Vitaly > > > > ср, 24 апр. 2019 г. в 19:17, Manuel M T Chakravarty : > > As I have said previously, I strongly agree with Simon on that we need to make some editorial decisions. > > > > Concerning the general proposal, I think, the convenience of trailing commas is a consequence of insufficient editor support and IMHO it’d be better to improve that support rather than applying band-aids to the language. However, I can live with the extensions as long as their is no conflict with TupleSections. > > > > Cheers, > > Manuel > > > > Am 24.04.2019 um 09:30 schrieb Simon Marlow : > > > > I'm also strongly against mutually incompatible extensions. > > > > I'm not sure about allowing the combination of TupleSections and ExtraCommas. It would mean that (x,) has a different meaning depending on what extensions are in force. This is a pretty strange direction to take the language in, and raises questions about whether we should think of GHC as a testing ground for language extensions of which only some will eventually make it into a language standard, or whether we should take a position on which extensions are sensible when there are conflicts. Personally I'm in favour of the committee taking some editorial decisions here - not just assessing which extensions make sense in isolation, but considering whether an extension makes sense in the context of the other extensions we already have. > > > > But back to the current proposal, I would vote for allowing the parts of the proposal that don't conflict with TupleSections. > > > > Cheers > > Simon > > > > On Thu, 18 Apr 2019 at 16:06, Richard Eisenberg wrote: > > I strongly dislike the idea of mutually-incompatible extensions. > > We could say that ExtraCommas allows extra commas everywhere, including in tuples and lists. We could also say that TupleSections overrides this behavior in tuples and gives it new meaning. We could further imagine ListSections that would override the behavior in lists. To me, this is preferable than mutual incompatibility. > > Does this make for a nice user experience? I'm not sure. Happily, the reinterpretation from TupleSections or ListSections would change types, so you'd get errors up front. These errors might even be clever enough to notice that both ExtraCommas and TupleSections are in effect and gently remind the user that this combination can be confusing. Actually, this might be a nice "have your cake and eat it too" moment: let's just do all the things! > > Richard > > > On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > > > | "tuples included" means "incompatible with tuple sections" means "they are > > | mutually exclusive to a module." > > > > You mean, some kind of new error message that says "these two extension are mutually incompatible". I can't say I love this. Let's just leave out tuples from ExtraCommas. > > > > (Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day. Maybe we omit list literals too? Or would that break the key use-cases? > > > > Simon > > > > | -----Original Message----- > > | From: Christopher Allen > > | Sent: 18 April 2019 10:08 > > | To: Simon Peyton Jones > > | Cc: Eric Seidel ; ghc-steering-committee at haskell.org > > | Subject: Re: [ghc-steering-committee] Extra Commas > > | > > | My understanding of previous discussions was that: > > | > > | > > | On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones > > | wrote: > > | > > > | > But it's actually *incompatible* with TupleSections, so how shoule > > | > (True,) > > | > be interpreted if both are on? > > | > > > | > S > > | > > > | > | -----Original Message----- > > | > | From: ghc-steering-committee > > | > | > > | > | On Behalf Of Christopher Allen > > | > | Sent: 18 April 2019 04:19 > > | > | To: Eric Seidel > > | > | Cc: ghc-steering-committee at haskell.org > > | > | Subject: Re: [ghc-steering-committee] Extra Commas > > | > | > > | > | I spoke with Matt, he's fine either way with or without tuples. > > | > | > > | > | I'd prefer "with tuples" for consistency. I use tuples sometimes, > > | > | but don't care about sectioning. > > | > | > > | > | On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel wrote: > > | > | > > > | > | > I favor accepting the proposal, with or without tuples. I've been > > | > | writing a bit of Rust recently, and agree with Chris about the > > | > | ergonomics of trailing commas. > > | > | > > > | > | > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote: > > | > | > > Hi, > > | > | > > > > | > | > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher > > | Allen: > > | > | > > > I gave my recommendation for ExtraCommas, acceptance of the > > | > | > > > original proposal as written. I talk with the proposer almost > > | > | > > > every day so I know where he stands. He still thinks it's > > | > | worth > > > doing and would like to see it accepted. I think > > | > | ExtraCommas > > > merits acceptance. If we can't achieve consensus > > | > | on it then it > > > should be rejected so it gets cleared off the > > | > | slate. I'm not > > > inclined to argue a syntactic extension like > > | > | this, but I will say > > | > | this: > > | > | > > > > > | > | > > > The proposal captures a nice design element that we've seen > > | > | work > > > very well ergonomically in Rust. We're never going to > > | > | make the > > > same decisions with the same tradeoffs as a totally > > | > | different > > > language but any time there is a relatively isolated > > | "good idea" > > | > | > > > like this, I'd like to see us try to take advantage of that > > | > | and > > > see if it works for us. > > | > | > > > > | > | > > thanks for picking this up. > > | > | > > > > | > | > > The most contentious point, besides whether its worth the > > | > | bother at > > all, was the interaction with TupleSections. Which > > | > | gives us three > > options, I think: > > | > | > > * reject > > | > | > > * accept, covering tuples (and making it conflict with > > > > | > | TupleSections) > > * accept, not covering tuples. > > | > | > > > > | > | > > No decision is absolutely wrong, none is obviously right. > > | > | > > > > | > | > > Maybe we should simply do a vote, to get it decided? Simons (as > > | > | > > Chairs), what do you think? > > | > | > > > > | > | > > Cheers, > > | > | > > Joachim > > | > | > > > > | > | > > -- > > | > | > > Joachim Breitner > > | > | > > mail at joachim-breitner.de > > | > | > > > > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww > > | > | .joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7 > > | > | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47 > > | > | %7C1%7C0%7C636911752855987147&sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u > > | > | 9fb%2BRkQMqGibDlM%3D&reserved=0 > > | > | > > > > | > | > > > > | > | > > _______________________________________________ > > | > | > > ghc-steering-committee mailing list > > > > | > | ghc-steering-committee at haskell.org > > | > | > > > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma > > | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a > > | > | mp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408d6 > > | > | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598 > > | > | 7147&sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&re > > | > | served=0 > > | > | > > ttee > > | > | > > > > | > | > > Attachments: > > | > | > > * signature.asc > > | > | > _______________________________________________ > > | > | > ghc-steering-committee mailing list > > > | > | ghc-steering-committee at haskell.org > > | > | > > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma > > | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ > > | > | &data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408 > > | > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855 > > | > | 987147&sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D& > > | > | amp;reserved=0 > > | > | > ee > > | > | > > | > | > > | > | > > | > | -- > > | > | Chris Allen > > | > | Currently working on > > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas > > | > | kellbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836 > > | > | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C > > | > | 636911752855987147&sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK > > | > | 8IyjBI%3D&reserved=0 > > | > | _______________________________________________ > > | > | ghc-steering-committee mailing list > > | > | ghc-steering-committee at haskell.org > > | > | > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma > > | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ > > | > | ee&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a294 > > | > | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528 > > | > | 55987147&sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D& > > | > | amp;reserved=0 > > | > > | > > | > > | -- > > | Chris Allen > > | Currently working on > > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo > > | ok.com&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408 > > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147 > > | &sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&reserved=0 > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Chris Allen Currently working on http://haskellbook.com From cma at bitemyapp.com Mon Jul 8 18:14:58 2019 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 8 Jul 2019 13:14:58 -0500 Subject: [ghc-steering-committee] Extra Commas In-Reply-To: References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de> Message-ID: Restating my point more explicitly: if you implemented the extension as described post-modification: I wouldn't enable it and I'm one of the biggest fans of Rust's syntax in this respect. I use Rust for fun and for work right now. A follow-up thought for this: the opinions and priorities of people who simply didn't want the extension or didn't plan to use it weighed heavily on where the proposal went. This took it places nobody interested in the proposal was interested in moving forward with. We might want to consider how we evaluate proposals in light of that problem. In the past I've held off commenting on proposals I wasn't interested in but considered benign to my priorities. I don't think everyone is operating on the same principle and it's making the process more bureaucratic and less effective for helping Haskell users achieve their ends. On Mon, Jul 8, 2019 at 1:05 PM Christopher Allen wrote: > > To reiterate nobody wants that or is interested in a partial solution. > The original proposer included. Neither of us are interested in > editing or implementing the post-modification proposal. I'd like to > return to the original proposer's final intent: closing the issue as > rejected. I'd sooner sit on it and wait for a time when it won't get > mutilated. A partial solution means a full implementation has zero > chance of getting accepted. > > If there are no objections, I will re-close the proposal as rejected. > > On Mon, Jul 8, 2019 at 5:23 AM Simon Peyton Jones via > ghc-steering-committee wrote: > > > > I’m ok with accepting, but excluding tuples, including constraint tuples. > > > > > > > > I’m be ok with excluding list literals too. > > > > > > > > We should ask the author if s/he feels that these exclusions would unacceptably eviscerate the proposal i.e. make it not worth doing. > > > > > > > > The upside is that it’s clearly a superficial, syntax-only issue. Nothing deep is at stake here. > > > > > > > > Simon > > > > > > > > From: ghc-steering-committee On Behalf Of Vitaly Bragilevsky > > Sent: 24 April 2019 20:20 > > To: ghc-steering-committee at haskell.org > > Subject: Re: [ghc-steering-committee] Extra Commas > > > > > > > > I am next voting to accept this proposal, not covering tuples. > > > > > > > > Vitaly > > > > > > > > ср, 24 апр. 2019 г. в 19:17, Manuel M T Chakravarty : > > > > As I have said previously, I strongly agree with Simon on that we need to make some editorial decisions. > > > > > > > > Concerning the general proposal, I think, the convenience of trailing commas is a consequence of insufficient editor support and IMHO it’d be better to improve that support rather than applying band-aids to the language. However, I can live with the extensions as long as their is no conflict with TupleSections. > > > > > > > > Cheers, > > > > Manuel > > > > > > > > Am 24.04.2019 um 09:30 schrieb Simon Marlow : > > > > > > > > I'm also strongly against mutually incompatible extensions. > > > > > > > > I'm not sure about allowing the combination of TupleSections and ExtraCommas. It would mean that (x,) has a different meaning depending on what extensions are in force. This is a pretty strange direction to take the language in, and raises questions about whether we should think of GHC as a testing ground for language extensions of which only some will eventually make it into a language standard, or whether we should take a position on which extensions are sensible when there are conflicts. Personally I'm in favour of the committee taking some editorial decisions here - not just assessing which extensions make sense in isolation, but considering whether an extension makes sense in the context of the other extensions we already have. > > > > > > > > But back to the current proposal, I would vote for allowing the parts of the proposal that don't conflict with TupleSections. > > > > > > > > Cheers > > > > Simon > > > > > > > > On Thu, 18 Apr 2019 at 16:06, Richard Eisenberg wrote: > > > > I strongly dislike the idea of mutually-incompatible extensions. > > > > We could say that ExtraCommas allows extra commas everywhere, including in tuples and lists. We could also say that TupleSections overrides this behavior in tuples and gives it new meaning. We could further imagine ListSections that would override the behavior in lists. To me, this is preferable than mutual incompatibility. > > > > Does this make for a nice user experience? I'm not sure. Happily, the reinterpretation from TupleSections or ListSections would change types, so you'd get errors up front. These errors might even be clever enough to notice that both ExtraCommas and TupleSections are in effect and gently remind the user that this combination can be confusing. Actually, this might be a nice "have your cake and eat it too" moment: let's just do all the things! > > > > Richard > > > > > On Apr 18, 2019, at 10:52 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > > > > > | "tuples included" means "incompatible with tuple sections" means "they are > > > | mutually exclusive to a module." > > > > > > You mean, some kind of new error message that says "these two extension are mutually incompatible". I can't say I love this. Let's just leave out tuples from ExtraCommas. > > > > > > (Actually I could imagine [a,,b,] meaning \xy. [a,x,b,y], one day. Maybe we omit list literals too? Or would that break the key use-cases? > > > > > > Simon > > > > > > | -----Original Message----- > > > | From: Christopher Allen > > > | Sent: 18 April 2019 10:08 > > > | To: Simon Peyton Jones > > > | Cc: Eric Seidel ; ghc-steering-committee at haskell.org > > > | Subject: Re: [ghc-steering-committee] Extra Commas > > > | > > > | My understanding of previous discussions was that: > > > | > > > | > > > | On Thu, Apr 18, 2019 at 2:17 AM Simon Peyton Jones > > > | wrote: > > > | > > > > | > But it's actually *incompatible* with TupleSections, so how shoule > > > | > (True,) > > > | > be interpreted if both are on? > > > | > > > > | > S > > > | > > > > | > | -----Original Message----- > > > | > | From: ghc-steering-committee > > > | > | > > > | > | On Behalf Of Christopher Allen > > > | > | Sent: 18 April 2019 04:19 > > > | > | To: Eric Seidel > > > | > | Cc: ghc-steering-committee at haskell.org > > > | > | Subject: Re: [ghc-steering-committee] Extra Commas > > > | > | > > > | > | I spoke with Matt, he's fine either way with or without tuples. > > > | > | > > > | > | I'd prefer "with tuples" for consistency. I use tuples sometimes, > > > | > | but don't care about sectioning. > > > | > | > > > | > | On Wed, Apr 17, 2019 at 8:15 PM Eric Seidel wrote: > > > | > | > > > > | > | > I favor accepting the proposal, with or without tuples. I've been > > > | > | writing a bit of Rust recently, and agree with Chris about the > > > | > | ergonomics of trailing commas. > > > | > | > > > > | > | > On Wed, Apr 17, 2019, at 18:31, Joachim Breitner wrote: > > > | > | > > Hi, > > > | > | > > > > > | > | > > Am Mittwoch, den 17.04.2019, 13:38 -0500 schrieb Christopher > > > | Allen: > > > | > | > > > I gave my recommendation for ExtraCommas, acceptance of the > > > | > | > > > original proposal as written. I talk with the proposer almost > > > | > | > > > every day so I know where he stands. He still thinks it's > > > | > | worth > > > doing and would like to see it accepted. I think > > > | > | ExtraCommas > > > merits acceptance. If we can't achieve consensus > > > | > | on it then it > > > should be rejected so it gets cleared off the > > > | > | slate. I'm not > > > inclined to argue a syntactic extension like > > > | > | this, but I will say > > > | > | this: > > > | > | > > > > > > | > | > > > The proposal captures a nice design element that we've seen > > > | > | work > > > very well ergonomically in Rust. We're never going to > > > | > | make the > > > same decisions with the same tradeoffs as a totally > > > | > | different > > > language but any time there is a relatively isolated > > > | "good idea" > > > | > | > > > like this, I'd like to see us try to take advantage of that > > > | > | and > > > see if it works for us. > > > | > | > > > > > | > | > > thanks for picking this up. > > > | > | > > > > > | > | > > The most contentious point, besides whether its worth the > > > | > | bother at > > all, was the interaction with TupleSections. Which > > > | > | gives us three > > options, I think: > > > | > | > > * reject > > > | > | > > * accept, covering tuples (and making it conflict with > > > > > | > | TupleSections) > > * accept, not covering tuples. > > > | > | > > > > > | > | > > No decision is absolutely wrong, none is obviously right. > > > | > | > > > > > | > | > > Maybe we should simply do a vote, to get it decided? Simons (as > > > | > | > > Chairs), what do you think? > > > | > | > > > > > | > | > > Cheers, > > > | > | > > Joachim > > > | > | > > > > > | > | > > -- > > > | > | > > Joachim Breitner > > > | > | > > mail at joachim-breitner.de > > > | > | > > > > > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww > > > | > | .joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7 > > > | > | C670f986836834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47 > > > | > | %7C1%7C0%7C636911752855987147&sdata=gCdvqR5gm0K54rJMnfcnIiOyyv4u > > > | > | 9fb%2BRkQMqGibDlM%3D&reserved=0 > > > | > | > > > > > | > | > > > > > | > | > > _______________________________________________ > > > | > | > > ghc-steering-committee mailing list > > > > > | > | ghc-steering-committee at haskell.org > > > | > | > > > > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma > > > | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-commi&a > > > | > | mp;data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408d6 > > > | > | c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63691175285598 > > > | > | 7147&sdata=NZqChpNEoHihvoow29uxmmDyPuLeVgn4iNwkcdMDno8%3D&re > > > | > | served=0 > > > | > | > > ttee > > > | > | > > > > > | > | > > Attachments: > > > | > | > > * signature.asc > > > | > | > _______________________________________________ > > > | > | > ghc-steering-committee mailing list > > > > | > | ghc-steering-committee at haskell.org > > > | > | > > > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma > > > | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ > > > | > | &data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408 > > > | > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855 > > > | > | 987147&sdata=1PZCPlMWYOlGrlN7MFkvn7rmpdMUqv%2BShDLpFyO4Y%2FI%3D& > > > | > | amp;reserved=0 > > > | > | > ee > > > | > | > > > | > | > > > | > | > > > | > | -- > > > | > | Chris Allen > > > | > | Currently working on > > > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhas > > > | > | kellbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836 > > > | > | 834427a29408d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C > > > | > | 636911752855987147&sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK > > > | > | 8IyjBI%3D&reserved=0 > > > | > | _______________________________________________ > > > | > | ghc-steering-committee mailing list > > > | > | ghc-steering-committee at haskell.org > > > | > | > > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma > > > | > | il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ > > > | > | ee&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a294 > > > | > | 08d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6369117528 > > > | > | 55987147&sdata=ESnHSYRuMMUvenMjIzpapcKWVfzbAqLJ9%2BcSNjoWklk%3D& > > > | > | amp;reserved=0 > > > | > > > | > > > | > > > | -- > > > | Chris Allen > > > | Currently working on > > > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskellbo > > > | ok.com&data=02%7C01%7Csimonpj%40microsoft.com%7C670f986836834427a29408 > > > | d6c3dd5cd0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636911752855987147 > > > | &sdata=u6TzKujVuJnrWL%2BnPr0YlcE7w8xHnENsWZUDK8IyjBI%3D&reserved=0 > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > -- > Chris Allen > Currently working on http://haskellbook.com -- Chris Allen Currently working on http://haskellbook.com From rae at richarde.dev Tue Jul 9 14:46:32 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 9 Jul 2019 10:46:32 -0400 Subject: [ghc-steering-committee] Extra Commas In-Reply-To: References: <1947572120aa9ae9ea0003765601d36f9e5cdee3.camel@joachim-breitner.de> Message-ID: <9ACFF4C7-6585-4FDC-95B3-C91BA0FA4BBE@richarde.dev> > On Jul 8, 2019, at 2:05 PM, Christopher Allen wrote: > > If there are no objections, I will re-close the proposal as rejected. As I've posted on the GitHub trail, I don't think we should close this quite yet. > the opinions and priorities of people > who simply didn't want the extension or didn't plan to use it weighed > heavily on where the proposal went. This took it places nobody > interested in the proposal was interested in moving forward with. We > might want to consider how we evaluate proposals in light of that > problem. In the past I've held off commenting on proposals I wasn't > interested in but considered benign to my priorities. I don't think > everyone is operating on the same principle and it's making the > process more bureaucratic and less effective for helping Haskell users > achieve their ends. This is a valuable observation. If we broadly split the world into two camps -- those that would like the extra commas and those that don't -- the middle-road solution indeed doesn't serve either one. I'm not sure where to go with this, exactly. But I do think it's worthwhile thinking whether users or non-users are the ones more actively influencing a proposal. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Jul 10 07:11:29 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 10 Jul 2019 09:11:29 +0200 Subject: [ghc-steering-committee] The GHC Committee welcomes its new members Message-ID: <5449e89bc59a881d9189d38cd19a98eb1b7cdcaa.camel@joachim-breitner.de> Dear Haskell community, the GHC Steering committee welcomes its new two members, Sandy Maguire and Arnaud Spiwack. We are happy to see that there is continued interest in our work, and are looking forward to the insights and energy that are brought to the committee by Sandy and Arnaud. They take the seats of Ben Gamari and Manuel Chakravarty. A big thanks to Ben and Manuel for their contributions to GHC and the proposal committee. In particular Ben, who created the initials draft of the proposal process. We had four nominations in total, and I would like to preserve their privacy. Since we only had two seats to fill, we had to make a pick; nevertheless I am grateful for all nominations, and encourage everyone, including those who did not make it this time, to try again next time. Neither the committee nor its process is perfect, as the way two recent proposals went show, but we are constantly trying to refine and improve. Your feedback is always welcome, either at the committee mailing list, or in private communication with the Chairs (the two Simons), me, or any other member. On behalf of the committee, Joachim Breitner PS: Sandy and Arnaud, please subscribe to the mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Wed Jul 10 07:41:09 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 10 Jul 2019 09:41:09 +0200 Subject: [ghc-steering-committee] New tasks for our new members Message-ID: <108139d5fabc44d7601726055d6da1c3113f6939.camel@joachim-breitner.de> Welcome Sandy and Arnaud, (CC’ing you still, but in general I’ll assume you will subscribe to the list). First tasks, besides subscribing to the mailing list, are: 1. Read through https://github.com/ghc-proposals/ghc-proposals/ 2. There are a few proposals in the committee deliberation list. Check the Shepherd’s recommendation and see if you agree with it. Tell us if not (you may also indicate support, of course): https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22 3. The following proposal were shepherded by our leaving members. These have been lingering for quite a while, so I would like to re-assign them to the new members: Type annotated quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Sandy, can you shepherd this (see the README for the next steps) Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Aranud, can you shepherd this (see the README for the next steps) Looks like I can’t reassign them until you accepted my invitation to join the GitHub organization. Please ping me once you have done that. Cheers, 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 arnaud.spiwack at tweag.io Fri Jul 12 15:52:16 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 12 Jul 2019 17:52:16 +0200 Subject: [ghc-steering-committee] Committee discussion: #115 Provenance-Qualified Package Imports Message-ID: Dear all, As the shepherd for #115, I've made a recommendation and started the committee discussion: https://github.com/ghc-proposals/ghc-proposals/pull/115 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Jul 14 19:17:11 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 14 Jul 2019 21:17:11 +0200 Subject: [ghc-steering-committee] Status Message-ID: <988ff79182296b8fbda2715d4c11676a510518d6.camel@joachim-breitner.de> Dear committee, looks like my intuitive Status update cadence has become two months, rather than one. Oh well. This has happened since the last status, we * have new members. Welcome Sandy and Arnaud. Also thanks to Ben and Manuel. * were asked to review these proposals: #228 Function result type signatures (Shepherd: Simon PJ) #229 Parsing of (~) etc. (Shepherd: Richard) #160 NoToplevelFieldSelectors (Shepherd: Eric) #231 Record with syntax (Shepherd: Simon M.) #232 Ambiguous Type pragma (Shepherd: Richard) #220 QualifiedImports (Shepherd: Simon M) #240 Compile with threaded RTS (Shepherd: Simon M) * have a recommendation form the shepherd about: #229 Parsing of (~) etc. (rec: accept) #160 NoToplevelFieldSelectors (rec: accept) #231 Record with syntax (rec: accept) #220 QualifiedImports (rec: reject) #232 Ambiguous Type pragma (rec: accept) #115 Provenance-Qualified Package Imports (rec: accept) * decided about the following proposals #214 Namespace specifiers (needs revision) #216 Local Do (needs revision) #87 ExtraCommas (accepted a specific variant after voting) We currently have to act on the following 10 proposals, 5 up since last stats. Please check if any needs your action, especially as a shepherd: Compile with threaded RTS Shepherd: Simon M. Status: Acceptance imminent. https://github.com/ghc-proposals/ghc-proposals/pull/240 {-# AMBIGUOUS #-} Shepherd: Richard Status: Acceptance recommended, discussion ongoing https://github.com/ghc-proposals/ghc-proposals/pull/232 Record with syntax Shepherd: Simon M. Status: Acceptance recommended, but no consensus https://github.com/ghc-proposals/ghc-proposals/pull/231 Simplified parsing of (~) and (!) Shepherd: Richard Status: Acceptance recommended, but no consensus https://github.com/ghc-proposals/ghc-proposals/pull/229 Function result type signatures Shepherd: Simon PJ Status: Acceptance imminent. https://github.com/ghc-proposals/ghc-proposals/pull/228 Qualified Imports Shepherd: Simon M. Status: Waiting for Simon to officially make a recommendation. https://github.com/ghc-proposals/ghc-proposals/pull/220 Updated partial type signatures Shepherd: Vitaly Status: Waiting for Vitaly to make a recommendation. https://github.com/ghc-proposals/ghc-proposals/pull/194 NoFieldSelectors Shepherd: Eric Status: Acceptance imminent, I believe https://github.com/ghc-proposals/ghc-proposals/pull/160 Type annotated quoters Shepherd: Sandy Status: Acceptance recommended, Simon PJ discovered some nits. https://github.com/ghc-proposals/ghc-proposals/pull/125 Provenance-Qualified Package Imports Shepherd: Arnaud Status: Acceptance recommended. Mostly agreed on. https://github.com/ghc-proposals/ghc-proposals/pull/115 Cheers, 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 Jul 16 16:05:36 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 16 Jul 2019 18:05:36 +0200 Subject: [ghc-steering-committee] Please review #228: Function result type signatures, Shepherd: Simon PJ In-Reply-To: <35538689a7606a8e3703aace1e9a5d7014ae534e.camel@joachim-breitner.de> References: <35538689a7606a8e3703aace1e9a5d7014ae534e.camel@joachim-breitner.de> Message-ID: <12f50c3abc7d1e8c08bde7ec901ade8076d1bd5f.camel@joachim-breitner.de> Hi, JFTR, this was just accepted. Cheers, Joachim Am Mittwoch, den 29.05.2019, 12:10 +0200 schrieb Joachim Breitner: > Dear Committee, > > this is your secretary speaking: > > Function result type signatures > have been proposed by Vladislav Zavialov > https://github.com/ghc-proposals/ghc-proposals/pull/228 > https://github.com/int-index/ghc-proposals/blob/fn-res-sig/proposals/0000-function-result-sigs.rst > > I propose Simon PJ as the Shepherd, for having commented on it before. > > Please reach consensus as described in > https://github.com/ghc-proposals/ghc-proposals#committee-process > In particular, talk to the authors before, if you think this should be > rejected, and kick off the discussion on Github, following the steps > described under “Now the shepherd proposes to accept or reject the > proposal” in the above link. > > > Thanks, > Joachim > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rae at richarde.dev Wed Jul 17 15:30:10 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 17 Jul 2019 11:30:10 -0400 Subject: [ghc-steering-committee] committee deliberation discussions Message-ID: Hi committee, A few months ago, we decided to move final proposal deliberations to GitHub, knowing that this might not work. I'd like to claim: it's not working. Here is why: * Though I've configured my mail reader to flag messages that invite the committee to deliberate (and this works), later messages in the thread are not thus flagged (and I don't know how I would do so), and so I have to remember the proposals under deliberation manually. This is error-prone. * The requests to the community to be quiet during deliberation are not working. Some participants miss that message (it can be quite far up the thread!) and then participate. Others doubtless have something to say, but refrain... and then possibly get annoyed at those who don't heed the request. * Though I haven't collected data, my guess is that there has been less involvement from the committee in these discussions than the ones we had previously. I thus propose we move deliberations back to this list. However, some good has come from all this, so I wish to further propose: * Shepherds still post to the GitHub thread before making a "reject" recommendation. Then the shepherd and the author can work out their differences. * After emailing their recommendation, shepherds post a link to the email archive of the recommendation. This makes the deliberation more transparently a public phenomenon, while still focusing our (committee members') inboxes and our attention. The shepherd may also cross-post thoughts to the GitHub trail seeking more public or author feedback, if that is warranted. Alternatively, we can set up the mailing list so that non-member posts are moderated instead of auto-rejected. The owner of the list (who is that, anyway?) could then approve posts from proposal authors. This is an annoying manual step, but I don't think it will be burdensome in practice. What do we think? I'm happy to post a diff to the process descriptor if there is support. Richard From rae at richarde.dev Wed Jul 17 18:31:16 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 17 Jul 2019 14:31:16 -0400 Subject: [ghc-steering-committee] committee deliberation discussions In-Reply-To: References: Message-ID: <0EAD7689-D2D5-4DF8-824E-874E5FBC5FDE@richarde.dev> > On Jul 17, 2019, at 2:15 PM, Sandy Maguire wrote: > > Could we grant proposal authors access to the mailing list during the discussion period? I'm not sure how technically easy or hard this would be. We could always accept emails from authors on a case-by-case basis, simply by changing the mailman settings. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Wed Jul 17 21:45:33 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 17 Jul 2019 14:45:33 -0700 Subject: [ghc-steering-committee] committee deliberation discussions In-Reply-To: References: Message-ID: Hello, I agree. For me, personally, the discussions on GitHub are quite exhausting, and while I still try to share my opinion when asked, I am certainly not looking forward to it. -Iavor On Wed, Jul 17, 2019 at 8:31 AM Richard Eisenberg wrote: > > Hi committee, > > A few months ago, we decided to move final proposal deliberations to GitHub, knowing that this might not work. I'd like to claim: it's not working. Here is why: > > * Though I've configured my mail reader to flag messages that invite the committee to deliberate (and this works), later messages in the thread are not thus flagged (and I don't know how I would do so), and so I have to remember the proposals under deliberation manually. This is error-prone. > > * The requests to the community to be quiet during deliberation are not working. Some participants miss that message (it can be quite far up the thread!) and then participate. Others doubtless have something to say, but refrain... and then possibly get annoyed at those who don't heed the request. > > * Though I haven't collected data, my guess is that there has been less involvement from the committee in these discussions than the ones we had previously. > > I thus propose we move deliberations back to this list. However, some good has come from all this, so I wish to further propose: > > * Shepherds still post to the GitHub thread before making a "reject" recommendation. Then the shepherd and the author can work out their differences. > > * After emailing their recommendation, shepherds post a link to the email archive of the recommendation. This makes the deliberation more transparently a public phenomenon, while still focusing our (committee members') inboxes and our attention. The shepherd may also cross-post thoughts to the GitHub trail seeking more public or author feedback, if that is warranted. Alternatively, we can set up the mailing list so that non-member posts are moderated instead of auto-rejected. The owner of the list (who is that, anyway?) could then approve posts from proposal authors. This is an annoying manual step, but I don't think it will be burdensome in practice. > > What do we think? > > I'm happy to post a diff to the process descriptor if there is support. > > Richard > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From arnaud.spiwack at tweag.io Thu Jul 18 07:36:58 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 18 Jul 2019 09:36:58 +0200 Subject: [ghc-steering-committee] committee deliberation discussions In-Reply-To: <0EAD7689-D2D5-4DF8-824E-874E5FBC5FDE@richarde.dev> References: <0EAD7689-D2D5-4DF8-824E-874E5FBC5FDE@richarde.dev> Message-ID: The steering committee mailing list is actually open to everybody to post. So on the technical side, I don't see a problem. On the social side, though, I see more difficulties. It will tend to create more barrier of entries for authors to make successful proposal, for instance (one more thing to get subscribed to, I should also mention that I've noticed that people in their twenties tend to be pretty uncomfortable with mailing lists). So I think a hybrid discussion where the committee speaks among themselves, then come back to the author, is probably the best option. It does put some more work for the shepherd which needs to organise the back and forth. But hopefully not too much. Other than that, I agree with everything Richard says and proposes. I'll add one argument: there is no good reason why the public discussion on a proposal should stop just because the committee is having a chinwag about it. On Wed, Jul 17, 2019 at 8:31 PM Richard Eisenberg wrote: > > > On Jul 17, 2019, at 2:15 PM, Sandy Maguire wrote: > > Could we grant proposal authors access to the mailing list during the > discussion period? > > > I'm not sure how technically easy or hard this would be. We could always > accept emails from authors on a case-by-case basis, simply by changing the > mailman settings. > > Richard > _______________________________________________ > 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 Thu Jul 18 09:46:07 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 18 Jul 2019 11:46:07 +0200 Subject: [ghc-steering-committee] committee deliberation discussions In-Reply-To: References: Message-ID: <3f0772f0d0b57fce86d70d23e2f22eb9081ead31.camel@joachim-breitner.de> Hi, Am Mittwoch, den 17.07.2019, 11:30 -0400 schrieb Richard Eisenberg: > Alternatively, we can set up the mailing list so that non-member posts are moderated instead of auto-rejected. are they rejected? I hope not: The mailing list is the recommended point of contact if someone wants to talk to the committee: https://github.com/ghc-proposals/ghc-proposals/#who-is-the-committee Cheers, 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 rae at richarde.dev Thu Jul 18 12:03:11 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 18 Jul 2019 08:03:11 -0400 Subject: [ghc-steering-committee] committee deliberation discussions In-Reply-To: <3f0772f0d0b57fce86d70d23e2f22eb9081ead31.camel@joachim-breitner.de> References: <3f0772f0d0b57fce86d70d23e2f22eb9081ead31.camel@joachim-breitner.de> Message-ID: <165C0FA5-9B78-41F0-B457-390B1BB26B8D@richarde.dev> I thought they were, but perhaps I'm wrong. I've contacted Ben, the owner of the list, to volunteer to become the new list owner since Ben's departure. Then we can decide how to turn the knobs. Richard > On Jul 18, 2019, at 5:46 AM, Joachim Breitner wrote: > > Hi, > > Am Mittwoch, den 17.07.2019, 11:30 -0400 schrieb Richard Eisenberg: >> Alternatively, we can set up the mailing list so that non-member posts are moderated instead of auto-rejected. > > are they rejected? I hope not: The mailing list is the recommended > point of contact if someone wants to talk to the committee: > > https://github.com/ghc-proposals/ghc-proposals/#who-is-the-committee > > Cheers, > 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 From marlowsd at gmail.com Thu Jul 18 12:57:53 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 18 Jul 2019 13:57:53 +0100 Subject: [ghc-steering-committee] committee deliberation discussions In-Reply-To: References: Message-ID: Agree with Richard. I've had exactly the same concerns. One suggested tweak: we currently recommend that the shepherd discusses with the author if they plan to recommend rejection. I suggest we also expand that to the situation where the shepherd recommended acceptance, but the ensuing discussion led the committee towards a reject decision. In that case we should also go back to the author and given them a chance to rebut. Cheers Simon On Wed, 17 Jul 2019 at 16:31, Richard Eisenberg wrote: > Hi committee, > > A few months ago, we decided to move final proposal deliberations to > GitHub, knowing that this might not work. I'd like to claim: it's not > working. Here is why: > > * Though I've configured my mail reader to flag messages that invite the > committee to deliberate (and this works), later messages in the thread are > not thus flagged (and I don't know how I would do so), and so I have to > remember the proposals under deliberation manually. This is error-prone. > > * The requests to the community to be quiet during deliberation are not > working. Some participants miss that message (it can be quite far up the > thread!) and then participate. Others doubtless have something to say, but > refrain... and then possibly get annoyed at those who don't heed the > request. > > * Though I haven't collected data, my guess is that there has been less > involvement from the committee in these discussions than the ones we had > previously. > > I thus propose we move deliberations back to this list. However, some good > has come from all this, so I wish to further propose: > > * Shepherds still post to the GitHub thread before making a "reject" > recommendation. Then the shepherd and the author can work out their > differences. > > * After emailing their recommendation, shepherds post a link to the email > archive of the recommendation. This makes the deliberation more > transparently a public phenomenon, while still focusing our (committee > members') inboxes and our attention. The shepherd may also cross-post > thoughts to the GitHub trail seeking more public or author feedback, if > that is warranted. Alternatively, we can set up the mailing list so that > non-member posts are moderated instead of auto-rejected. The owner of the > list (who is that, anyway?) could then approve posts from proposal authors. > This is an annoying manual step, but I don't think it will be burdensome in > practice. > > What do we think? > > I'm happy to post a diff to the process descriptor if there is support. > > Richard > _______________________________________________ > 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 eric at seidel.io Thu Jul 18 13:02:30 2019 From: eric at seidel.io (Eric Seidel) Date: Thu, 18 Jul 2019 09:02:30 -0400 Subject: [ghc-steering-committee] committee deliberation discussions In-Reply-To: <165C0FA5-9B78-41F0-B457-390B1BB26B8D@richarde.dev> References: <3f0772f0d0b57fce86d70d23e2f22eb9081ead31.camel@joachim-breitner.de> <165C0FA5-9B78-41F0-B457-390B1BB26B8D@richarde.dev> Message-ID: <7DA6112E-EE42-4DE7-AB46-A404C864AF5F@seidel.io> I recall a non-committee member posting to the list a few months ago to try to clarify something in our discussion. So it must be possible, I think it’s just much more obvious to the public that the list is primarily for committee discussions. I’ve also had trouble tracking which proposals are in an active committee deliberation. I’d favor some sort of hybrid model where we have discussions on the list, but don’t immediately reject proposals without inviting the author to address our concerns. Another option could be to invite the author to join the committee discussion on the list from the beginning. Then there’s a bit less back and forth between GitHub and the list. Sent from my iPhone > On Jul 18, 2019, at 08:03, Richard Eisenberg wrote: > > I thought they were, but perhaps I'm wrong. I've contacted Ben, the owner of the list, to volunteer to become the new list owner since Ben's departure. Then we can decide how to turn the knobs. > > Richard > >> On Jul 18, 2019, at 5:46 AM, Joachim Breitner wrote: >> >> Hi, >> >> Am Mittwoch, den 17.07.2019, 11:30 -0400 schrieb Richard Eisenberg: >>> Alternatively, we can set up the mailing list so that non-member posts are moderated instead of auto-rejected. >> >> are they rejected? I hope not: The mailing list is the recommended >> point of contact if someone wants to talk to the committee: >> >> https://github.com/ghc-proposals/ghc-proposals/#who-is-the-committee >> >> Cheers, >> 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 From simonpj at microsoft.com Thu Jul 18 19:35:06 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 18 Jul 2019 19:35:06 +0000 Subject: [ghc-steering-committee] committee deliberation discussions In-Reply-To: References: Message-ID: The thing I like about using GitHub is that it means that all the substantial technical critique is one place. Since the bandwidth for proposals under discussion is high, I often think “I’ll wait till the dust has settled and the proposal has been revised and submitted to the committee before giving a thorough look.” But when I do look I often have technical questions. Using the mailing list for all SC discussion means that the technical discussion ends up in two places; and non-SCE members are prevented (by convention at least) from responding. In our SC-email -list phase, I found myself putting comments on Github and (tiresomely) posting a link to email list as well. Here’s a straw man idea. During the SC phase, * If SC members have technical comments or questions, they should post them to GitHub, where the author or anyone else can respond. * If members want to post evaluations such as “I think we should accept because...” or similarly for reject, use the email list. That would allow the authors and others to continue to contribute without impeding the committee’s evaluation work. After some reflection I like this a lot better than having all SC contributions on the SC list. It would mean that SC members might have to track those posts on GitHub. I think we should also make it clearer that “submit to the committee” means “I have revised the proposal, so that it reflects precisely what I propose”. Committee members are obligated to read the proposal, but it should not be necessary to read the discussion thread and they should not feel obliged to do so. (If, say, they ask a technical question that is answered further up, that question should by now be answered by the proposal itself.) Simon From: ghc-steering-committee On Behalf Of Simon Marlow Sent: 18 July 2019 13:58 To: Richard Eisenberg Cc: Simon Peyton Jones via ghc-steering-committee Subject: Re: [ghc-steering-committee] committee deliberation discussions Agree with Richard. I've had exactly the same concerns. One suggested tweak: we currently recommend that the shepherd discusses with the author if they plan to recommend rejection. I suggest we also expand that to the situation where the shepherd recommended acceptance, but the ensuing discussion led the committee towards a reject decision. In that case we should also go back to the author and given them a chance to rebut. Cheers Simon On Wed, 17 Jul 2019 at 16:31, Richard Eisenberg > wrote: Hi committee, A few months ago, we decided to move final proposal deliberations to GitHub, knowing that this might not work. I'd like to claim: it's not working. Here is why: * Though I've configured my mail reader to flag messages that invite the committee to deliberate (and this works), later messages in the thread are not thus flagged (and I don't know how I would do so), and so I have to remember the proposals under deliberation manually. This is error-prone. * The requests to the community to be quiet during deliberation are not working. Some participants miss that message (it can be quite far up the thread!) and then participate. Others doubtless have something to say, but refrain... and then possibly get annoyed at those who don't heed the request. * Though I haven't collected data, my guess is that there has been less involvement from the committee in these discussions than the ones we had previously. I thus propose we move deliberations back to this list. However, some good has come from all this, so I wish to further propose: * Shepherds still post to the GitHub thread before making a "reject" recommendation. Then the shepherd and the author can work out their differences. * After emailing their recommendation, shepherds post a link to the email archive of the recommendation. This makes the deliberation more transparently a public phenomenon, while still focusing our (committee members') inboxes and our attention. The shepherd may also cross-post thoughts to the GitHub trail seeking more public or author feedback, if that is warranted. Alternatively, we can set up the mailing list so that non-member posts are moderated instead of auto-rejected. The owner of the list (who is that, anyway?) could then approve posts from proposal authors. This is an annoying manual step, but I don't think it will be burdensome in practice. What do we think? I'm happy to post a diff to the process descriptor if there is support. Richard _______________________________________________ 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 sandy at sandymaguire.me Thu Jul 11 19:10:01 2019 From: sandy at sandymaguire.me (Sandy Maguire) Date: Thu, 11 Jul 2019 15:10:01 -0400 Subject: [ghc-steering-committee] Type annotated quoters (#125) --- recommendation: accept Message-ID: Hi all, Proposal 125 is on the topic of making quasiquoters which annotate the type of expression they produce. For example: qq :: TQuasiQuoter Int which would work when used via foo :: Int foo = [qq|| blah ||] but would be a type error (even before expanding the splice) in the context of bar :: String bar = [qq|| blah ||] I'm in favor of this proposal. It's small, a natural extension to typed expressions+quasiquoters, and solves the very real problem of statically verifying literals at compile time. The proposal is here: https://github.com/ghc-proposals/ghc-proposals/pull/125 and my recommendation is: https://github.com/ghc-proposals/ghc-proposals/pull/125#issuecomment-510612026 I have recommend a syntactic change that is *not* present in the original proposal text. It seems unfair to make the proposer jump through more hoops after a year of inactivity on this proposal. As usual, silence will be considered assent! Best, Sandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandy at sandymaguire.me Wed Jul 17 18:15:56 2019 From: sandy at sandymaguire.me (Sandy Maguire) Date: Wed, 17 Jul 2019 14:15:56 -0400 Subject: [ghc-steering-committee] committee deliberation discussions In-Reply-To: References: Message-ID: I'm inclined to agree with Richard here. However, as a previous proposal author who subscribed to this mailing list, I found it particularly frustrating to watch the committee discuss my proposal but not have a means of replying to them when I felt they were misunderstanding something. Could we grant proposal authors access to the mailing list during the discussion period? Sandy On Wed, Jul 17, 2019 at 11:31 AM Richard Eisenberg wrote: > Hi committee, > > A few months ago, we decided to move final proposal deliberations to > GitHub, knowing that this might not work. I'd like to claim: it's not > working. Here is why: > > * Though I've configured my mail reader to flag messages that invite the > committee to deliberate (and this works), later messages in the thread are > not thus flagged (and I don't know how I would do so), and so I have to > remember the proposals under deliberation manually. This is error-prone. > > * The requests to the community to be quiet during deliberation are not > working. Some participants miss that message (it can be quite far up the > thread!) and then participate. Others doubtless have something to say, but > refrain... and then possibly get annoyed at those who don't heed the > request. > > * Though I haven't collected data, my guess is that there has been less > involvement from the committee in these discussions than the ones we had > previously. > > I thus propose we move deliberations back to this list. However, some good > has come from all this, so I wish to further propose: > > * Shepherds still post to the GitHub thread before making a "reject" > recommendation. Then the shepherd and the author can work out their > differences. > > * After emailing their recommendation, shepherds post a link to the email > archive of the recommendation. This makes the deliberation more > transparently a public phenomenon, while still focusing our (committee > members') inboxes and our attention. The shepherd may also cross-post > thoughts to the GitHub trail seeking more public or author feedback, if > that is warranted. Alternatively, we can set up the mailing list so that > non-member posts are moderated instead of auto-rejected. The owner of the > list (who is that, anyway?) could then approve posts from proposal authors. > This is an annoying manual step, but I don't think it will be burdensome in > practice. > > What do we think? > > I'm happy to post a diff to the process descriptor if there is support. > > Richard > _______________________________________________ > 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 Fri Jul 19 16:33:47 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 19 Jul 2019 16:33:47 +0000 Subject: [ghc-steering-committee] Type annotated quoters (#125) --- recommendation: accept In-Reply-To: References: Message-ID: My current POV is that I think this feature is far far more limited than I originally thought -- and hence unattractive. (I’ve posted on the discussion thread to that effect.) I’m willing to be educated! Simon From: ghc-steering-committee On Behalf Of Sandy Maguire Sent: 11 July 2019 20:10 To: ghc-steering-committee at haskell.org Subject: [ghc-steering-committee] Type annotated quoters (#125) --- recommendation: accept Hi all, Proposal 125 is on the topic of making quasiquoters which annotate the type of expression they produce. For example: qq :: TQuasiQuoter Int which would work when used via foo :: Int foo = [qq|| blah ||] but would be a type error (even before expanding the splice) in the context of bar :: String bar = [qq|| blah ||] I'm in favor of this proposal. It's small, a natural extension to typed expressions+quasiquoters, and solves the very real problem of statically verifying literals at compile time. The proposal is here: https://github.com/ghc-proposals/ghc-proposals/pull/125 and my recommendation is: https://github.com/ghc-proposals/ghc-proposals/pull/125#issuecomment-510612026 I have recommend a syntactic change that is *not* present in the original proposal text. It seems unfair to make the proposer jump through more hoops after a year of inactivity on this proposal. As usual, silence will be considered assent! Best, Sandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Fri Jul 19 17:27:57 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 19 Jul 2019 10:27:57 -0700 Subject: [ghc-steering-committee] Type annotated quoters (#125) --- recommendation: accept In-Reply-To: References: Message-ID: It is a rather small change, but I think it could be handy. I just posted an example on GitHub, along the lines of what you were asking for, have a look and see what you think. On Fri, Jul 19, 2019 at 9:34 AM Simon Peyton Jones via ghc-steering-committee wrote: > > My current POV is that I think this feature is far far more limited than I originally thought -- and hence unattractive. (I’ve posted on the discussion thread to that effect.) > > > > I’m willing to be educated! > > > > Simon > > > > From: ghc-steering-committee On Behalf Of Sandy Maguire > Sent: 11 July 2019 20:10 > To: ghc-steering-committee at haskell.org > Subject: [ghc-steering-committee] Type annotated quoters (#125) --- recommendation: accept > > > > Hi all, > > > > Proposal 125 is on the topic of making quasiquoters which annotate the type of expression they produce. For example: > > > > qq :: TQuasiQuoter Int > > > > which would work when used via > > > > foo :: Int > > foo = [qq|| blah ||] > > > > but would be a type error (even before expanding the splice) in the context of > > > > bar :: String > > bar = [qq|| blah ||] > > > > I'm in favor of this proposal. It's small, a natural extension to typed expressions+quasiquoters, and solves the very real problem of statically verifying literals at compile time. > > > > The proposal is here: https://github.com/ghc-proposals/ghc-proposals/pull/125 > > and my recommendation is: https://github.com/ghc-proposals/ghc-proposals/pull/125#issuecomment-510612026 > > > > I have recommend a syntactic change that is *not* present in the original proposal text. It seems unfair to make the proposer jump through more hoops after a year of inactivity on this proposal. > > > > As usual, silence will be considered assent! > > > > Best, > > Sandy > > _______________________________________________ > 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 Jul 29 13:32:25 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 29 Jul 2019 15:32:25 +0200 Subject: [ghc-steering-committee] Set reminders on Github Message-ID: <47e8a5fd48b0c46539074a4927480f282ab3a95f.camel@joachim-breitner.de> Dear Committe, I have enabled a “reminder bot” on our GitHub repository. You can set reminders by writing /remind me to close discussion next week or /remind @isovector to accept this on July 29 and the bot will confirm that it understood what you wrote, and then, well, remind you about it. You can use this for things like “if this stays silent, I will do X in Y days”. Cheers, 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 iavor.diatchki at gmail.com Mon Jul 29 17:55:25 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 29 Jul 2019 10:55:25 -0700 Subject: [ghc-steering-committee] Set reminders on Github In-Reply-To: <47e8a5fd48b0c46539074a4927480f282ab3a95f.camel@joachim-breitner.de> References: <47e8a5fd48b0c46539074a4927480f282ab3a95f.camel@joachim-breitner.de> Message-ID: Is there a way to set it up so that when people add "remind-me" fake messages no e-mail is sent to people subscribed to the thread? From mail at joachim-breitner.de Mon Jul 29 20:18:17 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 29 Jul 2019 22:18:17 +0200 Subject: [ghc-steering-committee] Set reminders on Github In-Reply-To: References: <47e8a5fd48b0c46539074a4927480f282ab3a95f.camel@joachim-breitner.de> Message-ID: <6A0DB886-B931-4429-B85A-8B481346C580@joachim-breitner.de> Hi, no, in don't think so, the bot really just posts a message. Maybe it's good to set a public timer? Of course you can just put a reminder in your personal calendar if you worry about the noise. Cheers, Joachim Am 29. Juli 2019 19:55:25 MESZ schrieb Iavor Diatchki : >Is there a way to set it up so that when people add "remind-me" fake >messages no e-mail is sent to people subscribed to the thread? From nvazou at cs.ucsd.edu Fri Jul 26 12:09:44 2019 From: nvazou at cs.ucsd.edu (Niki Vazou) Date: Fri, 26 Jul 2019 14:09:44 +0200 Subject: [ghc-steering-committee] Haskell Implementors Working: Looking for Panelists In-Reply-To: References: Message-ID: Hello, Haskell Implementors Workshop 2019 will be having a 45 min panel discussion (17.15-18.00 on Fri 23th August). The goal is to have panelists that represent the following committees: - ghc steering committee - Devops committee - core libraries committee - Haskell' committee - Haskell.org committee - Haskell Symposium & HiW steering committee Let me know if you - want like to be in the panel - if there are issues you want to raise in the panel discussion. Best, Niki Chair of HiW'19 -------------- next part -------------- An HTML attachment was scrubbed... URL: