[Haskell-cafe] Talking to Java from Haskell?

[Daniel Cook]

> I would probably start by writing a JNI wrapper around QuickFIX to expose it
> to C and C-like languages.  Then I would write a Haskell FFI binding to that
> library.  In this way, C will become your glue language as odd as that may
> sound.

vs.

> Depending on the data I'd use a very simple protocol for the
> communication Haskell <-> Scala.

The JNI thing would probably run very fast.  Given my total ignorance
of JNI and Haskell FFI, it could be challenging to implement, however.

In some ways, this suggestion encourages me even more to use a message
queue: people have already implemented the messaging interface for
both Haskell and Java, so that all I need to do is specify some
messages.

I should make it clear: my objective is to do the minimal amount of
engineering necessary to get the data from FIX messages into my
Haskell program.

> As a longer term solution, having a combinator library for FIX in Haskell
> sounds really nice.  I don't need it personally, but it just seems like the
> way to go.

It does - but I think "sounds really nice [...] it just seems like the
way to go" is exactly what my professors meant by mission creep in all
those software engineering classes.

Doesn't using an existing Scala & Haskell libraries to generate &
parse e.g. lightweight JSON messages also seem elegant?

> Another possibility that tends to work very well is to use Haskell to define
> a domain specific language.

Woah.  Lateral thinking.  In some ways, Jaskell has already done this.


On Fri, Jul 9, 2010 at 2:58 AM, Jason Dagit <dagit at codersbase.com> wrote:
>
>
> On Thu, Jul 8, 2010 at 6:35 PM, Daniel Cook <danielkcook at gmail.com> wrote:
>>
>> Hi,
>>
>> Someone has written a large Java library (QuickFIX/J) which speaks a
>> gnarled, ugly protocol (FIX).  There don't appear to be any FIX
>> protocol libraries in Hackage.  I need my Haskell program to talk to a
>> 3rd-party system that only speaks FIX.
>>
>> Should I:
>>
>> a) Reimplement the protocol directly Haskell?  (This appears to be
>> non-trivial)
>>
>> b) Wrap the Java library with some code to use a lightweight message
>> queue (zeromq) to send messages to my Haskell program?  (This would
>> require essentially re-implementing an abstracted subset of the the
>> protocol into 0MQ messages)
>>
>> c) Find a way for Haskell to interact directly with Java? (the various
>> JNI bridges seem very unmaintained...)
>
> Are you referring to projects like these?
> * lambdaVM: http://www.cs.rit.edu/~bja8464/lambdavm/
> * EclipseFP uses (or used, I'm not sure) a bridge between Java/Haskell.
> I doubt these approaches are very mature for general purpose work.  They
> probably work well for the author's original purpose, but perhaps you'd run
> into low level bugs using them yourself.  I assume they use Java's JNI and
> connect that to Haskell FFI.  I don't know why this would be a necessarily
> hard problem.  Haskell's FFI is very nice for talking to C, but perhaps
> Java's JNI is not as friendly.
> I would probably start by writing a JNI wrapper around QuickFIX to expose it
> to C and C-like languages.  Then I would write a Haskell FFI binding to that
> library.  In this way, C will become your glue language as odd as that may
> sound.
> As a longer term solution, having a combinator library for FIX in Haskell
> sounds really nice.  I don't need it personally, but it just seems like the
> way to go.  The drawback here is that you will have to duplicate a lot of
> effort to keep your implementation in sync with the de facto implementation.
>  On the other hand, depending on the nature of the technical hurdles your
> Haskell implementation may be significantly easier to maintain and could
> possibly end up serving as a concise, correct, reference implementation when
> the FIX specification changes.
> It's also possible that some Haskell compiler, such as YHC, would serve well
> here.  Maybe it's easier to modify that in the way lambdaVM is a
> modification to GHC.  If I recall correctly, YHC had a backend for
> JavaScript at one point.  That makes me think it has a very hackable
> backend.
> Another possibility that tends to work very well is to use Haskell to define
> a domain specific language.  Your DSL could generate Java source that uses
> QuickFIX directly.  You get the strength of using the de facto tool chain
> for your production binaries, the power of Haskell for language design, and
> the expressive power that comes from having a domain specific language.
>  This solution is also cheaper than it might sound.  You start with
> combinators that build up Java expressions and go from there.
> It's hard for me to say which is best without knowing more about the
> programs you'll be writing.
> Sounds like an interesting project!
> Good luck,
> Jason