[Rd] string concatenation operator (revisited)
Gabriel Becker
g@bembecker @end|ng |rom gm@||@com
Tue Dec 7 01:20:51 CET 2021
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
>> >>>
>> >>
>> >> [[alternative HTML version deleted]]
>> >>
>> >> ______________________________________________
>> >> R-devel using r-project.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>> >>
>>
>> ______________________________________________
>> R-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
[[alternative HTML version deleted]]
More information about the R-devel
mailing list