Btw folks some other folks are trying discord for keeping history, I am already in that one, there was one thread on /r/clojure
I also really really waet to pitch my idea of generalizing repls to other languages, you send clj for registering transpiling functions and sir/de functions for you js favorite transpiler, that is an easy win from upgradable repls
@richiardiandrea Iβm not opposed to serving other langs but I would really appreciate if you could develop > you send clj for registering transpiling functions and sir/de functions for you js favorite transpiler
so you just need a blob.py
True that, you need basically some code that your eval function can understand. Klipse does this already, the whole infrastructure is built in cljs but then everything that compiles to js can be evaluated in the browser.
The additional step to add to the upgrade is the transpiler, call a function to convert to js before eval and call a function for converting back the result I guess
Are you talking about clj-cljs or js-cljs?
I'm confused each time you mention a transpiler
Sorry this is cljs-in-cljs and a transpiler example would be the BuckleScript one converting from ocaml to js
So the idea is to have Lumo or a fork as universal repl for the whole js ecosystem
Just noticed Unrepl in this case stands for universal repl π
It is probably better for me at some point to create a poc or something, I hope to get a bit of time soon
so to expand: the repl receives a function, the repl transpiles to js, the repl evals the js. Of course there should be a mechanism to discover the function that does the transpilation to js...it would be awesome if we could send it as blob but it might a fully library
in case of Bucklescript, this whole thing: https://www.npmjs.com/package/bucklescript
I agree this might be a bit out of scope here
How easy it is to hook up in nodejs module resolution?
(If I understand the question correctly) In lumo
the module resolution is done automatically, node.js takes care of it so whatever is in .node_modules
gets resolved on a require
.
Too much context was missing from my question. It was a reaction to "it might be a fully library".
If we can hook up in the module loading then we can have them loaded on demand by the server from the client. So they wouldn't have to be part of the blob.
Yep I was thinking the same, and/or there could be a section in the package.json
of the transpiler for defining things like which function I need to call for this or that.
I think the first step would be to define the extension points or in another words what needs to be provided in order to be upgradable. In other other words abstract what the blob is. Will think and put my thoughts in the wiki page. At least this is not really clear to me π I was thinking of these two functions, but maybe there is more
Upgrading a X repl to be a X unrepl has more requirements than upgrading a cljs repl to a X unrepl.
Yeah that is what I feel I haven't discovered yet, how much more
I would say three. A parser to split input in evaluable snippets. Eval. Allowing evaluated code to take control of the repl streams.
Nice, so I am thinking it now in terms of pipable repl exposing to the world only two streams, one in and one out. Each one is responsible for evaluating its part of the stream without exposing parser and eval, and the terminal of this exhaust system is stdout π
I mean no rocket science here I know π However there are fewer things to add to the unrepl protocol if the only communication medium between repls are pipes
I probably now get in full what you had in mind all along π
Yeah maybe. And upgrading a repl is just the matter of sending a specific input.
yep the protocol stays the same, the "engine" can just pipe the streams when an upgrade is requested
All this upgrade stuff vaguely reminds me of Alan Kay and alien "objects".
Oh I don't know this one, so I will look it up
From memory: look for Alan Kay's AMA on HN, especially interactions with Rich.
Ah that part on HN, I remember having read it yet, need a refresher
At the time it sent me down a rabbit hole where i discovered jot and zot https://en.m.wikipedia.org/wiki/Iota_and_Jot
I created a wiki page, feel free to edit, dump thoughts, questions etc.
https://github.com/cgrand/unrepl/wiki/Design-notes#clj-hosted-cljs
On βregularβ CLJS: > 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.
Sure will dig into details, for now it is just an unproven idea I had π thanks for the wiki page