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