
Frege: A JVM pure functional programming language in the spirit of Haskell - smikhanov
https://github.com/Frege/frege
======
reirob
"Frege is thought as a substitute for this missing GHC port. While not derived
from any existing Haskell implementation, it is more or less equivalent to
Haskell 2010. Please see the wiki page that details the differences."

So now Haskell can produce native executable code, run in a JVM and as subset
of it
([https://github.com/faylang/fay/wiki](https://github.com/faylang/fay/wiki))
run in the browser. Now there is no excuse for me to NOT using Haskell ;)

Thanks for bringing Haskell to the JVM!

~~~
cordite
If you look at the differences page, it is equivalent in power, but does not
have the same expression.

Pragmas now sorta start with @, and type classes are (in my opinion) kinda
funky coming from Haskell.

~~~
cgh
Another difference not mentioned is given the use of recursion in Haskell and
the JVM's lack of tail-call optimisation, I have to wonder how dangerous this
is. I know Clojure has recur (I'm not a Clojure programmer) but unless Frege
has something similar, I predict many an exploding stack.

~~~
dustingetz
It can compile to a loop. JVM can't optimize it for free at runtime. Scala has
tail recursion elimination

~~~
bunderbunder
What about tail calls for mutually recursive functions? My understanding is
that Scala is not able to do tail call elimination in this situation. So the
only situation where you can be sure that deep recursion won't overflow the
stack is when a function is tail calling itself.

If Frege isn't able to do any better with mutual recursion then that might be
a severe limitation on its utility. Scala users can work around the issue by
writing loops manually. In a pure language, not so much.

~~~
voxfrege
Frege _can_ handle mutual recursion.

The only problematic point is recursion through a strict function argument,
like in:

    
    
        length (x:xs) = 1 + length xs

------
tieTYT
As a programmer who's getting annoyed and tired of Java's boilerplate, I
welcome this. I went from Haskell to Clojure to JavaScript.

I loved Haskell __the language __. What I don 't is third party libraries are
usually directly or indirectly (through a dependency) tied to an OS. I've
heard, even on irc's #haskell, that it's hard to reuse code unless you're on
linux. Coming from Java, this is a deal breaker for me.

Then I tried Clojure. I liked it, but I found it very challenging to refactor
and mentally debug my code. I missed all the benefits of static typing.
core.typed seemed like an answer, but when you compare it to other languages
it seems to triple the verbosity which is a real turn off.

JavaScript (via CoffeeScript) is a pretty good middle ground, but immutable
state is nearly impossible. If I get lazy, it's so easy to go back to a
OO/procedural style and I don't like that. That probably does have its
benefits, but not when you're trying to learn a new programming paradigm.

I know very little about Scala, but I get a terrible impression from it. Where
Clojure is about simplicity, Scala seems to be about complexity.

Since I learned Haskell, I wished there was a way I could use it and have it
"just work" when I decide to use a library. Frege may be the answer. I've
heard of it a long time ago. My concern is that I'd be 1 of 3 people who'd be
using it. But nothing's perfect.

~~~
voxfrege
> My concern is that I'd be 1 of 3 people who'd be using it.

This concern is probably well founded. :)

And yet. Remember, you get Java source code from the Frege compiler, and once
you pack up your JAR with Proguard, say, nobody will be able to tell you
didn't write it in Java. (Well, slightly exaggerated, but you could have used
some obscure library, who knows?)

So, if you have a small project, or some Haskell project without too many GHC
extensions you want for some reason on the JVM, give it a try.

~~~
andrewflnr
I suspect the GP is more worried about community support for the language than
other people making fun of them for using it. :)

~~~
voxfrege
Sure, nothing can replace a big community.

OTOH, it looks like the Poster did have bad experience with Haskell community,
though.

A small community is superior insofar as they are more motivated to help, and
are more likely to take (critical) feedback into account.

