thanks for keep making babashka more and more awesome 🙂

as I understand it, deftype dynamically defines a new Java class, and GraalVM doesn't allow for the creation (as in definition) of classes at runtime, so they're incompatible

interesting, I have deftypes all over #sicmutils but I’d be happy to compile classes instead, or use some form graal, js and jvm would be happy with. Is there an alternative?

Deftype isn't implemented since people usually use it for low level stuff and implement more than 1 java interfaces in them which is hard to support since you need to know all combinations at babashka compile time. Defrecord is the closest alternative

We could add support for a subset of deftype usages, but it would have the same restriction as defrecord: only 1 Java interface may be implemented at a time

Wait, I thought #sicmutils already worked on #sci? Have I missed something?

It works with SCI bindings, but this is a different usage than running it entirely from source in SCI

You can make almost any library work by plugging in the right SCI bindings

Ah, ok. So the deftypes don't actually run in sci. Thanks for explaining 👍

yes. we could support deftype for some cases, similar to how we support defrecord but usually people implement all kinds of interfaces on those things that make it very hard to pull it off correctly

In sicmutils the usual pattern is to make something feel like a vector, but override IFn and add more SICM-specific protocols

that might be supported

Okay, I'll make a task to get the full list of deftypes together and we'll see what we can do

$ bb -e '(def x (reify clojure.lang.IFn (invoke [_] :dude))) (x)'
:dude

on records it doesn't work currently I think

ok

This is a good example of deftype that is very hard to support in babashka. https://github.com/Engelberg/instaparse/blob/4d1903b059e77dc0049dfbc75af9dce995756148/src/instaparse/auto_flatten_seq.cljc#L87

https://github.com/sicmutils/sicmutils/blob/main/src/sicmutils/structure.cljc#L83-L296

here is the sort of thing @U04V15CAJ that we are dealing with. most look very similar to this

I also wanted to ask if you have a suggested way that I could incrementally make this conversion; for example, make a, or something and start growing up toward sicmutils.env

That sort of deftype is similar to the one from instaparse: it implements a bunch of stuff to make it a custom data structure with lots of interfaces which isn't possible in bb.

You can use either reader conditionals, :bb or the .bb extension to override code for bb

bb accepts both :clj and :bb reader conditionals, if you are using :bb you must place it before the :clj one

Is the answer perhaps to write the class in Java?

Babashka cannot execute Java classes

The answer, if you want to make your code bb compatible, is probably to use reader conditionals and support a subset

or you could write a pod that you can load from babashka, that's also an option. I don't know enough about SICMutils API to say if that's a good fit

Pods's arguments are serialized as json, edn or transit.

If you want to serialize functions, that's usually a problem

So maybe the subset approach could work. In your Structure example, this would mean: implement Structure as a record and remove the non-protocol implementations except Object using :bb reader conditionals