31

In the body of some R functions, for example lm I see calls to the match.call function. As its help page says, when used inside a function match.call returns a call where argument names are specified; and this is supposed to be useful for passing a large number of arguments to another functions.

For example, in the lm function we see a call to the function model.frame...

function (formula, data, subset, weights, na.action, method = "qr", 
model = TRUE, x = FALSE, y = FALSE, qr = TRUE, singular.ok = TRUE, 
contrasts = NULL, offset, ...) 
{
  cl <- match.call()
  mf <- match.call(expand.dots = FALSE)
  m <- match(c("formula", "data", "subset", "weights", "na.action", 
      "offset"), names(mf), 0L)
  mf <- mf[c(1L, m)]

  mf$drop.unused.levels <- TRUE
  mf[[1L]] <- quote(stats::model.frame)
  mf <- eval(mf, parent.frame())
  ...

...Why is this more useful than making a straight call to model.frame specifying the argument names as I do next?

function (formula, data, subset, weights, na.action, method = "qr", 
model = TRUE, x = FALSE, y = FALSE, qr = TRUE, singular.ok = TRUE, 
contrasts = NULL, offset, ...) 
{
  mf <- model.frame(formula = formula, data = data,
                    subset = subset, weights = weights, subset = subset)
  ...

(Note that match.call has another use that I do not discuss, store the call in the resulting object.)

smci
  • 32,567
  • 20
  • 113
  • 146
Usobi
  • 1,816
  • 4
  • 18
  • 25
  • 8
    For one, you don't have write all that out. You can do things like pass all the arguments at once, something like `f <- function(x, y, z) do.call("sum", as.list(match.call()[-1])) ; f(1, 2, 3) ## [1] 6`. Obviously this would be much more useful for a long list of named arguments – Rich Scriven Sep 09 '15 at 18:31
  • Fair enough, I guess you can also do reverse argument slicing. `f <- function(x, y, z){l <- as.list(match.call())[-1];do.call(sum, l[setdiff(names(l), 'z')])}`. Anyway, I guess I was confused about the use in `lm`. However I find that everything is solvable with the `...` argument quite easily. I guess I am getting picky. – Usobi Sep 09 '15 at 20:57
  • 3
    @Usobi: Is `match.call()` is more robust in the following sense? If you use `...` then you don't know what arguments get passed in, and you may end up with things being passed through that you didn't want or that break things in unexpected ways. On the other hand, if you explicitly repeat argument names to pass them along, then this will make code harder to refactor if you change function argument definitions. – peterthinking Nov 12 '16 at 20:32
  • @RichScriven but beware! `f <- function(x, y, z) {a <- 2; do.call("sum", as.list(match.call()[-1]))}; a <- 1; f(a, 2, 3)` outputs `7`. – bers Jul 22 '20 at 08:41

2 Answers2

18

One reason that is relevant here is that match.call captures the language of the call without evaluating it, and in this case it allows lm to treat some of the "missing" variables as "optional". Consider:

lm(x ~ y, data.frame(x=1:10, y=runif(10)))

Vs:

lm2 <- function (
  formula, data, subset, weights, na.action, method = "qr", 
  model = TRUE, x = FALSE, y = FALSE, qr = TRUE, singular.ok = TRUE, 
  contrasts = NULL, offset, ...
) {
  mf <- model.frame(
    formula = formula, data = data, subset = subset, weights = weights
  ) 
}
lm2(x ~ y, data.frame(x=1:10, y=runif(10)))
## Error in model.frame.default(formula = formula, data = data, subset = subset,  :
##   invalid type (closure) for variable '(weights)'

In lm2, since weights is "missing" but you still use it in weights=weights, R tries to use the stats::weights function which is clearly not what was intended. You could get around this by testing for missingness before you call model.frame, but at that point the match.call starts looking pretty good. Look at what happens if we debug the call:

debug(lm2)
lm2(x ~ y, data.frame(x=1:10, y=runif(10)))
## debugging in: lm2(x ~ y, data.frame(x = 1:10, y = runif(10)))
## debug at #5: {
##     mf <- model.frame(formula = formula, data = data, subset = subset,
##         weights = weights)
## }
Browse[2]> match.call()
## lm2(formula = x ~ y, data = data.frame(x = 1:10, y = runif(10)))

match.call doesn't involve the missing arguments at all.

You could argue that the optional arguments should have been made explicitly optional via default values, but that's not what happened here.

BrodieG
  • 51,669
  • 9
  • 93
  • 146
-1

Here's an example. In it, calc_1 is a function with loads of numerical arguments that wants to add and multiply them. It delegates this work to calc_2 , which is a subsidiary function that takes most of these arguments. But calc_2 also takes some extra arguments (q to t) which calc_1 can't supply from its own actual parameters. Instead, it passes them as extras.

The call to calc_2 would be truly horrendous if written so as to show everything calc_1 passes it. So instead, we assume that if calc_1 and calc_2 share a formal parameter, they give it the same name. This makes it possible to write a caller that works out which arguments calc_1 can pass to calc_2 , constructs a call that will do so, and feeds in the extra values to complete it. The comments in the code below should make this clear.

Incidentally, library "tidyverse" is only needed for %>% and str_c which I defined calc_2 with, and library "assertthat" for one assertion. (Though in a realistic program, I'd put in assertions to check the arguments.)

Here's the output:

> calc_1( a=1, b=11, c=2, d=22, e=3, f=33, g=4, h=44, i=5, j=55, k=6
+       , l=66, m=7, n=77, o=8, p=88 
+       )
[1] "87654321QRST"

And here's the code:

library( tidyverse )
library( rlang )
library( assertthat )


`%(%` <- call_with_extras
#
# This is the operator for calling
# a function with arguments passed
# from its parent, supplemented 
# with extras. See call_with_extras()
# below.


# A function with a very long
# argument list. It wants to call
# a related function which takes
# most of these arguments and
# so has a long argument list too.
# The second function takes some
# extra arguments.
#
calc_1 <- function( a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p )
{
  calc_2 %(% list( t = "T", q = "Q", s = "S", r = "R" )
  #
  # Call it with those extras, passing 
  # all the others that calc_2() needs
  # as well. %(% is my function for
  # doing so: see below.
}


# The function that we call above. It
# uses its own arguments q to t , as
# well as those from calc_1() .
#
calc_2 <- function( a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t )
{
  ( a + c * 10 + e * 100 + g * 1000 + i * 10000 + k * 100000 +
  m * 1000000 + o * 10000000 ) %>%
  str_c( q, r, s, t )
} 


# Calls function f2 . Passes f2 whichever
# arguments it needs from its caller. 
# Corresponding formals should have the
# same name in both. Also passes f2 extra
# arguments from the named list extra. 
# The names should have the same names as
# corresponding formals of f2 .
#
call_with_extras <- function( f2, extras )
{   
  f1_call <- match.call( sys.function(1), sys.call(1) )  
  # A call object.

  f1_actuals <- as.list( f1_call %>% tail(-1) ) 
  # Named list of f1's actuals.

  f1_formals <- names( f1_actuals )
  # Names of f1's formals.

  f2_formals <- names( formals( f2 ) )
  # Names of f2's formals.

  f2_formals_from_f1 <- intersect( f2_formals, f1_formals )
  # Names of f2's formals which f1 can supply.

  f2_formals_not_from_f1 <- setdiff( f2_formals, f1_formals )
  # Names of f2's formals which f1 can't supply.

  extra_formals <- names( extras ) 
  # Names of f2's formals supplied as extras.

  assert_that( setequal( extra_formals, f2_formals_not_from_f1 ) )
  # The last two should be equal.

  f2_actuals_from_f1 <- f1_actuals[ f2_formals_from_f1 ]
  # List of actuals which f1 can supply to f2.

  f2_actuals <- append( f2_actuals_from_f1, extras )
  # All f2's actuals.

  f2_call <- call2( f2, !!! f2_actuals )
  # Call to f2.

  eval( f2_call )
  # Run it.
}


# Test it.
#
calc_1( a=1, b=11, c=2, d=22, e=3, f=33, g=4, h=44, i=5, j=55, k=6
      , l=66, m=7, n=77, o=8, p=88 
      )
Phil van Kleur
  • 266
  • 2
  • 10