[Rd] eapply weirdness/bug
Luke Tierney
luke at stat.uiowa.edu
Sun Feb 20 17:58:29 CET 2005
On Sat, 20 Feb 2005, Peter Dalgaard wrote:
> 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, ...)
> }
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 at stat.uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
More information about the R-devel
mailing list