To counter possible misunderstandings: Frege is not positioned against Haskell in any way. To the contrary!

When you don't need the JVM, by all means, use GHC or some other native Haskell compiler! You'll have more language extensions, libraries, and your program will be faster and use less memory in most cases.

You nailed it.

OTOH, one experience we did make is that the JVM is not so bad in running pure code, as far as the JIT and GC is concerned.

The biggest hurdles on the JVM are: absence of value types (e.g. tuples), the smallish, fixed stack, and lack of tailcall bytecode.

Yes.

And, in addition, to Java source code.

Generally, >=

Uh, care to explain why you think something like compiling Haskell to Java will yield better performance than writing an optimizing compiler such as GHC, with its native backend and optimizations that are tailored specifically for the types of programs written in Haskell (including things like the runtime system such as the garbage collector)?

Sorry, riscy, with >= I mean, Frege programs will take longer than native ones.

Ah, okay. :)

Can you explain why? I'm not an expert but I know that GHC relies on some sort of stack reduction machinery. Implement something like this on top of an existing VM, and you would lose some performance, I would say.

Sure, this would be possible.

You can call "into" Frege code from any JVM language. OTOH, you can call any JVM code you could with Java (Frege is compiled to Java source code).

The crucial point are the data that get exchanged between Frege and Java in either direction. While there are no problems with primitive types or Strings, standard JVM container classes like java.util.HashMap or java.util.ArrayList represent mutable data, and thus we can't use them with _pure_ Frege code.

For that reason, we still need monads (in particuar, IO and ST) to deal with mutable data in Frege.

I can only encourage you to do this, and come back with criticism (or praise).

Frege has typeclasses (Haskell 2010).

Whoever told you it's impossible in .NET is probably wrong. Don't you have interfaces in C# ? But you don't even need interfaces. Strictly speaking, unless you use typeclasses with polymorphic recursion, you don't need a runtime representation for typeclasses at all.

> Whoever told you it's impossible in .NET is probably wrong.

I think brianberns is probably referring to this: https://visualstudio.uservoice.com/forums/121579-visual-stud...

The demand seems to be not that big, at least nobody started to seriously take on some out of the box Android support.

It's okay, at least when you have SSD or at least decent RAM.

Here is an example:

    ingo@freguntu:~/Frege/frege$ time java -jar fregec.jar -version
    3.23.900
    0:00.22 62016k
    ingo@freguntu:~/Frege/frege$ ls -l fregec.jar -rw------- 1 ingo ingo 33426802 Mär  6 12:32 fregec.jar

Aren't you checking the Frege compiler, there?

The complaint about Clojure is that Clojure apps start slow. Frege compiles to Java and from there to bytecode, so you'd need to compare a hello world in both languages to answer the original question, I think.

The compiler is a Frege app.

22 milliseconds? Unless I'm mistaken that's blazing fast?

I believe that's 220ms. Which isn't too bad. But Clojure can usually match that if you AOT everything.

It's still too slow for serious command-line utils, though, so you're back to Haskell.

Or using a long-running system daemon to host the VM

True, this "ecosystem" is often overlooked.

The goal of the Frege developers is to achieve full Haskell 2010 compatibility by the end of this year. However, that still doesn't mean you can port all code easily.

What it does mean is that you can use your Haskell skills in projects that are for some reason restricted to the JVM.