search

Qix- / arua-meta

Standards, RFCs and discussion of the Arua language
44 stars 2 forks source link

Out of box compatibility with JVM #25

Closed Qix- closed 8 years ago

Qix- commented 8 years ago

So up until today the initial plan was to support LLVM out of box initially, but I'd also like to look at out of box support for JVM via a project such as LLJVM.

There is a lot of overlap between dependency management and resolution, including semantics (zone names, etc). Realistically, we could map primitives to JVM types and dependencies to JVM packages/classes, but that might require some work.

I'm not up to snuff with JVM architecture or internals, but it would be very useful to be able to cross-compile Arua code as JVM and use JVM languages interoperably - perhaps even bridging that native interface gap by removing the need for explicitly different code units when having native functionality in JVM programs.

corbin-r commented 8 years ago

Honestly, seeing as how both the JVM and LLVM just decompile to (effectively) C bytecode, I don't see why this wouldn't be possible. Sure a type of interop package will have to be built and be able to run either alongside the main arua compiler (if it's built right into the compiler, then having an option to generate LLJVM bytecode or not). Or run it as a seperate service that reads the bytecode generated from the arua compiler then transpiles to LLJVM compliant code.

I'm not in favor of the transpiling option, yeah you gain compiler time and speed, but when you transpile from one thing to another without compiling natively? It can cause weird problems that prove a SoaB to solve.

Also something to think about. it would be very useful to be able to cross compile Arua code as JVM and use JVM languages interoperably I think this is a good idea, and bad idea. It's a good idea because, you now have lots of portability options with Arua, you can move code easily from one JVM compliant language to the next. But! When you start adding more support for more JVM compliant languages this bogs down the language with lots of prepackaged support code, which can turn the language into a slow mess. Now there's some ways I can think of too go around this, either A) Have "Packages" that are portability code for the language you want to cross-compile for... or B) Allow a compile time argument that will automatically download and link the language package. But if you build it into the language? The language could get huge with any X languages you want to support.

Qix- commented 8 years ago

I'm closing this as rejected. This was an awful idea and totally outside the scope of Arua.