@mfikes The pREPL proof of concept is now more fully featured. It works more like how the JVM Clojure reference implementation operates (given the limitations imposed by the fact that Planck's (p)REPL is necessarily a mixture of C and ClojureScript). I think it's getting closer to moving out of being a 'proof of concept' 😄

@mike858 Awesome!

Yeah! It's fun to play with it. Sending tap output to it from the main REPL was neat :)

I haven't looked at the implementation yet. One thing to perhaps look for is whether each pREPL session is independent. (I don't know if this is the case in the Clojure pREPL implementation.) By independent, this means that certain things like *1* would be unique for each session.

(This works for regular socket REPL sessions in to Planck and also for JVM Clojure.)

Yeah, the pREPLs are really an implementation of the socket REPL sessions.

Ahh, cool. Then they would effectively inherit that capability. 🙂

One thing I still want to try thinking about is whether there's some way to make the implementation more closely mirror JVM Clojure's such that there's a generic pREPL implementation that's then utilised through a more specific implementation (eg. a socket connection). I've been able to decouple things a little but the basic loop still assumes a socket-based connection. I don't think JVM Clojure requires that.

Ahh. Yeah. I don't know too much about JVM Clojure's pREPL and whether it only works via a TCP socket.

The thing is that if I did that, I think I'd need to write the socket logic all in Clojure and while we've got planck.socket.alpha, I'm not sure how I could incorporate them. Maybe write some generic C callbacks that execute a Planck function.

The thing is that I wonder if that's kind of past the point at which it really matters. pREPL's still a moving target so maybe having something that works basically the same as the example socket-based IO pREPL is better.

Yeah, that would be a bit more challenging. I don't recall, but I think having the socket REPL loop being native was a thing I did owing to startup considerations.

Yeah, could be problems there too.

Anyway, I'll probably give it a little thought and then maybe give up on doing anything more in that direction :P I think a better use of time would be making the error output as consistent as possible with JVM Clojure.

Yeah, a socket-based approach, with the native socket impl is probably fine

(I'm more focused on JVM Clojure rather than JVM ClojureScript because in my basic experimentation with the latter it looked a bit broken.)

I've also been corresponding a little with Oliver Caldwell (he's the guy working on Conjure, the nvim plug-in that's a bit like a more lightweight vim-fireplace) and he said once the functionality was there, he'd maybe have a look at getting Planck support into it.

Nice!

Yeah! :)