[Haskell-cafe] Haskell & Java/Scala interoperbility?

John A. De Goes john at degoes.net
Wed Jul 15 14:55:01 UTC 2015

This is a herculean effort due, among other things, to Spark’s heavy reliance on function serialization. Not to say you can’t do it, but it’s going to be a huge amount of effort to build and maintain it in any way that provides feature parity with any JVM language on Spark, and of course you’re going to be going Haskell -> C -> JVM, and JVM -> C -> Haskell for everything, which entails its own set of delightful pains.

If you’re not too picky about the ML, I’d suggest a better path is contributing to PureScript on the JVM (either that project or another one). PureScript’s semantics map cleanly to the JVM’s and very good native interop is possible; in addition, the PureScript compiler is designed for compiling to different backends (i.e. it has no runtime and will necessarily utilize the target’s native runtime environment).

One could ease Spark integration by targeting TASTY or generating functional code compatible with Scala / Java 8 runtimes.

John A. De Goes
Follow me @jdegoes

On July 14, 2015 at 9:13:05 PM, Vasili I. Galchin (vigalchin at gmail.com) wrote:

I am looking to suppprt Haskell (OCaml ??) for apache.spark.org. Currently there is support for programming language "R" which has functional features (not as rich as Haskell, OCaml, et. al.) and does lazy evaluation. I am going to drop back and look at the R->Scala/Java implementation BUT I will also read your link.  Any more.suggestions are gratefully welcome.

Kind thx,


On Tuesday, July 14, 2015, Jason Dagit <dagitj at gmail.com> wrote:
Did you look at java bridge?
  * https://hackage.haskell.org/package/java-bridge

Perhaps counter-intuitively, you're probably better off defining a protocol and using that for interop. Something like zeromq could simplify the communication.

The main hassle with a full interop is the difference between the notions of types in the two languages. For instance, subtyping on the Java side doesn't really map well to the Haskell side.

I would say that it forces attempts at a general interop to go with a least common denominator approach. In the extreme, this degenerates back to having the code on each side pretend like it's talking to C.

Whereas designing a message protocol for your task allows you to incorporate domain specific knowledge and thus avoid a general solution and also leave out things you will never use.

On Tue, Jul 14, 2015 at 7:14 PM, Vasili I. Galchin <vigalchin at gmail.com> wrote:

      I have been looking at Hackage for a package/library that
supports Haskell interoperability with Java/Scala. Didn't see any such
support. If true, is there any project in the works?


Haskell-Cafe mailing list
Haskell-Cafe at haskell.org

Haskell-Cafe mailing list  
Haskell-Cafe at haskell.org  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150715/67ac9532/attachment.html>

More information about the Haskell-Cafe mailing list