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@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, Vasili On Tuesday, July 14, 2015, Jason Dagit 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 wrote: Hello,       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? Thanks, Vasili _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe