Lang Server 2.0

[TimWhiting]

No description provided.

[daanx]

Wow -- this was a long time in development since the first contributions by @fwcd ! -- Thank you Tim (@TimWhiting ) for pushing it through and making it work so well. This will be great for Koka and already I start to prefer working from vscode versus the interpreter :-) Thanks so much!

[anfelor]

Wow, this is amazing! Can I already try this out?

Initially, I encountered this error when compiling the project with stack build, but it was fixed by running in stack clean:

<no location info>: warning: [-Wmissing-home-modules]
    These modules are needed for compilation but not listed in your .cabal file's other-modules for ‘main’ :
        Syntax.Lexer
[12 of 15] Compiling LanguageServer.Handler.Completion

/Users/anton/orga/phd/koka/src/Main/langserver/LanguageServer/Handler/Completion.hs:50:22: error:
    Module ‘Syntax.Lexer’ does not export ‘reservedNames’
   |
50 | import Syntax.Lexer (reservedNames, lexing, Lexeme (..), Lex (..))
   | 

Perhaps related to this, should Syntax/Lexer.hs be included in the repository? Stack seems to be happy without it (given that it is auto-generated from the alex file).

Following support/vscode/README.md, I could build the server, but it does not seem to work for me. While it can perform syntax highlighting, I do not see any type hints and many Koka: ... commands like Set compilation target, Restart language server, Clear all global state, or Open samples fail for me with a command '..' not found message. However, it seems to be able to connect to the server when I set koka.languageServer.compiler.

[TimWhiting]

@anfelor

We probably should include a bit more instructions in the readme. I'm assuming you did a npm run build && npm run package and then installed the resulting .vsix for the extension since the commands show up. As far as them failing, it is likely because the compiler found by the extension is an old version that does not have language server support. Setting the compiler config parameter like you did should fix it. In the extension itself in src/workspace.ts line 169 it searches for a Koka development workspace in your home directory under koka. (i.e. $HOME/koka) This will automatically pick up the latest build from stack. So maybe try to develop there? Daan develops in ($HOME/dev/koka), maybe we should have both be checked for developer paths, and recommend using one of those paths in the README.

[anfelor]

@TimWhiting Thanks, moving my Koka installation to ~/koka works!

While setting my koka.languageServer.compiler to the koka binary from current dev did stop the error messages that the extension couldn't connect to the server, it didn't give me type signatures and the Koka commands kept failing. But moving the same installation to ~/koka makes it work perfectly.

[daanx]

Hi @anfelor , good to hear from you and thank you for trying the new language server. With the "run debug|optimized" buttons it is getting better than the interpreter :-)

Strange that it didn't work at first and I think it might be related that it was still pointing to an incorrect Koka compiler version? Did you use stack path --local-install-root -- this may have updated as we use a later lts version.

The extension checks for a latest Koka compiler and prompts to install one if not found (and we plan to use the vscode extension as the main way to install binary koka versions). However, at the moment all recent compilers are v2.4.3 so it cannot detect if the language server is already up-to-date. (We should actually already bump the version to at least detect this situation.)

[TimWhiting]

Maybe @anfelor used a stack path --local-install-root prior to running stack build?

[anfelor]

@TimWhiting @daanx Hmm, it works for me now also with setting koka.languageServer.compiler and I can't reproduce the old behaviour -- it's not really clear to me what went wrong there. I also just updated to the newest Koka release and that works perfectly, including go-to-definition. This is really cool!

[TimWhiting]

Thanks for the feedback! We did add a new setting koka.dev.developmentPath which you can set to the place you clone the Koka repo. It will do a stack path --local-install-root in that directory to find the latest stack build. So it will no longer look in ~/koka anymore unless you edit that setting.