shimweasel

I'm currently contemplating a ruby-haskell bridge*, partly for the challenge, and partly because I think they go pretty well together**. Ruby has a shirtload of convenient frameworks and no shortage of people who like hacking in it, but it is, to be fair, horrifically slow at anything resembling computation. This is not much of a problem for your standard CRUDdy database-bound app, but doing anything like predictive in it would likely end in either tears or the heat-death of the universe. Haskell web frameworks, OTOH, are currently functional (if you'll pardon an awful, awful pun) but bare of all kinds of pleasantnesses that the ruby frameworks bring. In that spirit, then, why not let a thousand flowers bloom? Ruby for UI, Haskell for heavy lifting. ***

This reasoning sharply limits the requirements. We don't need full two-way communication: if Ruby's acting as front-end glue, it would be more than enough to let Ruby call Haskell. We don't need full mapping of data structures: functional analogues of object-oriented structures are a big, meaty, and in this case entirely unnecessary act of gold-plating. Hashes, arrays and primitive types a la JSON are plenty. Finally, we don't need re-entrancy, because once you're in Haskell-land, there's no (sanctioned) way to get back to ruby except by returning a value.

So, having limited our scope to something hopefully more than a toy but less than a thesis, how do we implement it? Two options spring immediately to mind:

1. take our embedded haskell code, compile it down to a dynamic library, and link it in with the ruby interpreter the same way you'd embed a C lib. This is currently slightly awkward, because GHC likes to do the linking itself, in order to sprinkle in a page's worth of object files, but should not prove impossible.
2. decorate the given code with a communication process like SOAP or JSON over pipes, and run it in a separate process. This is not really significantly different to running a persistent Haskell process that just accepts requests over an HTTP interface, except that the ruby process would be in control of keeping the Haskell process alive.

The second method is probably easier, but it's pretty clunky, and involves a bit more machinery behind the scenes. Ideally, I'd like something as smooth as Inline::C in Perl.

Have I missed something obvious? Flames, comments, experience reports, suggestions all welcome.

• * there's raskell, but it appears to be vapourware, apart from a warning about generating position independent code with GHC on platforms other than Mac OS X.
• ** and, fine, because I'm waiting for a call from the recruiter and I'm not very patient.
• *** snarky comments about speed of functional languages will be redirected to the computer language shootout. Even sans don's preternatural gift for optimisation, modern functional languages are fast.