From g@bembecker @end|ng |rom gm@||@com  Mon Dec  6 21:34:40 2021
From: g@bembecker @end|ng |rom gm@||@com (Gabriel Becker)
Date: Mon, 6 Dec 2021 12:34:40 -0800
Subject: [Rd] string concatenation operator (revisited)
In-Reply-To: <20211206180302.GA6850@mail.cs.toronto.edu>
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>
Message-ID: <CAD4oTHGLQVLwaLCcZtY3YqTg8PP6Y0Ji5ZNueND=uwSSGtZ5DA@mail.gmail.com>

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



[Rd] string concatenation operator (revisited)
Gabriel Becker