Frege: A Haskell-Like Language for the JVM

http://www.infoq.com/news/2015/08/frege-haskell-for-jvm

by reirob • 11 years ago

111 114 11 years ago

This is pretty cool and interesting, but I'm curious how they can claim purity if they still permit evaluation of code written in Java or other JVM languages, even if the types have to be redeclared. In other words, I'm curious if they are permitting execution of "impure" functions outside of a monad or unsafe function if the type has been redeclared. May have to pull it down and have a look.

duaneb• 11 years ago

I would imagine you could have some combination of unsafePerformIO + an exception handler.

michaelsbradley2• 11 years ago

Here's a write-up from 2013, Frege: Hello Java:

http://mmhelloworld.github.io/blog/2013/07/10/frege-hello-ja...

reirob3• 11 years ago

On the related Reddit thread [0] a commenter links to a very nice blog that evaluates Frege [1] in a very succinct way. To answer your question by quoting this blog post:

"Wrapping mutable Java stuff in Frege means that everything will end up in an ST monad, which is almost always IO. That means that using Java’s HashSet will force anything that uses that to be in the IO monad itself. So there goes purity and referential transparency, which are some of the best parts of Haskell in the first place."

[0] https://www.reddit.com/r/haskell/comments/3gr7y6/infoq_frege...

[1] http://taylor.fausak.me/2015/06/25/frege-a-jvm-haskell/

EDIT: formatting

lexicalscope3• 11 years ago

Thanks for this.

This is a bit misleading though I think, as you can actually unwrap and ST unlike an IO - my most common use for ST is actually to use a mutable object in a case where it's inefficient to keep copying immutable (e.g.: large vector or matrix manipulations) - then when you're done the ST monad can be unwrapped and you get the final structure - the entire function remains pure but inside of it, there are calculations that rely on state - but no state enters or leaves the function per say. 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.

zxexz• 11 years ago

The compiler isn't very 'user-friendly', but if you're literally looking for "Haskell on the JVM" and don't care about speed, Frege is a lot of fun once you get used to it. Impure functions/variables must be wrapped in a monad (ST) (take a look at [0]. Frege is almost identical to Haskell, but with a few differences [1]

[0] https://github.com/Frege/frege-native-gen/issues/14 [1] https://github.com/Frege/frege/wiki/Differences-between-Freg...

evincarofautumn• 11 years ago

Allowing foreign code doesn’t change the purity of the language. By default in Haskell, an FFI declaration must be in IO, e.g:

    -- int frob(int, char*)
    foreign import ccall "frob"
      frob :: Int -> CString -> IO Int

If you know such a function to be pure, you can use unsafePerformIO to tell the type system:

    refrob :: Int -> CString -> Int
    refrob x y = unsafePerformIO (frob x y)

If you lie to the type system and tell it that an impure function is pure, then all bets are off.

lexicalscope3• 11 years ago

I guess that was my question - if they are making it use FFI as in Haskell, since it's Haskell-like not actual Haskell, or if it's something else that's specific to their JVM version.

voxfrege15• 11 years 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.Math.cos :: Double -> Double

which should be roughly equivalent to:

     foreign import jvm "java.lang.Math.cos" cos :: Double -> Double

except that no Haskell compiler that I know implements the "jvm" calling convention, for obvious reasons.

In fact, all primitive operations, types and so on are defined this way in the Frege Prelude.

dustingetz2• 11 years ago

Worth pointing out that this approach isn't particularly helpful when wrapping mutable Java objects, because Java land still has a reference and can/will mutate the object right underneath us. So we still need to write our Fredge code in ST.

michaelsbradley2• 11 years ago

You can try Frege using your web browser:

http://try.frege-lang.org/

reirob3• 11 years ago

Thanks for sharing!

It shows with :java the produced Java code.

devty• 11 years ago

http://mmhelloworld.github.io/blog/2013/07/10/frege-hello-ja...

Am I correct in thinking that Frege cannot leverage on third-party java libraries? Clojure, another functional language built on JVM, has great support for this (possibly) missing feature.

maaku• 11 years ago

I don't know about Frege, by why wouldn't it? Being able to call out over FFI or the Java equivalent is a pretty standard feature.

