Hi All, Seeing this and the other thread (and admittedly not having clicked through to the linked r-help thread), I wonder about NAs.
Should NA <concat> "hi there" not result in NA_character_? This is not what any of the paste functions do, but in my opinoin, NA + <non_na_value> seems like it should be NA (not "NA"), particularly if we are talking about `+` overloading, but potentially even in the case of a distinct concatenation operator? I guess what I'm saying is that in my head missingness propagation rules should take priority in such an operator (ie NA + <anything> should *always * be NA). Is that something others disagree with, or has it just not come up yet in (the parts I have read) of this discussion? Best, ~G On Mon, Dec 6, 2021 at 10:03 AM Radford Neal <radf...@cs.toronto.edu> wrote: > > > In pqR (see pqR-project.org), I have implemented ! and !! as binary > > > string concatenation operators, equivalent to paste0 and paste, > > > respectively. > > > > > > For instance, > > > > > > > "hello" ! "world" > > > [1] "helloworld" > > > > "hello" !! "world" > > > [1] "hello world" > > > > "hello" !! 1:4 > > > [1] "hello 1" "hello 2" "hello 3" "hello 4" > > > > I'm curious about the details: > > > > Would `1 ! 2` convert both to strings? > > They're equivalent to paste0 and paste, so 1 ! 2 produces "12", just > like paste0(1,2) does. Of course, they wouldn't have to be exactly > equivalent to paste0 and paste - one could impose stricter > requirements if that seemed better for error detection. Off hand, > though, I think automatically converting is more in keeping with the > rest of R. Explicitly converting with as.character could be tedious. > > I suppose disallowing logical arguments might make sense to guard > against typos where ! was meant to be the unary-not operator, but > ended up being a binary operator, after some sort of typo. I doubt > that this would be a common error, though. > > (Note that there's no ambiguity when there are no typos, except that > when negation is involved a space may be needed - so, for example, > "x" ! !TRUE is "xFALSE", but "x"!!TRUE is "x TRUE". Existing uses of > double negation are still fine - eg, a <- !!TRUE still sets a to TRUE. > Parsing of operators is greedy, so "x"!!!TRUE is "x FALSE", not "xTRUE".) > > > Where does the binary ! fit in the operator priority? E.g. how is > > > > a ! b > c > > > > parsed? > > As (a ! b) > c. > > Their precedence is between that of + and - and that of < and >. > So "x" ! 1+2 evalates to "x3" and "x" ! 1+2 < "x4" is TRUE. > > (Actually, pqR also has a .. operator that fixes the problems with > generating sequences with the : operator, and it has precedence lower > than + and - and higher than ! and !!, but that's not relevant if you > don't have the .. operator.) > > Radford Neal > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
