Re: [Rd] eapply weirdness/bug

From: Luke Tierney <>
Date: Mon 21 Feb 2005 - 03:58:29 EST

On Sat, 20 Feb 2005, Peter Dalgaard wrote:

> Luke Tierney <> writes:
>> For this specific case though, I _think_ the semantics we want is this:
>> eapply1 <- function(env, FUN, ..., all.names = FALSE) {
>> 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 <-
> 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 Tierney
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:
Iowa City, IA 52242                 WWW:

______________________________________________ mailing list
Received on Mon Feb 21 03:04:56 2005

This archive was generated by hypermail 2.1.8 : Fri 18 Mar 2005 - 09:02:57 EST