Re: Order of multi sub definitions can resolve dispatch ambiguity

I'm not entirely sure what you're getting at with that example.
I was particularly interested in cases where there's some
ambiguity in multi-dispatch for particular values, where there's
some overlapping coverage between the prototypes.

Just for the hell of it, I'll stick another example at
the bottom of this message using numeric ranges this
time.

And it isn't exactly the way I *want* it to work, it's the way I
thought it was documented to work. I think I can see problems
with doing it either way:

If you use order-of-definition to resolve some of the difficult
cases, you have a situation where it can matter what order raku
has encountered the multi definitions.  Twiddling the order of
"use" lines could produce unexpected behavior... and there's some
risk of action-at-a-distance confusion: a new "use" line added in
a remote part of the code might effect the behavior of code you
thought you had working.

But if you give up on using order-of-definition, and the "is default"
tie-breaker is the only hint you have to resolve ambiguities,
what do you do if you've got ambiguity for different values in
*three* different cases?  If you make A "is default" to resolve
an ambiguity with B, what do you do about an ambiguity between B
and C?  You could apply "is default" to C, but that's no good if
you also had ambiguities between A and C.

(I think in practice I'd contrive some more complicated
subset/where checks that resolve the ambiguities before handing
it off to multi-dispatch...)

By the way, I don't see any reference to these sort of
things here:

   https://raku.org/archive/doc/design/apo/A12.html

I also don't see anything that exercises these cases here:

  roast/S12-subset/subtypes.t
  roast/S12-subset/multi-dispatch.t

And now Jonathan Worthington has announced that the new
Multi-dispatch mechanism is done... any bets on whether
any of this behavior will change?


As promised above, yet another example, this one using
overlapping numeric ranges via where clauses.  Here the
order of the multis resolves the ambiguous case "4":

  {
    multi sub check_range ( Int $n where {$_ > 3} ) {
        return "over 3";
    };
    multi sub check_range ( Int $n where {$_ < 5} ) {
        return "under 5";
    };
    say "2: ", check_range(2);  # 2: under 5
    say "7: ", check_range(7);  # 7: over 3
    say "4: ", check_range(4);  # 4: over 3
  }

  say "===";
  {
    multi sub check_range ( Int $n where {$_ < 5} ) {
        return "under 5";
    };
    multi sub check_range ( Int $n where {$_ > 3} ) {
        return "over 3";
    };
    say "2: ", check_range(2);  # 2: under 5
    say "7: ", check_range(7);  # 7: over 3
    say "4: ", check_range(4);  # 4: under 5
  }



On 9/25/21, Brad Gilbert <b2gills@gmail.com> wrote:
> On Sat, Sep 25, 2021 at 2:30 PM Joseph Brenner <doomvox@gmail.com> wrote:
>
>> > 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.
>>
>> I can see how there would be a big performance hit, but I haven't
>> yet turned up any reference to this behavior in the docs.  I
>> don't see anything to clue you in that subsets are an exception,
>> and I don't think there's anything about
>> order-of-definition-of-sub being a tie-breaker under any
>> circumstances.
>>
>
> The docs are not the definitive source of truth.
> They are at best an approximation.
>
>> By most narrow candidate, it means by type.
>>
>> If you'd said that to me, I'd still have expected it to work the
>> way that I did, because the way I look at it I'm creating new
>> types via subset.
>>
>
> By type I mean something that can be instantiated or subclassed.
> Subsets cannot do either of those two things.
> You can create a subset of a subset, but that is not the same thing.
>
>
>> > All subsets "of" the same type are sorted by the order they are
>> > written.
>>
>> Even if I'd figured that two subsets of Str were going to treated as Str,
>> I'd have expected an "Ambiguous call" error.
>>
>> If the two subsets are defined in different modules I suspect you
>> could get some strange behavior that would be hard to debug.
>> It's not always immediately obvious in what order two things were
>> defined.
>>
>
> Doing what you want would make using subsets with multis much less useful.
>
>     multi factorial ( 0 --> 1 ){}
>     multi factorial ( 1 --> 1 ){}
>     multi factorial ( UInt \n ){ factorial(n - 1) * n }
>
>     say factorial( 1 );
>     # ERROR: both UInt and 1 subsets match.
>
> You could modify the general case, but that is tedious and error prone.
>
>     multi factorial ( Int \n where {$_ >= 0 && $_ != 0 && $_ != 1} ){
> factorial(n - 1) * n }
>
> (The reason I didn't just do $_ >= 2 is that if another multi is added it
> should be dealt with in the same way as 0 and 1)
>
>
>> On 9/24/21, Brad Gilbert <b2gills@gmail.com> wrote:
>> > 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 <doomvox@gmail.com> 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 Hero    of 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 by Joseph Brenner
• Re: Order of multi sub definitions can resolve dispatch ambiguity by Brad Gilbert
• Re: Order of multi sub definitions can resolve dispatch ambiguity by Joseph Brenner
• Re: Order of multi sub definitions can resolve dispatch ambiguity by Joseph Brenner
• Re: Order of multi sub definitions can resolve dispatch ambiguity by Brad Gilbert
• Re: Order of multi sub definitions can resolve dispatch ambiguity by Joseph Brenner
• Re: Order of multi sub definitions can resolve dispatch ambiguity by Joseph Brenner