From r@d|ord @end|ng |rom c@@toronto@edu  Mon Dec  6 19:03:02 2021
From: r@d|ord @end|ng |rom c@@toronto@edu (Radford Neal)
Date: Mon, 6 Dec 2021 13:03:02 -0500
Subject: [Rd] string concatenation operator (revisited)
In-Reply-To: <b3509a16-a132-8a4e-322f-ccb708d12ff1@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>
Message-ID: <20211206180302.GA6850@mail.cs.toronto.edu>

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



[Rd] string concatenation operator (revisited)
Radford Neal