<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 class="gmail_default" style="font-family:tahoma,sans-serif">
So I think a better target is releasing a new edition of the Haskell language, dubbed GHC2024, in 2024.<font color="#888888"><br></font></div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I'd be happy with that too.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 11 Nov 2022 at 20:45, Richard Eisenberg <<a href="mailto:lists@richarde.dev">lists@richarde.dev</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">I somehow like 3 years more than 2 here. One reason: the feedback we would like has yet to materialize, because GHC2021 is still not widely available in industry. Industry is slow! (Example: earlier today I had trouble compiling GHC on my work machine because it uses TeXLive 2012, and sphinx has advanced beyond that.)<br>
<br>
But I also think there's a terminology problem: extension vs language. Why are some features part of the language and some extensions? It's all because of history. But today's programmers do not care about the history.<br>
<br>
There is good news here: GHC2021 is enabled in cabal with `default-language`. And the pragma in Haskell is called {-# LANGUAGE GHC2021 #-}. Hooray!<br>
<br>
So I think a better target is releasing a new edition of the Haskell language, dubbed GHC2024, in 2024.<br>
<br>
Richard<br>
<br>
> On Nov 5, 2022, at 8:24 AM, Tom Ellis <<a href="mailto:tom-hf@tomellis.org" target="_blank">tom-hf@tomellis.org</a>> wrote:<br>
> <br>
> Thanks Simon.<br>
> <br>
> On reflection, I'm not particularly motivated to consult the community<br>
> because the concerns I have impinge most strongly on members of the<br>
> community who are distant from where a consultation could easily<br>
> reach, and on non-but-potential-members of the community who are<br>
> getting a false impression from afar.<br>
> <br>
> I will content myself with elaborating on my concerns and then leaving<br>
> it to the steering committee to take them into account if they see<br>
> fit. To set the scene, everything I write below is presented from the<br>
> point of view of someone who wishes Haskell usage to increase and<br>
> believes that we can't increase Haskell usage by appealing to people<br>
> who are already comfortable with the way the Haskell ecosystem<br>
> currently works: we've already got most of those people.<br>
> <br>
> For the ten years that I have been in the community, Haskell has had a<br>
> (false) reputation, to outsiders, as a fragmented language with<br>
> multiple mysterious things called "language extensions" each of which<br>
> fractures the language in an incompatible way. "It's impossible to<br>
> learn Haskell because there are so many incompatible Haskells" they<br>
> say. It may be hard to believe that this perception exists: as users<br>
> of GHC we know that there are very few extensions that introduce any<br>
> incompatibility with others; extensions typically just remove<br>
> unneccesary restrictions. But, for those of you who don't spend<br>
> far-too-much of your time on discussion fora such as Hacker News and<br>
> Reddit, I can guarantee to you that this objection to Haskell comes up<br>
> *a lot*.<br>
> <br>
> Haskell also has, to both insiders and outsiders, a (true) reputation<br>
> for being an unstable moving target. "It's impossible to learn or use<br>
> Haskell because the language and libraries keep changing", they say.<br>
> This one is easier to believe.<br>
> <br>
> GHC2021 is a wonderful way of dealing with all of the first and part<br>
> of the second objection! I can now respond to complaints of language<br>
> fragmentation and language instability by simply saying "Turn on<br>
> GHC2021 and be happy". This is great news!<br>
> <br>
> (GHC2021 doesn't deal with instability in libraries of course, but I'm<br>
> pleased that there are many people making efforts in that area too.)<br>
> <br>
> I am concerned that GHC2023 would weaken the power of my rejoinder<br>
> "Turn on GHC2021 and be happy". Now I am at risk of the responses<br>
> "But why not GHC2023?", "Haskell introduced a new, incompatible<br>
> language just two years after standardising on GHC2021", "I just spent<br>
> my precious time learning GHC2021, now I have to spend time learning<br>
> GHC2023.". Sure, these responses are based on misunderstandings of<br>
> the technical details. But perceptions really, really matter! If we<br>
> want a large increase in Haskell usage then we have to take<br>
> perceptions into account. We can't substantially increase Haskell<br>
> usage any more by appealing just to our techncial excellence.<br>
> <br>
> If we choose to prioritise business-as-usual, that is, the<br>
> incorporation of highly technically excellent features on a regular<br>
> basis, with no thought to the costs, then the consequence will be<br>
> Haskellers-as-usual: people who value that kind of thing in spite of<br>
> the costs. We already have most of those people. We can't increase<br>
> Haskell adoption that way. If we choose to change tack then we have<br>
> the chance of changing the types of people we pick up as new<br>
> Haskellers, from among those who would never otherwise have considered<br>
> the language.<br>
> <br>
> To put it pithily, Joachim writes in a sibling thread "The point of<br>
> the GHC20xx series is to get (proven, useful, uncontroversial) goodies<br>
> into the hands of our users". Are members of the Haskell community,<br>
> and indeed non-but-potential-members, screaming out for new "goodies"?<br>
> Or are they screaming out for a brief respite from the unforgiving<br>
> churn of the Haskell ecosystem, both real and not-real-but-perceived.<br>
> My experience of the last ten years tells me it's the latter.<br>
> <br>
> To be clear, I personally am very much looking forward to more highly<br>
> technically excellent features, including the exciting ongoing work on<br>
> dependent types, WASM, GHCJS, and so on. It's one of the aspects of<br>
> the community that really inspires and excites me! I personally can<br>
> tolerate the churn. But I don't want those things at the *cost* of<br>
> continuing to push away potential new users who are currently peering<br>
> over the fence, discouraged because they can't tolerate the churn that<br>
> they see, real or perceived.<br>
> <br>
> Now, with my stability hat on, looking from the point of view of<br>
> process design, it's actually *better* for changes to happen in small<br>
> increments, so maybe having GHC20xx every year is actually *better*<br>
> than every five years. I don't wish to advocate for one choice or<br>
> another. Rather I wish to advocate for the point of view that:<br>
> <br>
> Technical excellence matters. Stability and the perception of<br>
> stability matter too.<br>
> <br>
> Tom<br>
> <br>
> <br>
> <br>
> <br>
> 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>
>> 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>
>>> <br>
>> <br>
>> Indeed, we originally said we'd review GHC20xx annually, but I think we<br>
>> might want to consult the community to see if that is too often. There has<br>
>> been an interesting thread<br>
>> <<a href="https://discourse.haskell.org/t/quo-vadis-ghc2023/5220" rel="noreferrer" target="_blank">https://discourse.haskell.org/t/quo-vadis-ghc2023/5220</a>>on the Haskell<br>
>> Discourse.<br>
>> <br>
>> The HF Stability Working Group discussed this on Monday, and I think Tom<br>
>> Ellis (a member of the SWG) is willing to lead a consultation. I think<br>
>> that would be great -- we have no axe to grind here, and I think we'll be<br>
>> delighted to do whatever makes the maximal number of people happy.<br>
>> <br>
>> Tom (cc'd) will write with more info shortly. Sound OK?<br>
>> <br>
>> Simon<br>
>> <br>
>> On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>><br>
>> wrote:<br>
>> <br>
>>> Hi Committee,<br>
>>> <br>
>>> when we defined the process for GHC20xx, as written in<br>
>>> <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>
> 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>
<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>