Join GitHub today
Operator overloading #2
Operator overloading is viewed quite reasonably with skepticism.
The first is being able to build a user interface to a tool like TensorFlow in neugram that is as compelling (or more) as the standard python user interface. This involves performing a series of arithmetic operations on objects that build up a model of a program to execute.
The second is support for matrices. Not only a single, fixed in-memory model for matrcies, but large sparse matrices, or matrices that exist in GPU memory and whose operations need to be batched and communicated to a different program.
Both of these problems require arithmetic and indexing operations backed by arbitrary computation. Operator overloading can do this.
Any type can have specifically-named methods the type checker will notice and use to implement operations on those types. Critically, named interfaces can also have these operator methods.
(The first comment of this issue is kept up-to-date with the current proposal.
Some more thinking about this. I no longer see why the methods should be obscure names. In fact, they could be the most obvious names. It would be nice if the operator overloading "just worked" for the gonum matrix types.
would translate into
(With the similar
The arithmetic operators are trickier. In gonum the concrete types implement methods that yield the interfaces:
There are two points here. Firstly, this is an in-place modification method. The problem is then to compile
Secondly, and more importantly, the gonum mat64 package does not define this method on the Matrix type. It avoids it for a good reason, a Matrix is not necessarily mutable. But that means we cannot do a static analysis of the multiply. We could do the analysis dynamically, but that means we have to successfully compile all sorts of wishy-washy code and see the failures at runtime.
Concretely, if mat64.Matrix defined what we needed statically, that is:
Then the Neugram code:
would compile into the equivalent Go:
But if we were to support the Matrix type without the Mul on it (but on many of the concrete implementations) then the
Gross. I think for now this is off the table.
All of which is unfortunate, because it means the gonum mat64 package won't really work out of the box.