From @masak

<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.

From @usev6

The addition of two quasis with arithmetical expressions works on Moar and JVM. On Parrot the old error ("Cannot call 'infix​:<+>'; none of these signatures match") is gone, but the result of the addition is still wrong.

$ perl6-m -e 'macro bohr() { my $q1 = quasi { 6 }; my $q2 = quasi { 6 * 10 }; quasi { {{{$q1}}} + {{{$q2}}} } }; say bohr()'
66

$ perl6-p -e 'macro bohr() { my $q1 = quasi { 6 }; my $q2 = quasi { 6 * 10 }; quasi { {{{$q1}}} + {{{$q2}}} } }; say bohr()'
120

(It's the same with "{ 5 + 1}" for the first quasi.)

I added two tests (fudged 'skip' for Parrot) to S06-macros/quasi-blocks.t with the following commit​: Raku/roast@bab9270

Please note​: There is something strange with the failing parrot tests. I have fudged them as 'skip' because if I fudge both tests as 'todo' and run "perl t/harness --fudge" manually, it reports one passed TODO​:

$ perl t/harness --fudge t/spec/S06-macros/quasi-blocks.t
t/spec/S06-macros/quasi-blocks.rakudo.parrot .. ok
All tests successful.

Test Summary Report

t/spec/S06-macros/quasi-blocks.rakudo.parrot (Wstat​: 0 Tests​: 14 Failed​: 0)
  TODO passed​: 1
Files=1, Tests=14, 6 wallclock secs ( 0.02 usr 0.01 sys + 5.47 cusr 0.22 csys = 5.72 CPU)
Result​: PASS

But if I execute the thereby generated test file t/spec/S06-macros/quasi-blocks.rakudo.parrot both tests fail. (So there is no passed TODO.)​:

$ perl6-p t/spec/S06-macros/quasi-blocks.rakudo.parrot
[...]
not ok 13 - addition of two quasis with arithmetical expressions works (1)# TODO RT #​115500

# Failed test 'addition of two quasis with arithmetical expressions works (1)'
# at t/spec/S06-macros/quasi-blocks.rakudo.parrot line 129
# expected​: '66'
# got​: '120'
not ok 14 - addition of two quasis with arithmetical expressions works (2)# TODO RT #​115500

# Failed test 'addition of two quasis with arithmetical expressions works (2)'
# at t/spec/S06-macros/quasi-blocks.rakudo.parrot line 136
# expected​: '66'
# got​: '120'
# FUDGED!

@usev6 - Status changed from 'new' to 'open'

From @usev6

Since support for Parrot was suspended with Rakudo Star Release 2015.02, I'm closing this "parrot only" ticket.

I added the ticket to a list of closed ticket living in the Mu repository​: https://github.com/perl6/mu/blob/master/misc/rt.perl.org/tickets_closed_parrot_only.txt.

In case support for Parrot will be restored in some future release the listed tickets can be checked and re-opened as appropriate.

@usev6 - Status changed from 'open' to 'rejected'