Epsilon is not compatible with Babashka

[noprompt]

• Unable to resolve classname: clojure.lang.ILookup [at /private/tmp/meander/src/meander/substitute/syntax/epsilon.cljc:1441:24]

• user=> (require '[meander.epsilon] :reload)
  Could not resolve symbol: S__23485 [at /private/tmp/meander/src/meander/epsilon.clj]

Probably related to one of the (let [save-id (gensym* "S__")] constructs.

[borkdude]

It's pretty interesting how far we've come, but I'm not sure if meander in its current form is a good fit for babashka.

E.g.

• The avoidance of predicates really works against performance in babashka: the clojure core predicates are pre-compiled with GraalVM in babashka, but the instance checks meander is doing are going through the interpreter.

• Meander is trying to do a lot of optimizations (I think?) at load time via macros, which is causing slow startup time in babashka. The less code babashka has to process, the faster the program will be. Babashka doesn't have AOT of any kind: all source is going to be interpreted all over again on every command line invocation.

So shorter programs which rely on clojure.core instead of lower level interfaces will be faster in babashka. This is why e.g. https://github.com/xapix-io/matchete is pretty fast in babashka, but probably less performant in Clojure on the JVM than meander.

[noprompt]

The avoidance of predicates

It's not clear to me what you're referencing here. Can you provide some more detail?

Meander is trying to do a lot of optimizations (I think?) at load time via macros

This is true, however, we can avoid that by providing and suggesting the utilization of an interpreter namespace which works basically as matchete does. At the moment I'm fast tracking this by ripping out the use of the macro match.

[borkdude]

That would be interesting!

The part about the predicates: e.g. doing #(instance? clojure.lang.Seqable %) instead of seqable?. We discussed that perf optimisation yesterday on Slack.

[borkdude]

I now measured some differences and in babashka it's basically equally fast, so you can disregard that comment or at least take this as information that this won't help much in babashka, probably.

So the main issue is keeping the amount of code to load for meander as small as possible to get the best startup time possible.

[noprompt]

So the main issue is keeping the amount of code to load for meander as small as possible to get the best startup time possible.

I'm in!

[aleksandersumowski]

Is meander still not compatible with babashka?

[borkdude]

@aleksandersumowski Since the latest release you should be able to load meander, but I think there are a few edge cases that might not be working yet. Feel free to report them in terms of small standalone issues on the bb side of things and we can see if we can fix those.

[aleksandersumowski]

ok, I'll give it a try :)

[srenatus]

Some time has passed; and meander spurts a "babashka compatible" thing now in its README -- is this resolved? 😅

[borkdude]

yes, tests work with babashka on CI: https://github.com/noprompt/meander/actions/runs/5231806454/job/14159967827