eapply weirdness/bug

Luke Tierney <luke@stat.uiowa.edu> 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, ...)
     }