search

dmiller / clojure-clr-next

Next generation of ClojureCLR under development.
Eclipse Public License 1.0
109 stars 5 forks source link

Looks like there is a huge overlap with MAGIC compiler? #4

Open divs1210 opened 1 year ago

divs1210 commented 1 year ago

Magic is another cleaner Clojure CLR implementation.

What are the similarities / differences?

How to decide which ClojureCLR implementation to use?

dmiller commented 1 year ago

Magic and related projects are built on top of the current ClojureCLR implementation. It is not a standalone. With this project I hope to do a complete rewrite of ClojureCLR and incorporate all the tremendous work Ramsey Nasser has done on compiler techniques. So, eventually I hope there will be a major overlap.

As for current state, I have to defer to Ramsey on how best to use Magic.

FalseProtagonist commented 1 year ago

Is it best to use magic right now or original clojureclr?

dmiller commented 1 year ago

What are you trying to do? I have no idea of the current capabilties of Magic+Nostrand. I suggest you contact Ramsey Nasser.

FalseProtagonist commented 1 year ago

In the dream scenario I'd replace (at least most of) a C# VSTO excel add-in with a clojureCLR powerred version. Sorry if the previous was an annoying question/not your question to answer. A more concrete question would be: is ClojureCLR currently likely to be solid enough for that usecase in production? I've scoured google groups, wiki, issues etc and can see that it's been used by people but also isn't the biggest project in the world so have never gone whole-hog and tried it.

bcalco commented 1 year ago

In the dream scenario I'd replace (at least most of) a C# VSTO excel add-in with a clojureCLR powerred version. Sorry if the previous was an annoying question/not your question to answer. A more concrete question would be: is ClojureCLR currently likely to be solid enough for that usecase in production? I've scoured google groups, wiki, issues etc and can see that it's been used by people but also isn't the biggest project in the world so have never gone whole-hog and tried it.

It so happens we (Apex Data Solutions) are already working on ClojureCLR integration with Office as part of our commercial product, which is called Accelerate. The main goal is legacy VBA app modernization, but also alternative ways to bring LAMBDAs into Excel and leverage Office artifacts as microservices. We've already successfully integrated IronScheme into it, but are adding ClojureCLR for some things it can do on .NET that IronScheme presently cannot (like create CLR types and subtypes). if you're interested to know more about that let me know.

nasser commented 2 months ago

MAGIC is built on David's ClojureCLR runtime so i would not characterize it as a "cleaner" implementation. It was started because the Arcadia project needed to run on iOS devices and to do that we needed to remove a few specific dynamic runtime components that ClojureCLR depends on. We also explored some aggressive optimizations for Unity3D/game development specific workflows, specifically local mutation of struct values for linear algebra code.

I would not recommend using MAGIC as is. It was built for a specific use case which is different from what is described here, and it is not getting any updates for the foreseeable future because my own commercial work does not involve Clojure or Unity anymore, so I cannot justify allocating my solo time to it. Further, the commercial clients that supported its development for a period are no longer able to do so.

That said it is "done" in the sense that it passed the Clojure test suite and successfully ran non-trivial Clojure programs on iOS. I think its a good object of study or something to build on, but it needs work to bring it in line with the changes in Clojure and dotnet that have happened since its last commits. Happy to offer guidance to anyone interested.