# New Ticket Created by
# Please include the string: [perl #131785]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=131785 >
Greetings!
I have written a module to process some numeric data types and found
that the run time will loop.
Here is minimal code for the module:
use v6.c;
unit module test1;
our package EXPORT::DEFAULT { # export classes, sub etc.
class Fpa does Numeric {
has UInt $.var is rw = 0;
}
multi infix:<+> ( Fpa:D $left, Fpa:D $right --> Fpa ) is equiv(
&infix:«+» ) {
say "here 1!";
return my $newFpa = fpaAdd( $left, $right );
}
multi infix:<+> ( Any:D $left, Fpa:D $right --> Fpa ) is equiv(
&infix:«+» ) {
say "here 2!";
return my $newFpa = fpaAdd( $left, $right );
}
multi infix:<+> ( Fpa:D $left, Any:D $right --> Fpa ) is equiv(
&infix:«+» ) {
say "here 3!";
return my $newFpa = fpaAdd( $left, $right );
}
our sub fpaAdd ( Fpa:D $left, Fpa:D $right --> Fpa ) {
say "In fpaAdd";
my Int $l = $left.var;
my Int $r = $right.var;
my $z = Fpa.new();
$z.var = $l + $r;
return $z;
}
} # end of package.
Here is some test driver code to call the module (test2.pm6):
use v6c;
use test1;
my Fpa $x = Fpa.new();
say $x.WHAT;
my Fpa $y = Fpa.new();
say $y.WHAT;
$y.var = 5;
$x.var = 1;
say "Object x set to " ~ $x.var ~ '.';
say "Object y set to " ~ $y.var ~ '.';
prompt "Press return and system will go into a loop.";
$x = $x + $y;
say "answer= " ~ $x.var ~ '.'; # This never happens.
exit;
Here is a run of the test2.pm6 code that calls the module:
perl6-m test2.pm6
(Fpa)
(Fpa)
Object x set to 1.
Object y set to 5.
Press return and system will go into a loop.
^C
$
Strangely, if the multi are taken out of the module and put in the test
driver, it works as expected.
If the "does Numeric" is removed from the class definition, it does not
resolve a call to a multi infix:<+> despite correctly matching object
types. The error message is:
Cannot resolve caller Numeric(test1::EXPORT::DEFAULT::Fpa: ); none of
these signatures match:
(Mu:U \v: *%_)
in block <unit> at test2.pm6 line 13
Is this expected behaviour?
Regards,
Andrew N Parker
