Hacker News Reader

Comment by kbenson | Hacker News Reader

    val label = "The width is "
    val width = 94
    val widthLabel = label + width

I really wish more languages would distinguish concatenation from addition, especially when they do type coercion. There's a very specific reason Perl opted for '.' to concatenate strings instead of +, which is that it disambiguates the following:

    val first = "2"
    val second = 3
    val together1 = first + second
    val together2 = second + first

Not to mention, addition is commutative and concatenation is not (1+2 == 2+1, but "one" + "two" != "two" + "one")

Hopefully Scala at least has some very well defined and easy rules for exactly how string concatenation works, but I think it's an uphill battle to argue that '+' is a good concatenation operator.

View on HN

'+' works great as a concatenation operator, so long as you don't ever try to implicitly convert the values. Case in point - Python:

  >>> 1+2
  3
  >>> "1"+"2"
  '12'
  >>> "1"+2
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: Can't convert 'int' object to str implicitly

Those are literals, not variables. My whole argument is about the ambiguity introduced when you are implicitly coercing variables. But yes, if the language does not coerce between string and numeric types, it's a non-issue. I'm specifically talking about supporting coercion but continuing to use '+' for concatenation of strings (and ==/!= for equivalence testing of strings as well).

Maybe, but in 20 years of programming (and 10+ of them with dynamic languages) I don't think I have had that issue more than 2-3 times.

(1) Passing an int/string when a function expects the other type? Yes, I had that happen lots.

(2) Concatenating a string and a (coerced) int?

It's either a much narrower subproblem of (1), or exactly what I wanted to happen in the first place (e.g. print "Your score is: " + n + " points".

I've dealt with it lots. While concatenating variable and string literals like your example is very rarely ambiguous, but what can be is using + to operating on two variables whose input has been returned from elsewhere.

Does that function that gets the user supplied value for height automatically convert to a numerical type, or is it a string?

What about the function that gets the user supplied value for width?

Is it stored in a back-end format that strictly types those fields to ensure that if the data is set from some less frequently used method it has the same type (e.g. are you storing as JSON, and can this JSON be created from multiple code paths?)

Given a simple statement like "foo = bar + baz", why should there be ambiguity when there doesn't need to be? The glib answer to the problem is to tell people to use better variable names, or document their functions better, or any number of suggestions that put the onus on the programmer, when this is a very simple to solve problem. Don't overload operators in the core language for conceptually different actions. We don't "add" strings, we concatenate them. Add is at best, shorthand for "add to end of" which means to append.

Coercion can be a useful tool, except for when it creates confusion. There are well known and tested ways to combat this confusion, so I'm not sure why we haven't adopted them widely where coercion is in use.

P.S. It's not just addition. Testing for equality is another common case where coercion can cause problems. The answer to that is equally as simple, use a different operator (such as "eq" and "ne" for string equality in Perl). Numeric equality is not the same as string equality (10.0 is equivalent to 10, but "foo." is not equivalent to "foo"), and making the programmer think (not not!) about what will happen when using an overloaded equality operator on two variables just shifts a small amount of up-front cost when learning the language (we have different operators for string concatenation and equivalence testing, learn them) to a cost imposed every time the programmer has to use those operators.

I think concats like 1 + "111" can be disabled with import scala.Predef.{find_right_implicit => _,_}. Cant imagine how many things it will break though

> There's a very specific reason Perl opted for '.' to concatenate strings instead of +

I don't see making string concatenation ambiguous with property access being a real improvement. At least use `..` or some other unused punctuation.

In Perl, '.' is not property access. I'm not trying to imply '.' is the best solution for a language where it's already in use, but that a separate, unambiguous symbol would be better. For example, Perl 6 moved to using '.' for calling methods, and uses '~' for concatenation. It's not like just changing '+' is sufficient anyway, there is still string equivalence to consider (outlined in my other replies).

D does.

auto greeting = "Hello" ~ " World!";

immutable x = 9 + 99;

auto:immutable::var:val

You can also use: s"The width is $width"

Which is good, but interpolation is really just a specialized case of concatenating string literals and variables, not variables to other variables, which is where some ambiguity is introduced.

You can also do s"$varOne$varTwo" and that concatenates two variables.

Yes, as an alternate syntax, interpolation works well to disambiguate your intent, which supports my point. It's really just a highly specialized form of a different operator, which says I work on strings, so anything I see that isn't a string coerce to a string. For example, in Perl

    $varOne . $varTwo

Is entirely equivalent to

    "$varOne$varTwo"

The question is why Scala chose to use + when it had other, non-ambiguous options, like above.

To be more familiar to Java developers.

There are some thoughts about migrating people away from + toward string interpolation. But automated conversion tools are required before this can happen.

D uses + for addition and ~ for concatenation

Reply on news.ycombinator.com