
Compiling to Java as a target language - fogus
http://matt.might.net/articles/compiling-to-java/
======
markokocic
Why would anyone compile to Java when it is much easier to compile directly to
JVM bytecode?

A lot of languages are doing exactly that, like Mirah, Clojure, ABCL, Scala
and many more.

~~~
lukesandberg
is that actually easier? I know its probably way more efficient in the long
run, but i really doubt you could write a bytecode compiler as easily as this
was written.

~~~
sedachv
People think real compilers are complicated, but often writing a native code
compiler is simpler than writing an interpreter or translator. Abdulaziz
Ghuloum has a great paper called An Incremental Approach to Compiler
Construction (<http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf>), which shows
how to build a Scheme native code x86 compiler in 10 pages. JVM bytecode isn't
that far away from machine code.

Another great example of how straightforward compilers can be is the Tiny C
Compiler (<http://bellard.org/tcc/>).

~~~
bad_user

        JVM bytecode isn't that far away from machine code.
    

It is far away in the case the type system is a complete mismatch, like
Haskell. Or in the case of Scheme, if you want to have continuations without a
huge performance penalty, you've got to put some effort into it.

For these instances I've see advices on Lambda-the-Ultimate to just go for
native-code, as it is easier to experiment since you have a lot more freedom.

That said, building on top of the JVM can have advantages other than being
easy to write the compiler.

------
larsberg
I disagree with one statement:

> performance will go up, but implementation code size and > complexity will
> go up by about a factor of two

Moving from basic compiler optimizations (CSE, let-floating, unused variable
elimination) to static-analysis driven optimizations (arity raising, useless
variable elimination, super-beta, CFA-driven closure conversion, transducer
identification and optimization for concurrency) may only double code size,
but the implementation complexity is pretty intense. Those optimizations often
are performing global reasoning against a CPS-style intermediate
representation, and debugging issues with them can take a while. We do all of
the parenthesized operations listed earlier (in Manticore,
<http://manticore.cs.uchicago.edu>), and I would claim order of magnitude more
time/thought spent on the them.

That said, I think I'm _supporting_ Matt's argument of avoiding moving up the
complexity order unless you have to!

