I am surprised nobody so far has mentioned glue which is an implementation in R of a python idiom.
It is a reverse import in a great number of R packages on CRAN. It specifies how some of the special cases so far considered are treated which seems an advantage: > library(glue) > glue(NA, 2) NA2 > glue(NA, 2, .sep = " ") NA 2 > glue(NA, 2, .na = NULL) NA David Scott On 7/12/2021 1:20 pm, Gabriel Becker wrote: > 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 > <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 > <https://stat.ethz.ch/mailman/listinfo/r-devel> > >> >> > >> > >> ______________________________________________ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > <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 > <https://stat.ethz.ch/mailman/listinfo/r-devel> -- _________________________________________________________________ David Scott Department of Statistics The University of Auckland, PB 92019 Auckland 1142, NEW ZEALAND Email:d.sc...@auckland.ac.nz [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel