support macros
borkdude opened this issue · comments
Braindump from Slack:
Crispin have you thought how to support macros is pods?
4:02 PM
borkdude I have though about "eval" in general. pods that already ship with sci, like spire, could just implement an eval function which will receive a EDN-encoded string, call sci/eval-string on that and return the EDN-encoded result
4:02 PM
Crispin yep cool. just like a repl
4:03 PM
borkdude so (pod.epiccastle.spire/eval "(with-bla [x 1] (ssh/foobar))") (edited)
4:03 PM
Crispin not perfect... but would bring some functionality
4:03 PM
what about sending it edn of the source args
4:03 PM
and the pod sending back the expanded source?
4:04 PM
not edn... the unevaled source
4:04 PM
that might enable body sections to contain other functions
4:04 PM
form the local scope
4:04 PM
so hooking that up, I just wire the pod coms up to the underlying funcs
4:05 PM
borkdude that could work, but might also lead to a lot of headaches. e.g. this:
(let [x 1] (spire/eval x))
I'll send you x. But you don't know what x is...
4:05 PM
Crispin if eval was a macro though, would send back (* x x)
4:05 PM
all the names are fully qualled
4:05 PM
so you could continue to expand
4:06 PM
and then you'd know what are functions
4:06 PM
borkdude that could work. we'll just have to start with a concrete example and consider all the alternatives, before jumping on macros as a built-in pod thing
4:07 PM
Crispin yeah would only work for sci pods, or clj pods
4:07 PM
lisp only
4:08 PM
borkdude for the docker pod, one problem was that a docker connection cannot be EDN-ified. so it would be useful if you could do (docker-pod/eval "(with-connection [conn ...] (+ 1 2 3))"), so eval all the things inside the pod 4:08 PM Crispin maybe then though the answer is pur clj and classpath 4:08 PM If I had more time I'd think about writing a pure clojure ssh 4:10 PM borkdude we could easily extend the pod protocol using something like: :vars [{:name x :async true} {:name :y :code "(defmacro y [x] (do ~x ~x))"}]. So fo the var y instead of creating a function var on the pod client side, it will just eval the code and hook up the var to that.
4:10 PM
Fucking hell, this slack markdown is starting to annoy me. I'm not going to correct it anymore, you get the idea.
4:11 PM
Crispin haha a lang with backtick... they didnt expect that!
4:12 PM
yeah. interesting. some code could be evaled on the bb side, by sending the source over.
4:12 PM
and some could stay on the pod side
4:12 PM
borkdude this would also allow the pod library to define normal functions. also macros. all flexible
4:12 PM
Crispin like the actual JSch calls stay in the pod.
4:13 PM
but the macros expand to encompass the users local code
4:13 PM
borkdude yes
4:14 PM
so a var with a :code attribute is just bb or clojure code that could be functions, macros, constants, and are not going back and forth between the pod, it's just local bb or clojure code.
4:15 PM
Crispin I like it
4:15 PM
straight forwards
4:15 PM
can you get a clj macro def transformed into source AST at runtime?
4:16 PM
borkdude no
4:16 PM
you might using the clojure.repl/source function
4:16 PM
but the sexprs aren't saved anywhere as metadata
4:18 PM
The :code could also have additional expressions like
"(require '[clojure.set :as s]) (defmacro foo [x y] `(s/join ~x ~y))"
(edited)
4:19 PM
as long as the last value is an object that can be attached to the var or something
4:19 PM
or maybe the effects must take care of the var to become into existence
4:20 PM
I think the latter is more flexible
4:20 PM
you could even provide macros from Rust code this way. While the pod itself doesn't have to speak lisp
Implemented.