New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
map subroutine ignores the sequence in the specific case #5233
Comments
From @titsukiSee the following results. $ echo "h o g e" | perl6 -e 'for $*IN.lines -> $line { $line.split(" ").map(-> $e { $e.perl.say; }) };' # map ignores the input The 1st example seems that map subroutine ignores the input sequence. My rakudo version is |
From @lizmat
I’m not sure. $*IN.lines is lazy, the for is lazy, the split is lazy, the map is lazy, and apparently the sink is also lazy. There’s nothing pulling values from the far end, so the whole chain is waiting for something to happen. This should probably create a warning like “Useless use of split in sink context”. If you make the split eager by storing its result, it works as you’d expect: $ echo "h o g e" | perl6 -e 'for $*IN.lines -> $line { my @a = $line.split(" ").map(-> $e { $e.perl.say; }) };' So I would qualify this as *not a bug*, although one could argue that the lack of warning on the split in sink context *is* a bug. And/or the lack of eagerness of the sink is a bug. Liz |
The RT System itself - Status changed from 'new' to 'open' |
From @titsukiThanks for your neat explanation. On 2016-4月-13 水 04:58:24, elizabeth wrote:
|
From @zoffixznetI'm going to close this, since the original report was ruled as not a bug. The lazines of such constructs has now also been documented in Traps. -- |
@zoffixznet - Status changed from 'open' to 'rejected' |
From @zoffixznetRe-opening per TimToady's comments: http://irclog.perlgeek.de/perl6/2016-07-21#i_12881470 The map de-lazifies when sunk, but in this case the for's sinking doesn't seem to propagate to the map. This, for example, prints all the values: m: for ^3 { ^10 .map: *.say; Nil }; say 42; -- |
@zoffixznet - Status changed from 'rejected' to 'open' |
From @TimToadyThe unwanted() routine needed to add an explicit sink to certain methods found in a block-final Want node. (Method calls for dispatch:<.=> and Pair.new are exempt, however. In the case of .=, it is 'nosink' because it's essentially going to cause a side effect anyway, and doing it twice tends to drain Seq prematurely if that's what .= returns. With Pair.new, wrapping in .sink suppressed sink warnings on useless use of pairs.) Other than those exceptions, it seems more reasonable to default method calls to sinking on the chance that the method will return a sequence that needs to be iterated for its side effects. Fix in 328402599c16077e182bb38baf68e435b8bc1082 Test in b6012e0cd755d9c89ddff00dc45ce81a82bcbdcc |
1 similar comment
From @TimToadyThe unwanted() routine needed to add an explicit sink to certain methods found in a block-final Want node. (Method calls for dispatch:<.=> and Pair.new are exempt, however. In the case of .=, it is 'nosink' because it's essentially going to cause a side effect anyway, and doing it twice tends to drain Seq prematurely if that's what .= returns. With Pair.new, wrapping in .sink suppressed sink warnings on useless use of pairs.) Other than those exceptions, it seems more reasonable to default method calls to sinking on the chance that the method will return a sequence that needs to be iterated for its side effects. Fix in 328402599c16077e182bb38baf68e435b8bc1082 Test in b6012e0cd755d9c89ddff00dc45ce81a82bcbdcc |
@TimToady - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#127879 (status was 'resolved')
Searchable as RT127879$
The text was updated successfully, but these errors were encountered: