

Dear Rhelpers:
I have a question related to < and =.
I saw very experienced R programmers use = rather than < quite
consistently.
However, I heard from others that do not use = but always stick to < when
assigning valuese.
I personally like = because I was using Matabl, But, would like to receive
expert opinion to avoid potential trouble.
Many thanks in advance.
Sean
[[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


On 3/11/2009 10:18 AM, Sean Zhang wrote:
> Dear Rhelpers:
>
> I have a question related to < and =.
>
> I saw very experienced R programmers use = rather than < quite
> consistently.
> However, I heard from others that do not use = but always stick to < when
> assigning valuese.
>
> I personally like = because I was using Matabl, But, would like to receive
> expert opinion to avoid potential trouble.
Use < for assignment, and = for function arguments. Then the
difference between
f( a = 3 )
f( a < 3 )
is clear, and you won't be surprised that a gets changed in the second
case. If you use = for assignment, the two lines above will be written as
f( a = 3 )
f( ( a = 3 ) )
and it is very easy to miss the crucial difference between them.
Duncan Murdoch
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


On Wed, Mar 11, 2009 at 7:18 AM, Sean Zhang < [hidden email]> wrote:
> Dear Rhelpers:
>
> I have a question related to < and =.
>
> I saw very experienced R programmers use = rather than < quite
> consistently.
> However, I heard from others that do not use = but always stick to < when
> assigning valuese.
>
> I personally like = because I was using Matabl, But, would like to receive
> expert opinion to avoid potential trouble.
>
> Many thanks in advance.
>
> Sean
The short answer is that < is used for assignment, and = is used to
associate function arguments with their values. You can use = instead
of < for assignment too (in most contexts), but the converse isn't
true.
I've provided more detail about when you can and can't exchange the
two operators (and some of the history about the operators themselves)
in this blog post:
http://blog.revolutioncomputing.com/2008/12/useequalsorarrowforassignment.html# David Smith

David M Smith < [hidden email]>
Director of Community, REvolution Computing www.revolutioncomputing.com
Tel: +1 (206) 5774778 x3203 (Seattle, USA)
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


Duncan Murdoch wrote:
>
> Use < for assignment, and = for function arguments. Then the
> difference between
>
> f( a = 3 )
> f( a < 3 )
>
> is clear, and you won't be surprised that a gets changed in the second
> case. If you use = for assignment, the two lines above will be
> written as
>
> f( a = 3 )
> f( ( a = 3 ) )
>
> and it is very easy to miss the crucial difference between them.
in fact, some recent posts show that things can go the other way round:
people try to use < for function arguments. i think the following is
the most secure way if one really really has to do assignment in a
function call:
f({a=3})
and if one keeps this convention, < can be dropped altogether.
vQ
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


Sean,
> would like to receive expert opinion to avoid potential trouble
[..]
> i think the following is the most secure way if one really
> really has to do assignment in a function call
> f({a=3})
> and if one keeps this convention, < can be dropped altogether.
secure is relative, since due to R's lazy evaluation you never know whether a function's argument is being evalutated, look at:
> f< function(x)TRUE
> x < 1
> f((x=2)) # obscured attempt to assign in a function call
[1] TRUE
> x
[1] 1
Thus there is dangerous advice in the referenced blog which reads:
"
f(x < 3)
which means "assign 3 to x, and call f with the first argument set to the value 3
"
This might be the case in C but not in R. Actually in R "f(x < 3)" means: call f with a first unevaluated argument "x < 3", and if and only if f decides to evaluate its first argument, then the assignment is done. To make this very clear:
> f < function(x)if(runif(1)>0.5) TRUE else x
> x < 1
> print(f(x < x + 1))
[1] TRUE
> print(f(x < x + 1))
[1] 2
> print(f(x < x + 1))
[1] 3
> print(f(x < x + 1))
[1] TRUE
> print(f(x < x + 1))
[1] 4
> print(f(x < x + 1))
[1] 5
> print(f(x < x + 1))
[1] TRUE
> print(f(x < x + 1))
[1] 6
> print(f(x < x + 1))
[1] TRUE
Here it is unpredictable whether your assignment takes place. Thus assigning like f({x=1}) or f((x=1))is the maximum dangerous thing to do: even if you have a codereviewer and the guy is aware of the danger of f(x<1) he will probably miss it because f((x=1)) does look too similar to a standard call f(x=1).
According to help("<"), R's assignment operator is rather "<" than "=":
"
The operators < and = assign into the environment in which they are evaluated. The operator < can be used anywhere, whereas the operator = is only allowed at the top level (e.g., in the complete expression typed at the command prompt) or as one of the subexpressions in a braced list of expressions.
"
So my recommendation is
1) use R's assignment operator with two spaces around (or assign()) and don't obscure assignments by using C's assignment operator (or other languages equality operator)
2) do not assign in function arguments unless you have good reasons like in system.time(x < something)
HTH
Jens Oehlschlägel
P.S. Disclaimer: you can consider me biased towards "<", never trust experts, whether experienced or not.
P.P.S. a puzzle, following an old tradition:
What is going on here? (and what would you need to do to prove it?)
> search()
[1] ".GlobalEnv" "package:stats" "package:graphics" "package:grDevices" "package:utils" "package:datasets" "package:methods"
[8] "Autoloads" "package:base"
> ls(all.names = TRUE)
[1] "y"
> y
[1] 1 2 3
> identical(y, 1:3)
[1] TRUE
> y[] < 1 # assigning 1 fails
> y
[1] 1 2 3
> y[] < 2 # assigning 2 works
> y
[1] 2 2 2
>
> # Tip: no standard packages modified, no extra packages loaded, neither classes nor methods defined, no print methods hiding anything, if you would investigate my R you would not find any false bottom anymore
>
> version
_
platform i386pcmingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 8.1
year 2008
month 12
day 22
svn rev 47281
language R
version.string R version 2.8.1 (20081222)

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


