GHCi/repl support?

[goldfirere]

Apologies if I've just missed a piece of documentation, but I'm wondering if there's a way to load an open file into GHCi.

Context: I'm switching to VSCode from emacs, where my usual workflow involves loading into GHCi several times every minute. With HLS giving me quick feedback, this isn't so necessary in VSCode, but it's still sometimes nice. (Example: sometimes I might want to see an error with -fprint-explicit-kinds enabled.)

I can, of course, open a terminal and run GHCi there. But this is still not quite as convenient as I'd like. Now, to load, I have to save my file, switch to the terminal window, reload, and then (perhaps) switch back to my file.

Is there a better way? If not, can this be a feature request to add one?

Thanks!

[jneira]

hi @goldfirere, nice to read you here 🙂
As most of other lsp features integration with ghci belongs to the server part (https://github.com/haskell/haskell-language-server)
There is a long standing ticket about: haskell/haskell-language-server#477

Quoting @alanz:

Haskell is legendary as a REPL driven language, via ghci. This is the last major piece missing from our IDE offering.

It has even a sketch of the design of the feature, but nobody has tackled it 😟
A poor's man repl could be the eval plugin: https://github.com/haskell/haskell-language-server/tree/master/plugins/hls-eval-plugin#readme

[lukel97]

Perhaps there could be a VS code command (for the vscode-haskell plugin only, outside of the scope of LSP) that opens up a new terminal and calls {ghc,cabal,stack} repl with the currently opened file. And when the file is saved, sends :r into the repl or equivalent.

[goldfirere]

Thanks for the responses. If it's helpful, I've filed haskellfoundation/tech-proposals#11 requesting Haskell Foundation attention / resources here, as I think supporting developer tooling, in general, is one of the more impactful ways the HF could help us all.

[jneira]

Perhaps there could be a VS code command (for the vscode-haskell plugin only, outside of the scope of LSP) that opens up a new terminal and calls {ghc,cabal,stack} repl with the currently opened file. And when the file is saved, sends :r into the repl or equivalent.

hmm that could work but it would need some work here, which will become obsolete after support in the server. So it would depend on how much time would cost to make the workaround here 😺

[alanz]

Perhaps there could be a VS code command (for the vscode-haskell plugin only, outside of the scope of LSP) that opens up a new terminal and calls {ghc,cabal,stack} repl with the currently opened file. And when the file is saved, sends :r into the repl or equivalent.

That is exactly what the debug adapter protocol (DAP) allows. The key is to get the DAP session talking to the same HLS server, which then manages context and an interpreter. And I have always had the idea that the external interpreter can help here, as you can run it with separate stdio pipes using a hook, and then it runs in its own process, separate from the HLS/GHC session.

We are doing something similar in the erlang language server.

[jneira]

So support for DAP and repl could come together? that sounds great

[alanz]

So support for DAP and repl could come together? that sounds great

Yes, and you potentially have a lot of options as to where you run the REPL too, based on launch configurations which are user configurable.

And as I pointed out before, there is already DAP support for GHC, using the Phoityne VSCode extension. Which means the protocol implementation in haskell for the GHC side already exists. The pieces should be to adapt that to run under HLS using the external interpreter, and orchestrating things so that both the LSP and DAP sessions talk to the same executable.

[jneira]

Well i think we could close this one and keep it only in the server