5 ms·

A polyglot's guide to multiple dispatch – part 2

70 points by nikbackm 11y ago

StefanKarpinski 11y ago
part 1: https://news.ycombinator.com/item?id=11526923 https://news.ycombinator.com/item?id=11526923
Diederich 11y ago
Is this an example of what Mr. Bendersky is talking about? I believe so: https://github.com/perl6/book/blob/master/src/multi-dispatch.pod https://github.com/perl6/book/blob/master/src/multi-dispatch...
- eliben 11y ago
  For more context, you may want to check out the first part in the series: http://eli.thegreenplace.net/2016/a-polyglots-guide-to-multiple-dispatch http://eli.thegreenplace.net/2016/a-polyglots-guide-to-multi...
- Someone 11y ago
  No. That is overloading with single dispatch. You need multiple arguments for multiple dispatch (they can be implicit, as with the 'this' argument in C++, but they rarely, if ever, are because making one argument implicit makes it look as if the situation is asymmetric in the arguments, and that is exactly something multiple dispatch is not) Edit: oops. I didn't notice that the discussion went beyond the to-json example, which definitely is _not_ multiple dispatch. The discussion starting at the header Multiple arguments is about multiple dispatch.
  - arnsholt 11y ago
    Perl 6 dispatches on multiple arguments based on runtime types, so it's full multiple dispatch.
    - raiph 10y ago
      I thought that, while Perl 6 can dispatch based on runtime types, it does candidate resolution at compile-time for functions (and thus operators) and private methods. It only adds in run-time overhead for these cases if the code uses a run-time type construct. Am I wrong?
phunge 11y ago
Ooh Python! Check out https://github.com/mrocklin/multipledispatch https://github.com/mrocklin/multipledispatch which is a little more fleshed out than Guido's implementation. From the author of toolz and dask so you know it's good ;) I also find that multiple dispatch is something that's occasionally handy, but single dispatch is truly everywhere. I think if you broke down multipledispatch uses in languages which embrace it (e.g. CLOS), the mix is like 95% single, 5% >single. For single dispatch in python, check out https://docs.python.org/3/library/functools.html#functools.singledispatch https://docs.python.org/3/library/functools.html#functools.s... which was added in to the Python 3.4 stdlib. The alternative is the OOP subclassing style, which works but IMHO isn't very readable.
- raiph 10y ago
  MD in Perl 6 is beyond "occasionally handy". A glance at the Perl 6 setting modules[1] revealed something like a 50/50 break down of SD vs MD. Operators in Perl 6 are all MD, so that's likely a significant factor. Additionally it is well designed. While the functionality starting point was CLOS, the UX has the benefit of hindsight and a decade of non-stop language evolution. [1] https://github.com/rakudo/rakudo/tree/nom/src/core https://github.com/rakudo/rakudo/tree/nom/src/core
gajomi 11y ago
It a bit funny that the article doesn't mention Julia, which has native multimethods with all kinds of bells and whistles. It could be a nice addition to a "polyglot" flavored discussion. There is also Clojure, although its mechanism for multiple dispatch is a bit overpowered (you dispatch on values returned from a function of the arguments).
- eliben 11y ago
  Part 3 will talk about Common Lisp / CLOS which had multiple dispatch 20 years before Julia was conceived :-) Part 4 will talk about Clojure. I just couldn't put it all in one piece - even broken to chunks it's of formidable length
  - tanlermin 11y ago
    What do you think of Julia?
    - eliben 11y ago
      I don't think of Julia, to be honest
  - StefanKarpinski 10y ago
    Common Lisp has certainly had multiple dispatch for a long time. One important distinction, however, is that in CL generic functions are opt-in rather than the default. This means that most operations are not generic, limiting the extent to which you can extend things – basically only when some library author decided that you should be allowed to. Dylan and Julia both have functions which are generic by default, meaning that almost all functions can be extended. Another distinction is that while Common Lisp and Julia both have parametric types, in CL you cannot use multiple dispatch on parametric types. Since parametric types are a very useful for writing generic, reusable libraries, not being able to dispatch on them is a significant limitation. There's also the issue of performance. In Julia even something as basic as mixed-type addition – e.g. `1 + 2.5` – is defined in terms of layers of generic functions, but the compiler is clever enough to boil it down to a couple of machine instructions. This allows multiple dispatch to be used everywhere, which is really transformative. I'm not aware of any CL implementation which can eliminate the abstraction overhead of multimethods so completely. It seems a bit remiss to have a series on multiple dispatch and never mention the two languages – Dylan and Julia – that take the paradigm the furthest and most seriously.
ThatGeoGuy 11y ago
Although a bit less interesting than part 1 IMO, I think it's still a really good read, especially the point: However, as we've seen here there are several variations on the multiple dispatch scheme, and each requires slightly different implementation considerations. This is interesting, and probably pretty important, especially if you're considering using Multiple Dispatch (MD) in a code base yourself. One of the advantages of CLOS-style MD is that it is built in, and usually covers your MD needs for 99%+ of cases (from what I've seen, at least). Looking forward to part 3 next week Eli!

