On Mo, 2015-02-23 at 16:54 -0500, Duncan Murdoch wrote:
> This is a feature: it allows you to have arguments that are never
> evaluated, because they are never used, or defaults that depend on
> things that are calculated within the function.
I haven't thought about the thing with the default arg
From: Daniel Kaschek
> ... When I evaluate this list of functions by
> another lapply/sapply, I get an unexpected result: all values coincide.
> However, when I uncomment the print(), it works as expected. Is this a
> bug or a feature?
>
> conditions <- 1:4
> test <- lapply(conditions, function(m
The documentation is not specific enough on the indented semantics in
this situation to consider this a bug. The original R-level
implementation of lapply was
lapply <- function(X, FUN, ...) {
FUN <- match.fun(FUN)
if (!is.list(X))
X <- as.list(X)
rval <- vecto
> On Feb 24, 2015, at 10:50 AM, wrote:
>
> The documentation is not specific enough on the indented semantics in
> this situation to consider this a bug. The original R-level
> implementation of lapply was
>
>lapply <- function(X, FUN, ...) {
>FUN <- match.fun(FUN)
>if (!is.
Dear R-devel
I have a function in a package that essentially provides a wrapper for a
group of functions in another Suggested package (it sets appropriate
defaults for the context, transforms output, etc). I've implemented
this by verifying that the package was loaded with
require(sna)
and
First, a clarification of terminology: a package can be loaded and
attached, or loaded and not attached. It can't be attached and not loaded.
To get the function from a package by name, you could do something like:
getExportedValue("sna", snaFunName)
where snaFunName is a string containing the
do.call(sna::snaFunName, args = args)
?
Hadley
On Tue, Feb 24, 2015 at 1:29 PM, Skye Bender-deMoll
wrote:
> Dear R-devel
>
> I have a function in a package that essentially provides a wrapper for a
> group of functions in another Suggested package (it sets appropriate
> defaults for the context
> On 24 Feb 2015, at 19:53 , Hadley Wickham wrote:
>
> do.call(sna::snaFunName, args = args)
>
> ?
>
I was about to suggest something similar. The key is that the first arg to
do.call is not necessarily a text string; it can be the actual function object.
So something along the lines of
n