some stuff that would be possible with a nrepl that is impossible with LSP:

• iex buffer inside your editor without a terminal emulator. simple buffers are less resource consuming
• work without a project(afaik, all current elixir LS kinda relies on a existing mix project to work)
• no need to implement an expensive protocol to expose functionalities(both LSP and DAP are verbose protocols). this would reduce significantly the load when using the tool
• no need for extra dependencies(now that erlang ships with a json encoder/decoder this could be the base of the communication or even just lines sent through a socket, even less overhead).

The initial objective here is to understand if this is a welcomed idea, we could discuss further details as the discussion moves forward.

I would love this.

Stuff that would be possible and great to have in that scenario would be once IEx stablishes an interface for network, other tools could expose apis ready to be used from the editor. like running credo checks or execute a particular tests and put you on the line that broke for that test and show a pop up with the error. maybe a logger backend that once attached to a editor shows the log as a pop up under the line that logged it.

I think it’s possible to have a nrepl in elixir outside of IEx, but being it inside IEx, we could start decoupling some outputs from being exposed in the shell, this way it’s easier to send it to the editor. I belive there might be some stuff like that already in place for Livebook(i need to take a look in the code).

@mauricio.szabo that works on the nrepl for ruby and wrote the client for clojure nrepl on atom/pulsar did a video showing the powers of nrepl in ruby, i think that’s a good way to see how different and helpful a nrepl is from a usual language server.

Author here, ask me anything :).

So, the project itself is not that hard. nREPL itself is very simple to implement, and even bencode is not that hard (having implemented it in Clojure and ClojureScript, in a purely functional way). It give a huge benefit to development, too.

The most complicated part, for Ruby at least, was (and still is) the actual editor part - parsing code and identifying where we are in the source, and what exactly do we need to evaluate, especially considering all special syntax that Ruby have.

For Ruby, things work quite well because the “binding” of the current “context” (like, inside a method which variables are visible, what are their values, etc) is first-class - meaning that I can “store” this binding in the nREPL side and then evaluate code as if I was still running that method (again, huge debugging capabilities here!). I don’t know how much IEx exposes, but considering that Elixir is a functional language, maybe we don’t even need these “hacks” because we don’t need to create a class, then set attributes, mutate stuff, before we can actually run some function

I remember there was an editor for clojure that allowed viewing of every variable of a call. Rather than doing an IO.inspect and re-running, the last variable was available.

It was a combination of debugger + editor of some kind…I think it was LightTable. Or perhaps emacs also supported it, but it has been roughly a decade, so I don’t remember anymore.

It seems that nREPL could support something like this, do you know if this type of functionality has been implemented for other languages?

I was thinking to approach it with the bare minimum, either json or just plain string(that would be elixir code), this way the editor could just work with interpolation and just use the responses back directly in the editor, with no encoding/decoding overhead.

I was thinking thinking to approach that with delegating it to the nrepl itself… since elixir has the Code.Fragment module. the idea was to send the current entire buffer and send the line+column that your command was being executed.

I’ve actually just copied iex code and i’m trying to make it work with just simple socket and binaries for now, the worse part is that iex expects an executing shell to do it’s work(i guess it relies heavily on the erlang shell if i understood it correctly). i’m thinking to explore livebook code to see if it would be easier to start from there. I wish I had more free time to work on that i’m planning to do a POC of this nrepl based on iex to write a good proposal to send in the language mailing list

LightTable did offer a “watch variable” (I believe) that allowed you to check the contents of the variable, but you had to watch before running the code.

I know FlowStorm (not an editor, but a different kind of debugger) allows you to inspect everything without re-running, and it’s still in active development.

Lazuli (my project for Ruby) does basically the same - it allows you to inspect the contents of a variable without re-running anything, but it’ll show the variable after things happened - meaning that if you have a parameter called a, and that is an empty array, and that gets mutated over and over (even outside the method) the only info Lazuli will have is the final, mutated version - not the original parameter (don’t know if there’s a way around that, to be honest).

@joelwallis just pointed me to this
https://github.com/mjrusso/nexrepl

are you around @mjrusso ?

It’s a shame there’s generally not more interest in this kind of thing, but what can you do ¯\(ツ)/¯ I used the REPL constantly when I was working in Rails, especially for debugging but also for spiking. I do find myself just doing puts debugging most of the time in Elixir since state is much easier to follow in FP. I also find myself spiking less in IEx because it’s a pain to work with for that purpose. This is frustrating because IEx is so good otherwise.

Perhaps it’s the idea that this could compete with LSP? Just guessing here. The cross-editor/cross-language is a very important problem LSP (mostly) solves, but for those of us who are power users of a single editor we never plan on ditching and only work in a few languages, the possibilities that this would open up are exciting.