From @masak

<flussence> rakudo​: sub add { [+]@​_ }; say add(4, 5)
<p6eval> rakudo 6fd077​: OUTPUT«2␤»
<flussence> :(
<benabik> rakudo​: sub add { [+] @​_ }; say add(4, 5)
<p6eval> rakudo 6fd077​: OUTPUT«2␤»
<jnthn> er, why on earth did [+] @​_ not work...
<flussence> b​: sub add { [+]@​_ }; say add(4, 5)
<p6eval> b 1b7dd1​: OUTPUT«9␤»
<masak> nom​: sub add { [+](@​_) }; say add 4, 5
<p6eval> nom 6fd077​: OUTPUT«2␤»
<benabik> nombug?
* masak submits rakudobug
<jnthn> nom​: sub add(*@​x) { [+] @​x }; say add 4, 5
<p6eval> nom 6fd077​: OUTPUT«9␤»
<jnthn> benabik​: Yeah, that's my guess
<benabik> A bug in the implicit @​_?
<TimToady> std​: sub add { [+]@​_ }; say add(4, 5)
<p6eval> std c22b2ee​: OUTPUT«�[31m===�[0mSORRY!�[31m===�[0m␤Two terms
in a row [...]
<TimToady> space required after a reduce
<masak> fairy nuff.
<grondilu> rakudo​: sub add { [+] @​_ }; say add 1, 42
<p6eval> rakudo 6fd077​: OUTPUT«2␤»
<benabik> Two bugs! Parsing and @​_ not working right in a reduce.
<jnthn> benabik​: It's not reduce
<jnthn> benabik​: It's something about the binding.
<TimToady> extra capture parens?
<jnthn> TimToady​: Almost certainly a failure to set a flatten flag or
something like that.
<TimToady> not marked as flatten
<flussence> well I've managed to break both rakudo branches today,
that's an achievement :)

Let's ignore the TTIAR parsing error for now -- I think we have a
separate ticket for that somewhere in RT. There's something wrong with
the binding of @​_.

From @jnthn

On Sun Sep 25 07​:19​:50 2011, masak wrote​:

<flussence> rakudo​: sub add { [+]@​_ }; say add(4, 5)
<p6eval> rakudo 6fd077​: OUTPUT«2␤»
<flussence> :(
<benabik> rakudo​: sub add { [+] @​_ }; say add(4, 5)
<p6eval> rakudo 6fd077​: OUTPUT«2␤»
<jnthn> er, why on earth did [+] @​_ not work...
<flussence> b​: sub add { [+]@​_ }; say add(4, 5)
<p6eval> b 1b7dd1​: OUTPUT«9␤»
<masak> nom​: sub add { [+](@​_) }; say add 4, 5
<p6eval> nom 6fd077​: OUTPUT«2␤»
<benabik> nombug?
* masak submits rakudobug
<jnthn> nom​: sub add(*@​x) { [+] @​x }; say add 4, 5
<p6eval> nom 6fd077​: OUTPUT«9␤»
<jnthn> benabik​: Yeah, that's my guess
<benabik> A bug in the implicit @​_?
<TimToady> std​: sub add { [+]@​_ }; say add(4, 5)
<p6eval> std c22b2ee​: OUTPUT«�[31m===�[0mSORRY!�[31m===�[0m␤Two terms
in a row [...]
<TimToady> space required after a reduce
<masak> fairy nuff.
<grondilu> rakudo​: sub add { [+] @​_ }; say add 1, 42
<p6eval> rakudo 6fd077​: OUTPUT«2␤»
<benabik> Two bugs! Parsing and @​_ not working right in a reduce.
<jnthn> benabik​: It's not reduce
<jnthn> benabik​: It's something about the binding.
<TimToady> extra capture parens?
<jnthn> TimToady​: Almost certainly a failure to set a flatten flag or
something like that.
<TimToady> not marked as flatten
<flussence> well I've managed to break both rakudo branches today,
that's an achievement :)

Let's ignore the TTIAR parsing error for now -- I think we have a
separate ticket for that somewhere in RT. There's something wrong with
the binding of @​_.

sub add { [+] @​_ }; say add 1, 42
43

Needs tests.

/jnthn

The RT System itself - Status changed from 'new' to 'open'

From @jnthn

Test added by tadzik++.

@jnthn - Status changed from 'open' to 'resolved'