Welcome! Please see the About page for a little more info on how this works.

0 votes
ago in ClojureCLR by

I've been browsing around to understand the ecosystem.

I see some libraries are ported to use CLR interop, like core.logic, some are part way finished, like core.async.

Here is one maintainer's concerns, they would much like to point at CLR users at a fork with CLR interop maintained by someone else:
https://github.com/weavejester/medley/pull/96
https://github.com/weavejester/medley/pull/65

For fun I examined how to use formal logic to do the code translation. Using Spec, and core.logic for code generation perhaps. I think it would require a lot of knowledge representation.

It might be easier, for these non-core/crucial libraries to use LLMs to do the code translation, and direct the outputs into a set of forks. Perhaps the core libraries used as training data on what to do. This author has some great insights and details on a plausible workflow(s) including with the utility of editor integration. He has done interop translation and work with clojure:
https://m.youtube.com/watch?v=oNhqqiKuUmw

As it is only the interop which requires translation (subsets of clojure files), with a skilled hand there might be better results than some of what he illustrates.

I looked around for a spec for the dotnet core API. I saw one they used to maintain but couldn't find a recent one. Though, all this LLM stuff is beyond me at this time. I thought to share some of my exploration.

Please log in or register to answer this question.

...