A "safe" do.call

Has anyone developed a version of do.call that is safe in the sense
that it silently drops parameters that do not appear in the formals of
the called function? This is useful when ... ends up being used in
multiple further functions.  e.g.

f <- function(a, b) {a + b}
do.call(f, list(a=1, b=2, c=3))  # Errors
safe.call(f, list(a=1, b=2, c=3)) # Returns 3

If have quickly thrown together the following, but it doesn't support
position based calls, and I'd like to avoid reinventing the wheel.

safe.call <- function(f, params, f.params = names(formals(f))) {
  if ("..." %in% f.params) {
    safe.params <- params
  } else {
    safe.params <- params[intersect(f.params, names(params))]
  }
  do.call(f, safe.params)
}

I hope to use safe.call to prevent a wide class of potential bugs in ggplot2.

Hadley

--
http://had.co.nz/

Maybe this function won't actually be the help I had hoped it would
be.  Unfortunately some functions (e.g. glm via glm.control) throw
errors when ... contain arguments that don't match some (eventual)
argument list.

Or is this a bug in glm?  It certainly seems that the documentation
should mention that ... is passed to glm.control, which only takes
three arguments.  I realise that this doesn't come up very often
during an interactive model fitting session, and it is easy to remedy
when it does, but it makes writing robust functions hard when a
function with ... does in fact have a fixed argument list.

Hadley

On Jan 28, 2008 8:19 PM, hadley wickham <h.wickham at gmail.com> wrote:

Has anyone developed a version of do.call that is safe in the sense
that it silently drops parameters that do not appear in the formals of
the called function? This is useful when ... ends up being used in
multiple further functions.  e.g.

f <- function(a, b) {a + b}
do.call(f, list(a=1, b=2, c=3))  # Errors
safe.call(f, list(a=1, b=2, c=3)) # Returns 3

If have quickly thrown together the following, but it doesn't support
position based calls, and I'd like to avoid reinventing the wheel.

safe.call <- function(f, params, f.params = names(formals(f))) {
  if ("..." %in% f.params) {
    safe.params <- params
  } else {
    safe.params <- params[intersect(f.params, names(params))]
  }
  do.call(f, safe.params)
}

I hope to use safe.call to prevent a wide class of potential bugs in ggplot2.

Hadley

--
http://had.co.nz/

--
http://had.co.nz/

Has anyone developed a version of do.call that is safe in the sense
that it silently drops parameters that do not appear in the formals of
the called function? This is useful when ... ends up being used in
multiple further functions.  e.g.

f <- function(a, b) {a + b}
do.call(f, list(a=1, b=2, c=3))  # Errors
safe.call(f, list(a=1, b=2, c=3)) # Returns 3

If have quickly thrown together the following, but it doesn't support
position based calls, and I'd like to avoid reinventing the wheel.

safe.call <- function(f, params, f.params = names(formals(f))) {
 if ("..." %in% f.params) {
   safe.params <- params
 } else {
   safe.params <- params[intersect(f.params, names(params))]
 }
 do.call(f, safe.params)
}

I hope to use safe.call to prevent a wide class of potential bugs in ggplot2.

Hadley

--
http://had.co.nz/

Or is this a bug in glm?  It certainly seems that the documentation
should mention that ... is passed to glm.control, which only takes
three arguments.  I realise that this doesn't come up very often
during an interactive model fitting session, and it is easy to remedy
when it does, but it makes writing robust functions hard when a
function with ... does in fact have a fixed argument list.

I think the docmentation has conflated '...' for glm and '...' for
weights.

My recollection is that this was intentional: at least one core developer
used to dislike '...' as it allowed mistyped argument names to be ignored.
And he has a good point, IMO.

"hw" == hadley wickham <h.wickham at gmail.com>
    on Tue, 29 Jan 2008 09:26:24 -0600 writes:

    hw> That seems a perfectly good reason not to use ... - but
    hw> if you are going to use ... it seems like you shouldn't
    hw> warn on mismatched argument names.

I disagree.

One "famous" example on this was -- in S-plus, early 1990s --
known about S users back then, and it happened here (as well),
not in theory: a scientist who later came for consulting to us
did a logistic regression

  mod1 <- glm(y ~ x1 + x2 + ....,  .......
              data = ....., famliy = binomial)
  summary(mod1)
  ...

and was wondering about the logistic regression coefficients and
their interpretation and more things
until we found out the small typo above
which made glm() compute a ("gaussian") model even though the
user had clearly said he wanted a logistic one.

Can you see the point?

    hw> That seems a perfectly good reason not to use ... - but
    hw> if you are going to use ... it seems like you shouldn't
    hw> warn on mismatched argument names.

I disagree.

One "famous" example on this was -- in S-plus, early 1990s --
known about S users back then, and it happened here (as well),
not in theory: a scientist who later came for consulting to us
did a logistic regression

  mod1 <- glm(y ~ x1 + x2 + ....,  .......
              data = ....., famliy = binomial)
  summary(mod1)
  ...

and was wondering about the logistic regression coefficients and
their interpretation and more things
until we found out the small typo above
which made glm() compute a ("gaussian") model even though the
user had clearly said he wanted a logistic one.

Can you see the point?

The point is that glm shouldn't use ... but should explicitly list all
of the arguments that it takes?  Why does glm need to use ... in your
example?

If you know the set of possible arguments in advance, why not list
them explicitly and document them individually, and not use ... at
all?

Hadley

--
http://had.co.nz/