It's not built-in and also it doesn't work from source due to deftype

Too bad, that would make my AoC code a lot faster... Now I have to build something similar myself...

I'll keep it in mind

@U4VT24ZM3 Hi. There’s https://github.com/babashka/sci/issues/345 if you come across other deftype issues. I added another lib to this today

@U08ALHZ2N Hm... I appreciate your effort, but it doesn't seem sustainable to me to adapt every library using deftype to Sci. 1. If SCI wants to be a universal Clojure interpreter, it has to support every Clojure Library that will ever be written. Otherwise, you would fragment the Clojure ecosystem into sci-compatible and non-sci-compatible. 2. If SCI doesn't want to be universal, it shouldn't grow any more than the absolute necessary libraries, otherwise we would sometime land at point 1.

I’m not looking to workaround these issues but rather compile a list of libraries that are blocked on deftype support. If the list is useful enough to people than perhaps the community will rally to tackle support

It's not only a matter of wanting, but also of constraints. deftype is often used for implementing Java interfaces. In GraalVM native you cannot define new types at runtime, there is no JVM bytecode stuff anymore. The choice you still have here is: compile the library natively and provide the functions with the SCI config (like many libraries in babashka). Or make a babashka pod around the library.

I do want to support this, I just don't know how.

deftype + only protocols could probably work but this isn't typically how deftype is used

We were almost there at one point, but this introduced a weird typing issue. What we did was that deftype would create a type that implemented a list of all available interfaces and then mapped to the user's implementation. But this had as a side effect that (instance? CustomType x) would always return true, even if the user didn't provide an implementation

I'm also not sure if I understand point 2. What does it mean that "it shouldn't grow any more than the absolute necessary libraries"?

I think it's better to support something than nothing.

If you want data priority map in your graalvm binary, this can work with SCI, no problem, just not from source currently. It's a matter of choices: we can't include just any library in bb without becoming the entire clojars in one binary. But feel free to post issues so other users can provide feedback and eventually, who knows.

> We were almost there at one point, but this introduced a weird typing issue. What we did was that deftype would create a type that implemented a list of all available interfaces and then mapped to the user’s implementation. But this had as a side effect that `(instance? CustomType x)` would always return true, even if the user didn’t provide an implementation Exciting! I didn’t know you had spiked on this. I’m hoping with enough hammock time a path forward emerges 🙏

Believe me, if I would know a good solution today, it would already be in there :)

You can read some of this stuff around issue 540 and surrounding commits

That was about reify but the problem is very similar

The issue is that you have to generate a real type at compile time that is the exact match of a mix of Java interfaces that the user will provide at runtime

Currently we only allow one Java interface in reify and pre-generate those types and link them to the run time implementation

but for deftype, there's often a Java interface or ... 5

Ok. I have to explain. First: My initial question was flawed by my misunderstanding. I thought, that in the absence of a bb.edn, babashka would pull the deps from the deps.edn. So I thought "Well BB doesn't support priority-map", not checking if I did something wrong myself. Which may have led to me misunderstanding the whole situation. I am not sure. Second (it shouldn't grow any more than the absolute necessary libraries) Well, it's a dark vision of the future. 🙂 Imagine SCI gets so wide-spread, that it is head-to-head with JVM Clojure ... Then we would have a fragmented Clojure ecosystem of sci-compatible and non-sci-compatible libraries, unless every library that will ever be written is SCI compatible. Wouldn't it? But as I said, I think I may have misunderstood something and the statement was me not knowing what I was talking about...

babashka only gets deps from bb.edn

some libraries use reader conditionals to make it work for JVM and bb

you can look at it this way: babashka, like CLJS, is a dialect of Clojure which tries to be close, but within the limits of its host.

and sometimes libraries have to introduce host-specific things to deal with that

the bb host being graalvm native

I think the deftype thing could work, if we went with the "be all types" thing, but then this could still give runtime errors:

(if (instance? ILookup my-deftype-thing) (get my-def-type-thing :a) ...)

Could we modify sci’s instance? check to fail checks to my-deftype-thing? Perhaps the amount of calls like that in the wild are near zero. Failing would make it explicit that it’s not supported

yes, we could, but this would not work when this type was passed to a precompiled function which uses instance

@U4VT24ZM3 I'm adding clojure.data.priority-map as a built-in in the next release of babashka (already available via https://github.com/babashka/babashka-dev-builds)

👍 Nice! But no hurry, Advent of Code 2022 is still months away! 😉

The current version of bb should already be significantly faster than compared to Dec 21

Here is more info on that: https://apple.stackexchange.com/a/408379/12216

thanks!