Quo vadit GHC2023?

#21

One perhaps unexpected thing GHC2021 is useful for is that it gives GHC developers more confidence to recommend some language extensions for better error messages, see Language Extensions vs. Plain Haskell 98/2010/... · Issue #9 · haskell/error-messages · GitHub

1 Like
#22

This is roughly what happened last year, although there the process to conclude that GHC2022==GHC2021 was very short:

https://mail.haskell.org/pipermail/ghc-steering-committee/2021-October/002620.html

It may well be that we end up with “no change” (and thus no actual definition) for GHC2023, but my sense is that we should look more carefully than last year :slight_smile:

2 Likes
#23

Thanks @nomeata for asking the question.

I’m surprised most responses are from people who’ve not even tried GHC2021. Is it that hard to load GHC 9.2 into a sandbox? I’ve tried it, I don’t like it (not any of 9.0 onwards); I uninstalled it; expect never to go beyond 8.10.

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

That’s tricky: because silently including -XScopedTypeVariables with its silently changing the meaning of forall is what I particularly don’t like.

#25

That’s funny, because it’s exactly these kinds of things that I want from a new standard/GHC20XX. Scoped type variables are useful, but turning them on only when you need them causes issues with existing code. If it had been on from the start you wouldn’t have any problems. Thus having them on by default is good, because you’ll never hit that problem case of them changing the meaning of existing code.

3 Likes
#26

…I’m curious: if e.g. simplified subsumption was the default to begin with, would there have also been no problems with “existing code”?

#27

I have been using GHC2021 in my libraries and partially (yet) at work. I think it is a very welcome initiative. It really helps to have a set of sanctified extensions that don’t have to be deeply questioned for their possible adverse consequences. Then we you add other extensions you can spend a bit of time to wonder why those extensions did not make it to the list and how it could be problematic if they were enabled by default in all projects.

So my suggestion maybe would be to maintain an explicit list of such reasons so that people can be fully aware of what it means to add another extension to their codebase.

5 Likes
#28

Hot take: Default to increasing versions of GHCxxxx (if no changes are proposed, just copy the previous year’s version). If this causes huge problems for the ecosystem due to some particular extension, remove that extension. Every 5 years (say) determine the common set of extensions in the previous years’ GHCxxxx sets and incorporate them (non-optional) into Haskell/GHC.

GHC is already the only implementation and we’re giving up a lot by making maintenance harder by supporting extension-X-on-or-off.

#29

It would seem to be clear that it is too early for a very large portion of the community to be able to give meaningful feedback on GHC2021. The users are simply moving much too slow to answer yet.

For applications I work on, most stick to stackage lts releases, which at the moment precludes using GHC2021. I’m fairly certain I know of a couple of projects are not even on ghc 8.10.7 yet. This seems to be in line with what some others have said here.

For libraries, I would hope to see very little adoption of GHC2021 at this point because it means a lack of compatibility. And that compatibility is not lost when specifying only the extensions that are needed. With that in mind, I would expect a hackage search to turn up very little in adoption for quite some time.

All of that said the language set is a useful stand in for the otherwise stuck report process. Ideally, I’d like to see a series of new reports, to progressively include some items from outside of GHC2021, such as Applicative as a superclass of Monad. Then also what we could from GHC2021 or later, and deprecate/remove those extensions.

More concretely on GHC2021 and a potential next version there are a small handful of extensions that for me would be nice to include in a future version. But would want to be very cautious about adding new extensions going forward. In particular ensuring we do not add sharp corners, make error messages harder to decipher by default, or continually make the syntax of the language complex. Those are all aimed at finding the balance between having a nice set so newcomers do not have to enable a huge list of things, but also keeping the language usable for beginners.

4 Likes
#30

I really like the GHCXXXX concept and hope it will be continued. Rust has editions every few years, and I don’t think that anyone complains about it being too unstable (because of that).
I am using GHC2021 for my applications and I can’t complain. The cabal file is shorter, and I need to make less judgement calls.
In general, I would say, that the committee can probably still evaluate extensions on their merit independently of the users already using GHC2021. If the committee waits until a GHCXXXX version has widespread use, feedback cycles will get very slow and users will need to wait even longer for better iterations. If it turns out, that some extensions are inconvenient in GHC2021 they can be dropped later, e.g. in GHC2024, no reason to hold off on GHC2023 because we might know better later.

