Hey all,

I was surprised to learn yesterday that D does not actually
support Multiple-Dispatch, also known as Multimethods. Why is
this? Support for this feature is already present in Scala, C#
4.0, Groovy, Clojure, etc... Would it not make sense for D to
remain competitive in this regard?

While I think many of us are aware that problems of the nature
that require Multiple-Dispatch can be approached with the Visitor
Pattern, there seems to be a general consensus that the Visitor
Pattern is pretty cumbersome and boilerplate-heavy, and thus
should be avoided.

The common response from my searching around seems to be that a
template-based, static implementation of Multiple-Dispatch is the
go-to solution in D, but considering the existing template-bloat
issues we have, I can't help but wonder if language support for
this feature might be a better path to go down. Seems like it
wouldn't be too difficult to implement, although I've not looked
very deeply into dmd's source-code.

So what seems to be the situation here?

Cheers,
Aero

Aerolite:

> I was surprised to learn yesterday that D does not actually
> support Multiple-Dispatch, also known as Multimethods. Why is
> this? Support for this feature is already present in Scala, C#
> 4.0, Groovy, Clojure, etc... Would it not make sense for D to
> remain competitive in this regard?

I think a hypothetical way for D to become more competitive is to have less OOP ;-) D things like onCmp() for classes are ugly and not easy to write correctly. Perhaps Rust solves (avoids) such problems better, and with much less complexity (but Rust will have other problems of course, like the excessive amount of type inference, because no one designs very good languages).

Bye,
bearophile

On Sunday, 24 August 2014 at 23:42:51 UTC, Aerolite wrote:
> Hey all,
>
> I was surprised to learn yesterday that D does not actually
> support Multiple-Dispatch, also known as Multimethods. Why is
> this? Support for this feature is already present in Scala, C#
> 4.0, Groovy, Clojure, etc... Would it not make sense for D to
> remain competitive in this regard?
>
> While I think many of us are aware that problems of the nature
> that require Multiple-Dispatch can be approached with the Visitor
> Pattern, there seems to be a general consensus that the Visitor
> Pattern is pretty cumbersome and boilerplate-heavy, and thus
> should be avoided.
>
> The common response from my searching around seems to be that a
> template-based, static implementation of Multiple-Dispatch is the
> go-to solution in D, but considering the existing template-bloat
> issues we have, I can't help but wonder if language support for
> this feature might be a better path to go down. Seems like it
> wouldn't be too difficult to implement, although I've not looked
> very deeply into dmd's source-code.
>
> So what seems to be the situation here?

At this point, if something can be implemented in a library rather than in the language, the odds are low that it will be solved in the language. The language is very powerful and already a bit complicated, so usually the response for questions like this is that we'll take advantage of D's existing features to implement the new feature rather than complicating the language further. If you could come up with a very good reason why it had to be in the language, then maybe it would happen, but my guess is that that's not likely to happen.

- Jonathan M Davis

On Sunday, 24 August 2014 at 23:42:51 UTC, Aerolite wrote:
> So what seems to be the situation here?

Hi Aerolite,

I've never used multiple dispatch in any language, but from looking at the C# syntax here[1]:

> ReactSpecialization(me as dynamic, other as dynamic);

You should be able to implement multiple dispatch yourself, using the getOverloads trait, using this (or a similar) syntax:

> dynamic!ReactSpecialization(me, other);

  [1]: http://blogs.msdn.com/b/shawnhar/archive/2011/04/05/visitor-and-multiple-dispatch-via-c-dynamic.aspx

On Monday, 25 August 2014 at 00:20:26 UTC, Vladimir Panteleev wrote:
>> dynamic!ReactSpecialization(me, other);

Here's a very basic implementation:

http://dpaste.dzfl.pl/5150ca9c13f4

Idan Arye is also working on functional pattern matching for object references:

https://github.com/D-Programming-Language/phobos/pull/1266

On Monday, 25 August 2014 at 00:08:25 UTC, Jonathan M Davis wrote:
> On Sunday, 24 August 2014 at 23:42:51 UTC, Aerolite wrote:
>> Hey all,
>>
>> I was surprised to learn yesterday that D does not actually
>> support Multiple-Dispatch, also known as Multimethods. Why is
>> this? Support for this feature is already present in Scala, C#
>> 4.0, Groovy, Clojure, etc... Would it not make sense for D to
>> remain competitive in this regard?
>>
>> While I think many of us are aware that problems of the nature
>> that require Multiple-Dispatch can be approached with the Visitor
>> Pattern, there seems to be a general consensus that the Visitor
>> Pattern is pretty cumbersome and boilerplate-heavy, and thus
>> should be avoided.
>>
>> The common response from my searching around seems to be that a
>> template-based, static implementation of Multiple-Dispatch is the
>> go-to solution in D, but considering the existing template-bloat
>> issues we have, I can't help but wonder if language support for
>> this feature might be a better path to go down. Seems like it
>> wouldn't be too difficult to implement, although I've not looked
>> very deeply into dmd's source-code.
>>
>> So what seems to be the situation here?
>
> At this point, if something can be implemented in a library rather than in the language, the odds are low that it will be solved in the language. The language is very powerful and already a bit complicated, so usually the response for questions like this is that we'll take advantage of D's existing features to implement the new feature rather than complicating the language further. If you could come up with a very good reason why it had to be in the language, then maybe it would happen, but my guess is that that's not likely to happen.
>
> - Jonathan M Davis

Speaking of library solutions, I checked with my `castSwitch` PR and it managed to implement single-argument multi-dispatch:

https://github.com/D-Programming-Language/phobos/pull/1266#issuecomment-53217374

