@anmonteiro @mfikes I’m working on #unrepl (basically a repl with a custom machine-printer that allow machine-readable rich output and features discovery). A very nice thing is that we can take a plain clojure repl and upgrade it over the wire to an unrepl repl. Sadly we can’t do the same with selfhosted cljs repls. To me what is missing to enable lumo and planck to be “upgradable” is that there are no standard way to get a hold of the two of three pieces of a REPL: • there’s no read (or there’s no read that when called from user-evaluated code read from *in* -- because there’s no *in*), • there’s no eval (or a standard way to get the compiler env to pass to cljs.js/eval). The P is covered by *print-fn* and friends.

I’ve started working on the R part: writing an evented reader https://gist.github.com/cgrand/d99afba8ce7ae9a13931184a58bbffc8

using that reader the underlying impl can feed the *in* stream and (read (fn [val ex] ...)) calls its callback (once) either when the form is complete or failed.

I think such a reader would be valuable in cljs.js proper (in lieu of the “blocking-style” cljs.reader).

disclaimer: this reader is not complete (no meta, no taglits, no ns map, no regexes, no anon fns, no syntax quote or quote...)

@cgrand Planck's compiler env happens to be at planck.repl/st

Planck also happens to have planck.core/eval which is like Clojure's eval. Do you need to eval ClojureScript forms or JavaScript code?

I had also started work on a read in Planck that reads from *in*, but haven't completed it. (This branch https://github.com/mfikes/planck/commit/f1b8547bf2a42bc06d04e81d52048555ba223c60)

@mfikes interesting. For both read and eval you try to stay true to Clojure. But given JS shouldn't you have both taking a callback?

I suppose that would be better. Everything that Planck does with JavaScriptCore is synchronous.