I think it is fair to say that the Frege community (currently about 6 more or
less active contributors) does its best, judging from
[http://stackoverflow.com/questions/tagged/frege](http://stackoverflow.com/questions/tagged/frege)
and [https://groups.google.com/forum/#!forum/frege-programming-
la...](https://groups.google.com/forum/#!forum/frege-programming-language)

Of course, if someone demands, say, to implements GADTs or multi-param type
classes by tomorrow, the answer will be gentle, but not affirmative.

------
allertonm
It's interesting to compare this to CAL - an earlier Haskell-like language on
the JVM that was a project of some of my former colleagues at Crystal
Decisions/Business Objects back in the 00's:
[http://openquark.org/Welcome.html](http://openquark.org/Welcome.html)

I've worked quite a bit with CAL over the years and it has been used for some
serious work. One of my big frustrations with it though has been the
clunkiness of the Java interop, especially since this is one of the reasons
you might choose to use a language on the JVM.

Looking at the Frege docs, I like the look of the way this has been handled -
rather than using an FFI-style approach, things like Int, String etc map
directly to Java types and Java classes can be used like ADTs, which would
make life way, way easier.

Given the nature of the language calling Frege from Java is always going to be
more complicated but it looks like they've done a nice "fluent" Java API for
calling into the runtime.

Would be interesting to see how this performs relative to CAL, in terms of
both speed and space.

~~~
voxfrege
> Would be interesting to see how this performs relative to CAL, in terms of
> both speed and space.

Indeed. Do you have some CAL installation somewhere to make a comparison? (The
links I find are all broken.)

~~~
allertonm
Unfortunately it looks like you would have to build from source. The best
place for that would be Rich Webster's fork -
[https://github.com/rdwebster/Open-Quark](https://github.com/rdwebster/Open-
Quark) \- which is the version maintained by Indicee.

~~~
voxfrege
In the "How to build..." document it says I need Eclipse exactly 3.3.0

I am not going to install this, even if I would find it somewhere, hence ....

~~~
allertonm
I imagine the documentation is completely out of date.

Anyway, if you don't want to look at it, that's your loss - while I don't
think CAL has much of a future a lot of work was invested in it by a very
talented team and there is probably something to be learned from it.

~~~
voxfrege
> Anyway, if you don't want to look at it, that's your loss

Actually, I did look into it several years back. If I remember correctly, CAL
was not pure and still lazy. (An explosive combination, if you ask me.)

------
Tyr42
I like some of the differences where it was not constrained by Haskell's
choices, like splitting up the Monad, Applicative, Functor instances, and
namespacing of accessors. I also quite like the • for compose, with then some
shims so that . works too if it's not being used for the namespacing.

~~~
anon_d
Yeah, I'd like to see more languages using unicode identifiers. Seems to be a
very unpopular approach, though :(

~~~
tikhonj
Haskell can do it: there's a library with common Unicode operators[1]
(including ∘ for function composition) and an extension allowing you to use
Unicode _syntax_ [2] (things like → in place of ->).

I've seen these things used, but they're not super common. People still worry
about not being able to input Unicode symbols in their editor! I personally
think this is absurd in this day and age. Naturally, it's very easy to do in
Emacs; somebody even wrote a Haskell input mode[3].

[1]: [http://hackage.haskell.org/package/base-unicode-
symbols-0.2....](http://hackage.haskell.org/package/base-unicode-
symbols-0.2.2.4/docs/Prelude-Unicode.html)

[2]:
[http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/synta...](http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/syntax-
extns.html)

[3]: [https://github.com/roelvandijk/emacs-haskell-unicode-
input-m...](https://github.com/roelvandijk/emacs-haskell-unicode-input-method)

~~~
anon_d
Oh, nice! I setup XCompose to support rfc1345, so I have fast unicode input
everywhere. I'm definitely going to experiment with that Haskell extension.
I've done that manually before in ML with a preprocessor, but it was a nasty
hack. A proper extension is much nicer!

EDIT: How many people still have trouble with Unicode input? Should I publish
my XCompose solution?

------
stuhood
The conclusions of [http://fregepl.blogspot.jp/2013/03/adding-concurrency-to-
fre...](http://fregepl.blogspot.jp/2013/03/adding-concurrency-to-frege-part-
iii.html) lead me to believe that the author knows significantly more about
Haskell than about either the JVM or concurrency. I hope that the language is
able to attract a healthy number of contributors in those areas before it
begins to accrete it's own idiomatic concurrency patterns.

~~~
noelwelsh
Your comment would be more useful if you elaborated on these claims.

~~~
stuhood
The section on forkIO vs forkOS is interesting because the author does not
mention implementing green threads atop the JVM. It would be feasible for
Frege and its core libraries to use an implementation of "green threads" based
on Promises or CPS under the covers in order to implement a concurrency model
indistinguishable from Haskell's.

While it is true that the vast majority of JVM code you interact with is
blocking and expects to own whatever OS thread it is running on, that _could_
be treated as a concern of FFI, where untrusted/blocking code in Java land
gets dedicated OS threads (similar to FuturePools/execution-contexts for scala
Futures, or how you would manually isolate blocking code for Erlang or Go
FFI.)

Additionally, the comment dismissing STM seems like an afterthought, because
there are at least three JVM implementations (Clojure's, Scala's, and
Multiverse)

But the main comment I was referring to was:

    
    
      To do serious concurrent work in an JVM environment is
      different and it will thus require different knowledge
    

... which suggests that the author isn't interested in supporting Haskell's
idiomatic concurrency model atop the JVM, and is instead fine with the status
quo of blocking code.

~~~
voxfrege
> which suggests that the author isn't interested in supporting Haskell's
> idiomatic concurrency model atop the JVM

This is not quite true (I am the author). Yet I know my limits. Every
contribution from the community is welcome, OTOH.

The point of the blog posts was only to explore how far one can get with what
Java has.

------
bitdiddle
Cute name. I wonder to what extent the language has anything to do with
Frege's work in logic. I mean Haskell's last name was Curry, and currying is a
big deal in FP. Thankfully that wasn't named after Moses Schoenfinkel.

~~~
Xophmeister
That said, I always felt that "Finkel" would be a cute name for an FP
language, service or library... I call dibs!

~~~
JasonSage
If that's the case, maybe you should name if after Raphael Finkel. [1]

Disclaimer: I had the privilege of meeting Dr. Finkel here at university a few
times before I stumbled across his name in Wikipedia and in the front of a
book in the library. Totally not biased.

[1]
[http://en.wikipedia.org/wiki/Raphael_Finkel](http://en.wikipedia.org/wiki/Raphael_Finkel)

------
reirob
A presentation about Frege from the author itself:
[http://fregepl.blogspot.jp/2013/08/talk-at-karlsruhe-
functio...](http://fregepl.blogspot.jp/2013/08/talk-at-karlsruhe-
functional.html)

Actually it is the link to the blog entry that contains a link to the
presentation.

------
_pmf_
Anything that replaces the horribly overengineered and bastardized Scala
travesty is welcome.

~~~
pron
One of the things that make the JVM so cool is the easy interoperability of
most JVM languages. It's good to have languages like Java (or Kotlin),
Clojure, Frege and Erjang on the JVM, each with its own strengths. Each can
remain relatively simple and consistent, and all interoperate and share
libraries. This is far better than that "bastardized travesty" trying to be
all languages at once, and ending up an incoherent mess, retaining little of
the advantages of those simple languages.

------
adultSwim
I really wish this was strict.

I feel like most regular programmers could understand and benefit from using
ML (or some similar language).

In Haskell, laziness kept the language pure while it was developing but now
I'm not sure it should be the default. I like OCaml style opt in laziness.

For most people, they could get a lot of pretty vanilla typed functional
programming language. Polymorphic type inference, algebraic data-types,
pattern matching. That gets you really far.

~~~
cannam
There is Yeti ([http://mth.github.io/yeti/](http://mth.github.io/yeti/)), a
JVM language from the ML family. I think it's close to a 1.0 release, and the
compiler has been pretty reliable for a while now. I find it a delight to use.

------
binarymax
I'm excited about this - but cannot seem to find a 'hello world' or any other
actual code examples?

\--Edit-- is it the exact same syntax as Haskell? Unclear.

~~~
quesebifurcan
have a look at:
[https://github.com/Frege/frege/tree/master/examples](https://github.com/Frege/frege/tree/master/examples)

------
lysium
The author Ingo Wechsung outlines the ideas and concepts of Frege in the
German blog 'Funktionale Programmierung': [http://funktionale-
programmierung.de/2013/10/10/frege.html](http://funktionale-
programmierung.de/2013/10/10/frege.html)

------
undoware
As an analytic phil PhD dropout _and_ a Haskell lover I can say with
confidence that (a) Gottlob Frege (the philosopher) was awesome (I still want
a 'morning star != evening star' tattoo) and (b) Frege sounds lovely too. I'd
actually considered writing something similar.

------
rtfm666
simplified one here too - [https://github.com/lwm/functional-
java/blob/master/src/test/...](https://github.com/lwm/functional-
java/blob/master/src/test/nonStrict/HigherOrderTest.java)

------
Touche
Looks really cool! Oh, it runs on the JVM. Hm, too bad.

~~~
waterlion
What would you prefer? A language that doesn't need a runtime, like C? A
language that has only one available runtime, like node.js? A language that
has a choice of runtimes but there are incompatibilities between them like
Python or Ruby? A language that has a choice of runtimes from a choice of
vendors like Java?

~~~
Touche
A runtime that can be used for a wide-variety of types of applications. JVM
can really only be used for writing web servers and possibly daemons.

~~~
Bostwick
And building Twitter [1], and big-data next-generation databases [2], and
android apps, and desktop apps, and big data [3], and as a platform for new
languages (Clojure, Scala, Frege), and many more applications.

Really, the JVM can be used for anything that _computers_ can be used for, and
it does so in a way that the code is runnable across all major platforms and
still maintains a top-5 language performance spot, even beating C/C++ in some
specific cases.

Why do you feel that the JVM is limited in its applications as a development
platform?

[1]
[http://blog.redfin.com/devblog/2010/05/how_and_why_twitter_u...](http://blog.redfin.com/devblog/2010/05/how_and_why_twitter_uses_scala.html)
[2] [http://www.datomic.com/about.html](http://www.datomic.com/about.html) [3]
[http://hadoop.apache.org/](http://hadoop.apache.org/)

~~~
Touche
> And building Twitter [1],

Web server.

> and big-data next-generation databases [2]

Daemon.

> and android apps

No, Android doesn't have a JVM.

> and desktop apps

If you say so, I see very few of these in production.

> and big data

Daemon.

> Why do you feel that the JVM is limited in its applications as a development
> platform?

You can't write cli applications in a JVM language because the start-up time
is too slow. Which means you can't compose scripts that call Java apps.

This is not just 1 type of application, it's the most important type of
application by far. It's fundamental to how Unix operates. With Java you can't
write small applications that do one thing well, you have to write big
applications that are going to run for a very long time.

This is useful for things like web servers and daemons, but otherwise it
sucks. It's why I can't get excited about JVM languages.

~~~
Bostwick
> You can't write cli applications in a JVM language because the start-up time
> is too slow. Which means you can't compose scripts that call Java apps.

You're right. In the case of small, fast applications designed to be called as
part of shell scripts, the JVM does suffer start-up costs. Some testing on my
personal machine shows the JVM to be 2x to 8x slower than a comparable Ruby or
Python script in startup time. [1] Depending on the script, that startup time
may or may not acceptable, and if the script runs for longer than a second,
which is entirely possible for anything that goes beyond the local machine,
the JVM will get progressively faster.

> This is not just 1 type of application, it's the most important type of
> application by far.

This needs more explanation. I've used Unix for many years, and I've
definitely bought in to its philosophy of small and composable; It's a
philosophy that in many ways mirrors functional programming. However, in my
opinion, the most important type of application varies considerably by person.
For you, the small, single-purpose applications may be what you use most.

And I agree, if you're programming for the Unix platform, the JVM would not be
the best choice. Unix was built on C. A program that builds on that platform
is probably a better choice.

But there are many more applications out there, and for any command-line
program that operate in a time domain longer than 10 seconds, the JVM startup
costs are mostly eliminated. This time-domain is very plausible for a command
that operates on medium-scale databases or anything with network connectivity.

It's silly to completely dismiss an entire platform because it is not the
absolute best choice for a single domain of programs.

I'm curious: What do you do where the short-lived, composable Unix functions
are the most important programs?

[1]
[https://gist.github.com/bostwick/8ee1d4df9c7743f9efed](https://gist.github.com/bostwick/8ee1d4df9c7743f9efed)

~~~
Touche
I think we simply approach software different. I feel that small, composable
applications should be the default, and I nearly always start off this way.
I've been involved in projects from writing a specialized version of cp, ETL
processes, to developer focused but consumer-facing web applications and the
first interface I write to anything I do is as a small cli application that
works well with standard unix tools.

When you embrace this philosophy it doesn't particularly matter how good a
language's ecosystem is, you have all of unix to interop with. For example, I
don't care if a language has a good JSON parsing because jq[1] exists and is
probably faster and easier to work with than just about any language's built
in tools, even better than JavaScript itself.

With JVM you can't participate in writing software this way. Everything must
revolve around the JVM and it's ecosystem.

[1][http://stedolan.github.io/jq/](http://stedolan.github.io/jq/)

