Create Dhall language server

[Gabriel439]

The language server project allows languages to build a server that implement the language server protocol and get widespread support for every editor that implements the language server client. As a bonus, many languages have already library support for the language server protocol. Language server implementations are not an all-or-nothing proposition. You can implement subsets of functionality and gradually support more as time goes on.

Note that I'm opening this against the dhall-lang repository and not the dhall-haskell repository because this server might not necessarily be implemented in Haskell.

[jbmusso]

On syntax highlighting. As of today it looks like this isn't yet supported at the language server level but must be handled by clients. There's an ongoing pull request microsoft/vscode-languageserver-node#367
Related: microsoft/language-server-protocol#513

[PanAeon]

Hi, I'm interested in learning LSP protocol, and have some spare time at the moment. So if nobody is working on this at the moment I can pick it up.

[Gabriel439]

@PanAeon: Yeah, go for it!

[Profpatsch]

In the meantime, here’s a minimal flycheck plugin for emacs that kind of works: https://github.com/Profpatsch/dhall-flycheck

[PanAeon]

Hi, as soon as I said that "I have some spare time" suddenly it disappeared, as usual :)
In principle, I've got something usable at this point:

I'm deliberately using https://github.com/alanz/haskell-lsp for the server part, as we both can get existing functionality from it and contribute back to the project.
At this point I want to clean-up the code, and add syntax highlighting before going "public".
For now I suggest we support only latest released version of the language, and add multi version support as the need arise. Users would likely have to build/install a separate server executable for each version of dhall, which is a bit inconvinient in my opinion.

[Gabriel439]

@PanAeon: Very nice work! I'm really impressed

I also think it's fine to only support the latest version of the language. I expect newer versions to be reasonably backwards compatible with older versions, especially now that hashes are more stable. The main exception is when we occasionally remove language features after a long deprecation cycle (such as the constructors keyword).

Whenever you are ready to release I can also help set up CI to automatically build downloadable executables that people can use.

[Profpatsch]

@PanAeon Do you handle caching imports in-memory? That’s the thing I stumbled over with dhall-flycheck, because some imports take half a second or more to be read, even from disk cache on an SSD.

[PanAeon]

@Profpatsch I'm not there yet. At this stage I just want to make sure that users will get diagnostic errors on file save, nothing will blow apart and users get more or less straitforward way to build/install the lsp server. I'll create an issue for the import caching, and add dhall-flycheck reference to it.

[Gabriel439]

@PanAeon: Right now I'm writing up a Google Summer of Code project idea (see: haskell-org/summer-of-haskell#90) for a student to work on a Dhall language server, preferably building on what you have done so far. Would you be interested in co-mentoring a student on this project with me?

[Gabriel439]

Here is the Google Summer of Code project sketch for reference: haskell-org/summer-of-haskell#103

[Profpatsch]

@PanAeon I found a way to cache remote files in-memory, upgrading dhall-flycheck to something like a LSP light: Profpatsch/dhall-flycheck@f7a06c1

Though I haven’t integrated it into the emacs source yet, dhall-flycheck --forever checks files and caches imports.

The support was already there, all I did was push an initial cache to loadWith and add some threading. This is the interesting part:

https://github.com/Profpatsch/dhall-flycheck/blob/f7a06c1f7607deb2063eae7b670c9a7a789e96bc/src/Dhall/Flycheck.hs#L222-L236

[PanAeon]

@Gabriel439 Well, I can provide a technical help for the student. I'm less confident in evaluating work, setting deadlines, etc...

[PanAeon]

Thank you @Profpatsch this is really good work!!! I think I'll add some timeout setting and/or command to flush remote caches. Also for local files from a same workspace cache invalidation should be quite straightforward.

[Gabriel439]

@PanAeon: Then I can go ahead and take care of mentoring the student. All I need is some time to familiarize myself with the codebase before the project begins

[PanAeon]

@Gabriel439 I have pushed extension to the VSCode Marketplace.
Only diagnostics on file save is provided (although I think that 'errors as you type' would be an overkill at this moment).
Right now users can build the server executable from source using stack (lts-13.0), instructions are provided. I think the next thing I'll do is set-up Travis CI. I plan uploading the executables to the Bintray. If you have a ready template for the stack on TravisCI that would be super useful.

[Gabriel439]

@PanAeon: Awesome! Thank you so much for doing this 🙂

[Gabriel439]

@PanAeon: Would it be possible to merge https://github.com/PanAeon/dhall-lsp-server as a subproject of https://github.com/dhall-lang/dhall-haskell? The main reasons I ask are:

• This would allow me to easily reuse the CI infrastructure from the dhall-haskell to create pre-built LSP executables for Linux/Windows/OS X (so that users don't have to build the project themselves from source)
• You'd get fixes to your project for free if I make any breaking changes to the dhall Haskell package because a successful build of your project would become a requirement for merging any change to the core package

[PanAeon]

Well, I think it's success, for me at least. :) I'll try to do this in the next couple of days.

[PanAeon]

This is the pull request dhall-lang/dhall-haskell#843 I had to change resolver for Appveyor to nightly-2018-12-17, because of the bug of ghc-8.6.3 on Windows. Also I haven't updated the nix build.

[Gabriel439]

I'll mark this as closed by dhall-lang/dhall-haskell#843

There will probably be more feature we could potentially add, but those can be tracked in follow-up tickets for more specific requests

@PanAeon: Thanks again for all your work on this! 🙂