From g@bembecker @end|ng |rom gm@||@com  Tue Dec  7 01:20:51 2021
From: g@bembecker @end|ng |rom gm@||@com (Gabriel Becker)
Date: Mon, 6 Dec 2021 16:20:51 -0800
Subject: [Rd] string concatenation operator (revisited)
In-Reply-To: <CAHqSRuRxwGRf9to5uNMXXZiJuB6oa_uF_3UKY_2y80t=CnRiYw@mail.gmail.com>
References: <mailman.52192.3.1638702001.27673.r-devel@r-project.org>
 <20211206061402.GA3810@mail.cs.toronto.edu>
 <b3509a16-a132-8a4e-322f-ccb708d12ff1@gmail.com>
 <20211206180302.GA6850@mail.cs.toronto.edu>
 <CAD4oTHGLQVLwaLCcZtY3YqTg8PP6Y0Ji5ZNueND=uwSSGtZ5DA@mail.gmail.com>
 <CAL6gwn+B+MP7-s2bgQq+GCAyF2vVdS3KtBR4Zot-pVYzGLQW9g@mail.gmail.com>
 <82ea4836-96dd-b979-e684-018354cb3f33@gmail.com>
 <CAHqSRuRxwGRf9to5uNMXXZiJuB6oa_uF_3UKY_2y80t=CnRiYw@mail.gmail.com>
Message-ID: <CAD4oTHE=Ap+NnQQeOWbexnQcvHYJ14rQdt9c7NZdp1D1BiEuOQ@mail.gmail.com>

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]]



[Rd] string concatenation operator (revisited)
Gabriel Becker