I need to take a serious look at Frege. I am writing a book on Haskell and I have spent years using various JVM languages, so Frege seems like a good bet to invest some time on - if the development environment, REPL style Dev, etc. is as smooth as it is for Haskell.
The below is the projects own take on that question:
"Frege gives you the opportunity to use your skills on the JVM. Most idiomatic Haskell code will run in Frege unmodified or with only minimal, obvious adaptions. Even more important: you can bring your purely functional problem solution strategies to your Java projects."
This is ridiculously optimistic. Perhaps many toy programs can be easily converted, but real programs that use libraries other than base will not be so easy to migrate.
I've used the Haste compiler which IS Haskell that supports ALL GHC extensions except TemplateHaskell, supports the Cabal build tool and in practice it has its own ecosystem; most of Hackage will not compile on it.
Frege doesn't implement all the language extensions (very commonly used ones, such as MultiParamTypeclasses, are not supported), it doesn't share a build tool. It would be a great deal of work to port any non-trivial program.
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.
> I've used the Haste compiler which IS Haskell that supports ALL GHC extensions except TemplateHaskell, supports the Cabal build tool and in practice it has its own ecosystem; most of Hackage will not compile on it.
As someone who's standing on the precipice of GHCJS, Haste and PureScript, I'm very curious to hear about your Haste experiences in this regard.
(I've been using PureScript in my side-projects for a bit. For the sake of completeness of this list, I've tried Elm and am not interested.)
I really want to like Haste. It supports nearly all features of GHC, it works with Cabal, it produces small output that can be understood/debugged. Its runtime is only 500 lines of clean javascript. I was able to build a toy app that shared code between client and server and let me use my existing tools to work on it (Hdevtools et al.). For awhile a nice react library was in development for it.
But... its lack of support for TemplateHaskell and native code means that a lot of firewalls/shims are required to share code with likely server programs. There is no support for common library types such as Text and Aeson types - ghcjs has shims for those that build without native dependencies. react-haskell library switched to ghcjs because the Haste ecosystem/development community is non-existent. And I would probably not build a serious project with Haste for the same reason.
ghcjs is nice but...it is too big in so many ways. The runtime footprint for real programs is very large. The complexity of it seems high and it still only has a single dedicated developer. I've heard its performance demands are high - it doesn't seem like something you'd want to run on a phone. It feels too risky to me - Purescript or Typescript is probably what I would go with for a serious project.
Are typeclasses possible on the JVM? I'm a .NET person, and I've always heard that typclasses aren't possible on the .NET CLR, so I wonder what's different about the JVM that makes this possible?
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.
Scala has typeclasses. It is not strictly equal to Haskell since it relies on the usage of `implicit`. Plus it doesn't enforce that there is only one typeclass per type in the classpath (I believe I remember that Haskell enforces that I compile time).
Implicit is basically just an implementation detail. The idea of only allowing one typeclass instance per data is generally referred as confluence and you're correct in that scala doesn't attempt to enforce it.
I understand the Haskell communities desire for coherent typeclasses, but I still find the newtype work around cludge to allow multiple implementation of, say, Monoid to be quasi hacky. What's worse, you can still fairly easily define multiple instances of the same typeclass accidentally (orphan instances) and the compiler won't catch it.
Maybe it was valueclasses you heard were not possible on the jvm? I think those are indeed possible on the CLR but not on the jvm. PS: yes I know scala has value classes, but sometimes those have to be instantiated.
Is writing "pure" Haskell to be hosted in a non-Haskell imperative environment a common thing to do, as opposed to separating the pure and the imperative via monads? Seems to me that Frege could make this quite attractive.
I mean leaving IO to a program to which the (pure-only) Haskell code is linked, dispensing with monad-based separation. Frege seems to make this particularly easy.
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.
That's not that different to the standard separation of Haskell code between "inside IO" and "outside IO", is it? In this case, the calling Java code "lives" inside IO (as all Java programs do).
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.
On a server, it's a non-issue. On desktop, likely, too. Modern Android does AOT compilation. Hopefully by the time Frege is ready for Android this will not be a problem anymore.
It's the core namespace that is huge. Also clojure embeds all metadata etc, taking more time than necessary for a script runtime. Clojure guys discussed having multiple builds, a lean runtime for fast boot, and more featured one for repl usage (even more documentation embedded etc)
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 can expect performance to be no better than a full-fledged native compiler for the language, if the native compiler was somewhat mature.
In this particular case, Frege is compiling to Java source code (not JVM bytecode), and Java does not give precise control over how things should be done at runtime, such as object representations. Additionally, while the main Java compiler is reasonably mature, its optimizations are certainly tailored for idiomatic Java, which includes a lot of mutation, strict evaluation, and use of object-oriented programming. Haskell in particular has unevaluated expressions everywhere (thunks) because of lazy evaluation, and heavy use of first-class and recursive functions.
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)?
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.
