A Lightweight IDE for SML/NJ

[AGoh2019]

Description

I wonder if anybody contributing design and code for the development of SML/NJ can also consider building a lightweight IDE modelled after the Processing Language IDE or the Python IDLE IDE.

[dmacqueen]

This issue (#275) is a duplicate of issue #270. See the discussion under that issue for more info.

This idea comes up periodically (e.g. Eclipse). Sounds good, but the problem is manpower to pursue such a goal. Looking at the Python IDLE documentation, it looks like it might represent a few man-years of work. Taking the existing Python implementation and translating it into SML (modulo the necessary GUI library) would possibly require a lot less work. Any volunteers?
[My own experience with IDEs consists of using the Symbolics Lisp Machine back in the 1980s, and before that the InterLisp programming environment. At the time, I was happy to give up the IDE, to use emacs instead.] The current light-weight alternative is to construct an LSP interface for SML/NJ, and this may happen. Check out the millet project at https://github.com/azdavis/millet. Millet is not directly useful to us because it is implemented in Rust rather than SML, and it duplicates a bunch of functionality that is part of the compiler, such as parsing and elaboration (type checking).

[mdbergmann]

Just my thoughts:

A full IDE is probably overkill.
An IntelliJ plugin might be doable.
As well as an LSP server written in SML. I've done a rudimentary (supporting showing compile errors, completions and documentation) LSP server for LFE (Lisp Flavoured Erlang) in two weeks evenings. It's not super complicated when you know the runtime and environment a bit, and can focus on the task.
LSP clients already exist for many editors.

(as a side note) I don't get why millet uses Rust rather than SML.

[dmacqueen]

These comments parallel my thinking — I just added a comment to issue #275 at GitHub.com/smlnj/smlnj. Since I plan to be doing a lot of work on the front end (mainly elaboration) of SML/NJ over the next year or two, it would make sense to try to incorporate a LSP interface at the same time. Would you be willing to advise/collaborate on that? Dave

On Sep 16, 2023, at 11:48 AM, Manfred Bergmann ***@***.***> wrote: Just my thoughts: A full IDE is probably overkill. An IntelliJ plugin might be doable. As well as an LSP server written in SML. I've done a rudimentary (supporting showing compile errors, completions and documentation) LFE (Lisp Flavoured Erlang) LSP server in two weeks evenings. It's not super complicated when you know the runtime and environment a bit, and can focus on the task. LSP clients already exist for many editors. (as a side note) I don't get why millet uses Rust rather than SML. — Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGXNPIQFWXIKG27GE4NZBTX2XYBRANCNFSM6AAAAAA4ZF76UY>. You are receiving this because you commented.

David MacQueen ***@***.***

[ratmice]

Since I plan to be doing a lot of work on the front end (mainly elaboration) of SML/NJ over the next year or two, it would make sense to try to incorporate a LSP interface at the same time. Would you be willing to advise/collaborate on that?

Not sure how much time I can dedicate, familiar with lsp, but first time reading through the base protocol or json-rpc that it is based upon. The first two questions I have is
We have a json-rpc library.

There is a comment in the specification, I'll just quote the beginning of the 2nd paragraph.

However, the server may decide to use a parallel execution strategy and may wish to return responses in a different order than
the requests were received. The server may do so as long as this reordering doesn’t affect the correctness of the responses.

from the lsp-specification, which makes me wonder what we would want to be done there. i.e. should it use concurrent ml, and if so
does the json-rpc library require any work to be used as such?

[mdbergmann]

The json lsp protocol is quite simple. I did not use a dedicated json-rpc library but just did the construction and parsing manually. A JSON library is handy though.

In most cases you just have a straight request/response model. But in some cases, like diagnostics, those are notifications and can be sent asynchronously from the server to the client, however usually also triggered by a client request. I.e. when opening existing files and you want to send diagnostics.

Maybe this gives some inspiration: https://github.com/mdbergmann/lfe-ls
In particular: https://github.com/mdbergmann/lfe-ls/blob/master/apps/lfe-ls/src/lsp-proc.lfe

[JohnReppy]

To jump into this thread, I've been puttering around with LSP stuff for the past year or so. Since version 3.17 of LSP, there has been a machine-readable description of the protocol (the so-called "meta model"). I've built some code for generating the encoder/decoders from the meta model that might be useful. This project just lives in my dropbox right now, but I can clean it up and make it available if someone wants to build on it.

[spdegabrielle]

To jump into this thread, I've been puttering around with LSP stuff for the past year or so. Since version 3.17 of LSP, there has been a machine-readable description of the protocol (the so-called "meta model"). I've built some code for generating the encoder/decoders from the meta model that might be useful. This project just lives in my dropbox right now, but I can clean it up and make it available if someone wants to build on it.

@JohnReppy Please publish it publicly as a GitHub repo with a (SML/NJ compatible license so others can take a look, people are more likely to be interested in something they can see. (and don't worry too much about cleaning it up.)

[JohnReppy]

In addition to this discussion, the (now closed) issues #257, #260, and #270 also request this feature. Future discussion of this issue should be here.