[Rd] Improving string concatenation

[Radford Neal]

Gabor Csardi writes:

> Btw. for some motivation, here is a (surely incomplete) list of
> languages with '+' as the string concatenation operator:
> 
> ALGOL 68, BASIC, C++, C#, Cobra, Pascal, Object Pascal, Eiffel, Go,
> JavaScript, Java, Python, Turing, Ruby, Windows Powers hell,
> Objective-C, F#, Sc-ala, Ya.


The situation for R is rather different from that of a language (as
many of the above) in which variables are declared to be of a specific
type.

In such a statically typed language, when you see the expression
"a+b", it is easy to figure out whether the "+" will be numeric
addition or string concatenation, by looking at the declarations of
"a" and "b".

But in a language such as R in which values have types, but variables
don't, someone seeing "a+b" in code wouldn't be able to tell easily
what it does.  This is OK, in fact desirable, in the case of operator
dispatch according to class when the different methods implement
versions of the operator that have analogous properties.  But numeric
addition and string concatenation have just about nothing in common,
so cases where functions are meant to have "+" be either addition OR
concatenation are going to be rare.

Furthermore, making "+" concatenate strings would preclude ever making
"+" convert strings to numbers (signalling an error if they aren't in
some numerical format) and then add them.  I'm not sure whether that
would be a good idea or not, but it might be unwise to eliminate the
possibility.

And of course, as someone else mentioned, it may instead be desirable
for attempts to add strings to signal an error, as at present, which
one also gives up by making "+" do concatenation.


> Yes, even Fortran has one, and in C, I can simply write "literal1"
> "literal2" and they'll be concatenated. It is only for literals, but
> still very useful.

Concatenation of literal strings could easily be added to the R parser
without changing anything else.  (Getting them to deparse as the same
two pieces would be tricky, but is maybe not necessary.)

   Radford Neal