Skip to content

embedding R?

1 message · Duncan Temple Lang

Original
Duncan Temple Lang
# 
As Luke once put it "This is a long one; you know what key to press if
you aren't interested...."


Apologies for coming into the R within Perl discussion late. (I have
been away from e-mail for several days.) 

The RSPerl package (http:://www.omegahat.org/RSPerl) is designed to be
symmetric in allowing the embedding in either direction. That is
embedding Perl within an R session or running R within a Perl session.
Either can be "in charge". The embedding R within Perl is less well
documented, to say the least.  I plan to release a version of the
package soon with more information about this and also more user-level
support for specifying converter functions. The very same model that
is used in the Java, CORBA, Python, JavaScript, etc. works for Perl
also. The Python package (of which there will be a new release within
the next day or two) might provide a useful place to see the setup
immediately.


The approach of using Expect perl works fine. However, using strings
can be very limiting for certain types of functionality and places a
lot of work on each programmer using it. They have to construct the R
command as a string and then send it to be evaluated.  Parsing R
output is very fragile and difficult to do in a flexible way (what if
the page width changes, etc.). It is hard to come up with general and
reusable ways to handle reading the results back in and hence one is
frequently coding context-specific approaches. Very time consuming.
(If one really wanted to do this, one might use XML to represent the R
values being returned and then read them into Perl. That is general
and extensible. Some of us (Vincent Carey, Robert Gentleman and I
currently) are working on this at present.) And perhaps the biggest
drawback to using strings to effect the inter-system interface is that
one end up programming in both languages and that also means debugging
the code for each but not necessarily in the easiest place. 

Basically, the overall problem is that the syntax of the other
language is being used and that breaks encapsulation. Suppose you are
using Perl from within R to read the contents of URLs. Then, you may
decide that Java or Python is better (say it handles firewalls or
SSL). Then you would have to rewrite your R code to generate
expressions in Omegahat or Python.

The approach we have been using in all the Omegahat inter-system
interface packages (the CORBA, Java, ....) is to allow one to call
functions and create objects and call their methods in the other
language. The functions look as if they are S functions. And so, it
fits naturally with the programming model, encapsulating what is
really happening.

Whatever approach one uses is good if it works for the problem at
hand. The important thing is to try to reduce the number of times one
has to hand-craft solutions. 

 I hope this helps explain what we are doing and how the S-Perl
connection is intended to work. 

  All the best.

   D.