Frege – a Haskell for the JVM | Hacker News Reader

Frege – a Haskell for the JVM

github.com

177 pointstalles48 comments

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.

I can only encourage you to do this, and come back with criticism (or praise).

Hopefully this can be turned into a GHC plugin providing an additional back-end with https://ghc.haskell.org/trac/ghc/ticket/11470

Interesting; any Haskell users comment on how portable code is between pure Haskell and Frege?

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.

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.

> 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?

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.

> Whoever told you it's impossible in .NET is probably wrong.

I think brianberns is probably referring to this: https://visualstudio.uservoice.com/forums/121579-visual-stud...

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.

Compilation is too local, but why can't a postprocess of the linker check for orphan or incoherent instances?

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.

Last I checked it was not possible to use a Frege program on Android. Has that changed any?

http://stackoverflow.com/questions/17222383/how-to-run-frege...

http://stackoverflow.com/questions/5151858/running-a-haskell...

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

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 fail to understand the question. Isn't hosting "pure" Haskell code in an imperative modern OS environment a common thing to do?

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.

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.

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).

One of the weaknesses of Clojure on the JVM is its ridiculously long startup time. How fast does Frege start up on the JVM?

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

Aren't you checking the Frege compiler, there?

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.

The compiler is a Frege app.

22 milliseconds? Unless I'm mistaken that's blazing fast?

I believe that's 220ms. Which isn't too bad. But Clojure can usually match that if you AOT everything.

It's still too slow for serious command-line utils, though, so you're back to Haskell.

Or using a long-running system daemon to host the VM

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.

Clojure is slow at startup because of the long list of classes have to be loaded at init I think.

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)

So then we have Haskell with Clojure.

Does that mean we can use Haskell with datomic?

How does Frege's performance compare to Haskell? The start-up time and over all.

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.

If there's a way to use Frege with Apache Spark that would be super useful

How does they compile it for JVM? To java-classes or to bytecode itself?

Yes.

And, in addition, to Java source code.

How does this compare performance-wise to natively compiled code?

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.

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.

Generally, >=

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)?

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

Ah, okay. :)

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.

Reply on news.ycombinator.com