Hacker News Reader

Comment by samatman | Hacker News Reader

Conflating concatenation and addition is just a terrible mistake, this is one illustration among many of that.

In Lua, `+` is always addition, and can be overloaded with an `__add` metamethod, while `..` is concatenation, overloaded with a `__concat` metamethod. `..` is also right associative, which means that `a .. b .. c .. d`, a normal enough string-building pattern, can be optimized into a single allocation for the new string, without having to create `a ..b` and then `ab .. c` and so on.

So I don't see this as a problem of operator overloading, I see it as a problem of a missing operator. Implicit conversion makes that problem worse, but `"12" .. 13` in Lua will give you "1213", as you would expect, and `"2" + 3` gives you 5, again, as you would expect.

View on HN

Concatenation is just addition, though: addition is the monoid operation on numbers with the identity of 0, concatenation is the monoid operation on lists with identity of [].

The problem is almost always not the overloading of + but the implicit type coercion rules

List[Int] has more than one monoid

But, when I'm thinking in List[Any], I expect to be working on the Monoid for List[Any], not the Monoid for List[Int]: things like special-casing List[Int] are exactly what make programming languages difficult to learn and use.

What to use for concatenation is a problem. PL/1 used "|", which was originally drawn with a break in the middle. But C took that over as "or", and that's now the accepted standard. ".." is accepted as a range operator now.

Moving deeper into Unicode is probably not the answer. Although, if a language needed a concatenate symbol, ⊞ (Squared Plus) might be a good choice. It's not used for much else.

As a binary operator `~` seems pretty unambiguous.

Yes, my vote for languages which are running out of glyphs would be `~~` actually.

Rather than using context to differentiate bitwise NOT from concatenation, just rule that ~~ is always concatenation. What you lose is just "NOT NOT", which (without this operator) is legal but pointless.

Perhaps ++, and just use += 1 for incrementing. Rust already doesn't have an increment operator, and my JavaScript linter forbids it.

If it didn’t cause problems (ones I can think of in seconds: it complicates parsing, mathematicians will think it signals multiplication, and it makes it hard to insert spaces), using a single space for concatenation would make sense to me.

(Aside: C (or the C preprocessor?) is the only piece of software that I know that supports that , but only for string literals)

and to make things weirder python can concat literal strings together with "space operator"(j/k)

    >>>'a' 'b' 'c'
    >>>'abc'

they got rid of that in Python 3, I think

Reply on news.ycombinator.com