Another way to look at it is that unlike e.g. each, the docs for map and grep do not say anything about it not returning values in order (not to mention that the examples assume it).
Also, looking at the pitfalls of emulating fork on Windows and possible "thread safe" concerns, I would hope that any parallelization would be introduced in some optional way, such as a new function (e.g. pgrep), or using pragmas to turn it on or off. Or worst case, even if none of that occurred, I would be shocked if there was not a way to compile perl without a parallelized grep.
| [reply] |
Looking at the history of Perl 5, it is very unlikely that a perl compiled with default settings will break old code. One of the top priorities of Perl 5 is backwards compatibility at (nearly) all costs. This is easily to see with strict and warnings, both are off by default simply because they could break old, dirty scripts. say, given-when, need to be enabled explicitly, because old scripts may have used those words as function names and would break otherwise. Smart match and defined-or are disabled by default, Perl 5 still accepts Perl 4 function calls with a & in front of the function name, and so on.
Another problem with a parallelizing grep is that it will likely need threads. Threads are still optional in Perl 5, many modules are still not thread-safe, and the perl interpreter would have to add a lot of behind-the-scenes tricks to make sure a parallelizing grep build-in behaves exactly identically to a non-parallelizing grep under all circumstances (including abuse as map or for), except for the better performance. I doubt that all that extra code required would make grep significantly faster.
So, I think it is very unlikely that we will see a parallelizing grep in Perl 5, and it is even more unlikely that any improved grep, parallelized or not, will - by default - behave differently than grep in Perl 5.0.0, except for the performance or memory usage. For a dramatically improved, but incompatible grep, we can expect to see some pragma enabling it, perhaps use feature qw(parallelgrep); or use parallelgrep;.
abufct, if you want to be really paranoid about grep and map behaviour, add a test for the expected behaviour to your installer. Something like this:
#!/usr/bin/perl
use strict;
use warnings;
use Test::More tests=>2;
is(join(":",grep { $_%2==0 } 1..6),"2:4:6","grep keeps order");
is(join(":",map { 1+$_ } 1..6),"2:3:4:5:6:7","map keeps order");
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply]
[d/l]
[select] |
#!/usr/bin/perl
$var = undef // "defined-or and smartmatch both work";
print "$var\n" if $var ~~ qr{work};
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
| [reply]
[d/l] |
Well, the m// and s/// operator defaults have changed once or twice over the years, so if you didn't specify //ms you might have to in a newer version
| [reply] |