On Sun, 1 Mar 2015, Radford Neal wrote:
There are other instances, such as Reduce where there is a bug
report pending that amounts to the same issue. Performing surgery on
expressions and calling eval is not good practice at the R level and
probably not a good idea at the C level either. It is worth thinking
this through carefully before a adopting a solution, which is what we
will be doing.
Surgery on expressions is what lapply does at the moment. My change
makes it no longer do that.
There is a general problem that lazy evaluation can have the effect
of making the internal details of how an R function like "apply" is
implemented leak into its semantics. That's what's going on with
the Reduce bug (16093) too.
I think one can avoid this by defining the following function for
calling a function with evaluation of arguments forced (ie, lazy
evaluation disabled):
call_forced <- function (f, ...) { list (...); f (...) }
(Of course, for speed one could make this a primitive function, which
wouldn't actually build a list.)
Then the critical code in Reduce could be changed from
for (i in rev(ind)) init <- f(x[[i]], init)
to
for (i in rev(ind)) init <- call_forced (f, x[[i]], init)
This is the option I was suggesting as a possibility in my reply to
Bill Dunlap -- I called it funcall. This may be the right way to
go. There are some subtleties to sort out, such as how missing
arguments should be handled (allowed or error), and whether the force
should stop at ... arguments as in turning
FUN(X[[i]], ...)
into
funcall(FUN, X[[i]], ...)
There is also a change in when the evaluation of X[[i]] happens, which
may or may not matter. Some testing against CRAN/BIOC packages should
reveal how much of an issue these are.
If one had a primitive (ie, fast) call_forced, a similar technique
might be better than the one I presented for fixing "apply" (cleaner,
and perhaps slightly faster). I don't see how it helps for functions
like lapply that are written in C, however (where help isn't needed,
since there's nothing wrong with the mod in my previous message).
If we adapt the funcall approach then it would be best if the C
implementation stayed as close as possible to an R reference
implementation. I do not think your proposed approach would do that.
mapply has its own issues with the MoreArgs argument that would be
nice to sort out at the same time if possible, as there are also a few
more instances of this in several places.
I will try to look into this more in the next week or so.
Best,
luke
Radford Neal
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
