Description
Hi there :)
I came here, first, to gratulate and thank you for this project, it's awesome!
So, now to my proposal. π
Multiple dispatch solves the expression problem.
It does so in the way, that Douglas Crockford mentioned in his famous book "JavaScript: The good parts"
If there is a feature of a language that is sometimes problematic, and if it can be replaced with another feature that is more reliable, then always use the more reliable feature.
Multiple dispatch solves the guidance problem of polymorphism.
It also solves the problem of extending and changing code written with a single inheritance in mind. I consider this to be a very nice side-effect.
The traditional methods of polymorphism (traditional in the popular sense) often have disadvantages, and C++ is famous for misunderstanding Alan Kay's initial intention of the term "object orientation."
The community adopted a 'composition over inheritance' mindset quite a while ago.
The team around Julia found unease with the typical forms of polymorphism as it had already existed in popular languages that they used before; including C++.
As they were considering certain forms of it for their language, they found that it didn't work well with the kind of data and computation scientific data was represented, and they wanted to try something new.
And on the research about that, they found that the solution to that topic has been discovered already decades ago.
As it happens. π
This dispatch method's cleanness and semantic elegance are easily demonstrated, and programmers often see the benefits quite quickly.
The issue with its implementations was, that it had been always a sloth in the past. It was simply never fast enough to compete with other ways of polymorphism.
And so, other means of abstracting the polymorphistic way gained more traction.
Julia set out to change that.
There are also other implementations, one in C++, and the native ones in CL and Clojure as examples.
I am today here to introduce this idea to your project and encourage you to see this little presentation of Julia's Stefan Karpinski.
Recognize that the key factor is, that code sharing only improves dramatically when used as a primary language feature.
This is of importance when thinking about the synergy of solving the guidance problem.
Julia has no way of abstracting behavior beyond functions and multiple dispatch.
So, I think it's clear that this replaces all forms of polymorphism as the default choice (and it's important to communicate this as a cultural good, as otherwise some of the benefits are lost).
Happily, existing codebases can be adjusted.
There is still a small performance penalty in the C++ library that I shared.
Depending on the number of methods implemented, it drops in performance by around 15% - 30%, when compared to virtual calls.
Considering that virtual calls take around 1-2 cycles, and that some use cases like rendering and simulations call these open multi methods frequently, we would transpile to single dispatch, as is implemented today, with one unified syntax for all dispatches.
Also, optimizing the dispatch table by type erasure and lazily dispatching (and initializing) does make some difference.
Julias' implementation of monomorphic and bimorphic dispatch is comparable in cost to virtual calls in C++, although they are closed multi methods, as said (who are inherently a bit more performant, due to the dynamic lookup.
The proposed yomm2 solution can be extended at runtime.
The lookup cost for dynamic additions to the runtime table will always add a small overhead.
I think that it is worth, implementing a system, that allows to extension of the program with a plugin system. A science-oriented language like Julia does not need so much as a more general-purpose language like Cpp.
Julia does manage to use these techniques with numerical and scientific computation in high-performance scenarios.