On 24-Aug-10 14:42:11, Davor Cubranic wrote: > On August 23, 2010 01:27:24 pm Philippe Grosjean wrote: >> They have to write such a code like this: >> >> if (x < -3) do_something >> >> That way, there is no ambiguity. Don't you think it's important to >> write clear code, including by using spaces where it makes it easier >> to read,... and less ambiguous, as you just realize? > > I fully agree, and I'm sure nobody here would dispute your advice. But > we all sometimes make typos, and the point here is that the grammar's > ambiguity makes for hard-to-find bugs. > > So, if I may focus us back on the OP's suggestion: "that R simply warn > about an ambiguity" in 'if' statement's comparison involving '<-[0-9]'. > It doesn't seem like an unreasonable suggestion. For comparison, GCC > will do the same thing with C code when the '-Wparentheses' switch if > assignment is used in a context where a truth value is expected. (E.g., > 'if (x = 3)'.) > > It's been a very long time since I looked at Yacc and Lex source, but > it looks like function 'xxif' in gram.y is the earliest place where we > have a whole IF statement. AFAICT, this is evaluated in 'do_if' > function of eval.c. There, the condition is evaluated via > 'asLogicalNoNA'. Could 'do_if' instead use a function similar to > 'asLogicalNoNA' but which issues a warning if the condition is an > assignment? > > Davor
I'm a bit doubtful about the suggestion to "trap" this kind of thing and issue warnings afterwards. It's not just in if() statements, but anywhere where a logical value (as "x< -3") can validly be placed and an assignment (as "x<-3") can validly be placed. E.g.: if(x<-3) print("yes") else print("no") # [1] "yes" because: as.logical(x<-3) # [1] TRUE as.logical(x<-0) # [1] FALSE Or: x <- -5 y <- c(5,4,3,2,1) y[x<-3] # [1] 3 x <- -5 y[x< -3] # [1] 5 4 3 2 1 It may be all very well to say that such examples look silly (in what context might anyone mean them seriously?), but remember that the context of this discussion is precisely where someone has written something they didn't mean, so "might mean them seriously" is not a criterion. As illustrated above, "x<-3" is valid in all sorts of syntactic contexts. The upshot is that, if such warnings are to be implemented in any context -- not just "if()" -- where one wanted to protect the innocent from their own fingers, then they would be triggered *every time* the expression "x<-3" (or the like) occurred! Of course one would need to be able to turn this warning off, but if (e.g. as a precaution in a class of beginnners) it were turned on, then there would be a huge number of false positives filling up the screen in almost any normal program. Reassuring for beginners! So, on those grounds, I doubt its wisdom (and would prefer giving the advice to bracket things, as in "x<(-3)". It's a potential syntactic trap, but it's only one of many which can be avoided in similar ways, and I think it's better to teach avoidance rather than warning after the event. Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <ted.hard...@manchester.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 24-Aug-10 Time: 16:18:27 ------------------------------ XFMail ------------------------------ ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel