Question - Could an embedded scripting interpreter at the same time be a language server?
ceesstuff.github.io
cross-posted from: https://programming.dev/post/1941692
cross-posted from: https://programming.dev/post/1941671
Details in the link of the headline.
You are viewing a single comment
These were a bit difficult to answer, cause i dont know exactly what youre after - precise examples such as given in question 1 would be helpful. I could be way off base on what you were asking about in your questions.
In general i think you might want to look into image based programming if you havent already (e.g. smalltalk systems, lisp machines, etc.) as many of these provide language server esq connections to their editor. Of note is interlisp-d with its structural editor, which if i remember right edits the source code data structures in memory.
Regarding Q1: this workflow has been implemented in various languages for a long time. The one i am most familiar with is the swank/slynk server for CL. If i remember right it opens up its own thread to process everything, and communicates on a specific port.
Regarding Q2: perhaps im misunderstanding or just forcing my own perceptions onto the question, but this seems to be more an issue of session management within the LSP client; assuming communication over a specific port, its more about the client figuring out which commands to send to which port.
Regarding Q3: im probably misunderstanding this one, because it seems like a duplicate of question 2 with some extra requirements
Regarding Q4: this can also be done. For loading from markup see literate programming (theres a CL system for loading systems from org files called literate-lisp). For loading from the internet and databases, im unsure what you mean; whether source code or byte code or machine code or what have you its all just ordered information, which can be grabbed from its storage location with the right tools (web client, db bindings, etc).
Hopefully all that was helpful :)
That was helpful, thanks.
As for LSP specifically, and in particular for Q2 & Q3: You are correct, those were meant to be very specific to session management and capabilities of existing, established protocol implementations of LSP. Would an implementation of those work without modifying editors? Looking at VSCode, LSP seems to be more of a guideline and it expected to provide your own LSP client plugin anyway, so it probably is less of a problem there. But some editors (e.g. Helix and Emacs) apparently have their official implementation.
On a second read, I think I should have worded the question in the titel and parts of the post differently. It's probably not all important that the interpreter frontend is the LSP server as much as that they live in the same process. Because what the graphics are supposed to show is, this would avoid manually feeding the LSP server with function signatures.