On Thursday 16 September 2004 20:27, Andy Moran wrote:
I'd like to say that this approach has worked for us time and time again, but, to date, we've never had to rewrite a slow component in C :-) For us, C interoperability has always been a case of linking to third party software, or for writing test harnesses to test generated C.
The point is that perhaps we will not have a prototype but a single implementation (not that I think it's a good idea in the general case, but we will write a relatively simple bookkeeping application). However I realize that one can write a great part of the software in a single language. The point is providing an escape to java, C++, C#, python or other in vogue languages in case we find that it's difficult to interface with legacy systems, or we don't find a coder to hire in the future. So the point is not to rewrite something in C for efficiency, but rather to be able to say "ok, this component is written in haskell and will stay this way, but the rest of the system won't be haskell anymore". However:
Things are different if your application is multi-process and/or distributed, and you're not going to be using an established protocol (like HTTP, for instance). In that case, you might want to look at HDirect (giving access to CORBA, COM, DCOM), if you need to talk to CORBA/COM/DCOM objects. There are many simple solutions to RPC available too, if that's all you need.
I see that there is for example xmlrpc that should fit my little interoperability needs, and would have liked to hear some experience on that route. Your reply is incouraging, though, since you didn't need any other language at all. That's my hope, too. Bye and waiting for that other famous hakell-using company that I didn't mention to attend this discussion :) Vincenzo