The idea here is that you can have an opaque interface. Then, adding new implementations of that interface is very easy. But, if you want to extend the interface, you need to modify all of the existing implementations. Multiple dispatch suffers of this problem just as much as single dispatch.
In the other case, you have a transparent interface - anyone can build code based on your data type. But, if you add more cases to your data type, anyone who had functionality built on it needs to take into account the new cases.
I think that this is in inherently an unavoidable problem. You can of course expose both kinds of constructs in your language, but you can't make interface implementation easily modifiable, and you can't make sum types easily extensible. The programmer ultimately has to choose the one that they believe will best capture the domain and its probable evolution.
What multiple dispatch can do is take some cases where sum types are obviously preferable to single dispatch (operations on related objects) and apply the interface abstraction to those cases as well (without reaching for horrible solutions like the visitor pattern).
Edit: thinking a bit more about the article, what they are showing is that you can essentially use the visitor pattern (and multiple dispatch) to implement GADTs instead of using them for regular multiple dispatch with inheritance. Basically, you can use them bring completely disparate types under the same umbrella, just like a GADT. I'm not sure that this still allows subtyping of that GADT as if it were a regular class.
You would need to add the required implementations, but there's really no way around that since the logic has to go somewhere.
And as soon as you start actually dispatching on multiple arguments, using sum types to solve the same prolem quickly turns into spaghetti.
Sure there is. If I have a function that takes a Foo and a Bar, and it calls a generic method on them, the generic method must have methods that cover the real subtypes of Foo and Bar. If someone had created subtypes of Foo and Bar and defined methods on all the generic methods that they knew about, and now you create a new generic method, you have absolutely broken the interface just as much as adding a new method to Iterable in Java.
Assuming you're running a version of Java that supports default implementations, which may often be used to avoid breaking the interface.
Sum types are a different story, as you would have to dive into existing code.
It does, more or less, since any subtype will have to implement the "accept" method for the visitor, which has been defined to only 'accept' the values that can be represented by the GADT. Any subtype will need to define how its possible values map to that of the supertype.
Here is an example: https://github.com/rust-lang/regex/blob/master/regex-syntax/...
The article's concern is real but overstated in my opinion. When adding a new function in a hierarchy you'll either have a good default or you'll be implementing via type matching branches or 10 implementations in each type behind multiple dispatch.
The difference, to me, is minimal.
This is incorrect. C++ and Java are typical examples of languages that lack multiple dispatch, but are able to emulate it using the visitor pattern, as tsimionescu already mentioned.
https://en.wikipedia.org/wiki/Multiple_dispatch#Emulating_mu...
My bad!
Java, Python and C++ require Visitor machinery that you ahev to write, for each case, to implement multiple dispatch (and Visitor only works for double dispatch, if you want more than 2 arguments you need even more boilerplate). Julia and CLOS essentially have that machinery built in.
In case this is not clear, multiple dispatch refers to choosing which method implementation to call based on the specific runtime subtypes of all function arguments, not just the runtime type of `this` (which is all that Java, C++, and even Python can dispatch based on). It's basically like applying C++ function overloading rules at runtime.
> The article's concern is real but overstated in my opinion. When adding a new function in a hierarchy you'll either have a good default or you'll be implementing via type matching branches or 10 implementations in each type behind multiple dispatch.
That's assuming you can modify all existing implementations. If you can't (e.g. if you wanted to modify Iterable to add a new method) then the solution is just.. don't do that. Note that the article also doesn't offer a solution - they're just showing that multiple dispatch can be used to implement a different construct with different limitations (GADTs).
we're in 2020
using value = std::variant<int, float, string>;
void foo(value a, value b, value c) {
struct {
void operator(int, float, string) { }
void operator(float, int, string) { }
void operator(float, string, int) { }
///... etc...
} visitor;
std::visit(visitor, a, b, c);
}
More importantly, this is not as powerful as true multiple dispatch like in CLOS. There is no way to call other methods, there is no way to specialize partially (e.g. combine the variant with subtypes, and define methods only for some combinations of subtypes and super types on the parameters, and allow the implementation to choose the most specific one).
Edit: to add a few more details on my second point. CLOS (and I assume Julia too) allows you to call 'parent' implementations from a child implementation, similar to calling base type methods in virtual dispatch - you can call the next-most-specific method that would have matched the params, which you can't with the visitor. Also, say I have a generic function F(Foo, Bar). I could define methods for F(FooSubtype1, Bar) and F(Foo, BarSubtype1), and then call F(FooSubtype1() , BarSubtypeOfSubtype1() ) and have the right implementation get called (F(Foo, BarSubtype1)).
It's far from the same thing though, less convenient and less flexible.
Multiple dispatch doesn't require a centralized declaration of the possible types and allows putting implementations in different files.
It didn't take us long. Schemers did multiple dispatch at least 40 years ago. SICP explains how to do it.
(Arguably, both R and Julia are Lisp dialects under the hood, just disguised behind a more arcane syntax. Which goes to show that 'practioners' take Lisp seriously exactly as long as they don't know it's Lisp.)
I have a friend who is like this, looked at some Rust code, saw closures with bars instead of parentheses and practically disregarded it on the spot. Took a lot of convincing that they wouldn’t notice after 15 minutes of actually using the language, and what do you know, I was right.
[1] https://link.springer.com/chapter/10.1007/978-3-540-24851-4_...
It's kind of both.
Julia has types on bindings, in that sense it is statically typed.
Also other answers have some good information, ie:
" (...) It can also be useful to indicate the argument types to restrict the kind of parameters passed when calling. Our function header for floating point numbers would then look as function mult(x::Float64, y::Float64). When we call this function with mult(5, 6), we receive an error, ERROR: 'mult' has no method matching mult(::Int64, ::Int64 ), proving that Julia is indeed a strongly typed language. It does not accept integer parameters for the floating point arguments. (...) "
...in other words saying that "Julia is dynamic langauge, full stop." doesn't answer the question fully as for many readers it implies "weak typing", however it's dynamic, but strongly-typed, with state of art optimisations available as in statically typed languages, with proper multiple dispatch on all arguments (not single/this dispatch as in ie. java) etc.
It is definatelly worth playing with the language for people who hesiate on learning it - Julia provides some very interesting features not seen anywhere else.
- In a FP language you can add a new function to an existing datatype just by adding a function. But, if you want to add a new case, you have to add the constructor and modify all the functions that use the datatype, which means modifying a lot of files and recompiling most of the program.
(...)"
...and by using multiple dispatch (as in Julia) you can do both. And it just works. True code reuse. Why did it take us so long to recognise this?