>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?
Yes.
On Mon, Dec 6, 2021 at 4:21 PM Gabriel Becker <gabembec...@gmail.com> 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
>>> >>>
>>> >>
>>> >> [[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
