brandonf2002 / links-lsp

An implimentation of the LSP for the Links programming langauge

links-lsp

An implimentation of the LSP for the Links programming langauge

links-lsp's Issues

Rename

Get rename working. Plain as simple.

Change how the notifications and the init loop match the methods

I just wrote handle_requests to make use of the GATD and this not only looks and feels cleaner but also saves on doing the string comparison twice.

This should be changed in both the handle_notifications and initialize functions too.

Refactor LSP -> lsp_types

Currently we have a dir called LSP that just contains type definitions and helper functions. This should be changed to be called lsp_types for clarity

Using First Class Modules for the Communication

Problem

Currently, the comms are modelled using an ADT that looks like this:

type file = string
type tcp_stream = int

type communication_channel =
  | Stdio
  | Pipe of file
  | Socket of tcp_stream

And is used like:

let read_message ch : string =
  match ch with
  | Stdio -> read_message_stdio ()
  | Pipe f -> failwith "Not implemented"
  | Socket s -> failwith "Not implemented"

Because the communication is only ever chosen when the program starts and is never changed during the execution of the program the use of the match statement will induce unneeded CPU instructions every time a message is sent/received.

Solution

We could make use of first class modules to import only the functionality we need on start up, reducing the extra checks needed during the match statement

Find some way to neatly switch between full and incrimental changes

Add logging to the LSP

This is useful for both me as the dev but also for the end users to debug the server when it inevitably breaks.

There is some standard to logging somewhere, this seems to be evident due to the fact that neovim has the command LSPLog which fetches the logging info for the Language Servers.

3 main textDocument functions

These are 3 required notifications that have to be handled by the LSP. These are:

• textDocument/didOpen
• textDocument/didClose
• textDocument/didChange

Run the parsing initialise once

Currently, this gets run every time we try and parse text, should probably just save the state of the first initialise on start

Completion

Figure out Responce, Batch Responce and Batch Call

Currently we have a match that ends like:

  ...
  | Response _ -> failwith "Response"
  | Batch_response _ -> failwith "Batch_response"
  | Batch_call _ -> failwith "Batch_call");

These should not fail. I'm fine not implementing these but failing seems dumb.

Check what we should do if we don't recive the initalised notification

Figure out the init handshake

What is known so far:

• the client starts the server
• sends an init request (JSON-RPC)
• This contains various sets of info, such as client capabilities, process id, and other client info
• The server should receive these (then do something with the info??)
• The server should then send an init message of its own, containing the server capabilities.
• Then a final message should be sent to the server, to confirm that the client has received the server's response.
• Handshake is now done.
• If a message is sent to the server before the handshake is completed respond with the following error code: -32002

What is not known:

• How this should be modelled using OCamls type system
• If the information sent from the client is of any use to the server.

Get a framework for the actual server working.

Why

Currently, we just read a message, write the contents to a file and terminate. Thats it.

We need to implement some form of read -> process -> write loop.

Problems

This would be easy to do as a single-threaded application. However, there is a chance that there may be messages that are waiting while we process a request.

This is why language servers are typically asynchronous, this is from the LSP spec "Language servers usually run in a separate process and clients communicate with them in an asynchronous fashion."

Diagnostic Information

Modularize The Codebase

Currently all files are in bin/main.ml. This should be fixed

Create a json-rpc library

This should just be a vague wrapper for the yojson library that helps incorporate the json-rpc protocol and some LSP specifics as well.

Testing

Currently my method of testing is just to try it and read the logs. This does not seem great.

However it also seems like a lot of work for a currently unclear amount of benefit.

Look into using threads to read and write message

Idk if these should be virtual or real threads (maybe both? Probably virtual).

But a few implementations of language servers I've seen have used a main thread to process the information and then helper threads whose full jobs are to handle the transfer of data.

TYPECHECKING - LSP Hover request

We need to get links in the LS ASAP.

Once #16 is done this should be high on the list

Create Server Capabilities object

This is sent to the client by the server to update the client with the capabilities of the server. This is sent in the very first message of servers handshake response

ignore casing of header items

Just noting this now so that I don't forget it

How to handle the prased and desugared ASTs

For the completion (And possibly other things down the line) we store the most recently successfully parsed ASTs. This is due to the fact that when completion is actually needed in when the program is in an unparsable state. This is all fine.

The issue is: Should we keep the parsed and desugared trees at the same point in time. To rephrase this somewhat. There are points where the first parse is successful, the desugar fails, should we choose not to update the parsed AST in this case?

Currently we update it, but this might not be the best thing to do. It may be better to keep both at the same "time" state for consistency. I do not know.

Putting it here to fix later.

Do some refactoring for the new types