Creating GUI desktop applications that call into either OCaml or Haskell -- Is it a fool's errand?

In both Haskell and OCaml, it's possible to call into the language from C programs. How feasible would it be to create Native applications for either Windows, Mac, or Linux which made extensive use of this technique?

(I know that there are GUI libraries like wxHaskell, but suppose one wanted to just have a portion of your application logic in th开发者_开发知识库e foreign language.)

Or is this a terrible idea?

Well, the main risk is that while facilities exist, they're not well tested -- not a lot of apps do this. You shouldn't have much trouble calling Haskell from C, looks pretty easy:

http://www.haskell.org/haskellwiki/Calling_Haskell_from_C

I'd say if there is some compelling reason to use C for the front end (e.g. you have a legacy app) and you really need a Haskell library, or want to use Haskell for some other reason, then, yes, go for it. The main risk is just that not a lot of people do this, so less documentation and examples than for calling the other way.

You can embed OCaml in C as well (see the manual), although this is not as commonly done as extending OCaml with C.

I believe that the best approach, even if both GUI and logic are written in the same language, is to run two processes which communicates via a human-readable, text-based protocol (a DSL of some sort). This architecture applies to your case as well.

Advantages are obvious: GUI is detachable and replaceable, automated tests are easier, logging and debugging are much easier.

I make extensive use of this by compiling haskell shared libs that are called outside Haskell.

usually the tasks involved would be to

1. create the proper foreign export declarations
2. create Storable instances for any datatypes you need to marshal
3. create the C structures (or structures in the language you're using) to read this information
4. since I don't want to manually initialize the haskell RTS, i add initiallisation/termination code to the lib itself. (dllmain in windows __attribute__ ((constructor)) on unix)
5. since I no longer need any of them, I create a .def file to hide all the closure and rts functions from being in the export table (windows)
6. use GHC to compile everything together

These tasks are rather robotic and structured, to a point you could write something to automate them. Infact what I use myself to do this is a tool I created which does dependency tracing on functions you marked to be exported, and it'll wrap them up and compile the shared lib for you along with giving you the declarations in C/C++.

(unfortunately, this tool is not yet on hackage, because there is something I still need to fix and test alot more before I'm comfortable doing so)

Tool is available here http://hackage.haskell.org/package/Hs2lib-0.4.8

Or is this a terrible idea?

It's not a terrible idea at all. But as Don Stewart notes, it's probably a less-trodden path. You could certainly launch your program as Haskell or OCaml, then have it do a foreign-function call right out of the starting gate—and I recommend you structure your code that way—but it doesn't change the fact that many more people call from Haskell into C than from C into Haskell. Likewise for OCaml.