From @masak

<blixtor> perl6​: sub foo { my $s; for 1..3 { $s += $_ } } ; say foo()
<p6eval> rakudo e45bf6​: OUTPUT«666␤»
<blixtor> what is the rationale for this returning '666'
<jnthn> We embeded the devil in Rakudo.
<jnthn> Also, for in Perl 6 is just a synonym for "map"
<blixtor> and it's leaking from time to time, I see ;)
<jnthn> So you're doing something like
<jnthn> (1..3).map​: { $s += $_ }
<jnthn> Which returns $s since that's the last thing you touched
<jnthn> So you end up with a list with $s in it 3 times
<blixtor> ahh, ok, that explains the difference to perl5, which
doesn't return anything
<jnthn> Yes, it's a difference from Perl 5.
<masak> why doesn't that return 136, though?
<masak> that's what I'd expect.
<sorear> masak​: because Rakudo map is rw
<sorear> it's not supposed to be
<sorear> in theory, take should decontainerize
* masak submits rakudobug
<masak> it's in there, I'm sure.
<masak> but it's nice to have this example on file.
<sorear> like return
<masak> aye.
<jnthn> erm
<jnthn> what?
<jnthn> We never returned or taked here
<masak> true.
<masak> which is why it's a different ticket, I now realize :)
<sorear> jnthn​: map is implemented using take
<jnthn> sorear​: No.
<jnthn> sorear​: Well, it *may* be.
<jnthn> sorear​: But it certainly doesn't have to be.
<jnthn> (That is, nothing in the spec says it needs to be.)
<jnthn> morning, takadonet
<jnthn> Anyway, it maybe should be decontainerizing somewhere here too
<sorear> jnthn​: well, in any case, the same underlying LTA is causing both
<jnthn> I'm just not sure where.
<jnthn> Anyway, a ticket does no harm and makes sure we don't forget the issue.

From @pmichaud

On Fri, Aug 20, 2010 at 04​:39​:00AM -0700, Carl Mäsak wrote​:

<blixtor> perl6​: sub foo { my $s; for 1..3 { $s += $_ } } ; say foo()
[...]
<sorear> jnthn​: well, in any case, the same underlying LTA is causing both
<jnthn> I'm just not sure where.
<jnthn> Anyway, a ticket does no harm and makes sure we don't forget the issue.

I suspect that any block should de-containerize its return value
unless it is somehow declared "is rw". So in the case above, it's
not the 'for', 'map', or (non-existent) 'take' that is failing to
decontainerize, it's the block argument to 'for' that needs to do it.

Pm

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

From @coke

On Fri Aug 20 04​:39​:00 2010, masak wrote​:

<blixtor> perl6​: sub foo { my $s; for 1..3 { $s += $_ } } ; say foo()
<p6eval> rakudo e45bf6​: OUTPUT«666␤»
<blixtor> what is the rationale for this returning '666'
<jnthn> We embeded the devil in Rakudo.
<jnthn> Also, for in Perl 6 is just a synonym for "map"
<blixtor> and it's leaking from time to time, I see ;)
<jnthn> So you're doing something like
<jnthn> (1..3).map​: { $s += $_ }
<jnthn> Which returns $s since that's the last thing you touched
<jnthn> So you end up with a list with $s in it 3 times
<blixtor> ahh, ok, that explains the difference to perl5, which
doesn't return anything
<jnthn> Yes, it's a difference from Perl 5.
<masak> why doesn't that return 136, though?
<masak> that's what I'd expect.
<sorear> masak​: because Rakudo map is rw
<sorear> it's not supposed to be
<sorear> in theory, take should decontainerize
* masak submits rakudobug
<masak> it's in there, I'm sure.
<masak> but it's nice to have this example on file.
<sorear> like return
<masak> aye.
<jnthn> erm
<jnthn> what?
<jnthn> We never returned or taked here
<masak> true.
<masak> which is why it's a different ticket, I now realize :)
<sorear> jnthn​: map is implemented using take
<jnthn> sorear​: No.
<jnthn> sorear​: Well, it *may* be.
<jnthn> sorear​: But it certainly doesn't have to be.
<jnthn> (That is, nothing in the spec says it needs to be.)
<jnthn> morning, takadonet
<jnthn> Anyway, it maybe should be decontainerizing somewhere here too
<sorear> jnthn​: well, in any case, the same underlying LTA is causing
both
<jnthn> I'm just not sure where.
<jnthn> Anyway, a ticket does no harm and makes sure we don't forget
the issue.

Behavior has changed​:

12​:50 < [Coke]> perl6​: sub foo { my $s; for 1..3 { $s += $_ } } ; say foo()
12​:50 <+camelia> rakudo-{parrot,jvm,moar} 60cd9d​: OUTPUT«Nil␤»

--
Will "Coke" Coleda

From @coke

On Fri Aug 22 09​:52​:24 2014, coke wrote​:

