[Rd] eapply weirdness/bug

[Peter Dalgaard]

Luke Tierney <luke at stat.uiowa.edu> writes:

> 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>))

Or, as I was suggesting, 

eval(substitute(F(x), list(F=FUN,x=as.name(e)), 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.

You have to be careful only to do this if the value is of mode "call",
I think. Or is quote always a no-op in the other cases? 

I'm getting a bit fond of the the solution that I had because it will
also work if the FUN uses deparse(substitute(....)) constructions, and
once you're at the level of constructing calls via LCONS() it isn't
really inefficient either. Extra arguments could be a bit of a bother
though. (What happens to those currently?? The function doesn't seem to
pass them to .Internal.)

-- 
   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