<div dir="ltr"><div>I would really like this effort not to die, so I've given the proposal another push. Following the comments from Simon and Joachim, I've re-framed the proposal as laying down a process to create new "language versions" yearly. The idea is to have one of these every year (or 2, or 3, whatever is decided), coinciding with the spring release of GHC. <a href="https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md">https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md</a></div><div><br></div>I think it's important for the community to be involved in the process. If it's clear that an extension is loved by most of the community, that's a big plus for acceptance. In addition, if we come with a list ourselves, we risk having made choices which only show our (biased) point of view.<br><div><br></div><div>Since in the first round the possible list of extensions may be quite big, we might introduce a "fast-lane process" for this one time, for extensions like EmptyDataDecls or different number formats which seem to have unanimous support.</div><div><br></div><div>Looking forward to hearing from all of you,</div><div>Alejandro<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El lun., 5 oct. 2020 a las 12:07, Joachim Breitner (<<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Am Montag, den 05.10.2020, 10:21 +0100 schrieb Simon Marlow:<br>
> > Personally, I would also like to come up with general guidance. Do<br>
> > we expect *any* extension fulfilling the criteria to be included?<br>
> > <br>
> <br>
> Let's be conservative: if there's controversy around a particular<br>
> extension, default to not including it in GHC2020.<br>
<br>
that was a core idea of my original process proposal:<br>
<br>
Without long, time-consuming and process-heavy debate around each<br>
extension, let’s all of us individually assemble a list of extensions,<br>
and turn that into GHC2020. (Maybe for extensions that were not on the<br>
list by only one or two give them a chance to reconsider).<br>
<br>
This way there is still a chance that it'd become GHC2020, and not<br>
GHC2021 or GHC2022, or just fizzle…<br>
<br>
And it would hopefully be the a GHC2020 that contains all the low-<br>
hanging, non-controversial fruit. This also means that GHC2020 has a<br>
good chance of actually getting used. Which means for the work for<br>
GHC2021, picking the next set of extensions, is actually relevant and<br>
meaningful.<br>
<br>
<br>
And if something doesn’t make it into GHC2020 that maybe should have?<br>
No big deal, as Simon says.<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
<br>
-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>