voxfrege15• 11 years ago

No, incorrect. You can use any existing bytecode, whether it was produced by Java or anything else.

jmillikan• 11 years ago

Calling Java from frege isn't hard, but there isn't currently a way to directly implement interfaces or inherit abstract classes in just frege. You can create a sort of proxy in Java (or whatever) and implement methods in frege, but it's not pretty. (I think; I haven't quite comprehended the examples.)

The article at https://mmhelloworld.github.io/blog/2013/07/10/frege-hello-j... talks about this, but doesn't quite explain the proxy mechanism, it just points out an example.

voxfrege15• 11 years 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.com/Frege/frege/blob/master/tests/comp/Issue2... which compiles to a class that implements java.util.Comparator. Instances thereof can be created from Frege by passing a custom comparision function and could be passed to Java.

The example would be useful in cases when you have Frege data in a Java collection and want to sort them. But it is merely there to show the possibilities.

hugofirth5• 11 years ago

One reason I would love to see this succeed which has almost nothing to do with the particulars of the Frege project itself is the effect it would have on the Scala community.

There is a significant portion of the Scala community which desperately wants Scala to be the Haskell they can get their bosses buy in for. IMO the result is unsatisfactory, both for those people and the Scala community as a whole.

If a straight Haskell variant in the JVM ecosystem were to "take off" then Scala could be its own thing.

MrBuddyCasino• 11 years ago

So thats the reason most Scala code reads like badly written Haskell fanfic.

dudul2• 11 years ago

I think most scala code reads like badly written Java code, mostly because people use at as a "better Java". FP fanatics try to use it as Haskell for JVM, but they are definitely not the majority.

Most scala users have no f-ing clue what a monad is :)

hugofirth5• 11 years ago

Out of interest - are you talking about the use of symbolic operators? Or something else (like the prevalence of the Typeclass pattern)?

Fiahil2• 11 years ago

One particular "annoying" feature of Scala is the Java interoperability. It's obviously great because you have a large quantity of tools usable from the Java world, but it leads to large quantities of time spent wrapping them into clean Scala interfaces (or dealing with unmelodious APIs, pick your curse).

I would love if I could avoid this with Fredge. But, in the end, I would probably be better off using Haskell directly.

hugofirth5• 11 years ago

I agree that when, in the process of learning Scala, you get beyond the "better Java" stage the interop can feel frustrating. On the other hand Scala gains so much from it. Its a huge net-positive IMHO.

As long as you are only bringing things in from Java-land, rather than going the other way though, the wrapping can be fairly minimal.

voxfrege15• 11 years 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, Haskell (i.e. GHC) is the probably the better choice.

Frege is just an offer for the minority that wants pure FP specifically on the JVM. Those people had no real choice until recently, given that CAL is dead, and E. Kmett's "ermine" not yet there.

rozap• 11 years ago

This is about 50% of the pain of Scala for me. I want to like scala, and some of the concepts behind it are neat, but in reality the act of writing it with the java interop, opaque unrepeatable errors, and compiler slowness makes it a fantastically unpleasant experience.

pron6• 11 years ago

There's an excellent implementation of OCaml for the JVM, which is, sadly, not well advertised (its author is a bit on the shy side): http://www.ocamljava.org/

lmm2• 11 years ago

The Haskelly parts of Scala are some of its best parts. It's always been a hybrid language, and it's always had a compromised design as part of that. But the result is wonderful, and either half alone would be diminished. And frankly any "boss-friendly Haskell" would have to have Scala-level Java interop, i.e. full support for inheritance, existentials and so on, at which point you end up going down the same path as Scala.

If you want Java you know where to find it. Likewise with Haskell. Scala draws from both and that's its greatest strength.

jbooth2• 11 years ago

Hopefully any future languages that prioritize java interop will do things like implement java.util.List rather than insist on renaming "add" to "+=" along with ":+", "+:", "+", "++", "++:" so that I have to constantly call .asScala, .asJava on collections while passing them around.

hugofirth5• 11 years ago

This is true - I love Scala for its hybrid nature. I'm just saying that I wish prominent members of its community would too. For example if you go on to the #scala IRC channel half the regulars on their will be complaining about how terrible Scala is ... For a variety of reasons that can be summed up as: its not Haskell.

