[R] Summary: do.call and environments

[Gabor Grothendieck]

To use the modify the solution from Tony and I 
so that you can pass the name of the function, rather
than the function itself, like this:

x <- 7
fx <- function(y) print(x*y)
f <- function(fun, x) {
	 fun <- get(fun)
         environment(fun) <- environment()
         do.call("fun",list(3))
}
f("fx",2)


---
Date:   Thu, 11 Mar 2004 08:22:45 +0100 
From:   Thomas Petzoldt <petzoldt at rcs.urz.tu-dresden.de>
Cc:   <petzoldt at rcs.urz.tu-dresden.de>, <r-help at stat.math.ethz.ch> 
Subject:   [R] Summary: do.call and environments 

 
Dear R users,

thank you very much for your suggestions. I've learned much, especially
that the problem was not as simple as I thought. There have been several
proposals, but most of them solved the problem only partly.

The proposal(s) of Gabor and Tony (different versions) seemed to be very 
promising:

> fx <- function(y) print(x*y)
> f <- function(fun, x) {
> environment(fun) <- environment()
> fun(3)
> }
> f(fx,2)

... but unfortunately they miss the "do.call" mechanism. I intended to 
call a function given as character with f("fx", value), and not f(fx, 
value).

Another proposal (from Robert Gentleman, thank you) works. It has the 
only disadvantage, that I have to set an environment outside of my own
function. If I understand this correctly, this means that the new
environment ist set persistently (*globally*) and may have side-effects 
to other calls:

> fx <- function(y) print(x*y)
> environment(fx) <- new.env()
>
> ff <- function(fun, x) {
> assign("x", x, environment(get(fun, mode="function")))
> do.call(fun, list(y=3))
> }

Furthermore, Andy pointed out that my idea was a bad one, but why I am 
trying such weired things? My problem is, that I want to define list 
objects which contain informations, about how they are processed (as 
character, not as copy of a function). This solver function (e.g. 
"lsoda" from the odesolve package) then calls a third function (my model 
equations), provided from my side again, but unfortunately does not 
"pass through" some additonal argument(s), needed by the model 
equations. So I wanted to call lsoda or my own function provided with 
the additional arguments within an own environment.

Now, as it comes out, that this was really a bad idea, I should focus on 
the pass-trough method (...) and use one of the 99% workarounds 
mentioned above in the meantime.

Thank you again

Thomas P.