haskell-language-server VS ghc-proposals

Indeed, there is a lot of room for improvements. But I just wanted to acknowledge and thank the work of those involved in HLS which IMHO was a game changer in that regard.

Specifically, gchup and HLS are both opensource community efforts. If you want to see HLS work with ghc-9.2.5, you may want to ask https://github.com/haskell/haskell-language-server or, better, provide them a PR that builds HLS with ghc-9.2.5.

Sadly ghcup tui is not available on windows, but you can check the available versions with ghcup list. Hls lists the compatible versions of ghc at their github releases. For 1.8.0.0 I went with 9.4.2. To install it and set it to default you have to use the ghcup install ghc 9.4.2 then the ghcup set ghc 9.4.2. Hopefully this will be useful to someone with the same problem.

Here's an issue I created for it: https://github.com/haskell/haskell-language-server/issues/3348

The code is executed by HLS, see https://github.com/haskell/haskell-language-server/blob/master/plugins/hls-eval-plugin/README.md and then its markdown/html output is displayed by VS Code.

As you can see there, Shake is also a good fit for Cabal scripts. And Cabal scripts work better in 3.8. There are still issues loading them with HLS, but hopefully not for long. For this reason, I also have a build.sh which wraps that, allowing the script to be loaded via GHC directly, but I look forward to being able to remove this.

AFAIK the latest GHC version which the haskell language server (which is what the vs code extension uses) supports is 9.2.2, so not yet, I'd say.

As far as I could see this bug is already reported. It is about stack not being able to handle multi crate project.

I believe you've bumped into this issue: https://github.com/haskell/haskell-language-server/issues/2857

I learned about this when proposing multiline strings in Haskell. The convo there might be of interest to you: https://github.com/ghc-proposals/ghc-proposals/pull/569

This brings up an interesting point. GHC Haskell is still actively being changed and the language is more than 30 years old.

FYI appending a colon to the link seems to mess it up. Here’s the link: https://github.com/ghc-proposals/ghc-proposals/pull/330

I see the remark that c = do { let { a = A }; foo !a } is disallowed because a wouldn’t be in scope. Does this address the issue of shadowing that SPJ brought up on my InlineBindings proposal? Briefly, do { let { a = pure "outer" }; (\a -> putStrLn !a) (pure "inner") } should fail, because which a is referenced by putStrLn !a depends on your choice of desugaring, and it’s especially confusing when it’s not the same one you would’ve gotten without the bang.

Related GHC proposals: * https://github.com/ghc-proposals/ghc-proposals/issues/527 * https://github.com/ghc-proposals/ghc-proposals/pull/64

Then there's the "simple" matter of parsing. As they say, "Mo' syntax, mo' problems". The GHC parser is an absolute beast. When I attempted to implement parsing for an improvement to pattern synonyms which was accepted, I found that I couldn't work out how, even with help from some very smart people. The more syntax there is, the darker the corners get. Best to clean out some crud before moving new stuff in, but it's really hard to break people's programs.

There is a proposal from 2019 but it doesn't seem to have gone anywhere.

I am eager to write strict Haskell. I understand the the -XStrict and Unlifted datatypes help with this. Actually it is interesting that -XStrict does not really cut it, we need unlifted datatypes..

A core feature of the proposal is to chose another operator than . namely because it have weird cross effects with the current module structure.Introducing first-order namespaces without changing the operator have created problems in the past GHC #295. There is an example in the proposal. However, other operators could be used \, #, or ::.