behavior of =
Philippe Grosjean
phgrosje@ulb.ac.be
Fri, 8 Nov 2002 16:24:15 +0100
Deprecating '_' for assignment in the perspective of reusing it in variables
names is nice (not just a personal impression bacause it is also common in
other languages). I am fighting too often with unreadable codes like
var_value, even without spaces before and after '_'!!!
Addition of '=' for assignment is nice too (also commonly used in other
languages), except for this problem with named arguments...! I know this is
a major change that would require patching all R code, but perhaps a
solution would be to replace '=' in named arguments with something else,...
('_' for instance.. no, I am kidding!). But perhaps, ':=' would be a nice
candidate. So:
foo(a=b) # Assignment of b to a, and a is passed as first argument to
function foo()
foo(a:=b) # b is passed to the named argument 'a' of function foo()
Best,
Philippe Grosjean
...........]<(({?<...............<?}))><...............................
( ( ( ( (
) ) ) ) ) Philippe Grosjean
( ( ( ( (
) ) ) ) ) IFREMER Nantes - DEL/AO
( ( ( ( ( rue de l'Ile d'Yeu, BP 21105, 44311 Nantes Cedex 3
) ) ) ) ) tel: (33) 02.40.37.42.29, fax: (33) 02.40.37.42.41
( ( ( ( ( e-mail: philippe.grosjean@ifremer.fr
) ) ) ) )
( ( ( ( ( "I'm 100% confident that p is between 0 and 1"
) ) ) ) ) L. Gonick & W. Smith (1993)
.......................................................................
-----Message d'origine-----
De : owner-r-devel@stat.math.ethz.ch
[mailto:owner-r-devel@stat.math.ethz.ch]De la part de John Chambers
Envoye : vendredi 8 novembre 2002 15:15
A : bolker@zoo.ufl.edu
Cc : R development mailing list
Objet : Re: behavior of =
It's a real confusion, but don't blame it on the use of "=" as an
assignment operator.
It's all the fault of having named arguments, which goes way back to the
dawn of time.
What you said (as opposed to what, of course, you meant) was that the
argument called "x" to "[" had the value of min(x).
The clue is that after evaluating the expression, x is unchanged
(distinctly NOT the case for the infamous C equivalent).
R> x <- runif(20)
R> y <- 1:20
R> y[x = min(x)]
numeric(0)
R> x
[1] 0.1452749 0.4936352 0.7872399 0.4377552 0.4072236 0.4416220
0.4748017
[8] 0.8523369 0.8870081 0.7401091 0.1480467 0.3367802 0.3825770
0.3596608
[15] 0.1040230 0.6873980 0.2974596 0.9955219 0.3217589 0.2199942
Unfortunately, the implementation of "[" doesn't check argument names
(plausibly a bug). To see the situation more clearly, use the sort
function, whose first argument is "x".
R> sort(x=min(x))
[1] 0.1040230
which is puzzling, but:
R> sort(y=5)
Error in sort(y = 5) : unused argument(s) (y ...)
All the same, it's a useful example for a "what went wrong" FAQ.
Ben Bolker wrote:
>
> I probably didn't follow the discussion of allowing "=" as an assignment
> operator closely enough, but I was a little bit horrified to discover
> today (using 1.6.0; I haven't upgraded to 1.6.1 yet) that
>
> x <- runif(20)
> y <- 1:20
> y[x=min(x)]
>
> gives numeric(0) (because min(x) is non-integer).
>
> x <- sample(1:20,20,TRUE)
> y[x=min(x)]
>
> is even worse -- it gives the "wrong" answer. I know exactly what's going
> on here (the = in the subsetting statement above was a typo for ==), and I
> should have known better, but I felt like I was programming in C again!
>
> I know that the designers tried to build in safeguards (from the man
> page):
>
> the `=' is only allowed at the top level (that is, in the complete
> expression typed by the user) or as one of the subexpressions in a
> braced list of expressions.
>
> These safeguards don't prevent the mishap shown above. Is there any way
> to detect this case syntactically (check for assignments inside subsetting
> operations??), or will I just have to train my students to watch out for
> this possibility?
>
> ----
> 318 Carr Hall bolker@zoo.ufl.edu
> Zoology Department, University of Florida http://www.zoo.ufl.edu/bolker
> Box 118525 (ph) 352-392-5697
> Gainesville, FL 32611-8525 (fax) 352-392-3704
>
> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
-.-.-
> r-devel mailing list -- Read
http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
> Send "info", "help", or "[un]subscribe"
> (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
>
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
_._
--
John M. Chambers jmc@bell-labs.com
Bell Labs, Lucent Technologies office: (908)582-2681
700 Mountain Avenue, Room 2C-282 fax: (908)582-3340
Murray Hill, NJ 07974 web: http://www.cs.bell-labs.com/~jmc
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
_._
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._