On Sun, Aug 30, 2020, at 03:11, Joachim Breitner wrote:

I wouldn’t worry about enabling the extension; you’d still have to actually write {..} to get the behavior, readers will at least know whether it is hard to tell where variables are abound.

I agree, but this is a concern that comes up often, so we should be prepared to address it.

...

at least consider adding OverloadedStrings and perhaps OverloadedLists.

I regularly write code where I use a library that only works nice if "foo" is monomorphic, because such strings are meant to be used in polymorphic contexts. With OverloadedStrings, you get ambiguity errors that you have to resolve with explicit type annotations. So unfortunately, that one probably can’t be on by default. Which is a shame, of course.

Interesting, I think I can count on one hand the number of times OverloadedStrings has caused an ambiguity error for me. What libraries do you use that are polymorphic in the string type?

Hi, yeah, I use `OverloadedStrings` all the time too, but didn't include it for the reason Joachim mentioned. For me one common pattern where ambiguity occurs is indeed with `aeson`, for example if you are encoding tagged sums you may write: ``` object [ "tag" .= ("inLeft" :: Text) ] ``` The type signature is required so that the `.=` operator knows how to make the JSON value. I don't think that's a big deal, and it's easy to work around (I typically make a helper function for making that field). I'd be OK with it being always on, but I didn't add it as it does require you to change your code sometimes. As for `RecordWildcards`, I do like the extension as it can make code significantly more readable in some situations (single record manipulation, or constructing large records, especially when effects are involved). I know some folks don't like it, but I hope we can get the extension included in the list, as it is not something that can be used "by accident" and also, using it does not affect a function's interface in any way. I feel `LambdaCase` is another extension in the same group---in this case I don't really like the extension, but I know other folks like it, so I think it'd be reasonable to add (although I did see we have a proposal for an incompatible alternative, so we'll have to see what to do about that) -Iavor On Mon, Aug 31, 2020 at 1:16 AM Joachim Breitner wrote:

Hi,

Am Sonntag, den 30.08.2020, 23:51 -0400 schrieb Eric Seidel:

...

Interesting, I think I can count on one hand the number of times OverloadedStrings has caused an ambiguity error for me. What libraries do you use that are polymorphic in the string type?

hmm, I don’t remember. It must have been code that deals with keys or labels of sorts, but it’s not aeson… sorry. Maybe I’ll remember later.

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Thanks for doing this Richard. I wonder if there might be a different way to organize this, that is more suitable for discussion? I just had a look at the page, and here are some issue I felt: - The page is already very long, and it barely has any comments. I wonder if it might make sense to have one page per extension, instead? Or at least a separate page for a group of related extensions? - Having a discussion on the wiki is tricky, and maybe before we do that and involve the rest of the community, we could practice among ourselves, at least until we figure out, for example, what might be suitable criteria - When I evaluate the extensions, I do apply some criterias, but my decisions are often not as binary as "this fits" or "this not", but rather more along the lines of "this would make this a little better", "while this might make things a little worse", and "if this was on, I might have to watch out for X,Y,Z, is that a problem?". I am not sure how to capture this though. So, I think my preference would be to have some discussion on the mailing list, or maybe we could even have a video chat with interested folks on specific topics, rather than trying to do everything on the wiki straight away... -Iavor PS: By the way, the FFI is part of Haskell2020, but on the wiki Richard marked it as not qualifying under his criteria 5. I would expect GHC 202X to be a super-set of the language standard, or do you think we should be also removing things? On Mon, Aug 31, 2020 at 11:55 AM Richard Eisenberg wrote:

A fun way to start the fall. (Today is my daughter's first day of "school". This defines the beginning of fall.) Thanks, Iavor, for kicking this off.

I initially wrote a long email in this space, with numbered criteria (heavily based on Iavor's suggestions) and my thoughts on the individual extensions proposed. But I realized this would quickly grow unwieldy. I thus have created https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020, where I propose we track this conversation. Specifically: arguments for or against an individual extension should go right on the wiki, labeled with the author's name/initials. This preserves these arguments for later. Then, to keep the conversation moving, write back to this list just mentioning which extensions you've commented on.

Please review the criteria on the wiki page. Do you agree with what I've put forward?

I've commented on the following extensions:

ApplicativeDo CApiFFI EmptyCase ExplicitNamespaces ForeignFunctionInterface LambdaCase MultiWayIf NamedFieldPuns OverloadedLists OverloadedStrings PatternSynonyms RecordWildCards ScopedTypeVariables StandaloneKindSignatures TupleSections TypeOperators

I have added these new extensions for consideration:

MultiParamTypeClasses ImplicitParams FlexibleContexts FlexibleInstances GeneralizedNewtypeDeriving DeriveDataTypeable DeriveGeneric DefaultSignatures InstanceSigs ConstrainedClassMethods ExplicitForAll DeriveFunctor DeriveTraversable DeriveFoldable PolyKinds RoleAnnotations NegativeLiterals DeriveAnyClass DeriveLift DerivingStrategies EmptyDataDeriving

Looking forward to seeing your thoughts here! Richard

On Sep 1, 2020, at 12:18 PM, Iavor Diatchki wrote:

Thanks for doing this Richard. I wonder if there might be a different way to organize this, that is more suitable for discussion?

I agree that the wiki page isn't ideal -- but I don't have a better suggestion, short of, say, a different ticket for each extension (or set of related extensions). My big worry is that email is terrible at this sort of thing. Either everyone quotes every prior person's entire message, or we quote selectively and then easily lose history. Gathering the set of comments pertinent to one extension will be manual and painful.

- When I evaluate the extensions, I do apply some criterias, but my decisions are often not as binary as "this fits" or "this not", but rather more along the lines of "this would make this a little better", "while this might make things a little worse", and "if this was on, I might have to watch out for X,Y,Z, is that a problem?". I am not sure how to capture this though.

I tend to agree here, both on the evaluation and unsureness of how to capture.

So, I think my preference would be to have some discussion on the mailing list, or maybe we could even have a video chat with interested folks on specific topics, rather than trying to do everything on the wiki straight away...

As I said above, I think email is a poor place to do this, because we will end up having to pore through the email chain to recreate decisions/rationale for each extension. The wiki is in my opinion a less-poor place to do this. Maybe there is a good place to have the discussion -- that would be great.

-Iavor PS: By the way, the FFI is part of Haskell2020, but on the wiki Richard marked it as not qualifying under his criteria 5. I would expect GHC 202X to be a super-set of the language standard, or do you think we should be also removing things?

I was reacting to Eric's concern about FFI. I've updated the wiki to say that FFI is part of Haskell2010. I agree that we should be a superset of extensions. Richard

On Mon, Aug 31, 2020 at 11:55 AM Richard Eisenberg mailto:rae@richarde.dev> wrote: A fun way to start the fall. (Today is my daughter's first day of "school". This defines the beginning of fall.) Thanks, Iavor, for kicking this off.

I initially wrote a long email in this space, with numbered criteria (heavily based on Iavor's suggestions) and my thoughts on the individual extensions proposed. But I realized this would quickly grow unwieldy. I thus have created https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020, where I propose we track this conversation. Specifically: arguments for or against an individual extension should go right on the wiki, labeled with the author's name/initials. This preserves these arguments for later. Then, to keep the conversation moving, write back to this list just mentioning which extensions you've commented on.

Please review the criteria on the wiki page. Do you agree with what I've put forward?

I've commented on the following extensions:

ApplicativeDo CApiFFI EmptyCase ExplicitNamespaces ForeignFunctionInterface LambdaCase MultiWayIf NamedFieldPuns OverloadedLists OverloadedStrings PatternSynonyms RecordWildCards ScopedTypeVariables StandaloneKindSignatures TupleSections TypeOperators

I have added these new extensions for consideration:

MultiParamTypeClasses ImplicitParams FlexibleContexts FlexibleInstances GeneralizedNewtypeDeriving DeriveDataTypeable DeriveGeneric DefaultSignatures InstanceSigs ConstrainedClassMethods ExplicitForAll DeriveFunctor DeriveTraversable DeriveFoldable PolyKinds RoleAnnotations NegativeLiterals DeriveAnyClass DeriveLift DerivingStrategies EmptyDataDeriving

Looking forward to seeing your thoughts here! Richard

Thanks Richard for organizing the wiki page! I've added some personal notes, mostly about the fact that I think that most people expect "ScopedTypeVariables" to be in a new language standard, even though it breaks some of the rules (which seem like a good general guidance). Alejandro El mar., 1 sept. 2020 a las 20:27, Richard Eisenberg () escribió:

On Sep 1, 2020, at 12:18 PM, Iavor Diatchki wrote:

Thanks for doing this Richard. I wonder if there might be a different way to organize this, that is more suitable for discussion?

I agree that the wiki page isn't ideal -- but I don't have a better suggestion, short of, say, a different ticket for each extension (or set of related extensions). My big worry is that email is terrible at this sort of thing. Either everyone quotes every prior person's entire message, or we quote selectively and then easily lose history. Gathering the set of comments pertinent to one extension will be manual and painful.

- When I evaluate the extensions, I do apply some criterias, but my decisions are often not as binary as "this fits" or "this not", but rather more along the lines of "this would make this a little better", "while this might make things a little worse", and "if this was on, I might have to watch out for X,Y,Z, is that a problem?". I am not sure how to capture this though.

I tend to agree here, both on the evaluation and unsureness of how to capture.

So, I think my preference would be to have some discussion on the mailing list, or maybe we could even have a video chat with interested folks on specific topics, rather than trying to do everything on the wiki straight away...

As I said above, I think email is a poor place to do this, because we will end up having to pore through the email chain to recreate decisions/rationale for each extension. The wiki is in my opinion a less-poor place to do this. Maybe there is a good place to have the discussion -- that would be great.

-Iavor PS: By the way, the FFI is part of Haskell2020, but on the wiki Richard marked it as not qualifying under his criteria 5. I would expect GHC 202X to be a super-set of the language standard, or do you think we should be also removing things?

I was reacting to Eric's concern about FFI. I've updated the wiki to say that FFI is part of Haskell2010. I agree that we should be a superset of extensions.

Richard

On Mon, Aug 31, 2020 at 11:55 AM Richard Eisenberg wrote:

...

A fun way to start the fall. (Today is my daughter's first day of "school". This defines the beginning of fall.) Thanks, Iavor, for kicking this off.

I initially wrote a long email in this space, with numbered criteria (heavily based on Iavor's suggestions) and my thoughts on the individual extensions proposed. But I realized this would quickly grow unwieldy. I thus have created https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020, where I propose we track this conversation. Specifically: arguments for or against an individual extension should go right on the wiki, labeled with the author's name/initials. This preserves these arguments for later. Then, to keep the conversation moving, write back to this list just mentioning which extensions you've commented on.

Please review the criteria on the wiki page. Do you agree with what I've put forward?

I've commented on the following extensions:

ApplicativeDo CApiFFI EmptyCase ExplicitNamespaces ForeignFunctionInterface LambdaCase MultiWayIf NamedFieldPuns OverloadedLists OverloadedStrings PatternSynonyms RecordWildCards ScopedTypeVariables StandaloneKindSignatures TupleSections TypeOperators

I have added these new extensions for consideration:

MultiParamTypeClasses ImplicitParams FlexibleContexts FlexibleInstances GeneralizedNewtypeDeriving DeriveDataTypeable DeriveGeneric DefaultSignatures InstanceSigs ConstrainedClassMethods ExplicitForAll DeriveFunctor DeriveTraversable DeriveFoldable PolyKinds RoleAnnotations NegativeLiterals DeriveAnyClass DeriveLift DerivingStrategies EmptyDataDeriving

Looking forward to seeing your thoughts here! Richard

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, sounds plausible. It would also allow us to use tags to easily indicate the status (e.g. clearly-not, definitely-yes, kinda-contested…), and then filter by issue to get the current list… But before we go there, shouldn’t we maybe have a discussion first on * do we even want that? * what are the abstract criteria (or guidelines)? * what is the process? I believe that discussion could be done like any other proposal. As for the process; when I brought up the idea, I was worried about us spending huge resources discussion individual extensions to death, and proposed, in the interest of efficiency and getting things done:

The process could be: Every member can nominate any number of extensions, to include, maybe a small rationale and then we do one round of independent approval voting, requiring a supermajority to really only pick uncontested extensions.

So instead of long debates, we start with GHC2020 being just those extensions that a supermajority on the committee considers to be ok. This is much more lightweight process that we could get done in a week or two (maybe using a doodle-like voting page). Maybe we would leave out one or two extension that initially people are reserved about, but could be swayed after lengthy discussions. But is that worth the lengthy discussion? cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

It seems clear that my wiki idea isn't winning the day -- I never really liked it either. I'd be fine with either Eric's or Joachim's approaches. Maybe start with Joachim's approach and then use Eric's when Joachim's runs out of steam? A big minus, though, to Joachim's approach is that it seems hard to get good community involvement. Richard

On Sep 2, 2020, at 8:11 AM, Eric Seidel wrote:

Opening a regular discussion about whether and how we want to work on GHC 2020 sounds fine, that will also give the community a place to weigh in. I do think the eventual contents should be informed by the community though, it shouldn’t just be us working alone.

Sent from my iPhone

...

On Sep 2, 2020, at 03:16, Joachim Breitner wrote:

Hi,

sounds plausible. It would also allow us to use tags to easily indicate the status (e.g. clearly-not, definitely-yes, kinda-contested…), and then filter by issue to get the current list…

But before we go there, shouldn’t we maybe have a discussion first on

* do we even want that? * what are the abstract criteria (or guidelines)? * what is the process?

I believe that discussion could be done like any other proposal.

As for the process; when I brought up the idea, I was worried about us spending huge resources discussion individual extensions to death, and proposed, in the interest of efficiency and getting things done:

...

The process could be: Every member can nominate any number of extensions, to include, maybe a small rationale and then we do one round of independent approval voting, requiring a supermajority to really only pick uncontested extensions.

So instead of long debates, we start with GHC2020 being just those extensions that a supermajority on the committee considers to be ok.

This is much more lightweight process that we could get done in a week or two (maybe using a doodle-like voting page). Maybe we would leave out one or two extension that initially people are reserved about, but could be swayed after lengthy discussions. But is that worth the lengthy discussion?

cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Dear all, I would really like to move this forward, and I would be happy to put some work on it. What do you think of the following plan? - Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible. - Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria. If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions. Regards, Alejandro El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee () escribió:

Just back from holiday. Some thoughts

* I don’t think this mailing list is the best place for the discussion. Basically, it's a GHC Proposal, so someone (possibly a committee member, possibly not) should write a proposal, and we should put it through the process.

* We should advertise the criteria, as Richard has done on the wiki page.

* Any such proposal should be informed by data. Notably, extension usage in Hackage, or perhaps Stackage (since it's a bit more curated).

* A proposer might also want to run a public poll, as an additional source of data

* When it comes to the committee, we can (I guess) vote on individual extensions, rather than just accept/reject the whole thing.

I am intrigued by the idea of using Kialo to coordinate discussion. Maybe it'd work better than GitHub? Are there other alternatives? But that's orthogonal to the GHC 2020 idea; let's not conflate them.

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Richard Eisenberg | Sent: 02 September 2020 14:57 | To: Eric Seidel | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | It seems clear that my wiki idea isn't winning the day -- I never | really liked it either. I'd be fine with either Eric's or Joachim's | approaches. Maybe start with Joachim's approach and then use Eric's | when Joachim's runs out of steam? A big minus, though, to Joachim's | approach is that it seems hard to get good community involvement. | | Richard | | > On Sep 2, 2020, at 8:11 AM, Eric Seidel wrote: | > | > Opening a regular discussion about whether and how we want to work on | GHC 2020 sounds fine, that will also give the community a place to | weigh in. I do think the eventual contents should be informed by the | community though, it shouldn’t just be us working alone. | > | > Sent from my iPhone | > | >> On Sep 2, 2020, at 03:16, Joachim Breitner wrote: | >> | >> Hi, | >> | >> sounds plausible. It would also allow us to use tags to easily | indicate | >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and | >> then filter by issue to get the current list… | >> | >> But before we go there, shouldn’t we maybe have a discussion first | on | >> | >> * do we even want that? | >> * what are the abstract criteria (or guidelines)? | >> * what is the process? | >> | >> I believe that discussion could be done like any other proposal. | >> | >> | >> As for the process; when I brought up the idea, I was worried about | us | >> spending huge resources discussion individual extensions to death, | and | >> proposed, in the interest of efficiency and getting things done: | >> | >>> The process could be: Every member can nominate any number of | >>> extensions, to include, maybe a small rationale and then we do one | >>> round of independent approval voting, requiring a supermajority to | >>> really only pick uncontested extensions. | >> | >> So instead of long debates, we start with GHC2020 being just those | >> extensions that a supermajority on the committee considers to be ok. | >> | >> This is much more lightweight process that we could get done in a | week | >> or two (maybe using a doodle-like voting page). Maybe we would leave | >> out one or two extension that initially people are reserved about, | but | >> could be swayed after lengthy discussions. But is that worth the | >> lengthy discussion? | >> | >> cheers, | >> Joachim | >> | >> -- | >> Joachim Breitner | >> mail@joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf | 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D | &reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

While I don't want to foist more responsibility on the committee, I think it's asking too much of our community to be responsible for this. Invariably, a community member would propose a GHC20XX, there would be lots of debate, the debate would answer some questions and leave others unanswered, and then the committee would vote. During this time, the proposer would have to keep the proposal up to date, based on the hard-to-discern whims of the community, which may end up at odds with the committee (hopefully not too much at odds!). And then the proposal would have to be revised again after the committee votes. This reduces the load on the committee, but it wouldn't make for a rewarding experience for the proposer -- essentially because the person who does the labor (the proposer) wouldn't have very much authority. I'm fine with Alejandro's plan, and would be fine with trying out a new tool to organize our discussion (or not -- it's all up to the person taking charge). As for responsibility in the future: I don't know if we should codify that updated GHC20XX languages are our responsibility, per se, but they are a function we can perform when we feel the time is right. Richard

On Sep 8, 2020, at 6:37 AM, Simon Peyton Jones wrote:

Personally I don’t think we should make the Steering Committee responsible for initiating or driving this. We should establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version), express open-ness to a proposal, and then review proposals when/if they materialise.

It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee responsible.

What do others think?

Simon

From: Alejandro Serrano Mena Sent: 08 September 2020 09:13 To: Simon Peyton Jones Cc: Richard Eisenberg ; Eric Seidel ; ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] GHC 2020

Dear all,

I would really like to move this forward, and I would be happy to put some work on it.

What do you think of the following plan?

- Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.

- Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.

If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.

Regards,

Alejandro

El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee (mailto:ghc-steering-committee@haskell.org>) escribió:

Just back from holiday. Some thoughts

* I don’t think this mailing list is the best place for the discussion. Basically, it's a GHC Proposal, so someone (possibly a committee member, possibly not) should write a proposal, and we should put it through the process.

* We should advertise the criteria, as Richard has done on the wiki page.

* Any such proposal should be informed by data. Notably, extension usage in Hackage, or perhaps Stackage (since it's a bit more curated).

* A proposer might also want to run a public poll, as an additional source of data

* When it comes to the committee, we can (I guess) vote on individual extensions, rather than just accept/reject the whole thing.

I am intrigued by the idea of using Kialo to coordinate discussion. Maybe it'd work better than GitHub? Are there other alternatives? But that's orthogonal to the GHC 2020 idea; let's not conflate them.

Simon

| -----Original Message----- | From: ghc-steering-committee mailto:bounces@haskell.org> On Behalf Of Richard Eisenberg | Sent: 02 September 2020 14:57 | To: Eric Seidel mailto:eric@seidel.io> | Cc: ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | It seems clear that my wiki idea isn't winning the day -- I never | really liked it either. I'd be fine with either Eric's or Joachim's | approaches. Maybe start with Joachim's approach and then use Eric's | when Joachim's runs out of steam? A big minus, though, to Joachim's | approach is that it seems hard to get good community involvement. | | Richard | | > On Sep 2, 2020, at 8:11 AM, Eric Seidel mailto:eric@seidel.io> wrote: | > | > Opening a regular discussion about whether and how we want to work on | GHC 2020 sounds fine, that will also give the community a place to | weigh in. I do think the eventual contents should be informed by the | community though, it shouldn’t just be us working alone. | > | > Sent from my iPhone | > | >> On Sep 2, 2020, at 03:16, Joachim Breitner https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0> wrote: | >> | >> Hi, | >> | >> sounds plausible. It would also allow us to use tags to easily | indicate | >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and | >> then filter by issue to get the current list… | >> | >> But before we go there, shouldn’t we maybe have a discussion first | on | >> | >> * do we even want that? | >> * what are the abstract criteria (or guidelines)? | >> * what is the process? | >> | >> I believe that discussion could be done like any other proposal. | >> | >> | >> As for the process; when I brought up the idea, I was worried about | us | >> spending huge resources discussion individual extensions to death, | and | >> proposed, in the interest of efficiency and getting things done: | >> | >>> The process could be: Every member can nominate any number of | >>> extensions, to include, maybe a small rationale and then we do one | >>> round of independent approval voting, requiring a supermajority to | >>> really only pick uncontested extensions. | >> | >> So instead of long debates, we start with GHC2020 being just those | >> extensions that a supermajority on the committee considers to be ok. | >> | >> This is much more lightweight process that we could get done in a | week | >> or two (maybe using a doodle-like voting page). Maybe we would leave | >> out one or two extension that initially people are reserved about, | but | >> could be swayed after lengthy discussions. But is that worth the | >> lengthy discussion? | >> | >> cheers, | >> Joachim | >> | >> -- | >> Joachim Breitner | >> mail@joachim-breitner.de mailto:mail@joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0%2F&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0%7Cfa6e3a6bcdf | 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D | &reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%3D&reserved=0

I would rather make the process Committee-driven, because otherwise it may derail into too many micro-discussions. I think it's better to start a conversation saying "this is our proposal, here are our criteria, here are the exceptions we want to make", and then discuss from there. Regards, Alejandro El mar., 8 sept. 2020 a las 14:01, Eric Seidel () escribió:

I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design.

I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product?

This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed.

Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them.

Eric

Sent from my iPhone

On Sep 8, 2020, at 06:37, Simon Peyton Jones wrote:



Personally I don’t think we should make the Steering Committee responsible for initiating or driving this. We should

- establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version), - express open-ness to a proposal, and then - review proposals when/if they materialise.

It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee *responsible*.

What do others think?

Simon

*From:* Alejandro Serrano Mena *Sent:* 08 September 2020 09:13 *To:* Simon Peyton Jones *Cc:* Richard Eisenberg ; Eric Seidel ; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

Dear all,

I would really like to move this forward, and I would be happy to put some work on it.

What do you think of the following plan?

- Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.

- Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.

If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.

Regards,

Alejandro

El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee () escribió:

Just back from holiday. Some thoughts

* I don’t think this mailing list is the best place for the discussion. Basically, it's a GHC Proposal, so someone (possibly a committee member, possibly not) should write a proposal, and we should put it through the process.

* We should advertise the criteria, as Richard has done on the wiki page.

* Any such proposal should be informed by data. Notably, extension usage in Hackage, or perhaps Stackage (since it's a bit more curated).

* A proposer might also want to run a public poll, as an additional source of data

* When it comes to the committee, we can (I guess) vote on individual extensions, rather than just accept/reject the whole thing.

I am intrigued by the idea of using Kialo to coordinate discussion. Maybe it'd work better than GitHub? Are there other alternatives? But that's orthogonal to the GHC 2020 idea; let's not conflate them.

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Richard Eisenberg | Sent: 02 September 2020 14:57 | To: Eric Seidel | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | It seems clear that my wiki idea isn't winning the day -- I never | really liked it either. I'd be fine with either Eric's or Joachim's | approaches. Maybe start with Joachim's approach and then use Eric's | when Joachim's runs out of steam? A big minus, though, to Joachim's | approach is that it seems hard to get good community involvement. | | Richard | | > On Sep 2, 2020, at 8:11 AM, Eric Seidel wrote: | > | > Opening a regular discussion about whether and how we want to work on | GHC 2020 sounds fine, that will also give the community a place to | weigh in. I do think the eventual contents should be informed by the | community though, it shouldn’t just be us working alone. | > | > Sent from my iPhone | > | >> On Sep 2, 2020, at 03:16, Joachim Breitner https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0> wrote: | >> | >> Hi, | >> | >> sounds plausible. It would also allow us to use tags to easily | indicate | >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and | >> then filter by issue to get the current list… | >> | >> But before we go there, shouldn’t we maybe have a discussion first | on | >> | >> * do we even want that? | >> * what are the abstract criteria (or guidelines)? | >> * what is the process? | >> | >> I believe that discussion could be done like any other proposal. | >> | >> | >> As for the process; when I brought up the idea, I was worried about | us | >> spending huge resources discussion individual extensions to death, | and | >> proposed, in the interest of efficiency and getting things done: | >> | >>> The process could be: Every member can nominate any number of | >>> extensions, to include, maybe a small rationale and then we do one | >>> round of independent approval voting, requiring a supermajority to | >>> really only pick uncontested extensions. | >> | >> So instead of long debates, we start with GHC2020 being just those | >> extensions that a supermajority on the committee considers to be ok. | >> | >> This is much more lightweight process that we could get done in a | week | >> or two (maybe using a doodle-like voting page). Maybe we would leave | >> out one or two extension that initially people are reserved about, | but | >> could be swayed after lengthy discussions. But is that worth the | >> lengthy discussion? | >> | >> cheers, | >> Joachim | >> | >> -- | >> Joachim Breitner | >> mail@joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0 %2F&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0 %7Cfa6e3a6bcdf | 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D | &reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I think there should be some requirement that an extension be widely-used (for some suitable definition of that), before we ratify it in GHC2020. Some of the extensions that made it past the first round of filtering are not widely-used, and would be therefore probably be controversial additions to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo to name a few that I noticed straight off. I think it's a good idea to be conservative here. Cheers Simon On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud wrote:

There seems to be some question about who should drive this debate. But there is something we all seem to agree on: it is our role, as the steering committee, to announce the criteria by which we intend to judge the reasonableness of each potential candidate extension.

So, let me suggest that we start discussing that, and move back to how this discussion ought to be driven when we are a bit clearer on the criteria.

Richard wrote a bunch of criteria in the wiki page upthread [1]. I think that they are worthy of discussion. So let me ask the question: do we agree with all these criteria? do we want to add more?

[1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020

On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena wrote:

...

I would rather make the process Committee-driven, because otherwise it may derail into too many micro-discussions. I think it's better to start a conversation saying "this is our proposal, here are our criteria, here are the exceptions we want to make", and then discuss from there.

Regards, Alejandro

El mar., 8 sept. 2020 a las 14:01, Eric Seidel () escribió:

...

I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design.

I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product?

This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed.

Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them.

Eric

Sent from my iPhone

On Sep 8, 2020, at 06:37, Simon Peyton Jones wrote:



Personally I don’t think we should make the Steering Committee responsible for initiating or driving this. We should

- establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version), - express open-ness to a proposal, and then - review proposals when/if they materialise.

It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee *responsible*.

What do others think?

Simon

*From:* Alejandro Serrano Mena *Sent:* 08 September 2020 09:13 *To:* Simon Peyton Jones *Cc:* Richard Eisenberg ; Eric Seidel ; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

Dear all,

I would really like to move this forward, and I would be happy to put some work on it.

What do you think of the following plan?

- Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.

- Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.

If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.

Regards,

Alejandro

El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee () escribió:

Just back from holiday. Some thoughts

* I don’t think this mailing list is the best place for the discussion. Basically, it's a GHC Proposal, so someone (possibly a committee member, possibly not) should write a proposal, and we should put it through the process.

* We should advertise the criteria, as Richard has done on the wiki page.

* Any such proposal should be informed by data. Notably, extension usage in Hackage, or perhaps Stackage (since it's a bit more curated).

* A proposer might also want to run a public poll, as an additional source of data

* When it comes to the committee, we can (I guess) vote on individual extensions, rather than just accept/reject the whole thing.

I am intrigued by the idea of using Kialo to coordinate discussion. Maybe it'd work better than GitHub? Are there other alternatives? But that's orthogonal to the GHC 2020 idea; let's not conflate them.

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Richard Eisenberg | Sent: 02 September 2020 14:57 | To: Eric Seidel | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | It seems clear that my wiki idea isn't winning the day -- I never | really liked it either. I'd be fine with either Eric's or Joachim's | approaches. Maybe start with Joachim's approach and then use Eric's | when Joachim's runs out of steam? A big minus, though, to Joachim's | approach is that it seems hard to get good community involvement. | | Richard | | > On Sep 2, 2020, at 8:11 AM, Eric Seidel wrote: | > | > Opening a regular discussion about whether and how we want to work on | GHC 2020 sounds fine, that will also give the community a place to | weigh in. I do think the eventual contents should be informed by the | community though, it shouldn’t just be us working alone. | > | > Sent from my iPhone | > | >> On Sep 2, 2020, at 03:16, Joachim Breitner https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0> wrote: | >> | >> Hi, | >> | >> sounds plausible. It would also allow us to use tags to easily | indicate | >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and | >> then filter by issue to get the current list… | >> | >> But before we go there, shouldn’t we maybe have a discussion first | on | >> | >> * do we even want that? | >> * what are the abstract criteria (or guidelines)? | >> * what is the process? | >> | >> I believe that discussion could be done like any other proposal. | >> | >> | >> As for the process; when I brought up the idea, I was worried about | us | >> spending huge resources discussion individual extensions to death, | and | >> proposed, in the interest of efficiency and getting things done: | >> | >>> The process could be: Every member can nominate any number of | >>> extensions, to include, maybe a small rationale and then we do one | >>> round of independent approval voting, requiring a supermajority to | >>> really only pick uncontested extensions. | >> | >> So instead of long debates, we start with GHC2020 being just those | >> extensions that a supermajority on the committee considers to be ok. | >> | >> This is much more lightweight process that we could get done in a | week | >> or two (maybe using a doodle-like voting page). Maybe we would leave | >> out one or two extension that initially people are reserved about, | but | >> could be swayed after lengthy discussions. But is that worth the | >> lengthy discussion? | >> | >> cheers, | >> Joachim | >> | >> -- | >> Joachim Breitner | >> mail@joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0 %2F&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0 %7Cfa6e3a6bcdf | 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D | &reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

What's the status of this push? I was delighted to see that Alejandro volunteered to be a motive force on this idea, and have thus refrained (as I am pushing on other ideas, too). But I also don't want this to die. :) Thanks! Richard

On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena wrote:

I agree with using the criteria that Richard posted + the addition by Simon. Just in case somebody hadn't looked at the wiki, the criteria would be: The extension is (mostly) conservative: All programs that were accepted without the extension remain accepted, and with the same meaning.

New failure modes that become possible with the extension are rare and/or easy to diagnose. (These failure modes include new error messages, wrong inferred types, and runtime errors, for example.)

The extensions complement the design of standard Haskell. (This one seems the most subjective.)

The extension has been -- and can reasonably be predicted to remain -- stable.

The extension is not to gate-keep an advanced or potentially-unsafe feature.

The extension is widely-used. For example, should we add to (6) "in current developments"? What about things like "EmptyDataDecls", which are just straightforward generalizations of what Haskell 2010 already allows, although in practice the only data type you would ever need to be empty is "Void"?

Alejandro

El jue., 17 sept. 2020 a las 16:42, Simon Marlow (mailto:marlowsd@gmail.com>) escribió: I think there should be some requirement that an extension be widely-used (for some suitable definition of that), before we ratify it in GHC2020. Some of the extensions that made it past the first round of filtering are not widely-used, and would be therefore probably be controversial additions to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo to name a few that I noticed straight off. I think it's a good idea to be conservative here.

Cheers Simon

On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> wrote: There seems to be some question about who should drive this debate. But there is something we all seem to agree on: it is our role, as the steering committee, to announce the criteria by which we intend to judge the reasonableness of each potential candidate extension.

So, let me suggest that we start discussing that, and move back to how this discussion ought to be driven when we are a bit clearer on the criteria.

Richard wrote a bunch of criteria in the wiki page upthread [1]. I think that they are worthy of discussion. So let me ask the question: do we agree with all these criteria? do we want to add more?

[1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena mailto:trupill@gmail.com> wrote: I would rather make the process Committee-driven, because otherwise it may derail into too many micro-discussions. I think it's better to start a conversation saying "this is our proposal, here are our criteria, here are the exceptions we want to make", and then discuss from there.

Regards, Alejandro

El mar., 8 sept. 2020 a las 14:01, Eric Seidel (mailto:eric@seidel.io>) escribió: I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design.

I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product?

This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed.

Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them.

Eric

Sent from my iPhone

...

On Sep 8, 2020, at 06:37, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote:

 Personally I don’t think we should make the Steering Committee responsible for initiating or driving this. We should

establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version), express open-ness to a proposal, and then review proposals when/if they materialise.

It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee responsible.

What do others think?

Simon

From: Alejandro Serrano Mena mailto:trupill@gmail.com> Sent: 08 September 2020 09:13 To: Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: Richard Eisenberg mailto:rae@richarde.dev>; Eric Seidel mailto:eric@seidel.io>; ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] GHC 2020

Dear all,

I would really like to move this forward, and I would be happy to put some work on it.

What do you think of the following plan?

- Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.

- Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.

If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.

Regards,

Alejandro

El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee (mailto:ghc-steering-committee@haskell.org>) escribió:

Just back from holiday. Some thoughts

* I don’t think this mailing list is the best place for the discussion. Basically, it's a GHC Proposal, so someone (possibly a committee member, possibly not) should write a proposal, and we should put it through the process.

* We should advertise the criteria, as Richard has done on the wiki page.

* Any such proposal should be informed by data. Notably, extension usage in Hackage, or perhaps Stackage (since it's a bit more curated).

* A proposer might also want to run a public poll, as an additional source of data

* When it comes to the committee, we can (I guess) vote on individual extensions, rather than just accept/reject the whole thing.

I am intrigued by the idea of using Kialo to coordinate discussion. Maybe it'd work better than GitHub? Are there other alternatives? But that's orthogonal to the GHC 2020 idea; let's not conflate them.

Simon

| -----Original Message----- | From: ghc-steering-committee mailto:bounces@haskell.org> On Behalf Of Richard Eisenberg | Sent: 02 September 2020 14:57 | To: Eric Seidel mailto:eric@seidel.io> | Cc: ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | It seems clear that my wiki idea isn't winning the day -- I never | really liked it either. I'd be fine with either Eric's or Joachim's | approaches. Maybe start with Joachim's approach and then use Eric's | when Joachim's runs out of steam? A big minus, though, to Joachim's | approach is that it seems hard to get good community involvement. | | Richard | | > On Sep 2, 2020, at 8:11 AM, Eric Seidel mailto:eric@seidel.io> wrote: | > | > Opening a regular discussion about whether and how we want to work on | GHC 2020 sounds fine, that will also give the community a place to | weigh in. I do think the eventual contents should be informed by the | community though, it shouldn’t just be us working alone. | > | > Sent from my iPhone | > | >> On Sep 2, 2020, at 03:16, Joachim Breitner https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0> wrote: | >> | >> Hi, | >> | >> sounds plausible. It would also allow us to use tags to easily | indicate | >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and | >> then filter by issue to get the current list… | >> | >> But before we go there, shouldn’t we maybe have a discussion first | on | >> | >> * do we even want that? | >> * what are the abstract criteria (or guidelines)? | >> * what is the process? | >> | >> I believe that discussion could be done like any other proposal. | >> | >> | >> As for the process; when I brought up the idea, I was worried about | us | >> spending huge resources discussion individual extensions to death, | and | >> proposed, in the interest of efficiency and getting things done: | >> | >>> The process could be: Every member can nominate any number of | >>> extensions, to include, maybe a small rationale and then we do one | >>> round of independent approval voting, requiring a supermajority to | >>> really only pick uncontested extensions. | >> | >> So instead of long debates, we start with GHC2020 being just those | >> extensions that a supermajority on the committee considers to be ok. | >> | >> This is much more lightweight process that we could get done in a | week | >> or two (maybe using a doodle-like voting page). Maybe we would leave | >> out one or two extension that initially people are reserved about, | but | >> could be swayed after lengthy discussions. But is that worth the | >> lengthy discussion? | >> | >> cheers, | >> Joachim | >> | >> -- | >> Joachim Breitner | >> mail@joachim-breitner.de mailto:mail@joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0%2F&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0%7Cfa6e3a6bcdf | 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D | &reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%3D&reserved=0_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

OK by me. Thank you Simon From: ghc-steering-committee On Behalf Of Alejandro Serrano Mena Sent: 29 September 2020 15:51 To: Richard Eisenberg Cc: ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] GHC 2020 I am still happy to drive this! I was not sure about whether we agreed as a Committee on pushing this. To make this more actionable, my goal is, during next Sunday, to create a new proposal with the criteria (based on Richard + Simon's list), and a preliminary assessment of which of the current extensions satisfy these criteria, and for those we might be willing to grant exceptions. Please raise your voice if you think we should proceed otherwise (or if you think we should not proceed at all!). Regards, Alejandro El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg (mailto:rae@richarde.dev>) escribió: What's the status of this push? I was delighted to see that Alejandro volunteered to be a motive force on this idea, and have thus refrained (as I am pushing on other ideas, too). But I also don't want this to die. :) Thanks! Richard On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena mailto:trupill@gmail.com> wrote: I agree with using the criteria that Richard posted + the addition by Simon. Just in case somebody hadn't looked at the wiki, the criteria would be: 1. The extension is (mostly) conservative: All programs that were accepted without the extension remain accepted, and with the same meaning. 2. New failure modes that become possible with the extension are rare and/or easy to diagnose. (These failure modes include new error messages, wrong inferred types, and runtime errors, for example.) 3. The extensions complement the design of standard Haskell. (This one seems the most subjective.) 4. The extension has been -- and can reasonably be predicted to remain -- stable. 5. The extension is not to gate-keep an advanced or potentially-unsafe feature. 6. The extension is widely-used. For example, should we add to (6) "in current developments"? What about things like "EmptyDataDecls", which are just straightforward generalizations of what Haskell 2010 already allows, although in practice the only data type you would ever need to be empty is "Void"? Alejandro El jue., 17 sept. 2020 a las 16:42, Simon Marlow (mailto:marlowsd@gmail.com>) escribió: I think there should be some requirement that an extension be widely-used (for some suitable definition of that), before we ratify it in GHC2020. Some of the extensions that made it past the first round of filtering are not widely-used, and would be therefore probably be controversial additions to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo to name a few that I noticed straight off. I think it's a good idea to be conservative here. Cheers Simon On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> wrote: There seems to be some question about who should drive this debate. But there is something we all seem to agree on: it is our role, as the steering committee, to announce the criteria by which we intend to judge the reasonableness of each potential candidate extension. So, let me suggest that we start discussing that, and move back to how this discussion ought to be driven when we are a bit clearer on the criteria. Richard wrote a bunch of criteria in the wiki page upthread [1]. I think that they are worthy of discussion. So let me ask the question: do we agree with all these criteria? do we want to add more? [1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634558661&sdata=8ZlvyXrW6%2Bj2GdlPu6pIOOfbrV%2FdtLNdi8LyaTewKZA%3D&reserved=0 On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena mailto:trupill@gmail.com> wrote: I would rather make the process Committee-driven, because otherwise it may derail into too many micro-discussions. I think it's better to start a conversation saying "this is our proposal, here are our criteria, here are the exceptions we want to make", and then discuss from there. Regards, Alejandro El mar., 8 sept. 2020 a las 14:01, Eric Seidel (mailto:eric@seidel.io>) escribió: I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design. I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product? This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed. Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them. Eric Sent from my iPhone On Sep 8, 2020, at 06:37, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote:  Personally I don’t think we should make the Steering Committee responsible for initiating or driving this. We should · establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version), · express open-ness to a proposal, and then · review proposals when/if they materialise. It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee responsible. What do others think? Simon From: Alejandro Serrano Mena mailto:trupill@gmail.com> Sent: 08 September 2020 09:13 To: Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: Richard Eisenberg mailto:rae@richarde.dev>; Eric Seidel mailto:eric@seidel.io>; ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] GHC 2020 Dear all, I would really like to move this forward, and I would be happy to put some work on it. What do you think of the following plan? - Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible. - Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria. If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions. Regards, Alejandro El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee (mailto:ghc-steering-committee@haskell.org>) escribió: Just back from holiday. Some thoughts * I don’t think this mailing list is the best place for the discussion. Basically, it's a GHC Proposal, so someone (possibly a committee member, possibly not) should write a proposal, and we should put it through the process. * We should advertise the criteria, as Richard has done on the wiki page. * Any such proposal should be informed by data. Notably, extension usage in Hackage, or perhaps Stackage (since it's a bit more curated). * A proposer might also want to run a public poll, as an additional source of data * When it comes to the committee, we can (I guess) vote on individual extensions, rather than just accept/reject the whole thing. I am intrigued by the idea of using Kialo to coordinate discussion. Maybe it'd work better than GitHub? Are there other alternatives? But that's orthogonal to the GHC 2020 idea; let's not conflate them. Simon | -----Original Message----- | From: ghc-steering-committee mailto:bounces@haskell.org> On Behalf Of Richard Eisenberg | Sent: 02 September 2020 14:57 | To: Eric Seidel mailto:eric@seidel.io> | Cc: ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | It seems clear that my wiki idea isn't winning the day -- I never | really liked it either. I'd be fine with either Eric's or Joachim's | approaches. Maybe start with Joachim's approach and then use Eric's | when Joachim's runs out of steam? A big minus, though, to Joachim's | approach is that it seems hard to get good community involvement. | | Richard | | > On Sep 2, 2020, at 8:11 AM, Eric Seidel mailto:eric@seidel.io> wrote: | > | > Opening a regular discussion about whether and how we want to work on | GHC 2020 sounds fine, that will also give the community a place to | weigh in. I do think the eventual contents should be informed by the | community though, it shouldn’t just be us working alone. | > | > Sent from my iPhone | > | >> On Sep 2, 2020, at 03:16, Joachim Breitner https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0> wrote: | >> | >> Hi, | >> | >> sounds plausible. It would also allow us to use tags to easily | indicate | >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and | >> then filter by issue to get the current list… | >> | >> But before we go there, shouldn’t we maybe have a discussion first | on | >> | >> * do we even want that? | >> * what are the abstract criteria (or guidelines)? | >> * what is the process? | >> | >> I believe that discussion could be done like any other proposal. | >> | >> | >> As for the process; when I brought up the idea, I was worried about | us | >> spending huge resources discussion individual extensions to death, | and | >> proposed, in the interest of efficiency and getting things done: | >> | >>> The process could be: Every member can nominate any number of | >>> extensions, to include, maybe a small rationale and then we do one | >>> round of independent approval voting, requiring a supermajority to | >>> really only pick uncontested extensions. | >> | >> So instead of long debates, we start with GHC2020 being just those | >> extensions that a supermajority on the committee considers to be ok. | >> | >> This is much more lightweight process that we could get done in a | week | >> or two (maybe using a doodle-like voting page). Maybe we would leave | >> out one or two extension that initially people are reserved about, | but | >> could be swayed after lengthy discussions. But is that worth the | >> lengthy discussion? | >> | >> cheers, | >> Joachim | >> | >> -- | >> Joachim Breitner | >> mail@joachim-breitner.demailto:mail@joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.dehttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0%2F&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=yhLtqXE3QsviB6UGtcJmag7Hp1MMBc7YzV0NgOUL6io%3D&reserved=0%7Cfa6e3a6bcdf | 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D | &reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=3ksDaGjTZCq%2BE2tBzPqrjoQ9LQ3ikh3RUNgZsaAe9B4%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=Q89KmMJ87VLBBWVdemnhkZSEPtLvt6K8mp5ZNFihrnQ%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=smlu8yLG%2FwgNoYFMv%2F3QnyHhqDMSvOjZk5e%2FtxLznKc%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634598642&sdata=mhXHnOFn4tKiYZy6h5WkpnGm4Hk5KFiDZYnUAdk5oZo%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=vyTjG7qSxDYx1SiUjMLoIcbGlZA0IWD%2B7cbqKDW0Rhs%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=MBlt7msCwwJRG6UAowr8NcARtLSO2rWiDdqF3lmSzjg%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%3D&reserved=0

Dear all, I've started working on a proposal for GHC2020. You can see the current status here: https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-202... I noticed the list by Richard was not exhaustive. Those extensions are headed by "In discussion". Preferably we should make up our minds before presenting the proposal. I would say there are three big groups of proposals. Any feedback is welcome on that part. Regards, Alejandrp El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (< iavor.diatchki@gmail.com>) escribió:

Thanks Alejandro. My preference would be that you share whatever you come up with the list so we can discuss it, before making a proposal that would represent the committee. -Iavor

On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via ghc-steering-committee wrote:

...

OK by me. Thank you

Simon

*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 29 September 2020 15:51 *To:* Richard Eisenberg *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

I am still happy to drive this! I was not sure about whether we agreed as a Committee on pushing this.

To make this more actionable, my goal is, *during next Sunday*, to create a new proposal with the *criteria* (based on Richard + Simon's list), and a preliminary assessment of which of the *current extensions* satisfy these criteria, and for those we might be willing to grant *exceptions*.

Please raise your voice if you think we should proceed otherwise (or if you think we should not proceed at all!).

Regards,

Alejandro

El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg () escribió:

What's the status of this push? I was delighted to see that Alejandro volunteered to be a motive force on this idea, and have thus refrained (as I am pushing on other ideas, too). But I also don't want this to die. :)

Thanks!

Richard

On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena wrote:

I agree with using the criteria that Richard posted + the addition by Simon. Just in case somebody hadn't looked at the wiki, the criteria would be:

1. The extension is (mostly) conservative: All programs that were accepted without the extension remain accepted, and with the same meaning. 2. New failure modes that become possible with the extension are rare and/or easy to diagnose. (These failure modes include new error messages, wrong inferred types, and runtime errors, for example.) 3. The extensions complement the design of standard Haskell. (This one seems the most subjective.) 4. The extension has been -- and can reasonably be predicted to remain -- stable. 5. The extension is not to gate-keep an advanced or potentially-unsafe feature. 6. The extension is widely-used.

For example, should we add to (6) "in current developments"? What about things like "EmptyDataDecls", which are just straightforward generalizations of what Haskell 2010 already allows, although in practice the only data type you would ever need to be empty is "Void"?

Alejandro

El jue., 17 sept. 2020 a las 16:42, Simon Marlow () escribió:

I think there should be some requirement that an extension be widely-used (for some suitable definition of that), before we ratify it in GHC2020. Some of the extensions that made it past the first round of filtering are not widely-used, and would be therefore probably be controversial additions to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo to name a few that I noticed straight off. I think it's a good idea to be conservative here.

Cheers

Simon

On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud wrote:

There seems to be some question about who should drive this debate. But there is something we all seem to agree on: it is our role, as the steering committee, to announce the criteria by which we intend to judge the reasonableness of each potential candidate extension.

So, let me suggest that we start discussing that, and move back to how this discussion ought to be driven when we are a bit clearer on the criteria.

Richard wrote a bunch of criteria in the wiki page upthread [1]. I think that they are worthy of discussion. So let me ask the question: do we agree with all these criteria? do we want to add more?

[1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634558661&sdata=8ZlvyXrW6%2Bj2GdlPu6pIOOfbrV%2FdtLNdi8LyaTewKZA%3D&reserved=0

On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena wrote:

I would rather make the process Committee-driven, because otherwise it may derail into too many micro-discussions. I think it's better to start a conversation saying "this is our proposal, here are our criteria, here are the exceptions we want to make", and then discuss from there.

Regards,

Alejandro

El mar., 8 sept. 2020 a las 14:01, Eric Seidel () escribió:

I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design.

I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product?

This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed.

Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them.

Eric

Sent from my iPhone

On Sep 8, 2020, at 06:37, Simon Peyton Jones wrote:



Personally I don’t think we should make the Steering Committee responsible for initiating or driving this. We should

· establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version),

· express open-ness to a proposal, and then

· review proposals when/if they materialise.

It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee *responsible*.

What do others think?

Simon

*From:* Alejandro Serrano Mena *Sent:* 08 September 2020 09:13 *To:* Simon Peyton Jones *Cc:* Richard Eisenberg ; Eric Seidel ; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

Dear all,

I would really like to move this forward, and I would be happy to put some work on it.

What do you think of the following plan?

- Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.

- Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.

If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.

Regards,

Alejandro

El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee () escribió:

Just back from holiday. Some thoughts

* I don’t think this mailing list is the best place for the discussion. Basically, it's a GHC Proposal, so someone (possibly a committee member, possibly not) should write a proposal, and we should put it through the process.

* We should advertise the criteria, as Richard has done on the wiki page.

* Any such proposal should be informed by data. Notably, extension usage in Hackage, or perhaps Stackage (since it's a bit more curated).

* A proposer might also want to run a public poll, as an additional source of data

* When it comes to the committee, we can (I guess) vote on individual extensions, rather than just accept/reject the whole thing.

I am intrigued by the idea of using Kialo to coordinate discussion. Maybe it'd work better than GitHub? Are there other alternatives? But that's orthogonal to the GHC 2020 idea; let's not conflate them.

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Richard Eisenberg | Sent: 02 September 2020 14:57 | To: Eric Seidel | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | It seems clear that my wiki idea isn't winning the day -- I never | really liked it either. I'd be fine with either Eric's or Joachim's | approaches. Maybe start with Joachim's approach and then use Eric's | when Joachim's runs out of steam? A big minus, though, to Joachim's | approach is that it seems hard to get good community involvement. | | Richard | | > On Sep 2, 2020, at 8:11 AM, Eric Seidel wrote: | > | > Opening a regular discussion about whether and how we want to work on | GHC 2020 sounds fine, that will also give the community a place to | weigh in. I do think the eventual contents should be informed by the | community though, it shouldn’t just be us working alone. | > | > Sent from my iPhone | > | >> On Sep 2, 2020, at 03:16, Joachim Breitner https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0> wrote: | >> | >> Hi, | >> | >> sounds plausible. It would also allow us to use tags to easily | indicate | >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and | >> then filter by issue to get the current list… | >> | >> But before we go there, shouldn’t we maybe have a discussion first | on | >> | >> * do we even want that? | >> * what are the abstract criteria (or guidelines)? | >> * what is the process? | >> | >> I believe that discussion could be done like any other proposal. | >> | >> | >> As for the process; when I brought up the idea, I was worried about | us | >> spending huge resources discussion individual extensions to death, | and | >> proposed, in the interest of efficiency and getting things done: | >> | >>> The process could be: Every member can nominate any number of | >>> extensions, to include, maybe a small rationale and then we do one | >>> round of independent approval voting, requiring a supermajority to | >>> really only pick uncontested extensions. | >> | >> So instead of long debates, we start with GHC2020 being just those | >> extensions that a supermajority on the committee considers to be ok. | >> | >> This is much more lightweight process that we could get done in a | week | >> or two (maybe using a doodle-like voting page). Maybe we would leave | >> out one or two extension that initially people are reserved about, | but | >> could be swayed after lengthy discussions. But is that worth the | >> lengthy discussion? | >> | >> cheers, | >> Joachim | >> | >> -- | >> Joachim Breitner | >> mail@joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0 %2F&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=yhLtqXE3QsviB6UGtcJmag7Hp1MMBc7YzV0NgOUL6io%3D&reserved=0 %7Cfa6e3a6bcdf | 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D | &reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail . | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=3ksDaGjTZCq%2BE2tBzPqrjoQ9LQ3ikh3RUNgZsaAe9B4%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=Q89KmMJ87VLBBWVdemnhkZSEPtLvt6K8mp5ZNFihrnQ%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail . | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=smlu8yLG%2FwgNoYFMv%2F3QnyHhqDMSvOjZk5e%2FtxLznKc%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634598642&sdata=mhXHnOFn4tKiYZy6h5WkpnGm4Hk5KFiDZYnUAdk5oZo%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail . | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=vyTjG7qSxDYx1SiUjMLoIcbGlZA0IWD%2B7cbqKDW0Rhs%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=MBlt7msCwwJRG6UAowr8NcARtLSO2rWiDdqF3lmSzjg%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I've made a decision about a few more extensions, but there are still 8 where I would really like some help: - MagicHash: is this simply an extension or it may break code which parses "a# b" as "a # b"? - PartialTypeSignatures and its accompanying NamedWildCards: maybe this should be seen more as a programmer's aid? - PackageImports: never used it, never heard of anybody using it, so I would say it fails criteria 6 (widespread usage) - PostfixOperators: a deviation from the Report - QuantifiedConstraints, RoleAnnotations: are these stable enough to be included. I could foresee _extending_ its language, but not having to break what's already there. But maybe they fail the widespread usage criterion? - RecordWildCards: there was some discussion in the wiki, about possible shadowing problems. As it stands now, I foresee most of the discussion on: - should GHC embrace its type level machinery? the current proposal does, since it includes DataKinds, TypeFamilies, and so forth. - should OverloadedLists and OverloadedStrings be part of GHC2020? - particular choices like LambdaCase (in), BlockArguments (out), TupleSections (out). But that's exactly what the proposal process is for! Regards, Alejandro El mié., 30 sept. 2020 a las 22:12, Alejandro Serrano Mena (< trupill@gmail.com>) escribió:

Of course, I could also write some proposal, and then we can use the usual PR mechanism to discuss it.

Alejandro

El mié., 30 sept. 2020 a las 22:06, Alejandro Serrano Mena (< trupill@gmail.com>) escribió:

...

Dear all, I've started working on a proposal for GHC2020. You can see the current status here: https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-202...

I noticed the list by Richard was not exhaustive. Those extensions are headed by "In discussion". Preferably we should make up our minds before presenting the proposal. I would say there are three big groups of proposals. Any feedback is welcome on that part.

Regards, Alejandrp

El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (< iavor.diatchki@gmail.com>) escribió:

...

Thanks Alejandro. My preference would be that you share whatever you come up with the list so we can discuss it, before making a proposal that would represent the committee. -Iavor

On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via ghc-steering-committee wrote:

...

OK by me. Thank you

Simon

*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 29 September 2020 15:51 *To:* Richard Eisenberg *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

I am still happy to drive this! I was not sure about whether we agreed as a Committee on pushing this.

To make this more actionable, my goal is, *during next Sunday*, to create a new proposal with the *criteria* (based on Richard + Simon's list), and a preliminary assessment of which of the *current extensions* satisfy these criteria, and for those we might be willing to grant *exceptions*.

Please raise your voice if you think we should proceed otherwise (or if you think we should not proceed at all!).

Regards,

Alejandro

El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg (< rae@richarde.dev>) escribió:

What's the status of this push? I was delighted to see that Alejandro volunteered to be a motive force on this idea, and have thus refrained (as I am pushing on other ideas, too). But I also don't want this to die. :)

Thanks!

Richard

On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena wrote:

I agree with using the criteria that Richard posted + the addition by Simon. Just in case somebody hadn't looked at the wiki, the criteria would be:

1. The extension is (mostly) conservative: All programs that were accepted without the extension remain accepted, and with the same meaning. 2. New failure modes that become possible with the extension are rare and/or easy to diagnose. (These failure modes include new error messages, wrong inferred types, and runtime errors, for example.) 3. The extensions complement the design of standard Haskell. (This one seems the most subjective.) 4. The extension has been -- and can reasonably be predicted to remain -- stable. 5. The extension is not to gate-keep an advanced or potentially-unsafe feature. 6. The extension is widely-used.

For example, should we add to (6) "in current developments"? What about things like "EmptyDataDecls", which are just straightforward generalizations of what Haskell 2010 already allows, although in practice the only data type you would ever need to be empty is "Void"?

Alejandro

El jue., 17 sept. 2020 a las 16:42, Simon Marlow () escribió:

I think there should be some requirement that an extension be widely-used (for some suitable definition of that), before we ratify it in GHC2020. Some of the extensions that made it past the first round of filtering are not widely-used, and would be therefore probably be controversial additions to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo to name a few that I noticed straight off. I think it's a good idea to be conservative here.

Cheers

Simon

On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud wrote:

There seems to be some question about who should drive this debate. But there is something we all seem to agree on: it is our role, as the steering committee, to announce the criteria by which we intend to judge the reasonableness of each potential candidate extension.

So, let me suggest that we start discussing that, and move back to how this discussion ought to be driven when we are a bit clearer on the criteria.

Richard wrote a bunch of criteria in the wiki page upthread [1]. I think that they are worthy of discussion. So let me ask the question: do we agree with all these criteria? do we want to add more?

[1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634558661&sdata=8ZlvyXrW6%2Bj2GdlPu6pIOOfbrV%2FdtLNdi8LyaTewKZA%3D&reserved=0

On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena < trupill@gmail.com> wrote:

I would rather make the process Committee-driven, because otherwise it may derail into too many micro-discussions. I think it's better to start a conversation saying "this is our proposal, here are our criteria, here are the exceptions we want to make", and then discuss from there.

Regards,

Alejandro

El mar., 8 sept. 2020 a las 14:01, Eric Seidel () escribió:

I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design.

I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product?

This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed.

Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them.

Eric

Sent from my iPhone

On Sep 8, 2020, at 06:37, Simon Peyton Jones wrote:



Personally I don’t think we should make the Steering Committee responsible for initiating or driving this. We should

· establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version),

· express open-ness to a proposal, and then

· review proposals when/if they materialise.

It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee *responsible*.

What do others think?

Simon

*From:* Alejandro Serrano Mena *Sent:* 08 September 2020 09:13 *To:* Simon Peyton Jones *Cc:* Richard Eisenberg ; Eric Seidel ; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

Dear all,

I would really like to move this forward, and I would be happy to put some work on it.

What do you think of the following plan?

- Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.

- Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.

If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.

Regards,

Alejandro

El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee () escribió:

Just back from holiday. Some thoughts

* I don’t think this mailing list is the best place for the discussion. Basically, it's a GHC Proposal, so someone (possibly a committee member, possibly not) should write a proposal, and we should put it through the process.

* We should advertise the criteria, as Richard has done on the wiki page.

* Any such proposal should be informed by data. Notably, extension usage in Hackage, or perhaps Stackage (since it's a bit more curated).

* A proposer might also want to run a public poll, as an additional source of data

* When it comes to the committee, we can (I guess) vote on individual extensions, rather than just accept/reject the whole thing.

I am intrigued by the idea of using Kialo to coordinate discussion. Maybe it'd work better than GitHub? Are there other alternatives? But that's orthogonal to the GHC 2020 idea; let's not conflate them.

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Richard Eisenberg | Sent: 02 September 2020 14:57 | To: Eric Seidel | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | It seems clear that my wiki idea isn't winning the day -- I never | really liked it either. I'd be fine with either Eric's or Joachim's | approaches. Maybe start with Joachim's approach and then use Eric's | when Joachim's runs out of steam? A big minus, though, to Joachim's | approach is that it seems hard to get good community involvement. | | Richard | | > On Sep 2, 2020, at 8:11 AM, Eric Seidel wrote: | > | > Opening a regular discussion about whether and how we want to work on | GHC 2020 sounds fine, that will also give the community a place to | weigh in. I do think the eventual contents should be informed by the | community though, it shouldn’t just be us working alone. | > | > Sent from my iPhone | > | >> On Sep 2, 2020, at 03:16, Joachim Breitner https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0> wrote: | >> | >> Hi, | >> | >> sounds plausible. It would also allow us to use tags to easily | indicate | >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and | >> then filter by issue to get the current list… | >> | >> But before we go there, shouldn’t we maybe have a discussion first | on | >> | >> * do we even want that? | >> * what are the abstract criteria (or guidelines)? | >> * what is the process? | >> | >> I believe that discussion could be done like any other proposal. | >> | >> | >> As for the process; when I brought up the idea, I was worried about | us | >> spending huge resources discussion individual extensions to death, | and | >> proposed, in the interest of efficiency and getting things done: | >> | >>> The process could be: Every member can nominate any number of | >>> extensions, to include, maybe a small rationale and then we do one | >>> round of independent approval voting, requiring a supermajority to | >>> really only pick uncontested extensions. | >> | >> So instead of long debates, we start with GHC2020 being just those | >> extensions that a supermajority on the committee considers to be ok. | >> | >> This is much more lightweight process that we could get done in a | week | >> or two (maybe using a doodle-like voting page). Maybe we would leave | >> out one or two extension that initially people are reserved about, | but | >> could be swayed after lengthy discussions. But is that worth the | >> lengthy discussion? | >> | >> cheers, | >> Joachim | >> | >> -- | >> Joachim Breitner | >> mail@joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0 %2F&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=yhLtqXE3QsviB6UGtcJmag7Hp1MMBc7YzV0NgOUL6io%3D&reserved=0 %7Cfa6e3a6bcdf | 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D | &reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=3ksDaGjTZCq%2BE2tBzPqrjoQ9LQ3ikh3RUNgZsaAe9B4%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=Q89KmMJ87VLBBWVdemnhkZSEPtLvt6K8mp5ZNFihrnQ%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=smlu8yLG%2FwgNoYFMv%2F3QnyHhqDMSvOjZk5e%2FtxLznKc%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634598642&sdata=mhXHnOFn4tKiYZy6h5WkpnGm4Hk5KFiDZYnUAdk5oZo%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=vyTjG7qSxDYx1SiUjMLoIcbGlZA0IWD%2B7cbqKDW0Rhs%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=MBlt7msCwwJRG6UAowr8NcARtLSO2rWiDdqF3lmSzjg%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Thanks Alejandro. How do you want feedback? The “discussed at this PR” link is broken. I think the criteria could be tightened up quite a bit. * I don’t know what “The extensions complement the design of standard Haskell” means. What would be an example of something that doesn’t complement it? * I don’t know what “The extension is not to gate-keep an advanced or potentially-unsafe feature” means. * Item (1), conservative extension, is a bit ambiguous. Is says “Mostly” but then “all programs”. Which is your intent? * What is a “new failure mode”? Do you mean existing programs that fail when the extension is on? Or new programs that are trying to use the new extension but get it wrong? For the latter it’s hard to see how they’d be rare. Simon From: Alejandro Serrano Mena Sent: 30 September 2020 21:06 To: Iavor Diatchki Cc: Simon Peyton Jones ; Richard Eisenberg ; ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] GHC 2020 Dear all, I've started working on a proposal for GHC2020. You can see the current status here: https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-202...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-ghc-2020.md&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042159563&sdata=YwM0vlfkVllsb4lwCRydeodKqs4mAbmBnYAss7jnrXA%3D&reserved=0 I noticed the list by Richard was not exhaustive. Those extensions are headed by "In discussion". Preferably we should make up our minds before presenting the proposal. I would say there are three big groups of proposals. Any feedback is welcome on that part. Regards, Alejandrp El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (mailto:iavor.diatchki@gmail.com>) escribió: Thanks Alejandro. My preference would be that you share whatever you come up with the list so we can discuss it, before making a proposal that would represent the committee. -Iavor On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote: OK by me. Thank you Simon From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Alejandro Serrano Mena Sent: 29 September 2020 15:51 To: Richard Eisenberg mailto:rae@richarde.dev> Cc: ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] GHC 2020 I am still happy to drive this! I was not sure about whether we agreed as a Committee on pushing this. To make this more actionable, my goal is, during next Sunday, to create a new proposal with the criteria (based on Richard + Simon's list), and a preliminary assessment of which of the current extensions satisfy these criteria, and for those we might be willing to grant exceptions. Please raise your voice if you think we should proceed otherwise (or if you think we should not proceed at all!). Regards, Alejandro El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg (mailto:rae@richarde.dev>) escribió: What's the status of this push? I was delighted to see that Alejandro volunteered to be a motive force on this idea, and have thus refrained (as I am pushing on other ideas, too). But I also don't want this to die. :) Thanks! Richard On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena mailto:trupill@gmail.com> wrote: I agree with using the criteria that Richard posted + the addition by Simon. Just in case somebody hadn't looked at the wiki, the criteria would be: 1. The extension is (mostly) conservative: All programs that were accepted without the extension remain accepted, and with the same meaning. 2. New failure modes that become possible with the extension are rare and/or easy to diagnose. (These failure modes include new error messages, wrong inferred types, and runtime errors, for example.) 3. The extensions complement the design of standard Haskell. (This one seems the most subjective.) 4. The extension has been -- and can reasonably be predicted to remain -- stable. 5. The extension is not to gate-keep an advanced or potentially-unsafe feature. 6. The extension is widely-used. For example, should we add to (6) "in current developments"? What about things like "EmptyDataDecls", which are just straightforward generalizations of what Haskell 2010 already allows, although in practice the only data type you would ever need to be empty is "Void"? Alejandro El jue., 17 sept. 2020 a las 16:42, Simon Marlow (mailto:marlowsd@gmail.com>) escribió: I think there should be some requirement that an extension be widely-used (for some suitable definition of that), before we ratify it in GHC2020. Some of the extensions that made it past the first round of filtering are not widely-used, and would be therefore probably be controversial additions to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo to name a few that I noticed straight off. I think it's a good idea to be conservative here. Cheers Simon On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> wrote: There seems to be some question about who should drive this debate. But there is something we all seem to agree on: it is our role, as the steering committee, to announce the criteria by which we intend to judge the reasonableness of each potential candidate extension. So, let me suggest that we start discussing that, and move back to how this discussion ought to be driven when we are a bit clearer on the criteria. Richard wrote a bunch of criteria in the wiki page upthread [1]. I think that they are worthy of discussion. So let me ask the question: do we agree with all these criteria? do we want to add more? [1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042164548&sdata=wFIQt92hr82HcXuEwTXacMF%2BEuCqyr2tnokVzqVTEQQ%3D&reserved=0 On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena mailto:trupill@gmail.com> wrote: I would rather make the process Committee-driven, because otherwise it may derail into too many micro-discussions. I think it's better to start a conversation saying "this is our proposal, here are our criteria, here are the exceptions we want to make", and then discuss from there. Regards, Alejandro El mar., 8 sept. 2020 a las 14:01, Eric Seidel (mailto:eric@seidel.io>) escribió: I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design. I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product? This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed. Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them. Eric Sent from my iPhone On Sep 8, 2020, at 06:37, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote:  Personally I don’t think we should make the Steering Committee responsible for initiating or driving this. We should • establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version), • express open-ness to a proposal, and then • review proposals when/if they materialise. It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee responsible. What do others think? Simon From: Alejandro Serrano Mena mailto:trupill@gmail.com> Sent: 08 September 2020 09:13 To: Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: Richard Eisenberg mailto:rae@richarde.dev>; Eric Seidel mailto:eric@seidel.io>; ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] GHC 2020 Dear all, I would really like to move this forward, and I would be happy to put some work on it. What do you think of the following plan? - Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible. - Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria. If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions. Regards, Alejandro El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee (mailto:ghc-steering-committee@haskell.org>) escribió: Just back from holiday. Some thoughts * I don’t think this mailing list is the best place for the discussion. Basically, it's a GHC Proposal, so someone (possibly a committee member, possibly not) should write a proposal, and we should put it through the process. * We should advertise the criteria, as Richard has done on the wiki page. * Any such proposal should be informed by data. Notably, extension usage in Hackage, or perhaps Stackage (since it's a bit more curated). * A proposer might also want to run a public poll, as an additional source of data * When it comes to the committee, we can (I guess) vote on individual extensions, rather than just accept/reject the whole thing. I am intrigued by the idea of using Kialo to coordinate discussion. Maybe it'd work better than GitHub? Are there other alternatives? But that's orthogonal to the GHC 2020 idea; let's not conflate them. Simon | -----Original Message----- | From: ghc-steering-committee mailto:bounces@haskell.org> On Behalf Of Richard Eisenberg | Sent: 02 September 2020 14:57 | To: Eric Seidel mailto:eric@seidel.io> | Cc: ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | It seems clear that my wiki idea isn't winning the day -- I never | really liked it either. I'd be fine with either Eric's or Joachim's | approaches. Maybe start with Joachim's approach and then use Eric's | when Joachim's runs out of steam? A big minus, though, to Joachim's | approach is that it seems hard to get good community involvement. | | Richard | | > On Sep 2, 2020, at 8:11 AM, Eric Seidel mailto:eric@seidel.io> wrote: | > | > Opening a regular discussion about whether and how we want to work on | GHC 2020 sounds fine, that will also give the community a place to | weigh in. I do think the eventual contents should be informed by the | community though, it shouldn’t just be us working alone. | > | > Sent from my iPhone | > | >> On Sep 2, 2020, at 03:16, Joachim Breitner https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042169538&sdata=Ctr6M2HoRc2%2BbyWPFB4JNql2WIse14k4iWELijNVItQ%3D&reserved=0> wrote: | >> | >> Hi, | >> | >> sounds plausible. It would also allow us to use tags to easily | indicate | >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and | >> then filter by issue to get the current list… | >> | >> But before we go there, shouldn’t we maybe have a discussion first | on | >> | >> * do we even want that? | >> * what are the abstract criteria (or guidelines)? | >> * what is the process? | >> | >> I believe that discussion could be done like any other proposal. | >> | >> | >> As for the process; when I brought up the idea, I was worried about | us | >> spending huge resources discussion individual extensions to death, | and | >> proposed, in the interest of efficiency and getting things done: | >> | >>> The process could be: Every member can nominate any number of | >>> extensions, to include, maybe a small rationale and then we do one | >>> round of independent approval voting, requiring a supermajority to | >>> really only pick uncontested extensions. | >> | >> So instead of long debates, we start with GHC2020 being just those | >> extensions that a supermajority on the committee considers to be ok. | >> | >> This is much more lightweight process that we could get done in a | week | >> or two (maybe using a doodle-like voting page). Maybe we would leave | >> out one or two extension that initially people are reserved about, | but | >> could be swayed after lengthy discussions. But is that worth the | >> lengthy discussion? | >> | >> cheers, | >> Joachim | >> | >> -- | >> Joachim Breitner | >> mail@joachim-breitner.demailto:mail@joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.dehttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042174527&sdata=iiAtfwNwjAnv5k92F63GysP4XAvmFd9ibxIggJSisU4%3D&reserved=0%2F&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042179516&sdata=3qCil%2FMoccFUJT5ewL2xNnAfltU6CrN4NG44tjlpv8E%3D&reserved=0%7Cfa6e3a6bcdf | 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D | &reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042184514&sdata=fuk93MrXnqJKCb9DnER3g1PQH3CCqpxXb%2Bbd%2Fv87OjM%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042189496&sdata=FGlQfF33ahePm0M2O0zfQny8v7bAMczOIWqZyEZJyNc%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042194488&sdata=YqgMoMxpdRNYxxZN2PjexDFO%2B9Vbi8K1L%2BZ1cFhecII%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042199478&sdata=9nZFHqY8MyAbz3RWgDuYX%2B%2F2MUFkMMdFEwrFSUMmHtA%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042209458&sdata=l1fNq0SUpDnKgGJmKOea4OI69aFo7s61JUQzgU2RVSc%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042214451&sdata=JR7JtEo%2BF5akMRQtaqy4feJy%2FrtdHDoKAAOKh%2BNPmbc%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042219441&sdata=jK4hfemsYlEp5Y%2BGhWSXkte1gt9DMga8toTbWpD%2B7kc%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042224430&sdata=jV83SWi62SM15AZgduDOULnRSb55grqKOI3RzX%2BlGPE%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042229422&sdata=rOqBh76f6LeI%2F2Vz9yDjqIpu4w5dzkqOKfU7xg7REu0%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042234412&sdata=A7yxkjePHouaA880w0Z2wISl7822I42gVHE1LRzBwZE%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042239402&sdata=1HvIaICrDrNn%2Bje%2BqBDXkuNSqa9kqUZiUrtBNNoibNY%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042244393&sdata=QlkYJves2UnTUVlMabzOFybaXWJvZnxNA%2BnxcdMX1nU%3D&reserved=0

Thanks. Rather than explaining to me, you could update the proposal? (In due course.) Simon From: Alejandro Serrano Mena Sent: 01 October 2020 09:18 To: Simon Peyton Jones Cc: Iavor Diatchki ; Richard Eisenberg ; ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] GHC 2020 My idea is to make this a bit better before sending the PR to the ghc-proposals repo (as Iavor suggested), but any preliminary feedback is welcome. Answering your questions (maybe Richard can also explain a bit, I'm giving here my interpretation): - By "complementing" we mean a (mostly subjective) idea that it goes with the spirit of Haskell. For example, MultiParamTypeClasses extends what's already there, and works well with the rest of features. If we suddenly decided you can use Lisp-like syntax, that would not complement it's current design. - We want to keep all potentially unsafe features under flags. IncoherentInstances should not be enabled by default because of its behavior. - I prefer to have a strict wording and then add exceptions. So I would say conservativeness should be described as "no program ceases to be accepted". - "Failure mode" is again not concrete, but the idea is that everything which would make the developer experience worse by being enabled should not be part of GHC2020. El jue., 1 oct. 2020 a las 10:11, Simon Peyton Jones (mailto:simonpj@microsoft.com>) escribió: Thanks Alejandro. How do you want feedback? The “discussed at this PR” link is broken. I think the criteria could be tightened up quite a bit. * I don’t know what “The extensions complement the design of standard Haskell” means. What would be an example of something that doesn’t complement it? * I don’t know what “The extension is not to gate-keep an advanced or potentially-unsafe feature” means. * Item (1), conservative extension, is a bit ambiguous. Is says “Mostly” but then “all programs”. Which is your intent? * What is a “new failure mode”? Do you mean existing programs that fail when the extension is on? Or new programs that are trying to use the new extension but get it wrong? For the latter it’s hard to see how they’d be rare. Simon From: Alejandro Serrano Mena mailto:trupill@gmail.com> Sent: 30 September 2020 21:06 To: Iavor Diatchki mailto:iavor.diatchki@gmail.com> Cc: Simon Peyton Jones mailto:simonpj@microsoft.com>; Richard Eisenberg mailto:rae@richarde.dev>; ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] GHC 2020 Dear all, I've started working on a proposal for GHC2020. You can see the current status here: https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-202...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-ghc-2020.md&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=1rK336YRHSWotXYZAqkH4Iwwi7efswXe5jTplbPu1Bs%3D&reserved=0 I noticed the list by Richard was not exhaustive. Those extensions are headed by "In discussion". Preferably we should make up our minds before presenting the proposal. I would say there are three big groups of proposals. Any feedback is welcome on that part. Regards, Alejandrp El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (mailto:iavor.diatchki@gmail.com>) escribió: Thanks Alejandro. My preference would be that you share whatever you come up with the list so we can discuss it, before making a proposal that would represent the committee. -Iavor On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote: OK by me. Thank you Simon From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> On Behalf Of Alejandro Serrano Mena Sent: 29 September 2020 15:51 To: Richard Eisenberg mailto:rae@richarde.dev> Cc: ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] GHC 2020 I am still happy to drive this! I was not sure about whether we agreed as a Committee on pushing this. To make this more actionable, my goal is, during next Sunday, to create a new proposal with the criteria (based on Richard + Simon's list), and a preliminary assessment of which of the current extensions satisfy these criteria, and for those we might be willing to grant exceptions. Please raise your voice if you think we should proceed otherwise (or if you think we should not proceed at all!). Regards, Alejandro El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg (mailto:rae@richarde.dev>) escribió: What's the status of this push? I was delighted to see that Alejandro volunteered to be a motive force on this idea, and have thus refrained (as I am pushing on other ideas, too). But I also don't want this to die. :) Thanks! Richard On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena mailto:trupill@gmail.com> wrote: I agree with using the criteria that Richard posted + the addition by Simon. Just in case somebody hadn't looked at the wiki, the criteria would be: 1. The extension is (mostly) conservative: All programs that were accepted without the extension remain accepted, and with the same meaning. 2. New failure modes that become possible with the extension are rare and/or easy to diagnose. (These failure modes include new error messages, wrong inferred types, and runtime errors, for example.) 3. The extensions complement the design of standard Haskell. (This one seems the most subjective.) 4. The extension has been -- and can reasonably be predicted to remain -- stable. 5. The extension is not to gate-keep an advanced or potentially-unsafe feature. 6. The extension is widely-used. For example, should we add to (6) "in current developments"? What about things like "EmptyDataDecls", which are just straightforward generalizations of what Haskell 2010 already allows, although in practice the only data type you would ever need to be empty is "Void"? Alejandro El jue., 17 sept. 2020 a las 16:42, Simon Marlow (mailto:marlowsd@gmail.com>) escribió: I think there should be some requirement that an extension be widely-used (for some suitable definition of that), before we ratify it in GHC2020. Some of the extensions that made it past the first round of filtering are not widely-used, and would be therefore probably be controversial additions to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo to name a few that I noticed straight off. I think it's a good idea to be conservative here. Cheers Simon On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> wrote: There seems to be some question about who should drive this debate. But there is something we all seem to agree on: it is our role, as the steering committee, to announce the criteria by which we intend to judge the reasonableness of each potential candidate extension. So, let me suggest that we start discussing that, and move back to how this discussion ought to be driven when we are a bit clearer on the criteria. Richard wrote a bunch of criteria in the wiki page upthread [1]. I think that they are worthy of discussion. So let me ask the question: do we agree with all these criteria? do we want to add more? [1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=lpOFIx5mBcaUbKIDIhs%2BnAmYd72%2FctVTwij1WJYTVF8%3D&reserved=0 On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena mailto:trupill@gmail.com> wrote: I would rather make the process Committee-driven, because otherwise it may derail into too many micro-discussions. I think it's better to start a conversation saying "this is our proposal, here are our criteria, here are the exceptions we want to make", and then discuss from there. Regards, Alejandro El mar., 8 sept. 2020 a las 14:01, Eric Seidel (mailto:eric@seidel.io>) escribió: I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design. I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product? This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed. Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them. Eric Sent from my iPhone On Sep 8, 2020, at 06:37, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote:  Personally I don’t think we should make the Steering Committee responsible for initiating or driving this. We should • establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version), • express open-ness to a proposal, and then • review proposals when/if they materialise. It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee responsible. What do others think? Simon From: Alejandro Serrano Mena mailto:trupill@gmail.com> Sent: 08 September 2020 09:13 To: Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: Richard Eisenberg mailto:rae@richarde.dev>; Eric Seidel mailto:eric@seidel.io>; ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] GHC 2020 Dear all, I would really like to move this forward, and I would be happy to put some work on it. What do you think of the following plan? - Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible. - Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria. If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions. Regards, Alejandro El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee (mailto:ghc-steering-committee@haskell.org>) escribió: Just back from holiday. Some thoughts * I don’t think this mailing list is the best place for the discussion. Basically, it's a GHC Proposal, so someone (possibly a committee member, possibly not) should write a proposal, and we should put it through the process. * We should advertise the criteria, as Richard has done on the wiki page. * Any such proposal should be informed by data. Notably, extension usage in Hackage, or perhaps Stackage (since it's a bit more curated). * A proposer might also want to run a public poll, as an additional source of data * When it comes to the committee, we can (I guess) vote on individual extensions, rather than just accept/reject the whole thing. I am intrigued by the idea of using Kialo to coordinate discussion. Maybe it'd work better than GitHub? Are there other alternatives? But that's orthogonal to the GHC 2020 idea; let's not conflate them. Simon | -----Original Message----- | From: ghc-steering-committee mailto:bounces@haskell.org> On Behalf Of Richard Eisenberg | Sent: 02 September 2020 14:57 | To: Eric Seidel mailto:eric@seidel.io> | Cc: ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | It seems clear that my wiki idea isn't winning the day -- I never | really liked it either. I'd be fine with either Eric's or Joachim's | approaches. Maybe start with Joachim's approach and then use Eric's | when Joachim's runs out of steam? A big minus, though, to Joachim's | approach is that it seems hard to get good community involvement. | | Richard | | > On Sep 2, 2020, at 8:11 AM, Eric Seidel mailto:eric@seidel.io> wrote: | > | > Opening a regular discussion about whether and how we want to work on | GHC 2020 sounds fine, that will also give the community a place to | weigh in. I do think the eventual contents should be informed by the | community though, it shouldn’t just be us working alone. | > | > Sent from my iPhone | > | >> On Sep 2, 2020, at 03:16, Joachim Breitner https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%3D&reserved=0> wrote: | >> | >> Hi, | >> | >> sounds plausible. It would also allow us to use tags to easily | indicate | >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and | >> then filter by issue to get the current list… | >> | >> But before we go there, shouldn’t we maybe have a discussion first | on | >> | >> * do we even want that? | >> * what are the abstract criteria (or guidelines)? | >> * what is the process? | >> | >> I believe that discussion could be done like any other proposal. | >> | >> | >> As for the process; when I brought up the idea, I was worried about | us | >> spending huge resources discussion individual extensions to death, | and | >> proposed, in the interest of efficiency and getting things done: | >> | >>> The process could be: Every member can nominate any number of | >>> extensions, to include, maybe a small rationale and then we do one | >>> round of independent approval voting, requiring a supermajority to | >>> really only pick uncontested extensions. | >> | >> So instead of long debates, we start with GHC2020 being just those | >> extensions that a supermajority on the committee considers to be ok. | >> | >> This is much more lightweight process that we could get done in a | week | >> or two (maybe using a doodle-like voting page). Maybe we would leave | >> out one or two extension that initially people are reserved about, | but | >> could be swayed after lengthy discussions. But is that worth the | >> lengthy discussion? | >> | >> cheers, | >> Joachim | >> | >> -- | >> Joachim Breitner | >> mail@joachim-breitner.demailto:mail@joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.dehttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%3D&reserved=0%2F&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=ddj4e3mS%2F%2FAhpGbMV5NkneCJW1aXe1YKfM4hg0%2FwGNg%3D&reserved=0%7Cfa6e3a6bcdf | 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D | &reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=KQfPgn0781%2Fi5JrFyEBp87Tcc3G%2FGiysbqlTM42Xgrw%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=X4VmXP6B65Tp%2Byv77g47%2FJiSx%2FdrScj5n5xMyzJKiik%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=BdY%2Fv6at9nrPOSB4RqbhsDmjKopgJqGlYBEY6XcQhOM%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=r3dK4INyOAgjOC3GmkBGVkTcko6auZjST5815b8Gq9c%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=4YyoqgXgYhjSanhyuMXMjEQsTZm3ux00U6O3mFv274g%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=rwo%2BaTMPD6sIQAYIcyWg1DU5Ut71bgKxYIdp3mP9Iuo%3D&reserved=0%7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=hFTP2bNd5ZWcDQ0vH98O3hhwYOp%2BIV0iLwHMTBJZEHI%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977311737&sdata=p895UWSa99PCifyQgpA9WEZKtdgVz4LbPW9y3TCE5%2Bc%3D&reserved=0

My idea was to turn the original wiki page https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 into an actual proposal, so we can open it to discussion. Except for a few extensions, I copied the original acceptance list, since people seemed to mostly agree with them. In any case, the aim was to agree on some set of extensions that we could propose as a Committee, before opening to further consultation, especially in order to agree on a set of criteria. It could well be that we should refrain from adding some of them; it seems that you think that roles for example are not there yet, so we should remove any extension which uses them implicitly. I am happy to go back to the original thread you sent, and tell which are those extensions which I consider fine. But as you said, that would make the discussion terribly inefficient. Any thoughts on the approach to follow? Otherwise I feel we'll be forever in a sort of deadlock. I am also happy with taking Iavor's original list, turning it into a proposal, and let the community speak. But then we need a good story about why some common extensions, like MultiParamTypeClasses, are not included. Regards, Alejandro El jue., 1 oct. 2020 a las 18:10, Iavor Diatchki () escribió:

I quite strongly disagree with a bunch of the classifications on Alejandro's link but I have no idea *why* he thinks they match the criteria, or what that even means. Rather than having an unstructured discussion about "I don't agree with this or that", I'd encourage us to avoid the "big bang" approach, of having a page with all extensions, and do something more focused. For example, in the extensions I sent in the original e-mail of this thread are grouped more or less "by topic", and I think we should do something similar in the discussion.

For the sake of concreteness, why don't we start by discussing extensions related to Haskell's deriving mechanism? In Alejandro's current link there are a whole lot of these listed as "matching all criteria", but not all of them are compatible with each other, so they should not be all part of GHC 2020. On this topic, the extensions I think should be part of GHC2020 would be: 1. EmptyDataDeriving 2. StandaloneDeriving 3. DeriveGeneric 4. DeriveLift

I don't think any of these are likely to affect existing code bases, and I don't think listing them as an explicit extension gives you any information that you couldn't easily obtain by just looking at the code. I don't use (1) a lot but I think it makes the language more consistent. (2) I use this sometimes, and having an extension to enable it doesn't really add any extra information, and (3) and (4) are for Generics and Template Haskell, both of which are fairly common and not likely to go away.

Other extensions that I use quite often are `GeneralizedNewtypeDeriving`, `DeriveTraversible`. I don't think we should add `GenerelizedNewtypeDeriving` because it brings in the whole "role" annotation machinery. I know why we need it at the moment, but it doesn't seem particularly elegant. I also tend to use it in extremely restricted ways, mostly to derive `Monad` instances. `DeriveTraversible` seems nice and I do use it, but I think it potentially interferes with the other deriving techniques (e.g. GND).

-Iavor PS: I'd be up for trying out something like Kialo if we'd prefer to use a tool rather than having the discussion over e-mail

On Thu, Oct 1, 2020 at 1:32 AM Simon Peyton Jones wrote:

...

Thanks. Rather than explaining to me, you could update the proposal? (In due course.)

Simon

*From:* Alejandro Serrano Mena *Sent:* 01 October 2020 09:18 *To:* Simon Peyton Jones *Cc:* Iavor Diatchki ; Richard Eisenberg < rae@richarde.dev>; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

My idea is to make this a bit better before sending the PR to the ghc-proposals repo (as Iavor suggested), but any preliminary feedback is welcome.

Answering your questions (maybe Richard can also explain a bit, I'm giving here my interpretation):

- By "complementing" we mean a (mostly subjective) idea that it goes with the spirit of Haskell. For example, MultiParamTypeClasses extends what's already there, and works well with the rest of features. If we suddenly decided you can use Lisp-like syntax, that would not complement it's current design.

- We want to keep all potentially unsafe features under flags. IncoherentInstances should not be enabled by default because of its behavior.

- I prefer to have a strict wording and then add exceptions. So I would say conservativeness should be described as "no program ceases to be accepted".

- "Failure mode" is again not concrete, but the idea is that everything which would make the developer experience worse by being enabled should not be part of GHC2020.

El jue., 1 oct. 2020 a las 10:11, Simon Peyton Jones (< simonpj@microsoft.com>) escribió:

Thanks Alejandro. How do you want feedback? The “discussed at this PR” link is broken.

I think the criteria could be tightened up quite a bit.

- I don’t know what “The extensions *complement* the design of standard Haskell” means. What would be an example of something that doesn’t complement it?

- I don’t know what “The extension is *not* to *gate-keep* an advanced or potentially-unsafe feature” means.

- Item (1), conservative extension, is a bit ambiguous. Is says “Mostly” but then “all programs”. Which is your intent?

- What is a “new failure mode”? Do you mean existing programs that fail when the extension is on? Or new programs that are trying to use the new extension but get it wrong? For the latter it’s hard to see how they’d be rare.

Simon

*From:* Alejandro Serrano Mena *Sent:* 30 September 2020 21:06 *To:* Iavor Diatchki *Cc:* Simon Peyton Jones ; Richard Eisenberg < rae@richarde.dev>; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

Dear all,

I've started working on a proposal for GHC2020. You can see the current status here: https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-202... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-ghc-2020.md&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=1rK336YRHSWotXYZAqkH4Iwwi7efswXe5jTplbPu1Bs%3D&reserved=0

I noticed the list by Richard was not exhaustive. Those extensions are headed by "In discussion". Preferably we should make up our minds before presenting the proposal. I would say there are three big groups of proposals. Any feedback is welcome on that part.

Regards,

Alejandrp

El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (< iavor.diatchki@gmail.com>) escribió:

Thanks Alejandro. My preference would be that you share whatever you come up with the list so we can discuss it, before making a proposal that would represent the committee.

-Iavor

On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via ghc-steering-committee wrote:

OK by me. Thank you

Simon

*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 29 September 2020 15:51 *To:* Richard Eisenberg *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

I am still happy to drive this! I was not sure about whether we agreed as a Committee on pushing this.

To make this more actionable, my goal is, *during next Sunday*, to create a new proposal with the *criteria* (based on Richard + Simon's list), and a preliminary assessment of which of the *current extensions* satisfy these criteria, and for those we might be willing to grant *exceptions*.

Please raise your voice if you think we should proceed otherwise (or if you think we should not proceed at all!).

Regards,

Alejandro

El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg () escribió:

What's the status of this push? I was delighted to see that Alejandro volunteered to be a motive force on this idea, and have thus refrained (as I am pushing on other ideas, too). But I also don't want this to die. :)

Thanks!

Richard

On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena wrote:

I agree with using the criteria that Richard posted + the addition by Simon. Just in case somebody hadn't looked at the wiki, the criteria would be:

1. The extension is (mostly) conservative: All programs that were accepted without the extension remain accepted, and with the same meaning. 2. New failure modes that become possible with the extension are rare and/or easy to diagnose. (These failure modes include new error messages, wrong inferred types, and runtime errors, for example.) 3. The extensions complement the design of standard Haskell. (This one seems the most subjective.) 4. The extension has been -- and can reasonably be predicted to remain -- stable. 5. The extension is not to gate-keep an advanced or potentially-unsafe feature. 6. The extension is widely-used.

For example, should we add to (6) "in current developments"? What about things like "EmptyDataDecls", which are just straightforward generalizations of what Haskell 2010 already allows, although in practice the only data type you would ever need to be empty is "Void"?

Alejandro

El jue., 17 sept. 2020 a las 16:42, Simon Marlow () escribió:

I think there should be some requirement that an extension be widely-used (for some suitable definition of that), before we ratify it in GHC2020. Some of the extensions that made it past the first round of filtering are not widely-used, and would be therefore probably be controversial additions to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo to name a few that I noticed straight off. I think it's a good idea to be conservative here.

Cheers

Simon

On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud wrote:

There seems to be some question about who should drive this debate. But there is something we all seem to agree on: it is our role, as the steering committee, to announce the criteria by which we intend to judge the reasonableness of each potential candidate extension.

So, let me suggest that we start discussing that, and move back to how this discussion ought to be driven when we are a bit clearer on the criteria.

Richard wrote a bunch of criteria in the wiki page upthread [1]. I think that they are worthy of discussion. So let me ask the question: do we agree with all these criteria? do we want to add more?

[1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=lpOFIx5mBcaUbKIDIhs%2BnAmYd72%2FctVTwij1WJYTVF8%3D&reserved=0

On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena wrote:

I would rather make the process Committee-driven, because otherwise it may derail into too many micro-discussions. I think it's better to start a conversation saying "this is our proposal, here are our criteria, here are the exceptions we want to make", and then discuss from there.

Regards,

Alejandro

El mar., 8 sept. 2020 a las 14:01, Eric Seidel () escribió:

I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design.

I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product?

This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed.

Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them.

Eric

Sent from my iPhone

On Sep 8, 2020, at 06:37, Simon Peyton Jones wrote:



Personally I don’t think we should make the Steering Committee responsible for initiating or driving this. We should

· establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version),

· express open-ness to a proposal, and then

· review proposals when/if they materialise.

It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee *responsible*.

What do others think?

Simon

*From:* Alejandro Serrano Mena *Sent:* 08 September 2020 09:13 *To:* Simon Peyton Jones *Cc:* Richard Eisenberg ; Eric Seidel ; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

Dear all,

I would really like to move this forward, and I would be happy to put some work on it.

What do you think of the following plan?

- Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.

- Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.

If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.

Regards,

Alejandro

El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee () escribió:

Just back from holiday. Some thoughts

* I don’t think this mailing list is the best place for the discussion. Basically, it's a GHC Proposal, so someone (possibly a committee member, possibly not) should write a proposal, and we should put it through the process.

* We should advertise the criteria, as Richard has done on the wiki page.

* Any such proposal should be informed by data. Notably, extension usage in Hackage, or perhaps Stackage (since it's a bit more curated).

* A proposer might also want to run a public poll, as an additional source of data

* When it comes to the committee, we can (I guess) vote on individual extensions, rather than just accept/reject the whole thing.

I am intrigued by the idea of using Kialo to coordinate discussion. Maybe it'd work better than GitHub? Are there other alternatives? But that's orthogonal to the GHC 2020 idea; let's not conflate them.

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Richard Eisenberg | Sent: 02 September 2020 14:57 | To: Eric Seidel | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | It seems clear that my wiki idea isn't winning the day -- I never | really liked it either. I'd be fine with either Eric's or Joachim's | approaches. Maybe start with Joachim's approach and then use Eric's | when Joachim's runs out of steam? A big minus, though, to Joachim's | approach is that it seems hard to get good community involvement. | | Richard | | > On Sep 2, 2020, at 8:11 AM, Eric Seidel wrote: | > | > Opening a regular discussion about whether and how we want to work on | GHC 2020 sounds fine, that will also give the community a place to | weigh in. I do think the eventual contents should be informed by the | community though, it shouldn’t just be us working alone. | > | > Sent from my iPhone | > | >> On Sep 2, 2020, at 03:16, Joachim Breitner https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%3D&reserved=0> wrote: | >> | >> Hi, | >> | >> sounds plausible. It would also allow us to use tags to easily | indicate | >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and | >> then filter by issue to get the current list… | >> | >> But before we go there, shouldn’t we maybe have a discussion first | on | >> | >> * do we even want that? | >> * what are the abstract criteria (or guidelines)? | >> * what is the process? | >> | >> I believe that discussion could be done like any other proposal. | >> | >> | >> As for the process; when I brought up the idea, I was worried about | us | >> spending huge resources discussion individual extensions to death, | and | >> proposed, in the interest of efficiency and getting things done: | >> | >>> The process could be: Every member can nominate any number of | >>> extensions, to include, maybe a small rationale and then we do one | >>> round of independent approval voting, requiring a supermajority to | >>> really only pick uncontested extensions. | >> | >> So instead of long debates, we start with GHC2020 being just those | >> extensions that a supermajority on the committee considers to be ok. | >> | >> This is much more lightweight process that we could get done in a | week | >> or two (maybe using a doodle-like voting page). Maybe we would leave | >> out one or two extension that initially people are reserved about, | but | >> could be swayed after lengthy discussions. But is that worth the | >> lengthy discussion? | >> | >> cheers, | >> Joachim | >> | >> -- | >> Joachim Breitner | >> mail@joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%3D&reserved=0 %2F&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=ddj4e3mS%2F%2FAhpGbMV5NkneCJW1aXe1YKfM4hg0%2FwGNg%3D&reserved=0 %7Cfa6e3a6bcdf | 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D | &reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail . | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=KQfPgn0781%2Fi5JrFyEBp87Tcc3G%2FGiysbqlTM42Xgrw%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=X4VmXP6B65Tp%2Byv77g47%2FJiSx%2FdrScj5n5xMyzJKiik%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail . | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=BdY%2Fv6at9nrPOSB4RqbhsDmjKopgJqGlYBEY6XcQhOM%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=r3dK4INyOAgjOC3GmkBGVkTcko6auZjST5815b8Gq9c%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail . | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=4YyoqgXgYhjSanhyuMXMjEQsTZm3ux00U6O3mFv274g%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=rwo%2BaTMPD6sIQAYIcyWg1DU5Ut71bgKxYIdp3mP9Iuo%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=hFTP2bNd5ZWcDQ0vH98O3hhwYOp%2BIV0iLwHMTBJZEHI%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977311737&sdata=p895UWSa99PCifyQgpA9WEZKtdgVz4LbPW9y3TCE5%2Bc%3D&reserved=0

Richard, I really liked your idea, so I've started to implement it as part of the proposal. You can read the current version as https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-202.... TL;DR: extensions should fulfill as many criteria as possible, we use another repo with one issue per extension. Personally, I would also like to come up with general guidance. Do we expect *any* extension fulfilling the criteria to be included? Alejandro El vie., 2 oct. 2020 a las 17:33, Richard Eisenberg () escribió:

A few scattered thoughts:

* I don't see a particular need to debate on this list separately from a debate more in public. This list is public, anyway! And having the debate organized from as early as possible seems better.

* I feel strongly that we should find a venue where we can discuss individual extensions on separately-marshalled threads, not in one monolithic clump. One idea (I think?) that was floated was to start a new repo (in the ghc-proposals org), where we can make a ticket for any contested extension. Kialo is another idea (assuming it supports separate threads for separate ideas); I have no experience. In the end, I don't care much about where this happens, as long as separate threads are indeed separable.

* Debating the criteria seems like a worthy place to start. That *could* be done over email, but I think a proposal is better.

Maybe this suggests the following structure:

* A ghc-proposal that sets out the criteria for inclusion -- but does not opine on any extensions (except perhaps as illustrations of a criterion). This can get debated and accepted in the usual fashion, except that it might form a new document in the top level of our repo, not just another proposal. This initial proposal can also set out the way to stage the rest of the debate.

* Upon acceptance, we proceed with the approach outlined in the first step, such as the extra repo or the Kialo space.

* Profit.

Richard

On Oct 1, 2020, at 3:34 PM, Alejandro Serrano Mena wrote:

My idea was to turn the original wiki page https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 into an actual proposal, so we can open it to discussion. Except for a few extensions, I copied the original acceptance list, since people seemed to mostly agree with them.

In any case, the aim was to agree on some set of extensions that we could propose as a Committee, before opening to further consultation, especially in order to agree on a set of criteria. It could well be that we should refrain from adding some of them; it seems that you think that roles for example are not there yet, so we should remove any extension which uses them implicitly.

I am happy to go back to the original thread you sent, and tell which are those extensions which I consider fine. But as you said, that would make the discussion terribly inefficient. Any thoughts on the approach to follow? Otherwise I feel we'll be forever in a sort of deadlock. I am also happy with taking Iavor's original list, turning it into a proposal, and let the community speak. But then we need a good story about why some common extensions, like MultiParamTypeClasses, are not included.

Regards, Alejandro

El jue., 1 oct. 2020 a las 18:10, Iavor Diatchki (< iavor.diatchki@gmail.com>) escribió:

...

I quite strongly disagree with a bunch of the classifications on Alejandro's link but I have no idea *why* he thinks they match the criteria, or what that even means. Rather than having an unstructured discussion about "I don't agree with this or that", I'd encourage us to avoid the "big bang" approach, of having a page with all extensions, and do something more focused. For example, in the extensions I sent in the original e-mail of this thread are grouped more or less "by topic", and I think we should do something similar in the discussion.

For the sake of concreteness, why don't we start by discussing extensions related to Haskell's deriving mechanism? In Alejandro's current link there are a whole lot of these listed as "matching all criteria", but not all of them are compatible with each other, so they should not be all part of GHC 2020. On this topic, the extensions I think should be part of GHC2020 would be: 1. EmptyDataDeriving 2. StandaloneDeriving 3. DeriveGeneric 4. DeriveLift

I don't think any of these are likely to affect existing code bases, and I don't think listing them as an explicit extension gives you any information that you couldn't easily obtain by just looking at the code. I don't use (1) a lot but I think it makes the language more consistent. (2) I use this sometimes, and having an extension to enable it doesn't really add any extra information, and (3) and (4) are for Generics and Template Haskell, both of which are fairly common and not likely to go away.

Other extensions that I use quite often are `GeneralizedNewtypeDeriving`, `DeriveTraversible`. I don't think we should add `GenerelizedNewtypeDeriving` because it brings in the whole "role" annotation machinery. I know why we need it at the moment, but it doesn't seem particularly elegant. I also tend to use it in extremely restricted ways, mostly to derive `Monad` instances. `DeriveTraversible` seems nice and I do use it, but I think it potentially interferes with the other deriving techniques (e.g. GND).

-Iavor PS: I'd be up for trying out something like Kialo if we'd prefer to use a tool rather than having the discussion over e-mail

On Thu, Oct 1, 2020 at 1:32 AM Simon Peyton Jones wrote:

...

Thanks. Rather than explaining to me, you could update the proposal? (In due course.)

Simon

*From:* Alejandro Serrano Mena *Sent:* 01 October 2020 09:18 *To:* Simon Peyton Jones *Cc:* Iavor Diatchki ; Richard Eisenberg < rae@richarde.dev>; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

My idea is to make this a bit better before sending the PR to the ghc-proposals repo (as Iavor suggested), but any preliminary feedback is welcome.

Answering your questions (maybe Richard can also explain a bit, I'm giving here my interpretation):

- By "complementing" we mean a (mostly subjective) idea that it goes with the spirit of Haskell. For example, MultiParamTypeClasses extends what's already there, and works well with the rest of features. If we suddenly decided you can use Lisp-like syntax, that would not complement it's current design.

- We want to keep all potentially unsafe features under flags. IncoherentInstances should not be enabled by default because of its behavior.

- I prefer to have a strict wording and then add exceptions. So I would say conservativeness should be described as "no program ceases to be accepted".

- "Failure mode" is again not concrete, but the idea is that everything which would make the developer experience worse by being enabled should not be part of GHC2020.

El jue., 1 oct. 2020 a las 10:11, Simon Peyton Jones (< simonpj@microsoft.com>) escribió:

Thanks Alejandro. How do you want feedback? The “discussed at this PR” link is broken.

I think the criteria could be tightened up quite a bit.

- I don’t know what “The extensions *complement* the design of standard Haskell” means. What would be an example of something that doesn’t complement it?

- I don’t know what “The extension is *not* to *gate-keep* an advanced or potentially-unsafe feature” means.

- Item (1), conservative extension, is a bit ambiguous. Is says “Mostly” but then “all programs”. Which is your intent?

- What is a “new failure mode”? Do you mean existing programs that fail when the extension is on? Or new programs that are trying to use the new extension but get it wrong? For the latter it’s hard to see how they’d be rare.

Simon

*From:* Alejandro Serrano Mena *Sent:* 30 September 2020 21:06 *To:* Iavor Diatchki *Cc:* Simon Peyton Jones ; Richard Eisenberg < rae@richarde.dev>; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

Dear all,

I've started working on a proposal for GHC2020. You can see the current status here: https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-202... https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-ghc-2020.md&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=1rK336YRHSWotXYZAqkH4Iwwi7efswXe5jTplbPu1Bs%3D&reserved=0

I noticed the list by Richard was not exhaustive. Those extensions are headed by "In discussion". Preferably we should make up our minds before presenting the proposal. I would say there are three big groups of proposals. Any feedback is welcome on that part.

Regards,

Alejandrp

El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (< iavor.diatchki@gmail.com>) escribió:

Thanks Alejandro. My preference would be that you share whatever you come up with the list so we can discuss it, before making a proposal that would represent the committee.

-Iavor

On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via ghc-steering-committee wrote:

OK by me. Thank you

Simon

*From:* ghc-steering-committee < ghc-steering-committee-bounces@haskell.org> *On Behalf Of *Alejandro Serrano Mena *Sent:* 29 September 2020 15:51 *To:* Richard Eisenberg *Cc:* ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

I am still happy to drive this! I was not sure about whether we agreed as a Committee on pushing this.

To make this more actionable, my goal is, *during next Sunday*, to create a new proposal with the *criteria* (based on Richard + Simon's list), and a preliminary assessment of which of the *current extensions* satisfy these criteria, and for those we might be willing to grant *exceptions*.

Please raise your voice if you think we should proceed otherwise (or if you think we should not proceed at all!).

Regards,

Alejandro

El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg () escribió:

What's the status of this push? I was delighted to see that Alejandro volunteered to be a motive force on this idea, and have thus refrained (as I am pushing on other ideas, too). But I also don't want this to die. :)

Thanks!

Richard

On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena wrote:

I agree with using the criteria that Richard posted + the addition by Simon. Just in case somebody hadn't looked at the wiki, the criteria would be:

1. The extension is (mostly) conservative: All programs that were accepted without the extension remain accepted, and with the same meaning. 2. New failure modes that become possible with the extension are rare and/or easy to diagnose. (These failure modes include new error messages, wrong inferred types, and runtime errors, for example.) 3. The extensions complement the design of standard Haskell. (This one seems the most subjective.) 4. The extension has been -- and can reasonably be predicted to remain -- stable. 5. The extension is not to gate-keep an advanced or potentially-unsafe feature. 6. The extension is widely-used.

For example, should we add to (6) "in current developments"? What about things like "EmptyDataDecls", which are just straightforward generalizations of what Haskell 2010 already allows, although in practice the only data type you would ever need to be empty is "Void"?

Alejandro

El jue., 17 sept. 2020 a las 16:42, Simon Marlow () escribió:

I think there should be some requirement that an extension be widely-used (for some suitable definition of that), before we ratify it in GHC2020. Some of the extensions that made it past the first round of filtering are not widely-used, and would be therefore probably be controversial additions to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo to name a few that I noticed straight off. I think it's a good idea to be conservative here.

Cheers

Simon

On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud wrote:

There seems to be some question about who should drive this debate. But there is something we all seem to agree on: it is our role, as the steering committee, to announce the criteria by which we intend to judge the reasonableness of each potential candidate extension.

So, let me suggest that we start discussing that, and move back to how this discussion ought to be driven when we are a bit clearer on the criteria.

Richard wrote a bunch of criteria in the wiki page upthread [1]. I think that they are worthy of discussion. So let me ask the question: do we agree with all these criteria? do we want to add more?

[1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=lpOFIx5mBcaUbKIDIhs%2BnAmYd72%2FctVTwij1WJYTVF8%3D&reserved=0

On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena < trupill@gmail.com> wrote:

I would rather make the process Committee-driven, because otherwise it may derail into too many micro-discussions. I think it's better to start a conversation saying "this is our proposal, here are our criteria, here are the exceptions we want to make", and then discuss from there.

Regards,

Alejandro

El mar., 8 sept. 2020 a las 14:01, Eric Seidel () escribió:

I think we may want to have the Committee initiate and drive the process. I think a GHC20XX proposal will turn into a bunch of micro proposals and discussions about individual (groups of) extensions, and it will be hard to track all of the threads of discussion in a single GitHub thread. We’ve dealt with long and contentious discussions before, but they were much more focused than GHC20XX will be, by design.

I suggested earlier that an alternative strategy could be to open a new repo where the community can collaborate on GHC20XX via a familiar PR-based process, with each proposed group of extensions getting its own PR and discussion. There are a few open questions here though. When/how do we decide that it’s time for a new standard? How do we decide when the full proposal is ready for review? Do we need to review and sign off on each group of extensions separately or only the final product?

This process would be a lot more work for us, so I’m happy to try the usual process first, and I’ll be happy to be proved wrong. But we should be prepared to step in and add some more structure if needed.

Regardless, the first step should be to update our docs to express interest in GHC20XX proposals, establish criteria for including language extensions, and outline a process for submitting them.

Eric

Sent from my iPhone

On Sep 8, 2020, at 06:37, Simon Peyton Jones wrote:



Personally I don’t think we should make the Steering Committee responsible for initiating or driving this. We should

· establish the criteria (including some idea of how frequently we’d be open to creating a new GHCxx version),

· express open-ness to a proposal, and then

· review proposals when/if they materialise.

It’d be fine for Alejandro, as an individual, to be a proposer. But that’s different from making the committee *responsible*.

What do others think?

Simon

*From:* Alejandro Serrano Mena *Sent:* 08 September 2020 09:13 *To:* Simon Peyton Jones *Cc:* Richard Eisenberg ; Eric Seidel ; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] GHC 2020

Dear all,

I would really like to move this forward, and I would be happy to put some work on it.

What do you think of the following plan?

- Create a ghc-proposal based on the (awesome) wiki page by Richard. I think the criteria in the wiki are quite nice. Explain that one of the goals is to encompass as many stable extensions as possible.

- Reformat the list to make 3 tables: one for extensions which satisfy all 5 criteria, one for extensions we want to include even if they don't, and one for those which should be rejected in the light of those criteria.

If the process works well, we could think about instaurating a yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.

Regards,

Alejandro

El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via ghc-steering-committee () escribió:

Just back from holiday. Some thoughts

* I don’t think this mailing list is the best place for the discussion. Basically, it's a GHC Proposal, so someone (possibly a committee member, possibly not) should write a proposal, and we should put it through the process.

* We should advertise the criteria, as Richard has done on the wiki page.

* Any such proposal should be informed by data. Notably, extension usage in Hackage, or perhaps Stackage (since it's a bit more curated).

* A proposer might also want to run a public poll, as an additional source of data

* When it comes to the committee, we can (I guess) vote on individual extensions, rather than just accept/reject the whole thing.

I am intrigued by the idea of using Kialo to coordinate discussion. Maybe it'd work better than GitHub? Are there other alternatives? But that's orthogonal to the GHC 2020 idea; let's not conflate them.

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Richard Eisenberg | Sent: 02 September 2020 14:57 | To: Eric Seidel | Cc: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | It seems clear that my wiki idea isn't winning the day -- I never | really liked it either. I'd be fine with either Eric's or Joachim's | approaches. Maybe start with Joachim's approach and then use Eric's | when Joachim's runs out of steam? A big minus, though, to Joachim's | approach is that it seems hard to get good community involvement. | | Richard | | > On Sep 2, 2020, at 8:11 AM, Eric Seidel wrote: | > | > Opening a regular discussion about whether and how we want to work on | GHC 2020 sounds fine, that will also give the community a place to | weigh in. I do think the eventual contents should be informed by the | community though, it shouldn’t just be us working alone. | > | > Sent from my iPhone | > | >> On Sep 2, 2020, at 03:16, Joachim Breitner https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%3D&reserved=0> wrote: | >> | >> Hi, | >> | >> sounds plausible. It would also allow us to use tags to easily | indicate | >> the status (e.g. clearly-not, definitely-yes, kinda-contested…), and | >> then filter by issue to get the current list… | >> | >> But before we go there, shouldn’t we maybe have a discussion first | on | >> | >> * do we even want that? | >> * what are the abstract criteria (or guidelines)? | >> * what is the process? | >> | >> I believe that discussion could be done like any other proposal. | >> | >> | >> As for the process; when I brought up the idea, I was worried about | us | >> spending huge resources discussion individual extensions to death, | and | >> proposed, in the interest of efficiency and getting things done: | >> | >>> The process could be: Every member can nominate any number of | >>> extensions, to include, maybe a small rationale and then we do one | >>> round of independent approval voting, requiring a supermajority to | >>> really only pick uncontested extensions. | >> | >> So instead of long debates, we start with GHC2020 being just those | >> extensions that a supermajority on the committee considers to be ok. | >> | >> This is much more lightweight process that we could get done in a | week | >> or two (maybe using a doodle-like voting page). Maybe we would leave | >> out one or two extension that initially people are reserved about, | but | >> could be swayed after lengthy discussions. But is that worth the | >> lengthy discussion? | >> | >> cheers, | >> Joachim | >> | >> -- | >> Joachim Breitner | >> mail@joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%3D&reserved=0 %2F&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=ddj4e3mS%2F%2FAhpGbMV5NkneCJW1aXe1YKfM4hg0%2FwGNg%3D&reserved=0 %7Cfa6e3a6bcdf | 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D | &reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee@haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=KQfPgn0781%2Fi5JrFyEBp87Tcc3G%2FGiysbqlTM42Xgrw%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=X4VmXP6B65Tp%2Byv77g47%2FJiSx%2FdrScj5n5xMyzJKiik%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=BdY%2Fv6at9nrPOSB4RqbhsDmjKopgJqGlYBEY6XcQhOM%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=r3dK4INyOAgjOC3GmkBGVkTcko6auZjST5815b8Gq9c%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=4YyoqgXgYhjSanhyuMXMjEQsTZm3ux00U6O3mFv274g%3D&reserved=0 %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=rwo%2BaTMPD6sIQAYIcyWg1DU5Ut71bgKxYIdp3mP9Iuo%3D&reserved=0 %7Cfa6e3a6bcdf04ed5 | 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518 | 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D& | amp;reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=hFTP2bNd5ZWcDQ0vH98O3hhwYOp%2BIV0iLwHMTBJZEHI%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977311737&sdata=p895UWSa99PCifyQgpA9WEZKtdgVz4LbPW9y3TCE5%2Bc%3D&reserved=0