Re: [babel][PATCHES] ob-R patches for review

[Rainer M Krug <Rainer@krugs.de>]

[-- Attachment #1: Type: text/plain, Size: 3727 bytes --]

Charles Berry <ccberry@ucsd.edu> writes:

> Rainer M Krug <Rainer <at> krugs.de> writes:
>
>> 
>> Hi
>> 
>> Attached please find seven patches for review to implement the storing
>> of org variables in their own environment and to make the org-issued R
>> code look nicer in the R session.
>
>
> Rainer,
>
>
> I have suggestions and a concern.
>
> I suggest that you look at how ESS handles R objects and constructs
> calls in elisp to be executed in an R session.
>
> It uses a package and its NAMESPACE to provide that functionality and
> store objects. That makes the elisp interface a lot cleaner and keeps
> ESS variables out of the users way. The package is found at <ESS>/etc/ESSR/.

That is effectively what I am doing as well, only that I am not using a
package but an environment and add it to the search path. 

By doing this, the org variables are stored in this environment and do
not overwrite existing R objects by the same name. If objects by the
same name as the org variables are existing in the global R environment,
they are still found first, but variables transferred from org can
*always* be accessed by using

,----
| .org_variables_$VARIABLE_NAME
`----

in R. As said, existing VARIABLE_NAME objects in R are *not* impacted
on.

If you use only

,----
| VARIABLE_NAME
`----

in R it returns the first object in the R search path.

So the only variable which can be overwritten when this patch is used is

,----
| .org_variables_
`----

which, I think, is quite unlikely to exist.

Concerning package: I like the idea and thought about it with the aim of
putting all R code into a package, to make it easier to maintain the
code and to customize it. The org variables can then be injected in
this package. But the problem of name clashes between user defined
variables and the name of the namespace / environment of the package is
the same - possible higher, as a package name (and therefore the
namespace and environment) should have meaningful names.

>
> I also suggest that you introduce a customization variable to
> allow a user to turn off the functionality you have created.

I don't think this is necessary as the behavior for the user does not
change at all, only that it becomes safer to use org variables in R (see
above).

>
> My concern is that you are injecting code into the R user session or
> script that the user may not want. If I already have an R object named
> 'org' your code will break my code.

Please see my later patch, which renames this to ".org_variables_" which
sounds like an unlikely name to exist.

>
> Further, all of this is hard coded, so I can't change the
> variable/file names.

OK - this can be added as a variable, and in regards to the file name
this makes sense. For the moment I would leave it as it is and discuss
what would be the useful approach, as there are some problems with the
usefulness of saving the variables - imagining different variables
passed to different code blocks. One option would be to have a variable,
whose default is NIL, which contains the file name:

- NIL :: no saving
- string :: saving under the name given



>
> HTH,

Yes definitely - discussions more then welcome,

Rainer

>
> Chuck
>
>
>
>
>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]