Giters

leostera / caramel

:candy: a functional language for building type-safe, scalable, and maintainable applications

Home Page:https://caramel.run

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Tooling support

leostera opened this issue · comments

commented

We'll need things like:

Formatting

Calling caramel fmt should reformat all inputs.

Doc Generation

Calling caramel docs *.mli *.rei --output ./docs should create docs from those interface files.

Language Server

What I'm considering atm is bundling Merlin within Caramel, so we have control over the subset of the language being accepted.

Calling caramel language-server should be the equivalent to booting a Merlin daemon, and we'll need a way to create the right .merlin files as well, possibly through a separate command that can be properly guided by a build system (e.g. caramel language-server setup ./path/to/lib/a ./path/to/lib/b ...)

REPL

TBD

commented

Language Server

[...]

Calling caramel language-server should be the equivalent to booting a Merlin daemon, and we'll need a way to create the right .merlin files as well, possibly through a separate command that can be properly guided by a build system (e.g. caramel language-server setup ./path/to/lib/a ./path/to/lib/b ...)

Besides the fork of Merlin, we'll also need our custom language server supporting the standard MS protocol (and running Merlin behind be scene to do the hard work, as you suggested!)
I suppose we can fork either Erlang LS or OCaml LS, or even Elixir LS which is more mature, and work on that. It's a shame that Erlang LS/Elixir LS don't rely on a shared library implementing a language agnostic LSP.

I guess the biggest challenges will be:

  • customizing Merlin with our custom syntax
  • supporting interop with at least Elixir and Erlang at the source code level
  • handle multiple build systems (rebar3, mix but also, opam/dune?). For that feature, we can eventually use the Build Server Protocol (it is used in Scala LSP for instance)
commented

I've been looking more into the ocaml-lsp project and I think it makes most sense to vendor since it already comes with Merlin vendored as well.

On top of this, we may get away by submitting a patch to the vscode-ocaml-lsp plugin that makes the actual lsp binary path configurable so it points to caramel lsp instead. I can't promise it'll be that easy, but it can't be that hard 🙌🏽

commented

Yes!
We might benefit from looking into that project: https://github.com/axelson/ls_proxy
@axelson recommended it ^^, he's the maintainer of elixir-ls

commented

I'd love to collaborate on LSP Proxy! It's a bit rough around some of the edges but it can be very helpful in understanding all of the messages that are going back and forth between the server and client.