[Rd] string concatenation operator (revisited)
g@bembecker @end|ng |rom gm@||@com
Mon Dec 6 21:34:40 CET 2021
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
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?
On Mon, Dec 6, 2021 at 10:03 AM Radford Neal <radford using 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"
> > >  "helloworld"
> > > > "hello" !! "world"
> > >  "hello world"
> > > > "hello" !! 1:4
> > >  "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 using r-project.org mailing list
[[alternative HTML version deleted]]
More information about the R-devel