As I recall, there was a large discussion related to that which resulted in the recycle0 argument being added (but defaulting to FALSE) for paste/paste0.
I think a lot of these things ultimately mean that if there were to be a string concatenation operator, it probably shouldn't have behavior identical to paste0. Was that what you were getting at as well, Bill? ~G On Mon, Dec 6, 2021 at 4:11 PM Bill Dunlap <williamwdun...@gmail.com> wrote: > Should paste0(character(0), c("a","b")) give character(0)? > There is a fair bit of code that assumes that paste("X",NULL) gives "X" > but c(1,2)+NULL gives numeric(0). > > -Bill > > On Mon, Dec 6, 2021 at 1:32 PM Duncan Murdoch <murdoch.dun...@gmail.com> > wrote: > >> On 06/12/2021 4:21 p.m., Avraham Adler wrote: >> > Gabe, I agree that missingness is important to factor in. To somewhat >> abuse >> > the terminology, NA is often used to represent missingness. Perhaps >> > concatenating character something with character something missing >> should >> > result in the original character? >> >> I think that's a bad idea. If you wanted to represent an empty string, >> you should use "" or NULL, not NA. >> >> I'd agree with Gabe, paste0("abc", NA) shouldn't give "abcNA", it should >> give NA. >> >> Duncan Murdoch >> >> > >> > Avi >> > >> > On Mon, Dec 6, 2021 at 3:35 PM Gabriel Becker <gabembec...@gmail.com> >> wrote: >> > >> >> 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 >> >> >> >> ______________________________________________ >> 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