[Rd] [R] Definition of = vs. <-
Waclaw.Marcin.Kusnierczyk at idi.ntnu.no
Thu Apr 2 10:53:26 CEST 2009
Wacek Kusnierczyk wrote:
> and btw. the following is also weird:
> # 1
> not because '=' works as named argument specifier (so that the result
> would be something like `=`(a, 1)),
i meant to write: not because '=' does not work as an assignment
operator (or otherwise the result would be ...)
> but because quote has no parameter
> named 'a', and i would expect an error to be raised:
> # hypothetical
> # error: unused argument(s): (a = 1)
> as in, say
> vector(mode='list', i=1)
> # error: unused argument(s): (i = 1)
> it appears that, in fact, quite many r functions will gladly match a
> *named* argument with a *differently named* parameter. it is weird to
> the degree that it is *wrong* wrt. the 'r language definition', sec.
> 4.3.2 'argument matching', which says:
> "The first thing that occurs in a function evaluation is the matching of
> formal to the actual or
> supplied arguments. This is done by a three-pass process:
> 1. Exact matching on tags. For each named supplied argument the list of
> formal arguments is
> searched for an item whose name matches exactly. It is an error to
> have the same formal
> argument match several actuals or vice versa.
> 2. Partial matching on tags. Each remaining named supplied argument is
> compared to the
> remaining formal arguments using partial matching. If the name of
> the supplied argument
> matches exactly with the first part of a formal argument then the
> two arguments are con-
> sidered to be matched. It is an error to have multiple partial
> matches. Notice that if f
> <- function(fumble, fooey) fbody, then f(f = 1, fo = 2) is illegal,
> even though the 2nd
> actual argument only matches fooey. f(f = 1, fooey = 2) is legal
> though since the second
> argument matches exactly and is removed from consideration for
> partial matching. If the
> formal arguments contain â€˜...â€™ then partial matching is only
> applied to arguments that
> precede it.
> 3. Positional matching. Any unmatched formal arguments are bound to
> unnamed supplied
> arguments, in order. If there is a â€˜...â€™ argument, it will take up
> the remaining arguments,
> tagged or not.
> If any arguments remain unmatched an error is declared.
> if you now consider the example of quote(a=1), with quote having *one*
> formal argument (parameter) named 'expr' (see ?quote), we see that:
> 1. there is no exact match between the formal 'expr' and the actual 'a'
> 2. there is no partial match between the formal 'expr' and the actual 'a'
> 3a. there is an unmatched formal argument ('expr'), but no unnamed
> actual argument. hence, 'expr' remains unmatched.
> 3b. there is no argument '...' (i think the r language definition is
> lousy and should say 'formal argument' here, as you can have it as an
> actual, too, as in quote('...'=1)). hence, the actual argument named
> 'a' will not be 'taken up'.
> there remain unmatched arguments (i guess the r language definition is
> lousy and should say 'unmatched actual arguments', as you can obviously
> have unmatched formals, as in eval(1)), hence an error should be
> 'declared' (i guess 'raised' is more appropriate).
> this does not happen in quote(a=1) (and many, many other cases), and
> this makes me infer that there is a *bug* in the implementation of
> argument matching, since it clearly does not conform to the definiton.
> hence, i cc: to r-devel, and will also report a bug in the usual way.
More information about the R-devel