HN user
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.jarTrue, 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.
Yes, I have often considered how I could employ GHC, for example. But it turns out, as always, that the devil is in the details. Ideally, one would think you could get away with just writing another backend and implementing another FFI calling convention for the JVM. Yet, projects like LambdaVM that pursue this approach are stalled or given up completly.
The difficulties are clearly stated in the Hasell wiki here https://wiki.haskell.org/GHC:FAQ#Why_isn.27t_GHC_available_f...
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.
I haven't read the "Begriffsschrift", but you are right. It is probable that he had developed his formal apparatus already then.
Well, probably the word "discovered" would fit better. :)
Here is a paragraph from "Funktion und Begriff" (1891):
Wie nun Funktionen von Gegenständen grundverschieden sind, so sind auch Funktionen, deren Argumente Funktionen sind und sein müssen, grundverschieden von Funktionen, deren Argumente Gegenstände sind und nichts anderes sein können. Diese nenne ich Funktionen erster, jene Funktionen zweiter Stufe.
For non-german speakers: Frege makes a distinction between functions that take things as arguments and functions whose argument are and must be functions. He calls the former ones "first order functions" and the latter ones "second order functions".
Today we call functions whose order is greater one "higher order".
Type inference for higher ranks is in fact undecidable, but not type checking. Hence, exactly like in Haskell with RankNTypes, you need to annotate your higher rank functions.
Actually, the Frege compiler employs an algorithm described in Simon Peyton-Jones paper "Practical Type Inference for Higher Ranked Types". Ordinary HM types are inferred, and higher ranked types checked.
It has both.
Somewhere it is said that it has all language features of Haskell 2010. This implies higher kinded types.
But in addition to Haskell 2010, Frege has also higher rank types.
Actually, you can write:
foo = (\a -> \b -> (a+b)*(a-b)) :: Num z => z -> z -> z
Given that Gottlob Frege invented higher order functions and currying, I am of slightly different opinion.
Regarding the pronounciation, who cares? For example, in Germany, half of the people say "Ay-Bee-Em", the other half pronounce the letters IBM in the german way.
but there isn't currently a way to directly implement interfaces or inherit abstract classes in just frege.
Not quite true anymore. TO be sure, some (inline) java will still be needed.
Here is an example https://github.com/Frege/frege/blob/master/tests/comp/Issue2... which compiles to a class that implements java.util.Comparator. Instances thereof can be created from Frege by passing a custom comparision function and could be passed to Java.
The example would be useful in cases when you have Frege data in a Java collection and want to sort them. But it is merely there to show the possibilities.
Yes, that is true.
But it is also not as relevant as one might think.
Consider how many Haskell programs actually use mutable C data, or export functions that take a foreign ptr to some mutable stuff.
Why should this be generally different in Frege? Useful Java APIs will be wrapped and sanitized through Frege libraries, and that is it then.
You can go directly to Java, just like you can directly go to C in Haskell, but it turns out one rarely actually does this.
I would probably be better off using Haskell directly.
This is certainly true. You can see Frege as a subset of Haskell 2010 plus some GHC extensions plus the native interface (i.e. the Java FFI).
Unless you really need the JVM, Haskell (i.e. GHC) is the probably the better choice.
Frege is just an offer for the minority that wants pure FP specifically on the JVM. Those people had no real choice until recently, given that CAL is dead, and E. Kmett's "ermine" not yet there.
This would mean using a hash set would be out of the question _for passing around outside of an ST monad_ but you could actually use it internally within functions.
Yes, but this is what the author was saying: you end up writing your code in ST. Remeber, there is no (general) way to freeze a mutable collection that was passed and then use it as if it was immutable. There can be a dozen different threads be busy modifying it.
However, as immutable objects are becoming more mainstream even in Java, there will still plenty of opportunities to make polyglot JVM programs employing pure code. Just not with the JAVA collection classes.
It is an FFI, though with different syntax, and much richer. Not only functions, but also foreign (in Frege its called "native") types. Which is indispensable IMHO when you interface a OO language where everything is classes and interfaces.
The different syntax should not be a big issue, as Haskell code that uses FFI targeting C is per se not portable.
If you know such a function to be pure, you can use unsafePerformIO to tell the type system
Better yet, if you know it to be pure, you can give it an appropriate type and just use it in pure code, like:
pure native cos java.lang.Math.cos :: Double -> Double
foreign import jvm "java.lang.Math.cos" cos :: Double -> Double
In fact, all primitive operations, types and so on are defined this way in the Frege Prelude.
No, incorrect. You can use any existing bytecode, whether it was produced by Java or anything else.
It is http://www.frege-lang.org or simply https://github.com/Frege/frege
Well, the Boolean operators in C-like languages are NOT normal functions, which is the point.
"Not normal", because the language is strict, and there is no way to make a lazy function on your own, even when it is so tremediously useful.
In other words, the C standard comittee decides which functions may be lazy. As a Haskell programmer, you decide.