voxfrege

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.

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

Yes.

And, in addition, to Java source code.

Generally, >=

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.

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

The compiler is a Frege app.

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

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.

Module header is currently still mandatory.

In the InfoQ article this topic ponts to, I've said something about this.

The short answer is that it is not derived from existing Haskell compilers.