Quo vadit GHC2023?

#1

It’s a year that we released a GHC version with support for -XGHC2021, and we have to start thinking about GHC2023 if we are serious about the idea of continuous improvement.

I’m keen on some feedback about GHC2021. Was it useful to you? Maybe only in some contexts (I could imagine it’s more useful in applications than in libraries that need to support multiple GHC versions)? What would you expect from the future of evolution of this feature?

(Ideally let’s try not to get bogged down by arguing over the inclusion of individual extensions at this point.)

6 Likes
#2

GHC2021 would be much more useful if it could be backported to 8.10 and 9.0. I think it’s very useful but I can’t confirm that because I can’t even use it yet since my workplaces uses 8.10.

10 Likes
#3

Same situation for me as for @tomjaguarpaw. I still haven’t used GHC2021. It was introduced in GHC 9.2. At work we’re still using GHC 9.0 and in my personal projects I just copy my previous project template or use summoner to create my project.

I already have a list of extensions I use in default-extensions in my .cabal file and since I usually support the latest 3 major GHC versions for my Haskell libraries, I’ll probably start using GHC 9.2 somewhere around GHC 9.8. The adoption for GHC 9+ was quite slow compared to the GHC 8+ series so I expect starting to use the new language in 2023 or even 2024.

Unfortunately, backwards compatibility is a real concern (at least for some people). So unless features are backported, they’ll probably will be used much later by library authors and much-much later by more conservative users who prefer stability over pivoting.

6 Likes
#4

-XGHC2021 seems great to me, having looked at what it enables. The main reason I haven’t used it is that I was unaware of it. So my only feedback would be that I’d love cabal or stack to suggest it as an option when starting a project, or HLS to suggest it.

Do you have a sense of what would change / be added in GHC2023?

#5

No, I’m just starting a process to figure that out (and this discussion is part of it). I only expect modest changes, if any, as Haskell hasn’t changed that much in two years I guess.

1 Like
#6

One of the great things that GHC2021 permits is that when non-Haskellers say “I tried Haskell but I had to turn on so many extensions, extensions mean that Haskell is really many incompatible languages”, I can reply “no, just turn on GHC2021 and be happy”. If we get GHC2023 just two years later then my reply is not going to hold much water any longer.

6 Likes
#7

And to be a little more concrete: I would love there to be no more GHC20xx for ten years. Maybe that’s optimistic, but a new one after five years would seem too early. Two years is far too early and almost makes a mockery of the whole endeavour!

5 Likes
#8

Hmm, but isn’t that exactly what GHC tries to do different than the regular (but too infrequent and too conservative) Haskell reports?

Note that GHC uses the latest GHC20xx by default, so your beginners, unless they opt out, will still get the better experience of not having to manually enable lots of extensions, but also don’t have to wait 10 years to get the latest (stable, commonly used) goodies.

If, in your narrative, you think of all GHC20xx as one “give me good defaults” that’s evolving as GHC evolves, doesn’t it then suddenly make sense?

3 Likes
#9

Note that GHC uses the latest GHC20xx by default

Does it? What does that mean? There’s only been one so far. That’s hardly a repeating pattern!

Sure, it makes sense, but it’s not something I want. I want GHC20xx to be a “cheap and liberal language report”. The effort to do a real language report didn’t materialize so we got 95% of the benefit for 5% of the work by declaring a group of extensions “standard”. Like a language report, I do want new ones occasionally but not on a frequency faster than every five years, preferably something closer to ten.

If other people interpreted GHC20xx as “whatever GHCHQ fancies lumping together every couple of years or so” then that’s perfectly valid but firstly not what I want and secondly not particularly useful, I think.

2 Likes
#10

For reference, here’s an example of the kind of confusion I would like GHC20xx to help resolve:

I heard there was such a thing: an effort by GHC to merge the most used ones into the main compiler? Or maybe some kind of default setting?

(I hate the splintering of all the “different Haskells” that exist due to the combinations of chosen language extensions.)

