voxfrege

5 ms·

1.
by voxfrege 11y ago
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 extens
2.
by voxfrege 11y ago
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,
3.
by voxfrege 11y ago
Sorry, riscy, with >= I mean, Frege programs will take longer than native ones.
4.
by voxfrege 11y ago
Yes. And, in addition, to Java source code.
5.
by voxfrege 11y ago
Generally, >=
6.
by voxfrege 11y ago
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 bet
7.
by voxfrege 11y ago
I can only encourage you to do this, and come back with criticism (or praise).
8.
by voxfrege 11y ago
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 polymo
9.
by voxfrege 11y ago
The demand seems to be not that big, at least nobody started to seriously take on some out of the box Android support.
10.
by voxfrege 11y ago
The compiler is a Frege app.
11.
by voxfrege 11y ago
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
12.
by voxfrege 11y ago
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
13.
by voxfrege 11y ago
Module header is currently still mandatory.
14.
by voxfrege 11y ago
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 call
15.
by voxfrege 11y ago
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.
16.
by voxfrege 11y ago
I haven't read the "Begriffsschrift", but you are right. It is probable that he had developed his formal apparatus already then.
17.
by voxfrege 11y ago
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 F
18.
by voxfrege 11y ago
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 S
19.
by voxfrege 11y ago
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.
20.
by voxfrege 11y ago
Actually, you can write: foo = (\a -> \b -> (a+b)*(a-b)) :: Num z => z -> z -> z HOwever, it is quite un-idiomatic, of course.
21.
by voxfrege 11y ago
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 pronou
22.
by voxfrege 11y ago
> 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.
23.
by voxfrege 11y ago
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
24.
by voxfrege 11y ago
> 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, Haskel
25.
by voxfrege 11y ago
> 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 c
26.
by voxfrege 11y ago
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 i
27.
by voxfrege 11y ago
> 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
28.
by voxfrege 11y ago
No, incorrect. You can use any existing bytecode, whether it was produced by Java or anything else.
29.
by voxfrege 12y ago
It is http://www.frege-lang.org or simply https://github.com/Frege/frege
30.
by voxfrege 13y ago
> 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 tremediou

More ›