[Rd] vapply definition question
Martin Morgan
mtmorgan at fredhutch.org
Wed Dec 17 06:54:15 CET 2014
On 12/16/2014 08:20 PM, Mick Jordan wrote:
> vapply <- function(X, FUN, FUN.VALUE, ..., USE.NAMES = TRUE)
> {
> FUN <- match.fun(FUN)
> if(!is.vector(X) || is.object(X)) X <- as.list(X)
> .Internal(vapply(X, FUN, FUN.VALUE, USE.NAMES))
> }
>
> This is an implementor question. Basically, what happened to the '...' args in
> the call to the .Internal? cf lapply:, where the ... is passed.
>
> lapply <- function (X, FUN, ...)
> {
> FUN <- match.fun(FUN)
> ## internal code handles all vector types, including expressions
> ## However, it would be OK to have attributes which is.vector
> ## disallows.
> if(!is.vector(X) || is.object(X)) X <- as.list(X)
> ##TODO
> ## Note ... is not passed down. Rather the internal code
> ## evaluates FUN(X[i], ...) in the frame of this function
> .Internal(lapply(X, FUN, ...))
> }
>
> Now both of these functions work when extra arguments are passed, so evidently
> the implementation can function whether the .Internal "call" contains the ... or
> not. I found other cases, notably in S3 generic methods where the ... is not
> passed down.
Hi Mick --
You can see that the source code doesn't contain '...' in the final line
~/src/R-devel/src/library/base/R$ svn annotate lapply.R | grep Internal\(l
38631 ripley .Internal(lapply(X, FUN))
and that it's been there for a long time (I'd guess 'forever')
~/src/R-devel/src/library/base/R$ svn log -r38631
------------------------------------------------------------------------
r38631 | ripley | 2006-07-17 14:30:55 -0700 (Mon, 17 Jul 2006) | 2 lines
another attempt at a faster lapply
------------------------------------------------------------------------
so I guess you're looking at a modified version of the function... The
implementation detail is in the comment -- FUN(X[i], ...) is evaluated in the
frame of lapply.
Martin Morgan
>
> So, essentially, my question is whether the vapply code "should" be changed or
> whether a .Internal implementation should always assume an implicit ...
> regardless of the code, if the semantics requires it.
>
> Thanks
> Mick
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
More information about the R-devel
mailing list