
Frege – a Haskell for the JVM - talles
https://github.com/Frege/frege
======
mark_l_watson
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.

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

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

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

~~~
macmac
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."

~~~
jeremyjh
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.

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

~~~
jeremyjh
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.

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

~~~
voxfrege
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.

~~~
ta_donk_gt
> 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...](https://visualstudio.uservoice.com/forums/121579-visual-
studio-2015/suggestions/2228766-add-higher-order-generics-to-f-type-classes)

------
mrcactu5
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/17222383/how-to-run-frege-
programs-on-android)

[http://stackoverflow.com/questions/5151858/running-a-
haskell...](http://stackoverflow.com/questions/5151858/running-a-haskell-
program-on-the-android-os)

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

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

~~~
nine_k
I fail to understand the question. Isn't hosting "pure" Haskell code in an
imperative modern OS environment a common thing to do?

~~~
asplake
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.

~~~
voxfrege
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.

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

~~~
voxfrege
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

~~~
mike_hearn
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.

~~~
voxfrege
The compiler is a Frege app.

------
yari_ashi_zero
So then we have Haskell with Clojure.

~~~
tangled_zans
Does that mean we can use Haskell with datomic?

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

~~~
voxfrege
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.

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

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

~~~
voxfrege
Yes.

And, in addition, to Java source code.

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

~~~
voxfrege
Generally, >=

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

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

~~~
riscy
Ah, okay. :)

