<div dir="ltr"><div>We could have a look at the extensions that almost made the cut in 2021 and autonominate them.<br></div><div><br></div><div>What I would like to nominate myself are:<br></div><div>- SimplifiedSubsumption</div><div>- ImpredicativeTypes<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
Does anyone have any insight from the real world? Has GHC2021 helped<br>
our users? And if not, why not?</div></blockquote><div><br></div><div>I haven't had feedback come my way. I do fine GHC2021 quite liberating, honestly.</div><div><br></div><div>On the other hand, there is one annoyance that I found but didn't have time to investigate: it seems that at least Stack, maybe Cabal, when starting a ghci process (e.g. for the language server) ends up having a ghci with GHC2021 turned on, even if the default language for the project is Haskell2010. This means that you get different error messages in your build and language server. Even if the programmer is unaware of GHC2021. But it probably shouldn't affect the current discussion.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 1, 2022 at 3:05 PM Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Adding Tom Ellis (thank you Jakob).</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:tahoma,sans-serif">
Another year has passed, and if we are serious with the idea that<br>
GHC20xx is a continuous thing, we should probably start defining<br>
GHC2023 – even if it is just a small delta. <br></div></blockquote><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Indeed, we originally said we'd review GHC20xx annually, but I think we might want to consult the community to see if that is too often. There has been an <a href="https://discourse.haskell.org/t/quo-vadis-ghc2023/5220" target="_blank">interesting thread </a>on the Haskell Discourse.</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">The HF Stability Working Group discussed this on Monday, and I think Tom Ellis (a member of the SWG) is willing to lead a consultation. I think that would be great -- we have no axe to grind here, and I think we'll be delighted to do whatever makes the maximal number of people happy.</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Tom (cc'd) will write with more info shortly. Sound OK?<br></div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<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 Committee,<br>
<br>
when we defined the process for GHC20xx, as written in <br>
<a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst</a><br>
we wrote<br>
<br>
Likely, the first iteration of this process will be vastly different<br>
from the following ones: The first one is expected to add a large<br>
number of uncontroversial extensions; so the next iteration will<br>
likely only make a smaller, but more controversial change.<br>
<br>
Therefore, this proposal does not commit to a fixed cadence.<br>
Instead, 6 months after the first release of a version of GHC that<br>
supports a GHC20xx set, we evaluate the outcome, the process, and<br>
the perceived need of a next release. At that time we will refine<br>
the processes, if needed, and set a cadence.<br>
<br>
The first version of GHC that supported GHC2021 was 9.2, released in<br>
October 2022.<br>
<br>
Last fall we said that not enough time has passed to do such an<br>
evaluation, and we skipped defining GHC2022.<br>
<br>
Another year has passed, and if we are serious with the idea that<br>
GHC20xx is a continuous thing, we should probably start defining<br>
GHC2023 – even if it is just a small delta. This e-mail tries to<br>
kickstart that process.<br>
<br>
<br>
Last time we did a relative elaborate thing where we voted on<br>
essentially _every_ extension. I think that made sense for the first<br>
iteration, where we had to winddow down the likely extensions. But now<br>
we have a base line (GHC2021), and are asked to find a suitable delta,<br>
and I’d go for a nomination-based approach: Committee members can<br>
propose adding (or removing, in theory) specific extensions, and then<br>
we vote only on those. Does that sound reasonable?<br>
<br>
Does anyone have any insight from the real world? Has GHC2021 helped<br>
our users? And if not, why not?<br>
<br>
What kind of hard data would you like to see, if any?<br>
<br>
(I’m a bit wary of spending too much time writing scripts to scrape<br>
hackage, for example to see which extensions people tend to enable _in<br>
addition_ to GHC2021, only to see that libraries on hackage are<br>
understandably slow to use default-language: GHC2021, as that’s not<br>
great for backward compat for now. But I am also not sure where to look<br>
for good data…)<br>
<br>
Cheers,<br>
Joachim<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>
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>
</blockquote></div></div>
_______________________________________________<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>