# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #115500]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=115500 >
<masak> r: macro bohr() { my $q1 = quasi { 6 }; my $q2 = quasi { 6 *
10 }; my $q3 = quasi { 100 + 200 + 300 }; quasi { {{{$q1}}} +
{{{$q2}}} + {{{$q3}}} } }; say bohr()
<p6eval> rakudo 6859fb: OUTPUT«Cannot call 'infix:<+>'; none of these
signatures match: [...]
<masak> :/
<jnthn> masak: It's nothing to do with the first quasi just having a literal in?
<masak> why would that make a difference?
<jnthn> I've no idea :)
<masak> r: macro bohr() { my $q1 = quasi { 1 + 5 }; my $q2 = quasi { 6
* 10 }; my $q3 = quasi { 100 + 200 + 300 }; quasi { {{{$q1}}} +
{{{$q2}}} + {{{$q3}}} } }; say bohr()
<p6eval> rakudo 6859fb: OUTPUT«720»
<masak> jnthn: you're right.
<jnthn> o.O
<jnthn> wtf, it was a complete guess
<masak> jnthn: it *does* have to do with $q1 containing just a literal.
<masak> note also that the above answer is wrong.
<masak> it should be 666, not 720.
<masak> something weird is going on here with precedence.
<colomon> hmmm... $q2 + $q2 + $q3 is 720
<jnthn> I'm doubtful it's a precedence bug. I do have to wonder if
it's not something busted in the code that walks through the AST to
find quasis and splicing things in.
<masak> ok, not a precedence bug.
<masak> I like colomon's theory better.
<masak> maybe $q1 gets lost somewhere and $q2 gets used instead.
<masak> r: macro bohr() { my $q1 = quasi { 6 * 10 }; my $q2 = quasi {
1 + 5 }; my $q3 = quasi { 100 + 200 + 300 }; quasi { {{{$q1}}} +
{{{$q2}}} + {{{$q3}}} } }; say bohr()
<p6eval> rakudo 6859fb: OUTPUT«612»
<masak> yeah, colomon++ is right.
<jnthn> masak: Yes, my guess was that the "getting lost" is happening
in the spliciing.
<masak> quite possibly.
* masak submits rakudobug
<colomon> thought: maybe the reason it wouldn't work when it was quasi
{ 6 } is there wasn't enough room to splice in 6 * 10.
<colomon> r: macro bohr() { my $q1 = quasi { 6 * 10 }; my $q2 = quasi
{ 1 + 5 * 2 }; my $q3 = quasi { 100 + 200 + 300 }; quasi { {{{$q1}}} +
{{{$q2}}} + {{{$q3}}} } }; say bohr()
<p6eval> rakudo 6859fb: OUTPUT«Cannot call 'Numeric'; none of these
signatures match: [...]
<colomon> r: macro bohr() { my $q1 = quasi { 6 }; my $q2 = quasi { 1
}; my $q3 = quasi { 100 + 200 + 300 }; quasi { {{{$q1}}} + {{{$q2}}} +
{{{$q3}}} } }; say bohr()
<p6eval> rakudo 6859fb: OUTPUT«602»
<colomon> r: macro bohr() { my $q1 = quasi { 6 + 1 }; my $q2 = quasi {
1 }; my $q3 = quasi { 100 + 200 + 300 }; quasi { {{{$q1}}} + {{{$q2}}}
+ {{{$q3}}} } }; say bohr()
<p6eval> rakudo 6859fb: OUTPUT«608»
<colomon> didn't expect that.
<masak> it gets the sum right.
<masak> that last one, I mean.
<masak> what the heck is going on here...?
<diakopter> r: macro bohr() { my $q2 = quasi { 1 + 5 }; my $q1 = quasi
{ 10 + 50 }; quasi { {{{$q1}}} + {{{$q2}}} + 600 } }; say bohr()
<p6eval> rakudo 6859fb: OUTPUT«612»
<diakopter> the second splats the first
<masak> not in the "608" case above.
<masak> so, yes, but only sometimes.
<diakopter> when both are additions
<diakopter> oh!
<diakopter> when both have 2 terms
<diakopter> multiplication works too
<diakopter> second splats the first when theyy're the same shape?
<masak> doesn't cover it. the first case had $q1 = quasi { 6 } and $q2
= quasi { 6 * 10 }
<colomon> but if the second is bigger, it super splats it, making
something outright illegal.
<masak> oh!
<masak> yes, diakopter + colomon might cover it.
* masak re-reads backlog to make sure
<masak> r: macro bohr() { my $q1 = quasi { 6 }; my $q2 = quasi { 6 *
10 }; quasi { {{{$q1}}} + {{{$q2}}} } }; say bohr()
<p6eval> rakudo 6859fb: OUTPUT«Cannot call 'infix:<+>'; none of these
signatures match: [...]
<masak> r: macro bohr() { my $q1 = quasi { 5 + 1 }; my $q2 = quasi { 6
* 10 }; quasi { {{{$q1}}} + {{{$q2}}} } }; say bohr()
<p6eval> rakudo 6859fb: OUTPUT«120»
<masak> yes, diakopter + colomon seem to have it.
