[Rd] eapply weirdness/bug

[Peter Dalgaard]

Luke Tierney <luke at 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, ...)
      }



-- 
   O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)             FAX: (+45) 35327907