If we have a new GHCxx then we won’t resolve the perception (in my opinion a misperception) that there is a “splintering into different Haskells”. If GHCxx is relatively stable, i.e. there’s a new one only every five years or so at most frequent, then this misperception can be easily addressed and users will have a target they feel comfortable investing a lot of time into studying and using. If we release GHC2023 then they’re going to think “Hey! I’ve only just installed GHC 9.2 and started trying to learn GHC2021! Why are you shifting the goalposts on me?”.

3 Likes
#11

@tomjaguarpaw I would encourage you to read the proposal for the GHC20xx process. It already answers some of your questions, e.g.

When ghc is used without an explicit language choice, the latest GHC20xx known to GHC is used. This applies in particular to uses of ghci.

and

Cadence

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.

[…]

Alternatives

  • We could fix a cadence already; one, two or three years have been proposed.

It was always the intention to update every few years. Five to ten years was not really considered.

2 Likes
#12

That’s very interesting, thanks. I guess I made a false assumption. In any case, I think that this policy should be reconsidered. I don’t see it as particularly useful as it is.

2 Likes
#13

Just chipping in to say that, like others, I haven’t had a chance to use it yet. But tbh I’m usually very conservative in extending syntax; I’ve never had a pressing need for the record extensions, the literals shorthand or type-heavy syntax. I do auto-derive as much as possible though.

One of my work projects is still (happily) on 8.6.5 and for the more experimental stuff I simply turn on extensions on a need basis.

#14

I used GHC2021 as a hobbyist. Loving it so far!
Of course not having to add all the extensions was one of the significant benefits,
but the most important one was knowing which extensions are great and in common usage.

8 Likes
#15

If we have a new GHCxx then we won’t resolve the perception (in my opinion a misperception) that there is a “splintering into different Haskells”.

I think the expectation is that each new version of GHCxx will be largely “accretive”, simply enabling more features in the language. There’s no confusion about which “splinter” to use: always use the latest available version.

I fear slowing down the cadence of GHCxx will lead us to a paralysis similar to that of Haskell2010.

In modern Java, each new release introduces new “preview features”, while formerly experimental features become standard and stable. There’s no expectation of freezing the stabilization of preview features for year-long periods.

2 Likes
#16

The uptake of GHC2021 has been pretty slow so far: Hackage Search

My perspective is that if GHC2023 enables less than, say, 5 new extensions compared to GHC2021 then it causes more harm than good.

6 Likes
#17

If we assume most code on hackage is libraries, and libraries try to be backward compatible with a few years worth of GHC releases, I don’t expect to see much of GHC2021 on hackage yet, and generally a delay. I expect the first adopters are those writing leaf code (applications) in a new project that already uses 9.2. Which is rather specific, I fear.

My perspective is that if GHC2023 enables less than, say, 5 new extensions compared to GHC2021 then it causes more harm than good.

Interesting take. Is it really something we can quantify by numbers? Probably still worth looking at the concrete two, five, eight extensions that would make it in the end to assess whether it’s worth it.

To me, there is value in doing GHC2023 with even few changes, if only to establish a continuous process, and not by accident feed into an expectation that GHC2021 is going to be the latest and greatest for half a decade or more.

8 Likes
#18

Like others, I have had no opportunity to use it yet. But I appreciate the concept and my first instinct was to say, “Yes, good, let’s keep this concept alive with a new version.” But @tomjaguarpaw 's points are not to be quickly dismissed.

I would not be sad if we do, in fact, set up a continuous process, and nevertheless decide that GHC2023 == GHC2021 and thus it doesn’t need to be created (since that would be confusing). 9.x has experienced slow adoption for legitimate reasons, but (imho) exceptional reasons. Let’s not build process around the exceptions, but let’s not ignore the consequences of the exceptions, either.

To address Tom’s concern, I think the benefit of GHC20xx isn’t that it’s a stable standard, but that it’s an up-to-date recommendation/default—with the option to “freeze” it for your package or project. In this way it’s more like the cabal version field than a new Report. That may not be what you want, but I believe it was the original idea and I think it’s valuable.

#19

I fear I may have derailed @nomeata’s original post, which wasn’t really supposed to be about whether we have a new GHC20xx at all. It is, yet again, a shame that Discourse doesn’t have proper threading.

#20

…if you really think anything more needs to be added there.