Re^4: Order in which grep/map receive elements

[afoken]

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