[R] Definition of = vs. <-

Wacek Kusnierczyk Waclaw.Marcin.Kusnierczyk at idi.ntnu.no
Thu Apr 2 10:31:09 CEST 2009


Peter Dalgaard wrote:
> Wacek Kusnierczyk wrote:
>> Stavros Macrakis wrote:
>>>> `->`
>>>>     
>>> Error: object "->" not found
>>>   
>>
>> that's weird!
>
> Why???
>

partly because it was april fools. 

but more seriously, it's because one could assume that in any syntactic
expression with an operator involved, the operator maps to a semantic
object.  it has been claimed on this list (as far as i recall;  don't
ask me for reference, but if pressed, i'll find it) that any expression
of the form

    <lhs> <op> <rhs>

is a syntactic variant for

    `<op>`(<lhs>, <rhs>)

(which would, following that argumentation, make r a lisp-like language)
but this apparently does not apply to '->'.  i would (naively, perhaps)
expect that `->` is a function, which, internally, may well just invert
the order of arguments and imemdiately call `<-`.  the fact that
expressions involving '->' are converted, at the parse time, into ones
using '<-' is far from obvious to me (it is now, but not a priori):

    quote(1->a)
    # a <- 1
    # why not: 1 -> a
    # why not: `->`(1, a)

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)), 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.

vQ




More information about the R-help mailing list