[ghc-steering-committee] GHC2023

[Simon Peyton Jones]

>
> So I think a better target is releasing a new edition of the Haskell
> language, dubbed GHC2024, in 2024.
>

I'd be happy with that too.

Simon

On Fri, 11 Nov 2022 at 20:45, Richard Eisenberg <lists at richarde.dev> wrote:

> 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.)
>
> 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.
>
> There is good news here: GHC2021 is enabled in cabal with
> `default-language`. And the pragma in Haskell is called {-# LANGUAGE
> GHC2021 #-}. Hooray!
>
> So I think a better target is releasing a new edition of the Haskell
> language, dubbed GHC2024, in 2024.
>
> Richard
>
> > On Nov 5, 2022, at 8:24 AM, Tom Ellis <tom-hf at tomellis.org> wrote:
> >
> > Thanks Simon.
> >
> > On reflection, I'm not particularly motivated to consult the community
> > because the concerns I have impinge most strongly on members of the
> > community who are distant from where a consultation could easily
> > reach, and on non-but-potential-members of the community who are
> > getting a false impression from afar.
> >
> > I will content myself with elaborating on my concerns and then leaving
> > it to the steering committee to take them into account if they see
> > fit.  To set the scene, everything I write below is presented from the
> > point of view of someone who wishes Haskell usage to increase and
> > believes that we can't increase Haskell usage by appealing to people
> > who are already comfortable with the way the Haskell ecosystem
> > currently works: we've already got most of those people.
> >
> > For the ten years that I have been in the community, Haskell has had a
> > (false) reputation, to outsiders, as a fragmented language with
> > multiple mysterious things called "language extensions" each of which
> > fractures the language in an incompatible way.  "It's impossible to
> > learn Haskell because there are so many incompatible Haskells" they
> > say.  It may be hard to believe that this perception exists: as users
> > of GHC we know that there are very few extensions that introduce any
> > incompatibility with others; extensions typically just remove
> > unneccesary restrictions.  But, for those of you who don't spend
> > far-too-much of your time on discussion fora such as Hacker News and
> > Reddit, I can guarantee to you that this objection to Haskell comes up
> > *a lot*.
> >
> > Haskell also has, to both insiders and outsiders, a (true) reputation
> > for being an unstable moving target.  "It's impossible to learn or use
> > Haskell because the language and libraries keep changing", they say.
> > This one is easier to believe.
> >
> > GHC2021 is a wonderful way of dealing with all of the first and part
> > of the second objection!  I can now respond to complaints of language
> > fragmentation and language instability by simply saying "Turn on
> > GHC2021 and be happy".  This is great news!
> >
> > (GHC2021 doesn't deal with instability in libraries of course, but I'm
> > pleased that there are many people making efforts in that area too.)
> >
> > I am concerned that GHC2023 would weaken the power of my rejoinder
> > "Turn on GHC2021 and be happy".  Now I am at risk of the responses
> > "But why not GHC2023?", "Haskell introduced a new, incompatible
> > language just two years after standardising on GHC2021", "I just spent
> > my precious time learning GHC2021, now I have to spend time learning
> > GHC2023.".  Sure, these responses are based on misunderstandings of
> > the technical details.  But perceptions really, really matter!  If we
> > want a large increase in Haskell usage then we have to take
> > perceptions into account.  We can't substantially increase Haskell
> > usage any more by appealing just to our techncial excellence.
> >
> > If we choose to prioritise business-as-usual, that is, the
> > incorporation of highly technically excellent features on a regular
> > basis, with no thought to the costs, then the consequence will be
> > Haskellers-as-usual: people who value that kind of thing in spite of
> > the costs.  We already have most of those people.  We can't increase
> > Haskell adoption that way.  If we choose to change tack then we have
> > the chance of changing the types of people we pick up as new
> > Haskellers, from among those who would never otherwise have considered
> > the language.
> >
> > To put it pithily, Joachim writes in a sibling thread "The point of
> > the GHC20xx series is to get (proven, useful, uncontroversial) goodies
> > into the hands of our users".  Are members of the Haskell community,
> > and indeed non-but-potential-members, screaming out for new "goodies"?
> > Or are they screaming out for a brief respite from the unforgiving
> > churn of the Haskell ecosystem, both real and not-real-but-perceived.
> > My experience of the last ten years tells me it's the latter.
> >
> > To be clear, I personally am very much looking forward to more highly
> > technically excellent features, including the exciting ongoing work on
> > dependent types, WASM, GHCJS, and so on.  It's one of the aspects of
> > the community that really inspires and excites me! I personally can
> > tolerate the churn.  But I don't want those things at the *cost* of
> > continuing to push away potential new users who are currently peering
> > over the fence, discouraged because they can't tolerate the churn that
> > they see, real or perceived.
> >
> > Now, with my stability hat on, looking from the point of view of
> > process design, it's actually *better* for changes to happen in small
> > increments, so maybe having GHC20xx every year is actually *better*
> > than every five years.  I don't wish to advocate for one choice or
> > another.  Rather I wish to advocate for the point of view that:
> >
> >  Technical excellence matters.  Stability and the perception of
> >  stability matter too.
> >
> > Tom
> >
> >
> >
> >
> > On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
> >> Another year has passed, and if we are serious with the idea that
> >>> GHC20xx is a continuous thing, we should probably start defining
> >>> GHC2023 – even if it is just a small delta.
> >>>
> >>
> >> 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 interesting thread
> >> <https://discourse.haskell.org/t/quo-vadis-ghc2023/5220>on the Haskell
> >> Discourse.
> >>
> >> 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.
> >>
> >> Tom (cc'd) will write with more info shortly.  Sound OK?
> >>
> >> Simon
> >>
> >> On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <
> mail at joachim-breitner.de>
> >> wrote:
> >>
> >>> Hi Committee,
> >>>
> >>> when we defined the process for GHC20xx, as written in
> >>>
> >>>
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst
> >>> we wrote
> >>>
> >>>   Likely, the first iteration of this process will be vastly different
> >>>   from the following ones: The first one is expected to add a large
> >>>   number of uncontroversial extensions; so the next iteration will
> >>>   likely only make a smaller, but more controversial change.
> >>>
> >>>   Therefore, this proposal does not commit to a fixed cadence.
> >>>   Instead, 6 months after the first release of a version of GHC that
> >>>   supports a GHC20xx set, we evaluate the outcome, the process, and
> >>>   the perceived need of a next release. At that time we will refine
> >>>   the processes, if needed, and set a cadence.
> >>>
> >>> The first version of GHC that supported GHC2021 was 9.2, released in
> >>> October 2022.
> >>>
> >>> Last fall we said that not enough time has passed to do such an
> >>> evaluation, and we skipped defining GHC2022.
> >>>
> >>> Another year has passed, and if we are serious with the idea that
> >>> GHC20xx is a continuous thing, we should probably start defining
> >>> GHC2023 – even if it is just a small delta. This e-mail tries to
> >>> kickstart that process.
> >>>
> >>>
> >>> Last time we did a relative elaborate thing where we voted on
> >>> essentially _every_ extension. I think that made sense for the first
> >>> iteration, where we had to winddow down the likely extensions. But now
> >>> we have a base line (GHC2021), and are asked to find a suitable delta,
> >>> and I’d go for a nomination-based approach: Committee members can
> >>> propose adding (or removing, in theory) specific extensions, and then
> >>> we vote only on those. Does that sound reasonable?
> >>>
> >>> Does anyone have any insight from the real world? Has GHC2021 helped
> >>> our users? And if not, why not?
> >>>
> >>> What kind of hard data would you like to see, if any?
> >>>
> >>> (I’m a bit wary of spending too much time writing scripts to scrape
> >>> hackage, for example to see which extensions people tend to enable _in
> >>> addition_ to GHC2021, only to see that libraries on hackage are
> >>> understandably slow to use default-language: GHC2021, as that’s not
> >>> great for backward compat for now. But I am also not sure where to look
> >>> for good data…)
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221111/c04344f0/attachment-0001.html>