Jens Oehlschlägel wrote:
> Sean,
>
>
>> would like to receive expert opinion to avoid potential trouble
>>
> [..]
>
>> i think the following is the most secure way if one really
>> really has to do assignment in a function call
>> f({a=3})
>> and if one keeps this convention, < can be dropped altogether.
>>
>
> secure is relative, since due to R's lazy evaluation you never know whether a function's argument is being evalutated,
for sure, but that's not different between < and {=}. in both cases,
if the argument is not used, assignment will not be made.
>> f< function(x)TRUE
>> x < 1
>> f((x=2)) # obscured attempt to assign in a function call
>>
> [1] TRUE
>
>> x
>>
> [1] 1
>
same with f(x<2)
> Thus there is dangerous advice in the referenced blog which reads:
> "
> f(x < 3)
> which means "assign 3 to x, and call f with the first argument set to the value 3
> "
> This might be the case in C but not in R. Actually in R "f(x < 3)" means: call f with a first unevaluated argument "x < 3", and if and only if f decides to evaluate its first argument, then the assignment is done.
indeed. i have already argued that using assignment within function
calls is not a good idea; but pick any book on r, you likely to find
numerous examples of it, without an appropriate warning.
<snip>
>
> Here it is unpredictable whether your assignment takes place. Thus assigning like f({x=1}) or f((x=1))
or f(x<1)
> is the maximum dangerous thing to do: even if you have a codereviewer and the guy is aware of the danger of f(x<1) he will probably miss it because f((x=1)) does look too similar to a standard call f(x=1).
>
sorry, to me f({x=1}) looks pretty much unlike f(x=1). if someone uses
assignments in function calls and does not know what he's doing, it's
his fault.
> According to help("<"), R's assignment operator is rather "<" than "=":
>
> "
> The operators < and = assign into the environment in which they are evaluated. The operator < can be used anywhere, whereas the operator = is only allowed at the top level (e.g., in the complete expression typed at the command prompt) or as one of the subexpressions in a braced list of expressions.
>
to me, it doesn't say anything like that R's assignment operator is
rather "<" than "=".
> "
>
> So my recommendation is
> 1) use R's assignment operator with two spaces around (or assign()) and don't obscure
... but do beautify ...
> assignments by using C's
don't acknowledge c for it
> assignment operator (or other languages equality operator)
> 2) do not assign in function arguments unless you have good reasons like in system.time(x < something)
>
certainly good advice.
>
> P.P.S. a puzzle, following an old tradition:
>
> What is going on here? (and what would you need to do to prove it?)
>
complete mystery to me.
cheers,
vQ
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


