From: MikkelFJ Date: 2003-08-21T18:33:14+09:00 Subject: Re: Rite/Ruby2.0 & Ruby vs OCaml wrote in message news:200308210345.49888.nospam4.me@ottomate.biz... > Thank you all so much for your informative comments. I saved a > few of them and read and re-read them in order so absorb all the > good info. > > I especially liked Mikkel's 'article' at: > http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/45787 > Very informative! thanks > It has been said that OCaml integrates well with C, and the same > has been said for Ruby. How about, does Ruby integrate well > with OCaml or vice versy? You cannot avoid C when intergrating languages unless you go to a wireprotocol such as XML-RPC (supported by OCaml and Ruby) or you use a component technology like COM (not sufficiently supported in both Ruby or OCaml). If you just want to have the occasional data exchange XML-RPC may be a fine choice. I think Ruby has good SOAP support as well. OCaml has SOAP but I don't think it is mature. You can however build SOAP around OCaml using the C/C++ library gSOAP and map the SOAP interface to OCaml functions - but this is only interesting if you generally want to use SOAP. I know a wireprotocol isn't the fastest solution but it is interesting because it gives distributed internet operation and language independence. In particular OCaml is very good at parsing so you can make a small command language and do many operations at once for each cross language call. You can also integrate Ruby and OCaml more closely via a C-core. I haven't tried this but I'm confident that it is possible. The only major obstacle is interference between OCamls garbage collection and Ruby's garbage collector. Therefore it is best to avoid having long lived data references from both languages - at least unless you manage the lifetime manually. Threading may also be an issue but it doesn't have to be. In order to intergrate to languages you load both languages from a common C-Core. Normally Ruby would be in charge and load C-extensions (for example a TCP-IP library), but you can also embed Ruby in a C application. This C application can be linked statically with OCaml modules, or it can load dynamic link libraries containing OCaml. You could also write a Ruby extension in mixed C and OCaml and have Ruby run the show. This would be a good for plugging in a parser written in OCaml. I guess this would be the easiest option. There is a number of possibilities and it would be a lengthy discussion - but it isn't all that difficult. I have written a bit of Glue code that makes it possible to expose OCaml as a DLL and so have others. In conclusion it is always messy to integrate components but if you have a project that is large enough to justify it, it is definitely possible. Before anything else I look at how I can integrate a language into a larger project. If a language can only be used when it is in full control of the program, you can't really use it for serious development. I believe both Ruby and Ocaml are well suited for integration. > And finally, I will rephrase one of my original questions. Does > anyone know if the development plans for Ruby 2.0 still include > a VM implementation? I don't think much is known except Matz presented some visions including a VM on a slideshow and that he has been busy on 1.8 - perhaps now that 1.8 is out this will make a VM more of a reality. I'm pretty sure Ruby will eventually get a VM. Even if it is not Rite, there is also the Parrot project (the future Perl VM engine). > If and when that does come about, will > Ruby still be an interperter but with byte-code compilation > abilities? Ruby can't function without an intepreter, bytecode or not, because of the eval statement. But If you think of an interactive interpreter like IRB, this is a separate question. I can't answer this but I also can't imagine Ruby without IRB. Mikkel