The multi infix:<+>( \a, \b ) candidate is the one that accepts non Numeric
values.
What it does is try to convert the two values into Numeric ones, and then
redispatch using those values.
If either one produces an error instead of a Numeric, that error is passed
along.
On Mon, Aug 30, 2021 at 9:30 AM Ralph Mellor
wrote:
> On Sun, Aug 22, 2021 at 4:59 PM yary wrote:
> >
> > "How would you know what types are compatible for a particular
> operation?"
> >
> > inspecting a routine's arguments.
>
> Bingo.
>
> > The first couple candidates raise questions for me
> >
> > multi($x = 0) - how is there a single-arg candidate for an infix
> operator?
>
> It's a really nice design for expressing what to do in situations like
> this:
>
> ```
> say infix:<+>(42); # 42
> my @numbers = 99;
> say [+] @numbers; # 99
> ```
> Similarly there are zero parameter candidates to cover zero arg cases:
> ```
> say infix:<+>(); # 0
> my @numbers;
> say [+] @numbers; # 0
> ```
>
> See https://en.wikipedia.org/wiki/Identity_function for the related
> concept
> used in mathematics. Raku uses these zero/one parameter signatures to
> provide a clean general solution to the general problem of what to do if an
> infix operator is passed less than two arguments.
>
> > multi(\a, \b) - does this accept everything, is it a "cleanup"
> > candidate for error reporting?
>
> It accepts any call with two arguments (as is the case for most
> calls) if none of the other two parameter signatures match.
>
> My guess would be that it's for error reporting. (Ideally one would
> be able to call `.WHY` on that candidate to see why it was written,
> in this case to see if it was for error reporting.)
>
> > I'm curious about how some candidates bind to bare names
> > \a, \b while others use sigilled variables, I'm assuming that's
> > due to the original programmer's style preference.
>
> A sigil implies some (rudimentary) type information. For example,
> an `@` implies `Positional`, which is pretty generic but not entirely
> so. Then there is of course the ultimate generic sigil, namely `$`.
>
> But while it is indeed *very* generic, it still implies some rudimentary
> type information that isn't 100% generic. For one thing, it hints that
> the value it's bound to probably *isn't* `Positional` or `Associative`.
> (Otherwise, why didn't they use `@` or `%`?) For another, it allows
> traits to be applied that add other dimensions of type information.
>
> Consider this code:
> ```
> multi foo (\a) { say a }
> multi foo ($ is rw) { say '$' }
> multi foo (@) { say '@' }
> multi foo (%) { say '%' }
>
> foo @; # @
> foo %; # %
> foo $; # $
> foo 42; # 42
> ```
>
> Slashing the sigil out removes any ambiguity (or, if you prefer,
> *maximizes* the ambiguity) of what a variable is bound to. It could
> be bound to *anything* -- `Positional`, `Associative`, or otherwise.
> So slashing the sigil -- `\foo` -- jumps out as being somehow even
> more generic than using `$`.
>
> --
> raiph
>
