[Rd] string concatenation operator (revisited)

[David Scott]

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 <williamwdunlap using 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.duncan using 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 <gabembecker using 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 
> <radford using 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 using 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 using r-project.org mailing list
> >> >> https://stat.ethz.ch/mailman/listinfo/r-devel 
> <https://stat.ethz.ch/mailman/listinfo/r-devel>
> >> >>
> >>
> >> ______________________________________________
> >> R-devel using 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 using 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.scott using auckland.ac.nz


	[[alternative HTML version deleted]]