From @masak

<jnthn> rakudo​: my $a = 1; my $b = 2; $a = ($a, $b); say $a.perl
<p6eval> rakudo 388eed​: OUTPUT«maximum recursion depth exceeded␤ in
'Block​::count' at line 6077​:CORE.setting␤ in 'Block​::count' at line
6077​:CORE.setting␤ in 'Any​::join' at line 1␤ in 'List​::perl' at line
2792​:CORE.setting␤ in <anon> at line 2792​:CORE.setting␤ in
'Any​::join' at line 1␤ in 'List​::perl' at …
<jnthn> rakudo​: my $a = 1; my $b = 2; $a ,= $b; say $a.perl
<p6eval> rakudo 388eed​: OUTPUT«maximum recursion depth exceeded [...]
<jnthn> Bug.
<masak> a known one, no?
<jnthn> masak​: I dunno, you're the human bug database. :P
<masak> rakudo​: my $a = 1; my $b = 2; $a ,= $b; say 'alive!'
<p6eval> rakudo 388eed​: OUTPUT«alive!␤»
<masak> it's a bug in .perl -- how boring.
* masak submits, Justin Case
<jnthn> rakudo​: my $a = 1; my $b = 2; $a ,= $b; $a.say
<p6eval> rakudo 388eed​: ( no output )
<jnthn> That looks...rather dubious too
<masak> rakudo​: my $a = 1; $a ,= 2; say $a.perl
<p6eval> rakudo 388eed​: OUTPUT«maximum recursion depth exceeded [...]
<jnthn> rakudo​: my $a = 1; my $b = 2; $a ,= $b; say ~$a
<p6eval> rakudo 388eed​: OUTPUT«maximum recursion depth exceeded [...]
<jnthn> It's more than just .perl it seems
<masak> aye.
<masak> jnthn++
* jnthn suspected so
<masak> let's call it a bug in ,=
<jnthn> :(
<jnthn> wait
* masak waits
<jnthn> rakudo​: my $a = 1; my $b = 2; $a = ($a, $b); say ~$a
<p6eval> rakudo 388eed​: OUTPUT«maximum recursion depth exceeded [...]
<jnthn> Darn.
<jnthn> It's a bug in parcel construction and assignment when the
parcel contains the assignee it seems... :/
<jnthn> Or something.
<jnthn> Well, maybe.
<jnthn> I note that stack trace has join in it, and the .perl one did too.
<jnthn> rakudo​: my $a = 1; my $b = 2; $a = ($a, $b); say $a.WHAT
<p6eval> rakudo 388eed​: OUTPUT«Seq()␤»
<jnthn> rakudo​: my $a = 1; my $b = 2; $a = ($a, $b); say $a[0]
<p6eval> rakudo 388eed​: ( no output )
<jnthn> rakudo​: my $a = 1; my $b = 2; $a = ($a, $b); say $a[1]
<p6eval> rakudo 388eed​: OUTPUT«2␤»
<jnthn> I wonder if something that should decontainerize is failing to do so.
<jnthn> Though if so, it's hard to say what. Since l-value parcels
surely shouldn't decontainerize on construction, or we break list
assignment forms like ($a, $b) = 1,2
* jnthn 's brain asplodes
<jnthn> Well, file it. :)

From @coke

On Tue Jan 18 14​:35​:46 2011, masak wrote​:

<jnthn> rakudo​: my $a = 1; my $b = 2; $a = ($a, $b); say $a.perl
<p6eval> rakudo 388eed​: OUTPUT«maximum recursion depth exceeded␤ in
'Block​::count' at line 6077​:CORE.setting␤ in 'Block​::count' at line
6077​:CORE.setting␤ in 'Any​::join' at line 1␤ in 'List​::perl' at line
2792​:CORE.setting␤ in <anon> at line 2792​:CORE.setting␤ in
'Any​::join' at line 1␤ in 'List​::perl' at …
<jnthn> rakudo​: my $a = 1; my $b = 2; $a ,= $b; say $a.perl
<p6eval> rakudo 388eed​: OUTPUT«maximum recursion depth exceeded [...]
<jnthn> Bug.
<masak> a known one, no?
<jnthn> masak​: I dunno, you're the human bug database. :P
<masak> rakudo​: my $a = 1; my $b = 2; $a ,= $b; say 'alive!'
<p6eval> rakudo 388eed​: OUTPUT«alive!␤»
<masak> it's a bug in .perl -- how boring.
* masak submits, Justin Case
<jnthn> rakudo​: my $a = 1; my $b = 2; $a ,= $b; $a.say
<p6eval> rakudo 388eed​: ( no output )
<jnthn> That looks...rather dubious too
<masak> rakudo​: my $a = 1; $a ,= 2; say $a.perl
<p6eval> rakudo 388eed​: OUTPUT«maximum recursion depth exceeded [...]
<jnthn> rakudo​: my $a = 1; my $b = 2; $a ,= $b; say ~$a
<p6eval> rakudo 388eed​: OUTPUT«maximum recursion depth exceeded [...]
<jnthn> It's more than just .perl it seems
<masak> aye.
<masak> jnthn++
* jnthn suspected so
<masak> let's call it a bug in ,=
<jnthn> :(
<jnthn> wait
* masak waits
<jnthn> rakudo​: my $a = 1; my $b = 2; $a = ($a, $b); say ~$a
<p6eval> rakudo 388eed​: OUTPUT«maximum recursion depth exceeded [...]
<jnthn> Darn.
<jnthn> It's a bug in parcel construction and assignment when the
parcel contains the assignee it seems... :/
<jnthn> Or something.
<jnthn> Well, maybe.
<jnthn> I note that stack trace has join in it, and the .perl one did
too.
<jnthn> rakudo​: my $a = 1; my $b = 2; $a = ($a, $b); say $a.WHAT
<p6eval> rakudo 388eed​: OUTPUT«Seq()␤»
<jnthn> rakudo​: my $a = 1; my $b = 2; $a = ($a, $b); say $a[0]
<p6eval> rakudo 388eed​: ( no output )
<jnthn> rakudo​: my $a = 1; my $b = 2; $a = ($a, $b); say $a[1]
<p6eval> rakudo 388eed​: OUTPUT«2␤»
<jnthn> I wonder if something that should decontainerize is failing to
do so.
<jnthn> Though if so, it's hard to say what. Since l-value parcels
surely shouldn't decontainerize on construction, or we break list
assignment forms like ($a, $b) = 1,2
* jnthn 's brain asplodes
<jnthn> Well, file it. :)

Another data point - here's a working GLR version​:

10​:48 < TimToady> m​: my $a = 1; my $b = 2; $a = (|$a, $b); say $a[0]
10​:48 <+camelia> rakudo-moar 47ddca​: OUTPUT«===SORRY!=== Error while compiling /tmp/gc6pUtxwbw␤Arg-flattening | is only valid in
  an argument list␤at /tmp/gc6pUtxwbw​:1␤------> my $a = 1; my $b = 2; $a = (|⏏$a, $b); say $a[0]␤»
10​:48 < GLRelia> rakudo-moar fffbe7​: OUTPUT«1␤»

--
Will "Coke" Coleda

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

From @niner

21​:03 < nine> m​: my $a = 1; my $b = 2; $a = ($a, $b); say $a[0]
21​:03 <+camelia> rakudo-moar 25fed4​: OUTPUT«(\List_139651993582776 = (List_139651993582776 2))␤»

This works in current Rakudo due to TimToady's fixes for .perl on self referential data structures. The bug has never been in list construction or assignment and always in .perl.

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