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

2009-04-02 Thread Wacek Kusnierczyk
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.
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


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

2009-04-02 Thread Wacek Kusnierczyk
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

  

is a syntactic variant for

``(, )

(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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel