And std::variant is now a better choice for cases like in the article above, where previously inheritance was used to represent a closed set of possible subtypes.
Where "now" means C++17 or C++20 depending on whether or not you understand what INVOKE<R> semantics are?
TIL that std::visit supports multiple variants. How new is that ?
Always did, as far as I know. Never knew why...
This is a nice illustration of the expression problem, which the article itself points out toward the end. Multiple dispatch is a language-level way to solve it. Crafting Interpreters [1] has a very approachable Java-based chapter that also covers these patterns in detail.
if only programmers cared about functionality as much as syntax we'd be living in a lisp heaven
You need some sort of critical majority that cares about deeper aspects of whatever (over superfice) or else everyone focuses on superfice, as that's what all the public debates are about.
But lacking that, lisp could improve its syntax (did that, BTW not hard, just added some containers and a few standard infix operators, which all compile to lists).
As I know C++ now allows multiple dispatch for std::variant: https://en.cppreference.com/w/cpp/utility/variant/visit2.htm....
And std::variant is now a better choice for cases like in the article above, where previously inheritance was used to represent a closed set of possible subtypes.
Where "now" means C++17 or C++20 depending on whether or not you understand what INVOKE<R> semantics are?
TIL that std::visit supports multiple variants. How new is that ?
Always did, as far as I know. Never knew why...
This is a nice illustration of the expression problem, which the article itself points out toward the end. Multiple dispatch is a language-level way to solve it. Crafting Interpreters [1] has a very approachable Java-based chapter that also covers these patterns in detail.
[0] https://en.wikipedia.org/wiki/Expression_problem
[1] https://craftinginterpreters.com/representing-code.html
if only programmers cared about functionality as much as syntax we'd be living in a lisp heaven
You need some sort of critical majority that cares about deeper aspects of whatever (over superfice) or else everyone focuses on superfice, as that's what all the public debates are about.
But lacking that, lisp could improve its syntax (did that, BTW not hard, just added some containers and a few standard infix operators, which all compile to lists).
Thanks for posting this!
Just a quick note that this post is the first in a series: see https://eli.thegreenplace.net/tag/multiple-dispatch for the full series
Would have been nice to mention that it's one thing that Julia seem to have gotten right.
It's a series of articles, Julia is (briefly) mentioned in Part 3.
Cue the smug Common Lisp weenies...
Oh, wait, that's me :-)
Part 3 of this series discusses Common Lisp - https://eli.thegreenplace.net/2016/a-polyglots-guide-to-mult...
Huh, that is cleaner than a giant pattern match. It would be nice to have this at work, I know exactly how I’d use it...
Oh no, this is how lisp ruins people, isn’t it.
don't worry. the Julia peeps can also be smug about this (as one)
To your point, I assume the "polyglot" part was referring to the arguments this would spawn in the comment section
Diligent Dylan hackers sound off!
...
...
...
Bueller?