Language Server Protocol (LSP) implementation

[ss2165]

See https://microsoft.github.io/language-server-protocol/

An implementation of the LSP for the guppy language to allow features like auto complete and type checking with knowledge of the guppy type system. This will make user experience in contexts like Visual Studio Code much much better.

The how is tricky - ideally we want to piggy back off existing Python LSPs and make minimal changes. Specifically since guppy exists inside python programs, what we probably want is an extension to a Python LSP that can detect guppy regions and switch modes. This issue should be fleshed out with more design ideas.

[mark-koch]

See this guide for how to do LSPs for embedded languages:

https://code.visualstudio.com/api/language-extensions/embedded-languages

[tatiana-s]

Just some initial thoughts:

• Compared to the example in the embedded language server guide, where the embedded language is distinct, we might want some python server capabilities work on Guppy code, as well as some capabilities that work across both (for import resolution for auto-completion for example). Especially if we end up having things like comptime mode or .gpy files. So it potentially becomes a bit more complicated than just calling a different language service depending on file region.

  • The most popular python language server implementations (for example https://github.com/python-lsp/python-lsp-server/tree/develop/pylsp but there are more - which also poses the question of which server we'd want to extend or integrate with if we go down this route) are structured into plugins for various capabilities that can be enabled / disabled to create custom servers in theory, but that doesn't take into account different regions.
  • You could have the Guppy server redirect requests to another Python server for python regions and then redirect the response to the client?
  • Alternatively, we could use some of the language services the existing python servers use directly, namely most of them seem to be based on https://github.com/davidhalter/jedi. Possibly a bit more effort in terms of writing the actual server compared to the idea above but also more flexibility and less overhead?
  • I assume it would be best to write the server in Python to make it easy to integrate with the compiler (see below), in which case https://github.com/openlawlibrary/pygls will probably be useful (the VSCode client needs to be written in JavaScript/TypeScript.)

• Another important implementation component to consider is that for any form of analysis such as type checking, while we probably want to try to rely on the existing analyses implemented in the Guppy compiler as much as possible, integrating them into an LSP will require some modification / extension. You want the IDE to not just report the first error it finds, but rather collect all of them and be able to emit them in a way that the server can can send back a diagnostics response with a list of them and their locations.

• Worth noting that there are some specific LSP requests / responses that need to be implemented to support notebooks, which seems to be a common document type to write Guppy in.

[ss2165]

Does lsp workloads on the guppy checker have any performance implications? Can we come up with performance lines we have to cross to have a decent real-time lsp experience?