On Thu, Mar 12, 2009 at 8:29 AM, "Jens Oehlschlägel" < [hidden email]> wrote:
> Thus there is dangerous advice in the referenced blog which reads:
> "
> f(x < 3)
> which means "assign 3 to x, and call f with the first argument set to the value 3
> "
The thrust of the blog post was the stylistic question of whether to
use < or = for assignment, not a recommendation to use constructs
like this. (In fact, the next line reads "This is a contrived example
though, and never really occurs in realworld programming.") But I've
added your sound advice that such constructs are best avoided. I've
never seen the need to perform assignments in function calls before,
but I'll avoid them now knowing about potential for mischief from lazy
evaluation. Thanks.
http://blog.revolutioncomputing.com/2008/12/useequalsorarrowforassignment.html# David Smith

David M Smith < [hidden email]>
Director of Community, REvolution Computing www.revolutioncomputing.com
Tel: +1 (206) 5774778 x3203 (Seattle, USA)
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


I think Venables' and Ripley's convention makes good sense:
http://www.stat.auckland.ac.nz/mail/archive/rdownunder/2008October/000300.htmlSo we not only are explicit about what we are assigning, but where we
are assigning it.
Cheers,
Simon.
On Thu, 20090312 at 17:10 0700, David M Smith wrote:
> On Thu, Mar 12, 2009 at 8:29 AM, "Jens Oehlschlägel" < [hidden email]> wrote:
> > Thus there is dangerous advice in the referenced blog which reads:
> > "
> > f(x < 3)
> > which means "assign 3 to x, and call f with the first argument set to the value 3
> > "
>
> The thrust of the blog post was the stylistic question of whether to
> use < or = for assignment, not a recommendation to use constructs
> like this. (In fact, the next line reads "This is a contrived example
> though, and never really occurs in realworld programming.") But I've
> added your sound advice that such constructs are best avoided. I've
> never seen the need to perform assignments in function calls before,
> but I'll avoid them now knowing about potential for mischief from lazy
> evaluation. Thanks.
>
> http://blog.revolutioncomputing.com/2008/12/useequalsorarrowforassignment.html>
> # David Smith
>
> 
> David M Smith < [hidden email]>
> Director of Community, REvolution Computing www.revolutioncomputing.com
> Tel: +1 (206) 5774778 x3203 (Seattle, USA)
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/rhelp> PLEASE do read the posting guide http://www.Rproject.org/postingguide.html> and provide commented, minimal, selfcontained, reproducible code.

Simon Blomberg, BSc (Hons), PhD, MAppStat.
Lecturer and Consultant Statistician
School of Biological Sciences
The University of Queensland
St. Lucia Queensland 4072
Australia
Room 320 Goddard Building (8)
T: +61 7 3365 2506
http://www.uq.edu.au/~uqsblombemail: S.Blomberg1_at_uq.edu.au
Policies:
1. I will NOT analyse your data for you.
2. Your deadline is your problem.
The combination of some data and an aching desire for
an answer does not ensure that a reasonable answer can
be extracted from a given body of data.  John Tukey.
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


Dear Jens and Wacek:
I appreciate your answers very much.
I came up an example based on your comments.
I feel the example helped me to understand...(I could be missing your points
though :( )
If so, please let me know.
Simon pointed out the following link:
http://www.stat.auckland.ac.nz/mail/archive/rdownunder/2008October/000300.htmlI am still trying to understand it...
My question is how my conclusion (see at the end of the example below) drawn
from "lexical scope" perspective is related to
an understanding from an "environment" perspective (if an understanding from
"environment" perspective validly exists).
Thank you all again very much!
Sean Zhang
#My little example is listed below
f1<function(a=1,b=2) {print(a); print(b); print(ab) }
f1() #get 3, makes sense
f1(2,) #get 0, makes sense
a < 10
b < 20
f1(a=a+1,b=a)
a #get 10 a is not changed outside function scope
b #get 20, b is not changed outside function scope
a < 10
b < 20
f1(a < a+1, b < a)
a #a is now 11, a is changed outside function
b #b is now 11 b is changed outside function
a < 10
b < 20
f1({a=a+1},{b = a})
a #a is changed into 11
b #b is changed into a(i.e., 11)
a < 10
b < 20
f1((a=a+1),(b = a))
a #a is changed into 11
b #b is changed into a(i.e., 11)
#my conclusion based on testing the example above is below
#say argument is a, when used inside paraenthesis of
whatever.fun<function()
#a<something, (a=something) , and {a<something}
#are the same. They all change the values outside the function's scope.
#Typically, this breaks the desired lexical scope convention. so it is
dangerous.
#Correct me, if my understanding is off.
#Also, how to interprete the above test results from an "environment"
perspective? evnironment vs. scope?
#big thanks. Sean
On Thu, Mar 12, 2009 at 11:29 AM, "Jens Oehlschlägel" < [hidden email]>wrote:
> Sean,
>
> > would like to receive expert opinion to avoid potential trouble
> [..]
> > i think the following is the most secure way if one really
> > really has to do assignment in a function call
> > f({a=3})
> > and if one keeps this convention, < can be dropped altogether.
>
> secure is relative, since due to R's lazy evaluation you never know whether
> a function's argument is being evalutated, look at:
>
> > f< function(x)TRUE
> > x < 1
> > f((x=2)) # obscured attempt to assign in a function call
> [1] TRUE
> > x
> [1] 1
>
> Thus there is dangerous advice in the referenced blog which reads:
> "
> f(x < 3)
> which means "assign 3 to x, and call f with the first argument set to the
> value 3
> "
> This might be the case in C but not in R. Actually in R "f(x < 3)" means:
> call f with a first unevaluated argument "x < 3", and if and only if f
> decides to evaluate its first argument, then the assignment is done. To make
> this very clear:
>
> > f < function(x)if(runif(1)>0.5) TRUE else x
> > x < 1
> > print(f(x < x + 1))
> [1] TRUE
> > print(f(x < x + 1))
> [1] 2
> > print(f(x < x + 1))
> [1] 3
> > print(f(x < x + 1))
> [1] TRUE
> > print(f(x < x + 1))
> [1] 4
> > print(f(x < x + 1))
> [1] 5
> > print(f(x < x + 1))
> [1] TRUE
> > print(f(x < x + 1))
> [1] 6
> > print(f(x < x + 1))
> [1] TRUE
>
> Here it is unpredictable whether your assignment takes place. Thus
> assigning like f({x=1}) or f((x=1))is the maximum dangerous thing to do:
> even if you have a codereviewer and the guy is aware of the danger of
> f(x<1) he will probably miss it because f((x=1)) does look too similar to a
> standard call f(x=1).
>
> According to help("<"), R's assignment operator is rather "<" than "=":
>
> "
> The operators < and = assign into the environment in which they are
> evaluated. The operator < can be used anywhere, whereas the operator = is
> only allowed at the top level (e.g., in the complete expression typed at the
> command prompt) or as one of the subexpressions in a braced list of
> expressions.
> "
>
> So my recommendation is
> 1) use R's assignment operator with two spaces around (or assign()) and
> don't obscure assignments by using C's assignment operator (or other
> languages equality operator)
> 2) do not assign in function arguments unless you have good reasons like in
> system.time(x < something)
>
> HTH
>
>
> Jens Oehlschlägel
>
> P.S. Disclaimer: you can consider me biased towards "<", never trust
> experts, whether experienced or not.
>
> P.P.S. a puzzle, following an old tradition:
>
> What is going on here? (and what would you need to do to prove it?)
>
> > search()
> [1] ".GlobalEnv" "package:stats" "package:graphics"
> "package:grDevices" "package:utils" "package:datasets"
> "package:methods"
> [8] "Autoloads" "package:base"
> > ls(all.names = TRUE)
> [1] "y"
> > y
> [1] 1 2 3
> > identical(y, 1:3)
> [1] TRUE
> > y[] < 1 # assigning 1 fails
> > y
> [1] 1 2 3
> > y[] < 2 # assigning 2 works
> > y
> [1] 2 2 2
> >
> > # Tip: no standard packages modified, no extra packages loaded, neither
> classes nor methods defined, no print methods hiding anything, if you would
> investigate my R you would not find any false bottom anymore
> >
> > version
> _
> platform i386pcmingw32
> arch i386
> os mingw32
> system i386, mingw32
> status
> major 2
> minor 8.1
> year 2008
> month 12
> day 22
> svn rev 47281
> language R
> version.string R version 2.8.1 (20081222)
>
> 
> Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:
> http://www.gmx.net/de/go/multimessenger01>
[[alternative HTML version deleted]]
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


I think most people find it odd at first if they have always used "=" but quickly you get use to it and nothing could be more clear. It is explicit. It is active and provides a direction, a value goes into an object. The equal sign for assignment is ambiguous.
As an example
x = 3
we only know that the value 3 is assigned to the object x because by convention a number cannot be an object, if not it could be read as the object "3" taking the value "x" The expression literally states that they are equal, yet you cannot assume that all instances of 3 are equal to x, so it is an inaccurate expression. On the other hand,
3 > x or
x < 3
is very clear. It makes no changes to "3" only to "x" I've been reading "Data Manipulation with R" and find the author's use of "=" for assignment disturbing. You quickly get use to > and will find after a short time that you prefer it.
Sean Zhang wrote
Dear Rhelpers:
I have a question related to < and =.
I saw very experienced R programmers use = rather than < quite
consistently.
However, I heard from others that do not use = but always stick to < when
assigning valuese.
I personally like = because I was using Matabl, But, would like to receive
expert opinion to avoid potential trouble.
Many thanks in advance.
Sean
[[alternative HTML version deleted]]
______________________________________________
Rhelp@rproject.org mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


Sean Zhang wrote:
> Dear Jens and Wacek:
>
> I appreciate your answers very much.
>
> I came up an example based on your comments.
> I feel the example helped me to understand...(I could be missing your points
> though :( )
> If so, please let me know.
> Simon pointed out the following link:
> http://www.stat.auckland.ac.nz/mail/archive/rdownunder/2008October/000300.html> I am still trying to understand it...
> My question is how my conclusion (see at the end of the example below) drawn
> from "lexical scope" perspective is related to
> an understanding from an "environment" perspective (if an understanding from
> "environment" perspective validly exists).
>
> Thank you all again very much!
>
> Sean Zhang
>
> #My little example is listed below
> f1<function(a=1,b=2) {print(a); print(b); print(ab) }
> f1() #get 3, makes sense
>
1?
> f1(2,) #get 0, makes sense
> a < 10
> b < 20
> f1(a=a+1,b=a)
> a #get 10 a is not changed outside function scope
> b #get 20, b is not changed outside function scope
> a < 10
> b < 20
> f1(a < a+1, b < a)
>
this is what you *really* shouldn't do unless you know what you're
doing. here you have not only the issue of whether the assignment will
actually be made, but also the issue of the order of evaluation of the
argument expressions, which depends on the when the arguments are used
within the function.
f = function(a, b, c)
if (c) ab
else ba
a=1; b=1; f(a < a+1, b < a, TRUE)
# 0
a
# 2
b
# 2
a=1; b=1; f(a < a+1, b < a, FALSE)
# 1
a
# 2
b
# 1
> a #a is now 11, a is changed outside function
> b #b is now 11 b is changed outside function
> a < 10
> b < 20
> f1({a=a+1},{b = a})
> a #a is changed into 11
> b #b is changed into a(i.e., 11)
>
> a < 10
> b < 20
> f1((a=a+1),(b = a))
> a #a is changed into 11
> b #b is changed into a(i.e., 11)
> #my conclusion based on testing the example above is below
> #say argument is a, when used inside paraenthesis of
> whatever.fun<function()
> #a<something, (a=something) , and {a<something}
> #are the same. They all change the values outside the function's scope.
> #Typically, this breaks the desired lexical scope convention. so it is
> dangerous.
>
i don't think you break lexical scoping here.
vQ
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


I would argue that this is a matter of preference and the arguments on
"principle" for one side or another are not particularly compelling.
When the "=" was introduced for assignment, an argument was made that
name=value function arguments are also implicitly a kind of assignment.
While Duncan has pointed out a typical example of how this could be
ambiguous, < also has its problems. A syntactic confusion with "<"
arises in expressions like
x<3
which could be read either as an assignment or as a logical expression
comparing x to 3. Perhaps obviously ambiguous when written naked like
this but when buried in a larger expression, it's easy to write an
expression like that and discover that you have overwritten x. Some might
(and have, most emphatically) advise that we should routinely insert
spaces in our typing in a way that disambiguates such expressions but I
find an argument that relies on spaces, which are usually syntactically
unmeaningful, not very compelling.
Besides, I just find that clumsy twocharacter arrow ugly! This is an
esthetic matter  reminds me too much of an emoticon. :( For over 10
years I used the alternative "_" underscore for S assignment (nice as a
single character with no competing syntactic meaning) but that has gone
away, as far as I can tell primarily due to discomfort (disdain?) of
developers who find it unattractive because of the use of "_" as a
connecting special category in OTHER contexts (C and shell programming).
However, a mutually satisfactory solution is at hand!! If growth in the
number of R programmers continues exponentially at its current rate, by
the year 2097 the number of R programmers will exceed the population of
the earth. At that point they will rise up and demand the restoration of
the APL arrow key (remembered by some doddering guru who heard about it
from her grandfather) to the standard keyboard, and our problem will be
solved. (But there will be a minor irritation because in the New Zealand
keyboard that key code will have been assigned to the locally popular
sheep icon.)
Alan Zaslavsky
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


Alan Zaslavsky wrote:
> I would argue that this is a matter of preference and the arguments on
> "principle" for one side or another are not particularly compelling.
indeed; i have argued (i think...) for treating them as equals, the
vhoice being a matter of taste.
> When the "=" was introduced for assignment, an argument was made that
> name=value function arguments are also implicitly a kind of assignment.
sure they are. you assign (or not, depending on whether the arguments
are actually used) to functioncalllocal variables, that is, the
function's parameters.
> While Duncan has pointed out a typical example of how this could be
> ambiguous, < also has its problems. A syntactic confusion with "<"
> arises in expressions like
>
> x<3
>
> which could be read either as an assignment or as a logical expression
> comparing x to 3.
ha! cool.
> Perhaps obviously ambiguous when written naked like this but when
> buried in a larger expression, it's easy to write an expression like
> that and discover that you have overwritten x.
even worse if the code is processed in some way that might remove
spaces, thus turning <  into <.
> Some might (and have, most emphatically) advise that we should
> routinely insert spaces in our typing in a way that disambiguates such
> expressions but I find an argument that relies on spaces, which are
> usually syntactically unmeaningful, not very compelling.
>
> Besides, I just find that clumsy twocharacter arrow ugly!
:)
> This is an esthetic matter  reminds me too much of an emoticon. :(
> For over 10 years I used the alternative "_" underscore for S
> assignment (nice as a single character with no competing syntactic
> meaning) but that has gone away, as far as I can tell primarily due to
> discomfort (disdain?) of developers who find it unattractive because
> of the use of "_" as a connecting special category in OTHER contexts
> (C and shell programming).
>
> However, a mutually satisfactory solution is at hand!! If growth in
> the number of R programmers continues exponentially at its current
> rate, by the year 2097 the number of R programmers will exceed the
> population of the earth. At that point they will rise up and demand
> the restoration of the APL arrow key (remembered by some doddering
> guru who heard about it from her grandfather) to the standard
> keyboard, and our problem will be solved. (But there will be a minor
> irritation because in the New Zealand keyboard that key code will have
> been assigned to the locally popular sheep icon.)
by that time r programs will be scanned directly from your head, i
suppose, and the intelligent scanner will as gladly take < as it will
=, so the problem will rather vanish.
vQ
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.


thanks for your supportive comments!
by that time r programs will be scanned directly from your head, i
suppose, and the intelligent scanner will as gladly take < as it will
=, so the problem will rather vanish.
Yes, and maybe the scanner will be more intelligent than the programmer so
when the programmer is confused about what he/she wants, the scanner will
figure it out! :)
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/rhelpPLEASE do read the posting guide http://www.Rproject.org/postingguide.htmland provide commented, minimal, selfcontained, reproducible code.

