From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Tue, 15 Mar 2005 08:52:38 +0100
Bob Rogers <[EMAIL PROTECTED]> wrote:
> What if one wants the first and third arguments to be the invocants?
> Then the first syntax gives
> .sub foo @MULTI
> .invocant Integer a
> .param pmc b
> .invocant String c
That should better be
> .sub foo @MULTI
> .invocant Integer a
> .invocant pmc b
> .invocant String c
Invocants are positional arguments, there isn't a case where the first
and the third are invocants in a Perl6 function signature. It of course
boils down to the same, namely that the second argument is a wildcard
(Perl6 Any) but it's for the dispatcher nethertheless a dispatch on
three invocants.
Thanks for clearing that up. (FWIW, your answer accords well with my
personal biases, too. ;-)
> . . .
> In that case the first syntax strikes me as cleaner . . .
I'm not sure. But there is still another thingy. A12 allows multiple
colons to separate invocant "classes". If there is a tie, the secondary
invocants are used as tie breakers, which could be written as:
.sub foo multi(Integer, pmc: String)
.param pmc a
.param pmc b
.param pmc c
- try to dispatch on the first two types in the first place
- if there is a tie, consider the type of the 3rd argument
leo
I've only read half of A12 by now, and am still digesting what I've read
(and that may take a while), but the section headed "multi sub *
(tradition multimethods)" seems to say that the dispatcher never
considers anything after the last colon. So perhaps you meant:
.sub foo multi(Integer, pmc: String:)
.param pmc a
.param pmc b
.param pmc c
Or is that wrong?
The next question is, what happens if you define a method with the
"long name":
.sub bar multi(Integer, Float: Float)
and I define one with
.sub bar multi(Integer: String, Integer)
That would mean that the "long names" have different "name length" in
this case. It seems to me that can't work, but if A12 rules it out, I
couldn't find it.
If this is supposed to work, then how should MMD handle disagreement
about invocant groups? And if the answer is simply to ignore it, and
treat each method independently, doesn't this screw up the distance
metric? The distance to your method will be computed on the first two
values, whereas the distance to mine will be computed on only the first,
so the two distances will be incommensurable, true?
TIA,
-- Bob Rogers
http://rgrjr.dyndns.org/
