tonsky / Clojure-Sublimed

Clojure support for Sublime Text 4
MIT License
359 stars 22 forks source link

Possibility of extendable socket REPL evaluation #98

Closed jo-sm closed 1 year ago

jo-sm commented 1 year ago

Hi there 👋 Firstly, thanks for the work on Clojure-Sublimed, it's great to see more devs using Clojure and Sublime (and I'm glad I'm not alone in using Sublime 😁).

I'm the primary maintainer on cljest and one of the next things I'm planning to add is REPL support, and one thing I'd really like to support with my REPL is jumping between Clojure and ClojureScript environments at runtime and have it work similarly to the vanilla :repl/quit mechanism: you send :jest/cljs and it will change your REPL to ClojureScript (with some cljest specific things) and :jest/clj for Clojure. I've gotten a basic prototype working with a vanilla Socket REPL (and one which works if I connect with telnet/nc).

I'm under the impression that I would be able to support this pretty easily in nREPL, where I can control what happens when the eval command comes in and it doesn't get overwritten, but at the moment I don't think it's possible with Socket REPL mode since when the client connects, it sends over the clojure_sublimed code and starts a new loop with its own evaluation mechanism.

So, I'm wondering if it would be possible to make the evaluation mechanism for Socket REPL mode extendable, such that a user or library could define what happens when the eval operation happens, rather than always using Compiler/eval, or alternatively, supporting a "raw" Socket REPL that doesn't overwrite the initial loop. How it would work I'm not entirely sure but I wanted to start the conversation first 🙂 What do you think?

tonsky commented 1 year ago

Well, our Socket REPL impl is very JVM-dependent, I don’t think it’ll be easy to extend. You can add new one that does CLJS over Socket REPL though. New REPLs are easily supported.

I’m also not a big fan of switching REPLs via commands. I think CLJS REPL story is so complicated partly because of this. How I imagine it should go: you want to connect to CLJS REPL? Open a port and connect to it and get the same nREPL/Socket REPL experience but inside CLJS. NOT by connecting to CLJ first and then “upgrading” it. But that’s just my general opinion :) Do what you have to do, of course :)

jo-sm commented 1 year ago

I think I see it slightly differently -- my ideal REPL is an environment where the exact evaluation mechanism is flexible, and one which is ideally configurable at runtime, and so I don't really see it as "upgrading" but rather switching environments (and the evaluation mechanism could be exposed directly in the REPL, e.g. (eval/cljs "...") and (eval/clj "...")).

In any case, if I wanted to add a new Socket REPL that supported CLJS, 1. do you think it would make sense to just do a "raw" Socket REPL, where it doesn't do the upgrading (basically like if you connected via nc), or do you have another idea?; and, 2. do you think it makes sense to add this REPL to this package?

tonsky commented 1 year ago
  1. do you think it would make sense to just do a "raw" Socket REPL, where it doesn't do the upgrading (basically like if you connected via nc), or do you have another idea?; and,

Yes, probably raw socket repl is your best option

  1. do you think it makes sense to add this REPL to this package?

No, you probably need a REPL client that emulates terminal connection, like Tutkain. Socket REPL works best in terminal, not from rich IDE environment

jo-sm commented 1 year ago

Closing since the raw socket REPL won't be added to the package.