Re: Order of multi sub definitions can resolve dispatch ambiguity

2021-09-24 Thread Brad Gilbert
This is intended behavior.

Since subsets are just code it would be difficult to impossible to
determine all of the ones that can match without actually running them all.
This would slow down every call that uses multiple subsets.

By most narrow candidate, it means by type. All subsets "of" the same type
are sorted by the order they are written.

The ambiguity it talks about is when two candidates have the same level of
type for a given input. For example Str and Int for an IntStr.


On Fri, Sep 24, 2021, 1:32 AM Joseph Brenner  wrote:

> This code uses multi dispatch with constraints that are ambiguous
> in a few cases, because there's some overlap in the lists of
> monsters and heroes: 'mothera' and 'godzilla'.
>
> my @monsters = < godzilla  mothera ghidora  gammera  golem
> wormface >;
> my @heroes   = < beowulf   bluebeetle  bernie   mothera  godzilla
> maynard_g_krebs >;
>
> subset Monster of Str where { $_ eq any( @monsters ) };
> subset Heroof Str where { $_ eq any( @heroes ) };
>
> ## Monster is favored over Hero because of the order of definition
> of these multi subs
> multi sub speak (Monster $m) {
> say "The monster, $m roars!";
> }
> multi sub speak (Hero $h) {
> say "The hero, $h shouts!";
> }
>
> speak('ghidora');  # The monster, ghidora roars!
> speak('beowulf');  # The hero, beowulf shouts!
> speak('mothera');  # The monster, mothera roars!
>
> I would've expected that in the case of 'mothera', this would
> error out unless an "is default" was added to one of the multi
> subs.  Instead the ambiguity is resolved by the order of
> definition: if you reverse the order of the "multi sub speak"s,
> then mothera is treated as Hero not Monster.
>
> This is not the behavior described in the documentation:
>
>  https://docs.raku.org/language/glossary#index-entry-Multi-Dispatch
>  Multi-dispatch§
>
>  The process of picking a candidate for calling of a set of
>  methods or subs that come by the same name but with different
>  arguments. The most narrow candidate wins. In case of an
>  ambiguity, a routine with is default trait will be chosen if
>  one exists, otherwise an exception is thrown.
>


Order of multi sub definitions can resolve dispatch ambiguity

2021-09-24 Thread Joseph Brenner
This code uses multi dispatch with constraints that are ambiguous
in a few cases, because there's some overlap in the lists of
monsters and heroes: 'mothera' and 'godzilla'.

my @monsters = < godzilla  mothera ghidora  gammera  golem
wormface >;
my @heroes   = < beowulf   bluebeetle  bernie   mothera  godzilla
maynard_g_krebs >;

subset Monster of Str where { $_ eq any( @monsters ) };
subset Heroof Str where { $_ eq any( @heroes ) };

## Monster is favored over Hero because of the order of definition
of these multi subs
multi sub speak (Monster $m) {
say "The monster, $m roars!";
}
multi sub speak (Hero $h) {
say "The hero, $h shouts!";
}

speak('ghidora');  # The monster, ghidora roars!
speak('beowulf');  # The hero, beowulf shouts!
speak('mothera');  # The monster, mothera roars!

I would've expected that in the case of 'mothera', this would
error out unless an "is default" was added to one of the multi
subs.  Instead the ambiguity is resolved by the order of
definition: if you reverse the order of the "multi sub speak"s,
then mothera is treated as Hero not Monster.

This is not the behavior described in the documentation:

 https://docs.raku.org/language/glossary#index-entry-Multi-Dispatch
 Multi-dispatch§

 The process of picking a candidate for calling of a set of
 methods or subs that come by the same name but with different
 arguments. The most narrow candidate wins. In case of an
 ambiguity, a routine with is default trait will be chosen if
 one exists, otherwise an exception is thrown.