Working with old versions of GHC in VSCode

[sweirich]

https://github.com/haskell/vscode-haskell/issues/454 is a feature request for better support for working with old versions of haskell-language-server, which is needed for working with older versions of GHC.

This issue is important to me for teaching. For simplicity, I'm using stack for my class this semester and have configured all course projects and autograders to use the same lts. In August, I selected the most recent lts that worked with all of the tools that I wanted to use (hlint, ormolu, vscode) on all platforms. However, in November, haskell-language-server dropped support for GHC-8.10.4 and the auto update meant that vscode stopped working for all of my students. There are workarounds, but I'd like to have a smoother experience.

Following Richard's lead, I'm filing this as an issue in the hope that Haskell Foundation can assist.

[myShoggoth]

I talked to the HLS team about this, and they've made one step towards addressing it: https://github.com/haskell/vscode-haskell/pull/506.

[Ericson2314]

I think an underlying issue here is that Stackage (and much of the community) has been stuck on GHC 8.10. We should definitely be cautious deprecating old versions, but on the other hand, having a large number downstream projects all work to support extra concurrent versions of each of those projects because and upstream bottleneck, is also somewhat wasteful.

Concretely, https://github.com/haskell/vscode-haskell/pull/506 sounds like a good first step, and we should definitely keep 8.10 things working until stackage can advance, but longer term we should try to avoid this "stuck on old compiler" situation in the first place.

[hasufell]

The problem here is that stack has an odd scheme of tying GHC versions to stackage resolvers.

If your project builds with GHC-8.10.4, it will in 98% of the cases also build with GHC-8.10.7 (on the same stack resolver). Supporting 8.10.4 at this point in time really makes very little sense. Stack should simply handle this better.

For simplicity, I'm using stack for my class this semester and have configured all course projects and autograders to use the same lts.

I'd suggest to use cabal instead and then simply use stackage with cabal. There are 3 options for this.

1. https://www.stackage.org/lts-18.26/cabal.config (and any other resolver) can be saved as cabal.project.freeze and you get stackage + can easily use packages outside of stackage
2. you can use the latest cabal pre-release 3.8.0.20220526 (can be installed via ghcup after enabling pre-release channel) and then use the new import feature to directly import those URLs from point 1 in your cabal.project without saving them manually
3. if you have more elaborate stack.yaml files, you can use https://hackage.haskell.org/package/stack2cabal to convert

If you want to stick to stack, check out the documentation, which explains how to overwrite GHC version for stack.

---

VSCode extension at this point in time supports installing older toolchains and HLS versions easily:

• if your project sets a specific resolver, it should in fact automatically figure out the GHC version of that solver and the latest corresponding HLS release that supports this GHC version
• if you want to force a specific HLS version, you can do so as well: https://github.com/haskell/vscode-haskell#setting-a-specific-toolchain
• to see which GHC versions are supported by a particular HLS version, you can look here:
  • https://haskell-language-server.readthedocs.io/en/latest/supported-versions.html#current-ghc-version-support-status
  • https://github.com/haskell/ghcup-metadata/blob/master/hls-metadata-0.0.1.json