strategy to avoid multiple RFortran-based procedures from interfering with each others global R variables

[GoogleCodeExporter]

Hi Mark,

I am using RFortran increasingly for various things, and what is becoming clear 
is that some good general strategy is needed to handle cases where multiple 
routines using RFortran may be creating variables with the same name.

When the whole code is developed by the same person this could be avoided to 
some extent (though not very naturally). However, whenever RFortran is used to 
create various plugins into a general framework such as BATEA, and these 
plugins (models, etc) are contributed by multiple people, namespace clashes 
become almost impossible to avoid.

This may completely break to program, if procedure A inadvertently uses the 
same R variable name as procedure B, and can change its value, etc.

This is not an easy question, and is not just an RFortran issue, but I think 
should be thought about, and some good strategies (and maybe code) developed 
and recommended.

The problem is that at the moment when calling R functions via RFortran we have 
to create a global R variable, which could clash with many others. I had a look 
and Rcall doesnt really mitigate this (it just shortens the code).

For example, a possible convention would be to append "_xxx" to variable names 
defined within procedure "xxx", and always require procedures to remove their 
global variables created just as arguments for R. I am not sure if this covers 
all situations, but worth having a careful think about.

cheers,
d

Original issue reported on code.google.com by dmitri.k...@gmail.com on 13 Jun 2011 at 9:53

[GoogleCodeExporter]

Yes, I can see this is going to be a problem in the longer term. 

As an interim solution, I would recommend using status="new" in the Rput 
command, or set the RFortran global variable, statusDef = "new"   

This checks if an Rput command is going to overwrite an existing R variable and 
returns an error. At least then an error is returned if a variable is going to 
be overwritten.

In the longer term R has a feature called an "environment", where an R variable 
can be defined in a an environment and does not interact with other variables 
in a different environment. The R scoping rules are hard to follow however - 
see http://cran.r-project.org/doc/contrib/Fox-Companion/appendix-scope.pdf  

An Rcall command could first setup its own environment, perform its 
calculations return the values and somehow close the environment. 

Something to look at in longer term  

Original comment by mark.th...@gmail.com on 13 Jun 2011 at 11:55

• Changed state: Accepted