7 Likes
#31

Note that part of the motivation was to have it enabled by default in e.g. GHCi, and there, usage is hard to measure. I imagine extensions like e.g. TypeApplications are particularly useful in that context.

1 Like
#32

Absolutely, and not my intention. I know that the latency between decision for GHCxx and widespread use is very large (and unavoidably so), so tying the frequency of updates to the latency would be silly.

#33

Because I think it’s, forgive me, irrelevant to most people, except maybe for tooling that aids beginners.

I’d expect most maintainers to specify exactly what extension they are using.

And yet, I think doing GHCXXXX is worthwhile. It facilitates at least some discussion.

3 Likes
#34

Now that haskell-language-server has mostly caught up I’d expect usage of 9.2+ to increase more quickly.
I personally have found GHC2021 to be extremely pleasant even for code without fancy types. Even a language server prompt to enable tuple section adds some friction which makes it harder for me to stay focused.

I think -XPatternSignatures and -XMethodTypeVariables (once separated) are commonly useful, feel very natural, and in my experience cause little backwards compatibility problems.

If I was the only person affected I’d also add DerivingVia, DerivingStrategies, FunctionalDependencies, and LambdaCase. Though I expect these to be more contentious.

4 Likes
#35

triggered by using the latin phrase but refusing to conjugate the verb. should be “quo vadit ghc2023”

4 Likes
#36

Or “quo vadis, ghc2023?”

2 Likes
#37

cabal init as of cabal-3.8 does list GHC2021 as a language option. It’s not the default option though. Please, open a Cabal ticket if you think that it should be the default. I, for one, think it’s better to align with GHC’s default (which is GHC2021), but when adding this option I decided to go more conservative with the aim of switching the default to GHC2021 at some point, depending on the adoption of the extension and community’s feeling about it.

5 Likes
#38

I am not confident what the best option is. It could be

  1. Haskell2010
  2. the latest GHCxx known to cabal (probably a bad idea)
  3. the latest GHCxx known to the version of (oldest) ghc that is being used
  4. none (meaning you get the latest default of the ghc you are using.)

I think it depends on whether you want to support multiple GHC versions:

  • If you do, because you are building a public library), then option 1 is probably the best. Or option 3, once there is a GHCxxxx supported by all GHC’s you target.

  • You you don’t, and you pin your version of GHC (and likely your library versions as well, with a cabal.freeze file or nix or something like that), then 3 or even 4 might be better.

    If you do that (fixed environment, no intention to upload to hackage), then there are more thing about your Cabal file that you probably want to do differently (maybe no version bounds in build-depends) .

Since cabal init optimizes for the first case of packages publishable to Hackage, then Haskell2010 is probably the better default for now, I’d say.

2 Likes
#39
  1. Haskell2021

I wish :stuck_out_tongue:

Since cabal init optimizes for the first case of packages publishable to Hackage, then Haskell2010 is probably the better default for now, I’d say.

cabal init already puts a very restrictive bound on base, so it basically only allows building with the GHC version being used. Given that, it makes sense to choose option 3. But perhaps a better solution is to change that default base constraint too.

2 Likes
#40

Good point! I like the idea that the current behavior w.r.t. base would make more sense together with the GHCXXXX language. As for changing that behavior: I do find that bound quite annoying at times, but I can’t think of a better default. Can you?

#41

I was thinking that cabal could default to supporting the last N major base versions. The proposed maintainership standards lists 4 years of GHC support as an example of a Gold-Standard requirement, so that would be 7 base versions back (GHC 8.4 with base 4.11).

Another reasonable option would be to have no constraints at all. I do expect packages published on Hackage to have constraints, but I think a large percentage of packages created with cabal init never end up on Hackage, so perhaps we shouldn’t be so strict with the defaults. Especially now that installing libraries system-wide is discouraged in favor of creating one-off packages with explicit dependencies.