70 points by nikbackm 11y ago

part 1: https://news.ycombinator.com/item?id=11526923 https://news.ycombinator.com/item?id=11526923

Is this an example of what Mr. Bendersky is talking about? I believe so: https://github.com/perl6/book/blob/master/src/multi-dispatch.pod https://github.com/perl6/book/blob/master/src/multi-dispatch...

eliben 11y ago
For more context, you may want to check out the first part in the series: http://eli.thegreenplace.net/2016/a-polyglots-guide-to-multiple-dispatch http://eli.thegreenplace.net/2016/a-polyglots-guide-to-multi...
Someone 11y ago
No. That is overloading with single dispatch. You need multiple arguments for multiple dispatch (they can be implicit, as with the 'this' argument in C++, but they rarely, if ever, are because making one argument implicit makes it look as if the situation is asymmetric in the arguments, and that is exactly something multiple dispatch is not) Edit: oops. I didn't notice that the discussion went beyond the to-json example, which definitely is _not_ multiple dispatch. The discussion starting at the header Multiple arguments is about multiple dispatch.
- arnsholt 11y ago
  Perl 6 dispatches on multiple arguments based on runtime types, so it's full multiple dispatch.
  - raiph 10y ago
    I thought that, while Perl 6 can dispatch based on runtime types, it does candidate resolution at compile-time for functions (and thus operators) and private methods. It only adds in run-time overhead for these cases if the code uses a run-time type construct. Am I wrong?

phunge 11y ago

Ooh Python! Check out https://github.com/mrocklin/multipledispatch https://github.com/mrocklin/multipledispatch which is a little more fleshed out than Guido's implementation. From the author of toolz and dask so you know it's good ;) I also find that multiple dispatch is something that's occasionally handy, but single dispatch is truly everywhere. I think if you broke down multipledispatch uses in languages which embrace it (e.g. CLOS), the mix is like 95% single, 5% >single. For single dispatch in python, check out https://docs.python.org/3/library/functools.html#functools.singledispatch https://docs.python.org/3/library/functools.html#functools.s... which was added in to the Python 3.4 stdlib. The alternative is the OOP subclassing style, which works but IMHO isn't very readable.

raiph 10y ago
MD in Perl 6 is beyond "occasionally handy". A glance at the Perl 6 setting modules[1] revealed something like a 50/50 break down of SD vs MD. Operators in Perl 6 are all MD, so that's likely a significant factor. Additionally it is well designed. While the functionality starting point was CLOS, the UX has the benefit of hindsight and a decade of non-stop language evolution. [1] https://github.com/rakudo/rakudo/tree/nom/src/core https://github.com/rakudo/rakudo/tree/nom/src/core

gajomi 11y ago

It a bit funny that the article doesn't mention Julia, which has native multimethods with all kinds of bells and whistles. It could be a nice addition to a "polyglot" flavored discussion. There is also Clojure, although its mechanism for multiple dispatch is a bit overpowered (you dispatch on values returned from a function of the arguments).

eliben 11y ago
Part 3 will talk about Common Lisp / CLOS which had multiple dispatch 20 years before Julia was conceived :-) Part 4 will talk about Clojure. I just couldn't put it all in one piece - even broken to chunks it's of formidable length
- tanlermin 11y ago
  What do you think of Julia?
  - eliben 11y ago
    I don't think of Julia, to be honest
- StefanKarpinski 10y ago
  Common Lisp has certainly had multiple dispatch for a long time. One important distinction, however, is that in CL generic functions are opt-in rather than the default. This means that most operations are not generic, limiting the extent to which you can extend things – basically only when some library author decided that you should be allowed to. Dylan and Julia both have functions which are generic by default, meaning that almost all functions can be extended. Another distinction is that while Common Lisp and Julia both have parametric types, in CL you cannot use multiple dispatch on parametric types. Since parametric types are a very useful for writing generic, reusable libraries, not being able to dispatch on them is a significant limitation. There's also the issue of performance. In Julia even something as basic as mixed-type addition – e.g. `1 + 2.5` – is defined in terms of layers of generic functions, but the compiler is clever enough to boil it down to a couple of machine instructions. This allows multiple dispatch to be used everywhere, which is really transformative. I'm not aware of any CL implementation which can eliminate the abstraction overhead of multimethods so completely. It seems a bit remiss to have a series on multiple dispatch and never mention the two languages – Dylan and Julia – that take the paradigm the furthest and most seriously.

ThatGeoGuy 11y ago

Although a bit less interesting than part 1 IMO, I think it's still a really good read, especially the point: However, as we've seen here there are several variations on the multiple dispatch scheme, and each requires slightly different implementation considerations. This is interesting, and probably pretty important, especially if you're considering using Multiple Dispatch (MD) in a code base yourself. One of the advantages of CLOS-style MD is that it is built in, and usually covers your MD needs for 99%+ of cases (from what I've seen, at least). Looking forward to part 3 next week Eli!