[Rd] string concatenation operator (revisited)

Duncan Murdoch
2021-12-06T21:28:01Z

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 at
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 at
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 at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>          [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>