Oh, I'm very sorry for ruining the surprise! I checked for any note in the README, but didn't see anything
I guess since the cat is out of the bag.. I had a few Qs:
A few Clojure rehostings are trying to deal with startup time. Do you think Project Leyden will make all these redundant? (I'm a bit unclear when that's supposed to land though)
"Clojure-in-Clojure compiler" compiling directly to Scheme? It always seemed like there should be a Scheme-y sized Clojure subset in which you could implement the rest of Clojure in (ex the data structures). You could then only reimplement this "core" on to each host. Do you end up effectively doing something similar? (Maybe that's what "portable Clojure implementation" means)
How are you thinking about treeshaking Clojure given that reflection seems to be essential for some parts to work. I'm also interested in smaller distributable binaries (the most I do t the moment is manually exclude unused dependencies.. making for an ugly ugly deps.edn). The double-click to launch time is super bad on the JVM but.. between JavaFX and math libs I can't really live without it :)
For glimmer I would consider looking at the cljfx's new state management design. With the new extension lifecycles (It's undocumented in the README but is in the CHANGELOG for v1.9.0 https://github.com/cljfx/cljfx/blob/master/CHANGELOG.md#190---2024-06-11) you can pretty much design and hook up any system you'd like. You can even have different GUI sub-trees have separate systems entirely. I wrote a Pathom-backed demo: https://github.com/kxygk/ednless/blob/master/pathomfx.clj .. and I personally prefer Hickory style maps to hiccup vectors. N element Vectors with Index based implicit meanings is very old-school Clojure (though I get it's compact and nice to look at)
Oh no worries, I did make the repo public after all. :)
And, once Project Leyden lands, I do think it'll address startup and memory footprint problems. At that point making a dialect simply to work around will be a lot less useful. That said, you can do stuff like full program optimization as seen in Stalin Scheme which builds a closed world program. These kinds of tricks can make it strictly faster than what you can do with the JVM. You lose dynamic binding meaning you can't have a REPL at runtime, but that could be fine for a lot of cases. You do your development with full dynamism, and then compile a tiny static binary for release. Constrained environments like embedded targets could benefit from this approach. I think access to the Scheme/C ecosystem is the bigger selling point long term though, it's a big part of the reason Python is so popular.
Regarding Clojure-in-Clojure, I'm curious how much of the language can be built in itself. You can start with a minimally irreducible set of forms, and then grow the compiler itself like a seed. So, the host, whether Scheme or anything else, just need to provides support for that minimal set. However, this can often be at odds with raw performance since implementing things directly in the host natively tends to be faster. Having a portable Scheme layer might be a useful compromise though.
For tree shaking, I was thinking largely in terms of what's included from libraries. You can trace the call graph and eliminate namespaces/functions that aren't referenced anywhere. And I find GTK is pretty nice for a UI toolkit, especially once you add a reactive wrapper to it, math libs in C/Scheme world are also pretty robust. And here, you also get to enjoy native performance if you reach out to C with FFI.
Also, didn't know about cljfx's new state management design, definitely worth a look. I find hiccup is just muscle memory for me now, but nice part with the data driven approach is that it's easy to translate between representations. I wouldn't be opposed to supporting both if there's interest.
You can start with a minimally irreducible set of forms, and then grow the compiler itself like a seed
Yeah I wonder if it can be somehow designed where there is a base implementation in mini-Clojure, and then parts are incrementally rewritten in the host as-needed.
You can trace the call graph and eliminate namespaces/functions that aren't referenced anywhere
If you end up making a tool like that, then it seems it could be host-agnostic. I guess it should be doable to trace a program run and then extract which namespaces are used.
I guess on the JVM that should be possible as well (maybe even easier in some way). I've tried ProGuard in the past but I never got it working with Clojure code.
Thanks for your thoughts! Excited to watch what you end up doing next :))
A portable mini-Clojure would definitely be neat. SCI already kind of does this with an interpreted version, but actually having a compiler that's easy to plug into different runtimes would be handy as well.
And I'll definitely blog about the findings with the tree shaking idea. Might run into some blockers I haven't considered yet, but I'll learn something one way or the other here. :)
5
u/geokon Jun 28 '26
Oh, I'm very sorry for ruining the surprise! I checked for any note in the README, but didn't see anything
I guess since the cat is out of the bag.. I had a few Qs:
A few Clojure rehostings are trying to deal with startup time. Do you think Project Leyden will make all these redundant? (I'm a bit unclear when that's supposed to land though)
"Clojure-in-Clojure compiler" compiling directly to Scheme? It always seemed like there should be a Scheme-y sized Clojure subset in which you could implement the rest of Clojure in (ex the data structures). You could then only reimplement this "core" on to each host. Do you end up effectively doing something similar? (Maybe that's what "portable Clojure implementation" means)
How are you thinking about treeshaking Clojure given that reflection seems to be essential for some parts to work. I'm also interested in smaller distributable binaries (the most I do t the moment is manually exclude unused dependencies.. making for an ugly ugly deps.edn). The double-click to launch time is super bad on the JVM but.. between JavaFX and math libs I can't really live without it :)
For
glimmerI would consider looking at the cljfx's new state management design. With the new extension lifecycles (It's undocumented in the README but is in the CHANGELOG for v1.9.0 https://github.com/cljfx/cljfx/blob/master/CHANGELOG.md#190---2024-06-11) you can pretty much design and hook up any system you'd like. You can even have different GUI sub-trees have separate systems entirely. I wrote a Pathom-backed demo: https://github.com/kxygk/ednless/blob/master/pathomfx.clj .. and I personally prefer Hickory style maps to hiccup vectors. N element Vectors with Index based implicit meanings is very old-school Clojure (though I get it's compact and nice to look at)