On Fri Aug 20 04​:39​:00 2010, masak wrote​:

<blixtor> perl6​: sub foo { my $s; for 1..3 { $s += $_ } } ; say foo()
<p6eval> rakudo e45bf6​: OUTPUT«666␤»
<blixtor> what is the rationale for this returning '666'
<jnthn> We embeded the devil in Rakudo.
<jnthn> Also, for in Perl 6 is just a synonym for "map"
<blixtor> and it's leaking from time to time, I see ;)
<jnthn> So you're doing something like
<jnthn> (1..3).map​: { $s += $_ }
<jnthn> Which returns $s since that's the last thing you touched
<jnthn> So you end up with a list with $s in it 3 times
<blixtor> ahh, ok, that explains the difference to perl5, which
doesn't return anything
<jnthn> Yes, it's a difference from Perl 5.
<masak> why doesn't that return 136, though?
<masak> that's what I'd expect.
<sorear> masak​: because Rakudo map is rw
<sorear> it's not supposed to be
<sorear> in theory, take should decontainerize
* masak submits rakudobug
<masak> it's in there, I'm sure.
<masak> but it's nice to have this example on file.
<sorear> like return
<masak> aye.
<jnthn> erm
<jnthn> what?
<jnthn> We never returned or taked here
<masak> true.
<masak> which is why it's a different ticket, I now realize :)
<sorear> jnthn​: map is implemented using take
<jnthn> sorear​: No.
<jnthn> sorear​: Well, it *may* be.
<jnthn> sorear​: But it certainly doesn't have to be.
<jnthn> (That is, nothing in the spec says it needs to be.)
<jnthn> morning, takadonet
<jnthn> Anyway, it maybe should be decontainerizing somewhere here too
<sorear> jnthn​: well, in any case, the same underlying LTA is causing
both
<jnthn> I'm just not sure where.
<jnthn> Anyway, a ticket does no harm and makes sure we don't forget
the issue.

Behavior has changed​:

12​:50 < [Coke]> perl6​: sub foo { my $s; for 1..3 { $s += $_ } } ; say foo()
12​:50 <+camelia> rakudo-{parrot,jvm,moar} 60cd9d​: OUTPUT«Nil␤»

15​:57 < masak> [Coke]​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=77334 is not
  valid any more, at least not with that kind of for loop.
15​:57 < masak> m​: sub foo { my $s; ($s += $_ for 1..3) } ; say foo()
15​:57 <+camelia> rakudo-moar 5bd2d4​: OUTPUT«6 6 6␤»
15​:58 < masak> [Coke]​: need to do it that way instead :)

So, no change, really. masak++

--
Will "Coke" Coleda

From @masak

<[Coke]> rant​: old tickets with "maybe" or "either std or rakudo is wrong"
<masak> [Coke]​: if I'm to blame for "either std or rakudo is wrong" tickets, send them to me and I'll take action on them.
<masak> I'm pretty sure I don't file "maybe" tickets :)
<[Coke]> masak​: RT #​77334
<synopsebot> Link​: https://rt-archive.perl.org/perl6//Public/Bug/Display.html?id=77334
* masak looks
<[Coke]> that maybe ticket is from 4 years ago.
<masak> oh, we talked about that one the other day.
<masak> the question we should ask on that one is "what use case are we making impossible by having `for` loops decontainerize?"
<masak> actually, two more questions.
<masak> "which way is least surprize?" (pretty sure it's doing the decont)
<masak> "which way shoots us in the fewest amount of feet wrt performance?" (pretty sure it's the decont)
<masak> in other words, if we can't think of a use case for Q1, then there's no "maybe" there.
<masak> [Coke]​: good enough? :)
* masak adds this to the ticket
<[Coke]> please update the subject to indicate the choice.
<masak> [Coke]​: well, we haven't quite failed to think of a use case yet...
<[Coke]> so it is still a maybe? arglebargle.
<masak> m​: sub foo { my $s; (+($s += $_) for 1..3) }; say foo() # [Coke]​: here's the result if we decont.
<camelia> rakudo-moar 9a6644​: OUTPUT«1 3 6␤»
<masak> [Coke]​: do you agree that it's a less surprising result?
<[Coke]> masak​: surprising or no, I want tickets of the form "this code generates result A when it should generate result B". not "we're not sure what's the right answer here..."
<[Coke]> because that kind of ticket stays open for 4 years.
<masak> *nod*
<masak> ok, I'll remove the "maybe", simply because I haven't seen and can't think of a use case that's more important than not letting [Coke] down.
<masak> anyone from the future who knows of such a use case, take note​: I consider uprooting my decision to be valid to the extent there's a use case to motivate it.
<masak> that may include but is not limited to someone who tries to implement this and notices that the correct implementation fails some (hard to dispute) previously passing spectest.

From @masak

<masak> n​: sub foo { my $s = 0; ($s += $_ for 1..3) }; say foo()
<camelia> niecza v24-109-g48a8de3​: OUTPUT«1 3 6␤»
<masak> this is a data point, too. Niecza decontainerizes.

From @jnthn

On Sat Aug 30 08​:31​:30 2014, masak wrote​:

<masak> n​: sub foo { my $s = 0; ($s += $_ for 1..3) }; say foo()
<camelia> niecza v24-109-g48a8de3​: OUTPUT«1 3 6␤»
<masak> this is a data point, too. Niecza decontainerizes.

It's a tad more sutble​:

15​:07 < jnthn> masak​: Only tricky thing is that it may not be as simple as
  decont
15​:08 < jnthn> m​: say (1, 2, 3).map({ $['a' xx $_] }).perl
15​:08 <+camelia> rakudo-moar e5612a​: OUTPUT«($["a"], $["a", "a"], $["a", "a",
  "a"]).Seq␤»
15​:08 < jnthn> If I decont then we lose the itemization on those.
15​:09 < masak> ...hm.

So we need to decide if we care to retain the meaning of the $ in such cases, and perhaps rule on the sub case too​:

15​:09 < jnthn> So we more need the return from sub semantics (recont if Iterable)
15​:09 < masak> uh, ok
15​:09 < masak> I had no idea subs did that :P
15​:11 < jnthn> They did 'cus you filed a ticket when they didn't :P
15​:12 * PerlJam wonders if this falls in the category of tormenting the
  implementor ...
15​:12 < jnthn> Back when we had lots of implicit flattening and [...] was an
  item, it was rather more noticable.
15​:12 < jnthn> Nowadays I'd probably get through spectest with a patch that
  just deconts, but... :)

