Plus Sign Overloading

Plus-sign overloading is a problem in my opinion. It is difficult to tell by looking at the expression alone how it is going to handle various situations. And, each language that uses it seems to have different rules. I say dispense with overloading and have a dedicated string concatenation character.

As far as what the concatenation operation should be, I prefer "&" over "." because "." is best used for object/array dividers. But some languages use "&" for dereferencing.

I didn't mind the use of `++` in Haskell.

Me too, but it is used as pre/post-increment in C++ and others (which has is own problems.

In my domain I use string catenation far more often than arithmetic addition. Thus, I'd rather have a single character.

Ah. By that reasoning, I suggest you use `(`. That neatly avoids the PlusSignOverloading problem and simultaneously provides you with a one-character solution to your string(catenation(requirements.

I hope this is meant as a joke. Obviously, "(" has a lot of other potential uses. "@" or "*" are some options that are not used very often for other purposes.
If '*' was in use, you'd be here complaining about MulSignOverloading... and the CeePlusPlus guys would just go grab a beer and start talking about FourStarProgramming. Use of '$' or '%' or '^' aren't too bad, though.
You are right, toss the the "*" suggestion. I was thinking of doing something else with multiplication, but decided against it.

String concatenation in Haskell is a grossly expensive operation, unfortunately. I learned that lesson really fast when writing the prototype for CUT 3. However, expressing strings as large trees of extents made things go much faster -- there, I'd flatten the tree only when absolutely necessary, and amortized the cost of concatenation or printing. Perhaps, with that being said, the best solution to string concatenation isn't concatenation, but rather, composition of extents in lists? --SamuelFalvo?

Even if you've got ropes or other forms of high-efficiency logical concatenation, you'd do well to have an operator for(indicating(intent(to(concatenate.

CategoryLanguageFeature CategoryCpp CategoryRuby