eapply weirdness/bug

On Sat, 20 Feb 2005, Peter Dalgaard wrote:

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, ...)
     }

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:      luke@stat.uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu