[Rd] [R] Definition of = vs. <-

Wacek Kusnierczyk 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:
>
>     quote(a=1)
>     # 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
>     quote(a=1)
>     # 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 mailing list