penberg / fjord Goto Github PK

There were a few tweets from Don Syme, for example:

Don Syme ‏@dsyme 29 Mar
@7sharp9 @sforkmann @ovatsus Doing an independent reimplementation of F# in Java is just not a path to success.

I tend to agree. This project sounds like a great opportunity to bury a lot of man-years and come up with an incompatible and inefficient implementation of F# that at best will fragment the F# user community.

Could you give us your perspective on some of these questions, in no particular order:

Why is it important to have F# run on the JVM?
Have you considered cross-compiling the existing compiler?
Have you considered cross-compiling .NET bytecode to the JVM?
How are you going to handle tail calls on the JVM?
How are you going to handle value types?
How are you planning to deal with inferior generics of the JVM (most F# libraries rely on the JIT specializing the generic code for efficient execution)
Why are you using Java as an implementation language?
Why start from the parser (the least important and interesting component)?
Why focus on F# instead of a better defined (smaller) functional language in the ML family like SML?

IMHO there is a lot more value-for-money right now in improving Mono, F# itself, and tooling around F# than attempting to re-implement F# on the JVM. CLR is simply a better runtime. There are a lot of good libraries for the JVM and I have found in practice that it is reasonable to use them on the CLR by cross-compiling with IKVM. I imagine the other way round, if at all possible, would be a lot more painful.

Hi @penberg

Have you thought about using FSharp.Compiler.Service and generating JVM code from the resolved expression trees and symbols that component gives you?

If you succeeded, you could then bootstrap FSharp.Compiler.Service to be a completely JVM component.

At least, I'd encourage you to take a look at that. I think that's where I'd start if getting F# on the JVM.

Cheers!
@dsyme

Use invokedynamic for function calls in Fjord.

Implementation suggestion from @headius:

Actually I have a better idea now: don't bind the method in the
bootstrap, bind it after that.

So the bootstrap basically just returns a MutableCallSite pointing at
another method we'll call postBootstrap. postBootstrap receives the
class where the function is defined (as a java.lang.Class object)
along with the call arguments for the function. So the first
invocation of a function passes through here and looks up the
appropriate function on the given class, dynlang-style. Subsequent
calls just stay bound to that function.

We use this pattern for Ruby "constants" which must be looked up
dynamically at runtime and can't be looked up at bootstrap time (since
they depend on call context and other things). It optimizes just fine;
the MutableCallSite does not get in the way.