# New Ticket Created by jn...@jnthn.net
# Please include the string: [perl #63286]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=63286 >
Moritz Lenz wrote:
> Parrot r36678, Rakudo 0f87695c:
>
> class Scissor { };
> class Paper { };
> class Stone { };
>
> multi wins(Scissor $x, Paper $y) { 1 };
> multi wins(Paper $x, Stone $y) { 1 };
> multi wins(Stone $x, Scissor $y) { 1 };
> multi wins(::T $x, T $y) { 0 };
> multi wins($x, $y) { -1 };
>
> say wins(Scissor.new, Paper.new);
> # dies with 'Null PMC access in find_method()'
> say wins(Paper.new, Paper.new);
> # same, if moved further up
> say wins(Stone.new, Paper.new);
>
>
I think that's related to any lexically scoped thingy declared in the
signature and used during the type check.
> I think this is also a bug, not 100% sure though:
>
> ./perl6 -e 'multi f(::T $x, T $y) { "first" }; multi f(Int $x, Num
> $y) { "second" }; say f(1, 2)'
> # output: second
>
>
It's not. We do the sorting on what we statically know the types to be
(for some definition of statically, but the heart of it is "independent
of any particular call"). The type T that we capture is known on a
per-call basis, and as such we check it as a constraint, but it isn't a
part of the candidate sorting process. So at the candidate sorting level
it's like a :(Any, Any).
> P.S.: it would be nice if this bug could be fixed quickly, since I want to
> use this code in an article for a fairly big IT magazine, and the submission
> deadline is end of February. So if you fix this soon, we'll get lots of good
> publicity cookies ;-)
>
>
I'll try and do that - will see how my initial idea for the fix goes. It
just involves dealing with continuations, which is a little scary,
especially when there's C boundary issues...all quite a brain ache.
Thanks,
Jonathan
