On Thu Jan 12 02:02:04 2012, masak wrote:
> <masak> ./perl6 -e 'sub MAIN(Int $a) { say $a - 5 }' 7
> <masak> 7
> <masak> :10($a) is a workaround so far.
> <masak> ./perl6 -e 'sub MAIN(Int $a) { say :10($a) - 5 }' 7
> <masak> 2
> <moritz> confirmed.
> <masak> can anyone confirm?
> * masak submits rakudobug
> <moritz> I guess it's the mixing in of the current string form that's
> bothering the multi dispatcher
> <masak> I'm sure it is.
<moritz> OMG
<moritz> bigints are to blame
<masak> o.O
<moritz> the bigint operations need to generate a new bigint object
<moritz> and they try to create one of the right type
<moritz> ... by chosing the type of one of the arguments
<moritz> and here it happens to be the type of the first argument
<moritz> and that turns out to be less clever than we would have hoped
:/
<moritz> the fix is to add an additional parameter for the type object
of the result to nearly all bigint ops
<jnthn> :/
* masak adds this to the ticket
<moritz> the result is a proper 5, it just stringifies to 7
<moritz> nom: my role orig-string[$o] { method Str() { $o.Str } }; my $a
= 7 but orig-string['7']; say nqp::p6box_s(nqp::unbox_i($a - 2))
<p6eval> nom f365ad: OUTPUT«5»
<jnthn> moritz: If somebody sends a subclass in, are we expecting to
drop that in the type of the result?
<jnthn> Guess we could...
<moritz> jnthn: I don't think we are supposed to do any automagic
polymorphy in the int ops...
<jnthn> moritz: Yeah, I hoped we'd get away with this and save a lookup.
<moritz> how could we possibly know what to do with A + B where both A
and B inherit from Int, if not returning Int?
<jnthn> moritz: Guess wildly :)
<jnthn> moritz: Anyway, yeah, we probably should be returning an Int.
<moritz> jnthn: that's what led to RT #108052 :/ (guessing wildly)
* jnthn shoulda guessed somebody would run into this in the space of
weeks rather than years. :/
<masak> guess who ran into it... :)
<moritz> 'masak' given 'somebody' :-)
