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

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

__
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
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