I'll try to get it to support multiple arguments(shouldn't be that hard) and then all we'll need is a simple wrapper to have our very own library implemented single dispatch.

I'm thinking we'll want two versions - a regular templated function like in Vladimir's reply, and also a template mixin that can take a bunch of methods with the same name(or annotated with a UDA) and create a multi-method of them.

These wrappers will be another PR, but they can be based on `castSwitch` for it's somewhat-optimized type-comparison implementation.

On Monday, 25 August 2014 at 00:36:40 UTC, Vladimir Panteleev wrote:
> On Monday, 25 August 2014 at 00:20:26 UTC, Vladimir Panteleev wrote:
>>> dynamic!ReactSpecialization(me, other);
>
> Here's a very basic implementation:
>
> http://dpaste.dzfl.pl/5150ca9c13f4
>
> Idan Arye is also working on functional pattern matching for object references:
>
> https://github.com/D-Programming-Language/phobos/pull/1266

And here I was struggling to think of a way to efficiently check a tuple against a typetuple, neglecting to recall the rarely used continue-to-label...

Thanks! I'm gonna borrow that idea for `castSwitch`.

On Monday, 25 August 2014 at 00:08:25 UTC, Jonathan M Davis wrote:
>
> At this point, if something can be implemented in a library rather than in the language, the odds are low that it will be solved in the language. The language is very powerful and already a bit complicated, so usually the response for questions like this is that we'll take advantage of D's existing features to implement the new feature rather than complicating the language further. If you could come up with a very good reason why it had to be in the language, then maybe it would happen, but my guess is that that's not likely to happen.
>
> - Jonathan M Davis

I definitely get that, and it's the right idea given how powerful
the language is as it stands. :)

With respect to something like Multiple-Dispatch though, this
seems like something that, conceptually at least, should really
be below the library layer. A library solution in this regard is
tantamount to writing virtual method handling as a library
solution, which is obviously crazy talk.

While I understand the strong desire feature-freeze the language
itself (I want the same thing!), I really think this feature is
one we can get at the language level without any real structural
change (i.e. this doesn't seem like something we'd need any extra
syntax for - only a semantic change).

So, to weigh up the pros and cons of each implementation strategy:

Language implementation:
- Pros:
-- No syntax modification (unless you want the feature to be
optional)
-- Extremely low likely-hood of it being a breaking change (no
one really writes functions/methods that could take advantage of
this, currently)
-- Potentially transparent to non-users
-- Potentially faster builds (just resolve the actual type for
each *class parameter*, instead of doing what would likely be a
fair few template expansions)
-- Less code bloat (see above)
-- Overall, shouldn't be very difficult to implement
- Cons:
-- Yet another step away from a language feature freeze
-- We can emulate this with templates
-- Potential for slower builds in large projects that have no
need of it (unless it's optional, but that would likely require
syntactical changes or a new attribute)
-- However small, there's still the possibility that it might
break existing code

Template / library implementation:
- Pros:
-- No changes to the language syntax or spec
-- No chance of any breaking changes
-- No potential build-speed impact for those who don't require it
- Cons:
-- Template bloat (which, as I understand it, is already a
significant issue)
-- Potentially large build-speed impact, depending on
implementation and project size
-- Doesn't scale nicely to run-time dispatch (although I can't
think of a situation where this would actually be a problem)
-- Conceptually the entirely wrong place for this kind of feature
(see virtual method comment above, although this could be
considered subjective)

Just going off that (unless I'm wrong, or have missed something),
a language implementation seems like it would actually be the
best option.

TL;DR:
This isn't a feature that conceptually belongs at the library
level, and a language implementation has the potential to be
transparent to non-users, lessens code-bloat, and would ideally
require only a small semantic change that almost no one would be
negatively affected by.

Also, looking at things from a very vain, marketing perspective,
it'd be a nice little thing to add to the 'Power' section on the
homepage! :P

On Monday, 25 August 2014 at 00:20:26 UTC, Vladimir Panteleev
wrote:
> On Sunday, 24 August 2014 at 23:42:51 UTC, Aerolite wrote:
>> So what seems to be the situation here?
>
> Hi Aerolite,
>
> I've never used multiple dispatch in any language, but from looking at the C# syntax here[1]:
>
>> ReactSpecialization(me as dynamic, other as dynamic);
>
> You should be able to implement multiple dispatch yourself, using the getOverloads trait, using this (or a similar) syntax:
>
>> dynamic!ReactSpecialization(me, other);
>
>   [1]: http://blogs.msdn.com/b/shawnhar/archive/2011/04/05/visitor-and-multiple-dispatch-via-c-dynamic.aspx

Yep, very true. In fact I was looking at doing something like
this for the project I'm working on! :)

I just can't help but think that really, such a feature should be
at the language level. Naturally though, I do understand the want
and need to feature-freeze the language, and if the community
feels the effort outweighs the gain in this regard, so be it.

On Monday, 25 August 2014 at 00:42:41 UTC, Idan Arye wrote:
> Speaking of library solutions, I checked with my `castSwitch` PR and it managed to implement single-argument multi-dispatch:
>
> https://github.com/D-Programming-Language/phobos/pull/1266#issuecomment-53217374
>
> I'll try to get it to support multiple arguments(shouldn't be that hard) and then all we'll need is a simple wrapper to have our very own library implemented single dispatch.
>
> I'm thinking we'll want two versions - a regular templated function like in Vladimir's reply, and also a template mixin that can take a bunch of methods with the same name(or annotated with a UDA) and create a multi-method of them.
>
> These wrappers will be another PR, but they can be based on `castSwitch` for it's somewhat-optimized type-comparison implementation.

Damn, that is really nice! I was wondering when we'd see
something like this make its way into the standard library. :)