Here's a not-so-mathy application that I had recently. I was implementing a units system in Python. Operator overloading allowed me to define joules like so: `J = KG * M**-1 * S**-2`. Then I could define grays (a radiation-related unit) like `Gy = J/KG`. Repeat for hundreds of units. If I had to do it in Java, I'd be frustrated by the verbosity and it would be easier to make mistakes.
My point -- Guy's point, actually -- is that if you don't give people the ability to grow a language, then their expressive power will be limited. And you can't anticipate ahead of time all the ways they'll want to express themselves.
Admittedly, my application is kinda mathy under the hood, because the units exist in a vector space. I guess that's to be expected when the operators come from maths.
Presumably exponentiation rather than multiplication by a constant, right?
This is cool and reminds me of how the Python Z3 binding uses operator overloading to let you express arithmetic and logical constraints
>>> import z3
>>> s = z3.Solver()
>>> a, b, c, d = (z3.Int(x) for x in "abcd")
>>> s.add(a*b == c+d)
>>> s.add(a+b == c+d)
>>> s.add(a!=0,b!=0,c!=0,d!=0)
>>> s.check()
sat
>>> s.model()
[d = 6, c = -2, b = 2, a = 2]
>>> s.reset()
>>> s.add(a>1, b>1, c>1)
>>> s.add(a*a + b*b == c*c)
>>> s.check()
sat
>>> s.model()
[c = 17, b = 8, a = 15]
That's cool too! How do you define the variables?
... there we go.
You use Z3 objects that represent unknowns of particular types, like Z3.Int, Z3.Bool, etc. Each one returns an object representing a variable of that type, which can then be used in (Python-formatted!) expressions that you give to a solver.
The D community has generally agreed, and we haven't had much trouble with people overloading operators to do a regular expression DSL, for example.
Yes. Most other uses for operator overloading are really chains of functions. There's better syntax for that.
I once wrote some overloads for C++ so that you could write
result = fileobject | item | item | item | item;
Python is notorious for problems that stem from combining operator overloading and implicit conversions. "+" is arithmetic for some types and concatenation for others.
[1,2,3] + [4,5,6]
[1,2,3,4,5,6]
which you might not expect. If you add arrays from numpy, those add arithmetically. You can add a numpy array to a built-in array. Trouble comes when you pass a numpy array to a function that expects a built-in array, and the wrong semantics of "+" are applied.
Rust has operator overloading without implicit conversions. That avoids such ambiguities, at the cost of requiring many explicit conversions.
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.
The problem is almost always not the overloading of + but the implicit type coercion rules
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.
(Aside: C (or the C preprocessor?) is the only piece of software that I know that supports that , but only for string literals)
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.
>>>'a' 'b' 'c'
>>>'abc'It seemed obvious to me as soon as I saw it in Perl that the Perl approach ("+" for adding numbers, "." for concatenating strings) is a much better idea than using "+" for both operations.
I'm not sure why people keep wanting to use + for concatenation.
(My other language pet peeve is using backslash as the escape character for your mini-DSL that gets parsed from strings, when backslash is also the escape character for strings. You want to use separate escape characters for each context; stacking the same one in several contexts is the worst possible approach.
C was aware of the problems: it uses `\` as the escape for strings and `%` as the escape for printf commands. But somehow by the time we were writing regular expression libraries, this simple, obvious technology had been lost.)
It's a little bit of a kludge! But a clever one, which uses the precedence of the existing operators to match the expected precedence of concatenation and the `/` ordered choice operator from PEG grammars.
In general I'm suspicious of arguments that boil down to "people might use this language feature badly". I'm not sure I want the full ability to add my own infix and postcircumfix operators, the way e.g. Raku allows, but there's no denying that being able to write `if foo ∈ test_set` is expressive and cool.
Maybe expressive and cool isn't a terminal value for language design, maybe `if test_set.element(foo)` is good enough. I kinda like it though.
In languages which only let you overload existing operators; those operators often get used for a bunch of different things.
I mean, how many languages use `+` for both addition and string concatenation? … and maybe also set union?
Its kind of interesting that Raku’s own docs think of '=' being used for both item assignment and lost assignment as an exception to this, because it illustrates how narrowly Raku defines “one thing”. (As does the use of different postcircumfix operators for positional and associative access, which most languages call indexing, and use one construct for, which may not even technically be an operator.)
But its not just freedom to create new operators that allows this; for it to work Raku has a huge number of built-in basic operators, plus the hyper- and meta-operators.
my @a = 1,2,3;
my @a;
@a.VAR.STORE((1,2,3));
As for separate positional and associative access:
Raku has separate positional and named arguments to functions.
An argument list is actually a singular thing called a Capture. Even if it usually pretends to not be.
my \capture = \( 'a', b => 10 ); # Capture litteral
say capture[0]; # a
say capture{'b'}; # 10
sub foo ( |capture ) {
say capture[0]; # a
say capture{'b'}; # 10
}
foo |capture; # give it the above capture litteral
# foo 'a', b => 10
sub bar ( $a, :$b ){
say $a; # a (positional)
say $b; # 10 (named)
}
bar |capture; # give it the above capture litteral
# bar 'a', b => 10
The same thing also applies to extracting information out of regexes
'a10' ~~ / (.) # $0
$<b> = (..) # $<b>
/;
say $0; # a
say $<b>; # 10
say $/[0]; # a (positional index into $/)
say $/{'b'}; # 10 (named index into $/)Of course, if we just use s-expressions, then there's no difference between operators and functions and this whole thing becomes moot. Although, with the caveat that your nice infix math expressions are still not nice infix math expressions. Then again, if we are using sexps, then we're likely using a language with macros and writing an infix macro for those mathy parts wouldn't be such a bad idea... ;-)
Maybe its hard to achieve absolute best performance, but I'm not arguing for that, I'm only arguing that operator overloading leads to better programmer ergonomics. I can benchmark and convert to optimised functions after I have it working nicely. Ergonomics first, optimisations after.
The problems I had read about applied to operations on larger matrices, where the difference between n^3 and n^2.5 or whatever becomes extremely noticeable, and makes it worth to write mulAndAdd(a, b, c) rather than a*b+c.
For example, there’s boost Spirit, a library to write parsers. You describe a grammar in something that looks a lot like a EBNF grammar (https://www.boost.org/doc/libs/1_67_0/libs/spirit/doc/html/s...)
Rust's ability for smart pointers to overload the dereference operator works pretty well, though there is still some potential for abuse.
Part of what makes it reasonable is the required function signature: It can only ever produce a reference to some other type, which rules out some of the crazier possibilities.
scala> 1 +: List(2, 3) ++: List(4, 5) :+ 6
res0: List[Int] = List(1, 2, 3, 4, 5, 6)
- Vectors, matrices
- Immutable containers (lists, sets, maps, etc.)
- Domain specific languages (regular expressions, constraint languages, etc.)
And without good support for matrices, the data science and ML people will just use Python instead of Java to build their libraries. And then everyone will use the language with the best libraries, even if they don't use matrix math in their code.
For regular expressions, you have to use a DSL embedded in Strings in Java instead of using operators like | as operator on regular expressions directly.
My programming experience is that that these "mathy" objects are about the only unambiguous use case for operator overloading. Given the limited use case, I'm not sure whether it's worth the added complexity for language designers.
I wrote the simulator engine code for CircuitLab (https://www.circuitlab.com/). We have complex numbers, sparse matrices, and extended-precision (more than a 64-bit double) floating point classes, all of which we use extensively within the simulation engine. Yes, it can be a bit annoying and verbose to do X.add(Y) instead of X+Y, but I tend to just leave an end-of-line comment to aid readability later. And this mathematical core code tends to be infrequently changed and well covered by tests.