string concatenation operator (revisited)

After seeing what others are saying, it is clear that you need to carefully
think things out before designing any implementation of a more native
concatenation operator whether it is called "+' or anything else. There may
not be any ONE right solution but unlike a function version like paste()
there is nowhere to place any options that specify what you mean.

You can obviously expand paste() to accept arguments like replace.NA="" or
replace.NA="<NA>" and similar arguments on what to do if you see a NaN, and
Inf or -Inf, a NULL or even an NA.character_ and so on. Heck, you might tell
to make other substitutions as in substitute=list(100=99, D=F) or any other
nonsense you can come up with.

But you have nowhere to put options when saying:

c <- a + b

Sure, you could set various global options before the addition and maybe
rest them after, but that is not a way I like to go for something this
basic.

And enough such tinkering makes me wonder if it is easier to ask a user to
use a slightly different function like this:

paste.no.na <- function(...) do.call(paste, Filter(Negate(is.na),
list(...)))

The above one-line function removes any NA from the argument list to make a
potentially shorter list before calling the real paste() using it.

Variations can, of course, be made that allow functionality as above. 

If R was a true object-oriented language in the same sense as others like
Python, operator overloading of "+" might be doable in more complex ways but
we can only work with what we have. I tend to agree with others that in some
places R is so lenient that all kinds of errors can happen because it makes
a guess on how to correct it. Generally, if you really want to mix numeric
and character, many languages require you to transform any arguments to make
all of compatible types. The paste() function is clearly stated to coerce
all arguments to be of type character for you. Whereas a+b makes no such
promises and also is not properly defined even if a and b are both of type
character. Sure, we can expand the language but it may still do things some
find not to be quite what they wanted as in "2"+"3" becoming "23" rather
than 5. Right now, I can use as.numeric("2")+as.numeric("3") and get the
intended result after making very clear to anyone reading the code that I
wanted strings converted to floating point before the addition.

As has been pointed out, the plus operator if used to concatenate does not
have a cognate for other operations like -*/ and R has used most other
special symbols for other purposes. So, sure, we can use something like ....
(4 periods) if it is not already being used for something but using + here
is a tad confusing. Having said that, the makers of Python did make that
choice.

-----Original Message-----
From: R-devel <r-devel-bounces at r-project.org> On Behalf Of Gabriel Becker
Sent: Monday, December 6, 2021 7:21 PM
To: Bill Dunlap <williamwdunlap at gmail.com>
Cc: Radford Neal <radford at cs.toronto.edu>; r-devel <r-devel at r-project.org>
Subject: Re: [Rd] string concatenation operator (revisited)

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

string concatenation operator (revisited)

Thread (23 messages)