You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The clavascript compiler can run with JVM/bb and in Node/browser. We should have an evaluator that can evaluate macros while compiling. SCI would be a good piece of infrastructure for this*, which will keep the compiler working on all these hosts.
The thing we should still figure out: how do you require macros from a clava script? We don't yet have the concept of a classpath. Should we use relative paths to the required script?
So given src/script.cljs. it would load macros from src/macros.cljc?
*) More details on why SCI:
There's two ways to do macros:
We use a Clojure evaluator in the "host". Currently the host can be JVM/bb or Node.js/browser. We could use SCI to cover evaluation in the host, since it covers all of these targets.
We first compile macros down to JS and then load these JS files in the compiler, to then further compile code that uses those macros (which is what's supported right now, but it limits the host to run in JS).
For 2) things are further complicated that in clavascript, functions produce JS data structures, so if we go that road, then we should extend the compiler to transform not only CLJ(S) data structures, but also JS. So I'm kinda leaning towards 1 now since it keeps most options open and doesn't require much changes to the compiler. Of course we could also just eval on the JVM and bb using eval but maybe it would be nice to expose the same APIs everywhere so macro-expansion is consistent.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The clavascript compiler can run with JVM/bb and in Node/browser. We should have an evaluator that can evaluate macros while compiling. SCI would be a good piece of infrastructure for this*, which will keep the compiler working on all these hosts.
The thing we should still figure out: how do you require macros from a clava script? We don't yet have the concept of a classpath. Should we use relative paths to the required script?
So given
src/script.cljs
. it would load macros fromsrc/macros.cljc
?*) More details on why SCI:
There's two ways to do macros:
For 2) things are further complicated that in clavascript, functions produce JS data structures, so if we go that road, then we should extend the compiler to transform not only CLJ(S) data structures, but also JS. So I'm kinda leaning towards 1 now since it keeps most options open and doesn't require much changes to the compiler. Of course we could also just
eval
on the JVM and bb usingeval
but maybe it would be nice to expose the same APIs everywhere so macro-expansion is consistent.cc @lilactown @corasaurus-hex
Beta Was this translation helpful? Give feedback.
All reactions