If you spend a bit of time there it fades to background noise and #scala is actually a really friendly and helpful place - but "x is hard to do in Scala because Scala [sucks]" is an odd impression to give a newcomer.

piokuc• 11 years ago

The examples reminded me this artwork by Manuel Simoni: http://2.bp.blogspot.com/-nPo8up-CfXc/TmjmkzfY5NI/AAAAAAAAA2...

agumonkey• 11 years ago

I hope this argument fades away into eternity.

thedufer• 11 years ago

    main = putStrLn "\n"

Yes, that was very difficult. I see where you're coming from.

yawaramin2• 11 years ago

Actually putStrLn "" is enough, since it prints a newline after the string :-)

zak_mc_kracken3• 11 years ago

It's called humor. You should get some.

CommonLispr• 11 years ago

I think the name was a poor choice. It would have been a better fit for a Prolog-style language, and most people will probably mispronounce it.

voxfrege15• 11 years 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 pronounce the letters IBM in the german way.

mafribe12• 11 years ago

In what sense did Frege invent higher-order functions?

nnq3• 11 years ago

I know it's a minor thing, but why do people keep coppying this annoying Haskell/ML pattern where I have to type twice the name of a function if I want to explicitly define it's type?

    current :: IO String
    current = ...

(yeah, it's a minor issue compared to the uber-annoying problem of 'name clashes in record fields' https://wiki.haskell.org/Name_clashes_in_record_fields ...but still)

nightski• 11 years ago

I personally find it incredibly clean. You separate the type signature from the implementation (mostly because a lot of the times it is unnecessary from the compiler's pov, but useful as documentation). To that end, I don't see it as any different from a javadoc or any kind of code documentation.

In addition since Haskell supports multiple case defitions at the top level inline type declarations would be redundant. For example -

current a 0 :: IO Int Int -> Int current 0 b :: IO Int Int -> Int current 0 0 :: IO Int Int -> Int

vs.

current :: IO Int Int -> Int current 0 a = ... current a 0 = ... current 0 0 = ...

tome2• 11 years ago

What syntax do you propose?

nnq3• 11 years ago

This is the most obvious that comes to mind:

    current :: IO String : = do
        d <- Date.new ()  -- reads system timer, hence IO
        d.toString

...or for something that works better with a really huge type signature or list of arguments, you could extend it like this

    myFunctionFoo :: Int -> Int -> Int -> Int
    : a b c =
        2*a + 3*b + 4*c

OnleMeMeMe2• 11 years ago

What helps most beginners with Monads etc. is seeing it from a problem perspective: You have two things and want to combine them to get a third thing. Depending on how these things are 'wrapped' you need different concepts:

  Monoid: A + B (|+|)
  Functor: M[A] => (A => B) => M[B]
  Monad: M[A] => (A => M[B]) => M[B]
  Applicative: M[A] => M[A=>B] => M[B]
  Kleisli: (A => M[B]) => (B => M[C]) => (A => M[C])

mafribe12• 11 years ago

The Frege page says that Frege features

    Higher rank types

but says nothing about higher-kinded types (HKTs). The two are different. The rank of a type describes the depth at which universal quantifiers appear contravariantly. This is quite different from higher-kinded types, which allow type-level computation. For good monad support one uses HKTs. I wonder if Frege has HKTs and the description on the original page made a mistake?

voxfrege15• 11 years 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.

mafribe12• 11 years ago

Thanks.

Type inference for types of rank > 2 is undecidable, how does this go together with the claim that Frege has type inference? I'm not a Haskell expert, but I think the

    {-# LANGUAGE RankNTypes #-}

extension enables HRTs in Haskell too.

mafribe12• 11 years ago

How is the Frege compiler written? Is it a new compiler, built from scratch, or does it borrow heavily from a Haskell compiler?

voxfrege15• 11 years 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.

mafribe12• 11 years ago

I should have read the InfoQ article more carefully.

If you had a Frege -> Haskell translator, which shouldn't be hard to do, except in edge cases, you could use GHC as a testing oracle for the Frege compiler.

Frege: A Haskell-Like Language for the JVM

Related Stories