Design notes

Welcome to the unrepl design notes!

What does unrepl stands for?

No idea, it came out of a discussion between Paulus and Christophe. Apocryphal interpretations include: Unlike Nrepl, UNified/UNiform repl, unicorn repl, undead repl, underspecified repl, etc. It started in a directory named richrepl both because it enables richer interaction but also because it was inspired by Rich Hickey's messages about the socket repl.

unrepl means different things to different people

First and foremost unrepl is basically a repl with a custom printer (which produces machine-readable outputs) and which cleanly multiplex output streams (instead of the random interleaving of a standard repl).

Second unrepl means "non-intrusive" tooling as all it needs is two streams (socket or pipe) to a plain repl. However for this to work, a repl needs to be upgradable. At the moment only clojure REPL is upgradable (and a pit of streams can be rebuilt on top of nrepl https://github.com/cgrand/unrepl/blob/master/src/unrepl/nrepl_bridge.clj of course it's of no use to non-JVM clients).

Self-hosted CLJS

Christophe has written an upgradable self-hosted CLJS repl which works on current Lumo and on a branch of Planck.

Having both of them ship with the upgradable repl as (at least) their socket repl would be great. It would be even greater to have the upgradable repl to land in CLJS proper but there's a blocker: the upgradable REPL works only because both Planck and Lumo eval is synchronous (despite an async API). For the upgradable REPL to work there must be a binding conveyance solution for CLJS (the upgradeable repl has its own, the self-hosted eval has its own and they conflict).

clj-hosted CLJS

Some random thoughts:

• If one wants a true repl where one can send both a defmacro and a defn, either we need two repls, or a modal repl (stateful toggle) or a CLJC repl (where toggling between repls is done using conditional readers).
• current REPL is Read-Compile (in Clojure) followed by eval-print (in JS), to make this more upgradable, one option would be to start by setting up an upgradable JS repl (that would consume framed inputs as a JS reader is not handily available). Hence the process (even for a non-unrepl REPL) would be: upgrade the JS repl to a JS-eval CLJS-print repl and, from there, the REPL could work as usual -- except that now unrepl could upgrade the JS repl to JS-eval EDN-print.