Live data from Hacker News

Fjord – F# programming language for the JVM

github.com

31–40 of 62 posts

Re: Fjord – F# programming language for the JVM

#31
post #5

Earlier quoted context omitted.

F# works very well on Mono. You can compile and use the open-source edition of the F# compiler [1] on both Linux and on OS X (though I haven't tried OS X). This port is in very early stages, and only has the start of a lexer as far as I can see. [1] https://github.com/fsharp/fsharp

FYI, F# 3.0 is shipped as part of the Mono package for OS X. It's also available through the FreeBSD ports system: http://www.freshports.org/lang/fsharp/

(Replying to myself, since I can't edit the post now...)

More info on F# 3.0 + Mono 3.0 + FreeBSD can be found here: https://groups.google.com/forum/?fromgroups=#!topic/fsharp-o...

Arch Linux users: the thread I linked also has instructions on how to build/install F# 3.0 and Mono 3.0, if you're interested.

Re: Fjord – F# programming language for the JVM

#32
post #11

How is this supposed to work given the JVM does not support tail calls?

Maybe someone who knows Scala or Clojure internals can answer this question..

Someone has made TCO possible in Clojure already: https://github.com/cjfrisz/clojure-tco

Re: Fjord – F# programming language for the JVM

#33

Earlier quoted context omitted.

Maybe someone who knows Scala or Clojure internals can answer this question..

Clojure has a loop/recur construct which makes the tail recursion explicit so doesn't need to be done by the JVM. In other words regular recursive calls should not be used for loops if you want performance.

Scala has a similar explicit @Tailrec annotation for its compiler, too:

"A method annotation which verifies that the method will be compiled with tail call optimization. If it is present, the compiler will issue an error if the method cannot be optimized into a loop."

http://www.scala-lang.org/api/current/index.html#scala.annot...

Re: Fjord – F# programming language for the JVM

#34
post #23
post #15

Earlier quoted context omitted.

Or scala, which is an acceptable ML if you ignore the OO parts :-).

It's really not. Scala is a very interesting language, and it incorporates many functional features, but it's not at all ML-like. In particular, type annotations are needed in many, many places where they would be superfluous in an ML-derived language.

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.

Re: Fjord – F# programming language for the JVM

#35
post #11

How is this supposed to work given the JVM does not support tail calls?

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.

Re: Fjord – F# programming language for the JVM

#36
post #32

Earlier quoted context omitted.

Maybe someone who knows Scala or Clojure internals can answer this question..

Someone has made TCO possible in Clojure already: https://github.com/cjfrisz/clojure-tco

That's very cool. But note that as far as I can tell it only handles mutual recursion, not arbitrary tail calls (e.g. calls to a function argument).

Re: Fjord – F# programming language for the JVM

#37
post #25
post #18

Earlier quoted context omitted.

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

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?

Re: Fjord – F# programming language for the JVM

#38
post #11

How is this supposed to work given the JVM does not support tail calls?

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.

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

Re: Fjord – F# programming language for the JVM

#39
post #11

How is this supposed to work given the JVM does not support tail calls?

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.

Plus, as it is relatively simple to perform tail call elimination with iteration instead of reusing the frame in many (most?) cases, static analysis can classify those cases and hygienically rewrite those functions.

Most attempts I've seen to exploit TCO either aren't optimizations or can be dealt with via another control mechanism. My suspicion is that it is largely a solution in search of a problem for the programmer attempting to employ the technique, much like using AOP to add logging information for every "enter" and "return" from a method/function.

Mind you, I am in no way dismissing tail-call elimination as an important tool. Just that some of its practitioners (such as whichever idiot who wrote some of the barely-readable code in old programs of mine!) are a bit zealous in its use.

Re: Fjord – F# programming language for the JVM

#40
post #17

Earlier quoted context omitted.

What's the quality of code produced by Mono? How does it compare with Microsoft's compiler? I'd like to see Mono C# and F# numbers compared against Microsoft's compilers. Will I get 90% of the performance?

There are games running on Mono (e.g. Unity C# scripts, Bastion was ported to Mono to run in Chrome, etc..). I'm sure the performance of Mono may depend on your specific application but many people have been using it without any issues.

the c# performance over mono is really different to the f# performance..while c# has a decent performance on mono, f# doesn't performance so well......
Post reply on HN