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…
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…
Sorry, riscy, with >= I mean, Frege programs will take longer than native ones.
Yes. And, in addition, to Java source code.
Generally, >=
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…
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…
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…
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…
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…
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…
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 HOwever, it is quite un-idiomatic, of course.
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…
> 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…
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…
> 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…
> 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…
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…
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…
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…
Sorry, riscy, with >= I mean, Frege programs will take longer than native ones.
Yes. And, in addition, to Java source code.
Generally, >=
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…
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…
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…
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…
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…
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…
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 HOwever, it is quite un-idiomatic, of course.
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…
> 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…
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…
> 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…
> 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…
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…