Luke Tierney <[EMAIL PROTECTED]> 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 ~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 ______________________________________________ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
