Search code examples
f#jvmocamlyetifunscript

What's the easiest way to build an F# compiler that runs on the JVM and generates Java bytecode?

The current F# Compiler is written in F#, is open source and runs on .Net and Mono, allowing it to execute on many platforms including Windows, Mac and Linux. F#'s Code Quotations mechanism has been used to compile F# to JavaScript in projects like WebSharper, Pit and FunScript. There also appears to be some interest in running F# code on the JVM.

I believe a version of the OCaml compiler was used to originally Bootstrap the F# compiler.

If someone wanted to build an F# compiler that runs on the JVM would it be easier to:

  1. Modify the existing F# compiler to emit Java bytecode and then compile the F# compiler with it?
  2. Use a JVM based ML compiler like Yeti to Bootstrap a minimal F# compiler on the JVM?
  3. Re-write the F# compiler from scratch in Java as the fjord project appears to be attempting?
  4. Something else?
Solution

  • Another option that should probably be considered is to convert the .NET CLR byte code into JVM byte-code like http://www.ikvm.net does with JVM > CLR byte codes. Although this approach has been considered and dismissed by the fjord owner.

    Getting buy-in from the top with option 1) and have the F# compiler team have pluggable backends that could emit Java bytecode sounds in theory like it would produce the most polished solution.

    But if you look at other languages that have been ported to different platforms this is rarely the case. Most of the time it's been a rewrite from scratch. But this is also likely due to the original language team having no interest in supporting alternative platforms themselves and that the original host implementation might've not been able to support multiple backends and it's already too slow for this to be a feasible option to start with.

    My hunch is a combination of re-writing from scratch and being able to do as much code sharing and automation as possible from the original implementation. E.g. if the test suites could be re-used for both implementations it would take a lot of the burden off the JVM port and go a long way in ensuring language parity.