On Sat, 20 Feb 2005, Peter Dalgaard wrote:
Luke Tierney <[EMAIL PROTECTED]> writes:
For this specific case though, I _think_ the semantics we want is this:
eapply1 <- function(env, FUN, ..., all.names = FALSE) { FUN <- match.fun(FUN) lapply(.Internal(env2list(env, all.names)), FUN, ...) }
Not passing the ... in the current implementation is, I think, an oversight, as is the extra evaluation that occurs. Given that lapply is already internal I'm not sure there really is very much benefit in having the internal eapply. If not I'd prefer to replace it by something like this; if there are reasons for keeping the .Internal we can work on replicating these semantics as closely as possible. I think Robert is the one who would know the issues.
I agree on the semantics (I didn't quite think of the consequences of FUN doing an eval.parent and things like that before). But if implemented literally, wouldn't that env2list cause some undesirable copying? I have the impression that people interested in eapply use their environments to hold some pretty large objects. So maybe we should stick with the get()-based version
eapply2 <- function(env, FUN, ..., all.names = FALSE) { FUN <- match.fun(FUN) nm <- ls(envir=env,all.names=all.names) FUN2 <- function(name,...)FUN(get(name),...) lapply(nm, FUN2, ...) }
The copying issue is a good point--Robert also reminded me of this. I _think_ the approach based on env2list would be OK but I'd have to check very caerfully to be sure. Rather than spend time doing that I think this argues for keeping the .Internal varsion and modifying it to obtain the semantics we want. I'll look into that.
luke
-- Luke Tierney University of Iowa Phone: 319-335-3386 Department of Statistics and Fax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
______________________________________________ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
