eapply weirdness/bug

<Mark.Bravington@csiro.au> writes:

The following looks like an 'eapply' bug to me:

t/subtest> e <- new.env()
t/subtest> e$tempo <- quote( 1+'hi')

t/subtest> lapply( ls( e), function( x) length( get( x,e)))
[[1]]
[1] 3
# seems reasonable-- e$tempo is a 'call' object of length 3

t/subtest> eapply( e, length)
Error in 1 + "hi" : non-numeric argument to binary operator

t/subtest> eapply( e, length)
t/subtest> traceback()
1: eapply(e, length)

For some reason 'eapply' seems to *evaluate* objects of mode 'call' (it
happened with every call-mode object I tried). This shouldn't happen--
or should it?

It's probably related to the fact that

eval(substitute(length(x),list(x=e$tempo)))

Error in 1 + "hi" : non-numeric argument to binary operator

I.e., you cannot construct calls with a mode call argument by
substituting the value of the mode call object. (Got that? Point is
that the substitute returns quote(length(1+"hi")))

It is not clear to me that there is a nice way of fixing this. You
probably need to construct calls of the form FUN(env$var) -- I suspect
that with(env, FUN(var)) or eval(FUN(var), env) would looking for
trouble. Hmm, then again, maybe it could work if FUN gets inserted as
an anonymous function...

Looks broken to me:

     > e<-new.env()
     > assign("x",quote(y),e)
     > eapply(e, function(x) x)
     Error in FUN(y, ...) : Object "y" not found

in contrast to

     > lapply(list(quote(y)),function(x) x)
     [[1]]
     y

looks like eapply has an extra eval in the code.  It does because the
code creates a call of the form

     FUN(<value>)

with the literal value in place and then calls eval on this, which
results in calling eval on value.  The internal lapply in contrast
creates a call of the form

     FUN(<list>[[<index>]])

and evals that.  This causes the literal <list> and <index> values to
be evaluated, which is OK since they are guaranteed to be a list
(generic vector) and integer vector and so evaluate to themselves, and
the call to [ is then evaluated, returning what is in the list at the
appropriate index and passing that, without further evluation, to FUN.
The semantics we want in eapply is I think equivalent to creating

     FUN(get(<name>, <envir>))

and evaluating that, but we are not getting this.  Direct use of this
would be less efficient that the current approach, but using

     FUN(quote(<value>))

as the constructed call should do the trick.

[There seem to be a few other unnecessary eval's in cmputing the arguments
but I haven't thought this through yet]

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