From @jnthn

On Fri Aug 22 13​:46​:45 2014, coke wrote​:

On Fri Aug 22 09​:52​:24 2014, coke wrote​:

On Fri Aug 20 04​:39​:00 2010, masak wrote​:

<blixtor> perl6​: sub foo { my $s; for 1..3 { $s += $_ } } ; say
foo()
<p6eval> rakudo e45bf6​: OUTPUT«666␤»
<blixtor> what is the rationale for this returning '666'
<jnthn> We embeded the devil in Rakudo.
<jnthn> Also, for in Perl 6 is just a synonym for "map"
<blixtor> and it's leaking from time to time, I see ;)
<jnthn> So you're doing something like
<jnthn> (1..3).map​: { $s += $_ }
<jnthn> Which returns $s since that's the last thing you touched
<jnthn> So you end up with a list with $s in it 3 times
<blixtor> ahh, ok, that explains the difference to perl5, which
doesn't return anything
<jnthn> Yes, it's a difference from Perl 5.
<masak> why doesn't that return 136, though?
<masak> that's what I'd expect.
<sorear> masak​: because Rakudo map is rw
<sorear> it's not supposed to be
<sorear> in theory, take should decontainerize
* masak submits rakudobug
<masak> it's in there, I'm sure.
<masak> but it's nice to have this example on file.
<sorear> like return
<masak> aye.
<jnthn> erm
<jnthn> what?
<jnthn> We never returned or taked here
<masak> true.
<masak> which is why it's a different ticket, I now realize :)
<sorear> jnthn​: map is implemented using take
<jnthn> sorear​: No.
<jnthn> sorear​: Well, it *may* be.
<jnthn> sorear​: But it certainly doesn't have to be.
<jnthn> (That is, nothing in the spec says it needs to be.)
<jnthn> morning, takadonet
<jnthn> Anyway, it maybe should be decontainerizing somewhere here
too
<sorear> jnthn​: well, in any case, the same underlying LTA is
causing
both
<jnthn> I'm just not sure where.
<jnthn> Anyway, a ticket does no harm and makes sure we don't
forget
the issue.

Behavior has changed​:

12​:50 < [Coke]> perl6​: sub foo { my $s; for 1..3 { $s += $_ } } ; say
foo()
12​:50 <+camelia> rakudo-{parrot,jvm,moar} 60cd9d​: OUTPUT«Nil␤»

15​:57 < masak> [Coke]​:
https://rt-archive.perl.org/perl6/Ticket/Display.html?id=77334 is not
valid any more, at least not with that kind of for
loop.
15​:57 < masak> m​: sub foo { my $s; ($s += $_ for 1..3) } ; say foo()
15​:57 <+camelia> rakudo-moar 5bd2d4​: OUTPUT«6 6 6␤»
15​:58 < masak> [Coke]​: need to do it that way instead :)

So, no change, really. masak++

TimToady++ has ruled that `for` should not decontainerize, on the basis that it's easy enough to make it not do so (such as with the <> postfix) but there's not an easy way to avoid the decontainerization if you don't want it. Also, there's usually a better way to write these things. Discussion​:

http://irclog.perlgeek.de/perl6/2015-10-27#i_11440206

Tests covering this ruling in S04-statement-modifiers/for.t and S04-statements/for.t.

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