Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fjord – F# programming language for the JVM

github.com

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Fjord – F# programming language for the JVM

#51

Post by lysium »

clhodapp wrote: post #48
lysium wrote: post #42

Earlier quoted context omitted.

If you want to be pedantic, the JVM does not support tail (function) _calls_, but jumps, which may be the result of tail call optimization or elimination. As far as I know, we still cannot efficiently turn mutual recursive calls into a chain of jumps, but I'll be glad to be corrected here.

I think there may be a misconception here: A tail call is NOT a call that doesn't allocate a stack frame. A tail call is a call that is the return value of a function. This is why we refer it the stack frame-eliminating optimization as "tail call elimination". We are taking a jump-to-subroutine (call) instruction and replacing it with a normal jump instruction, thus eliminating a "call" from our program. The JVM most…

Thanks for the clarification.

If I read you correctly, you say, the JVM 'supports tail calls', because it can call other methods. I think, the phrase 'supports tail calls' is as meaningful as 'supports function calls' then.

In any case, I don't think this is a question of optimization. I don't see how, for example, an F# program written in CPS can ever run on the JVM.

Re: Fjord – F# programming language for the JVM

#52

Post by carterschonwald »

th0ma5 wrote: post #37
octo_t wrote: post #25

Earlier quoted context omitted.

surely you could just run lljvm on the llvm IR that ghc emits and have haskell code on your JVM?

could you get the kind of adhoc library interop you get with other on-the-jvm languages like this with llvm?

probably not if you did it this week :)

That said, there is some very interesting work going on towards having a sane call out to JVM / .net code from haskell, though nothing will realistically be in a truly usable for in the next 12-18th months

Re: Fjord – F# programming language for the JVM

#53

Post by lucian1900 »

skrebbel wrote: post #27
daeken wrote: post #10

Earlier quoted context omitted.

IKVM runs JVM code on .NET, not the other way around.

That may not be a practically relevant difference. Why would you want to run F# on the JVM? To interface with JVM code. IKVM lets you do that already. I've rolled out multiple .NET programs that contain Java open source libraries through IKVM. It works just fine, and the amount of extra work you need to do to make the JVM->.NET mapping work is remarkably little.

Or perhaps you'd wish to run F# on the JVM because you like the language, but don't wish to depend on .NET (or Mono).

Re: Fjord – F# programming language for the JVM

#54

Post by lucian1900 »

lysium wrote: post #42
clhodapp wrote: post #35

Earlier quoted context omitted.

In general speech, I can get behind the idea that you shouldn't correct someone if you understand what they mean. In programming, however, I think it's important to be pedantic. You must mean tail call optimization/elimination here. Clearly, the JVM supports tail calls.

If you want to be pedantic, the JVM does not support tail (function) _calls_, but jumps, which may be the result of tail call optimization or elimination. As far as I know, we still cannot efficiently turn mutual recursive calls into a chain of jumps, but I'll be glad to be corrected here.

Scheme implementations will compile any tail calls into jumps, even if they're mutually recursive. This is easy to understand by doing CPS transformation by hand on such calls.

Re: Fjord – F# programming language for the JVM

#55

Post by groovy2shoes »

clhodapp wrote: post #49
tomp wrote: post #38

Earlier quoted context omitted.

I think everyone knows what he meant. In programming, everything supports everything anyhow, as long as it's Touring complete.

This isn't really fair: some implementations really do rule out certain optimizations. Turing-Completeness only refers to what is computable, not what actual algorithms and optimization techniques are possible.

And to be more specific, Turing completeness refers to what is computable with an unbounded amount of memory and time. This is why we have complexity theory layered on top of computability theory. Some things are theoretically computable but practically infeasible. Compiler optimizations can help greatly in some of those cases.

Re: Fjord – F# programming language for the JVM

#56

Post by mafribe »

jon_smark wrote: post #47
mafribe wrote: post #34

Earlier quoted context omitted.

As a recent migrant from Ocaml to Scala (due to stagnation of Ocaml), I have to say that you are quite right about type-annotations, but the style of programming that an Ocaml/F# person would be accustomed to is quite easily replicable using Scala.

What do you mean by "stagnation of OCaml"? There was a period some 4-5 years ago where it did seem like there was little development on the language, but things have changed quite a lot since then. Lots of developments in the core language (including first-class modules and GADTs!), and a blossoming of the ecosystem around it. To me, it seems OCaml has never been livelier than now...

Let me start by saying that I By stagnation I mostly meant the comparatively tiny ecosystem of libraries vis-a-vis, e.g. JVM-based languages. In particular, with Akka, Scala has much nicer support for concurrency. The ability to call, and be called by, Java code in the smoothes possible way is also beneficial for my use cases.

I'm surprised that GADTs were added, because a few years ago I visited the Gallium team at INRIA who develop Ocaml, and asked about GADTs. I was told by one of the senior Ocaml developers that there were no plans for the inclusion on this feature.

Re: Fjord – F# programming language for the JVM

#57

Post by happy_dino »

cantankerous wrote: post #22
happy_dino wrote: post #16

Earlier quoted context omitted.

Support for tail calls pretty much depends on the actual runtime implementation. If it is important to you (it certainly is to me), use an implementation which supports proper tail calls. I'm doing it and I have never looked back.

Out of curiosity, which implementation are you using?

Have a look at http://oss.readytalk.com/avian/.

Re: Fjord – F# programming language for the JVM

#60

Post by voxfrege »

quasque wrote: post #18
Raphael_Amiard wrote: post #9

To save anyone the trouble, this project is totally empty yet. It doesn't say anything about the ability of the owner to port F# to the JVM, but just know that it is just a readme, three almost empty java classes, and the beginning of an ANTLR parser. So to answer other questions here, you can't even compare it to F# on Mono. F# on Mono works perfectly. The F# compiler and runtime is huge, and getting to parity will…

Perhaps of more interest is Frege, which is basically Haskell for the JVM. Seems to be coming along nicely: https://github.com/Frege/frege

I am not so sure if Frege would be of interest for people that look for an impure, strict language. A better fit for that would be Yeti.

And assuming that porting a language that is so deeply rooted in the .NET world like F# is very difficult, my guess is that going with Yeti and thus fully embracing the JVM will be a better choice. The more so as one could do this right now.

Post reply on HN