<?xml version="1.0" encoding="windows-1252"?>
<node id="997576" title="Re^4: Order in which grep/map receive elements" created="2012-10-06 00:37:26" updated="2012-10-06 00:37:26">
<type id="11">
note</type>
<author id="747201">
afoken</author>
<data>
<field name="doctext">
&lt;p&gt;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 [mod://strict] and [mod://warnings], both are off by default simply because they could break old, dirty scripts. [doc://say], [doc://given]-[doc://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 &lt;c&gt;&amp;&lt;/c&gt; in front of the function name, and so on.&lt;/p&gt;
&lt;p&gt;Another problem with a parallelizing &lt;c&gt;grep&lt;/c&gt; 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 &lt;c&gt;grep&lt;/c&gt; build-in behaves exactly identically to a non-parallelizing &lt;c&gt;grep&lt;/c&gt; under all circumstances (including abuse as &lt;c&gt;map&lt;/c&gt; or &lt;c&gt;for&lt;/c&gt;), except for the better performance. I doubt that all that extra code required would make &lt;c&gt;grep&lt;/c&gt; significantly faster.&lt;/p&gt;
&lt;p&gt;So, I think it is very unlikely that we will see a parallelizing &lt;c&gt;grep&lt;/c&gt; in Perl 5, and it is even more unlikely that any improved &lt;c&gt;grep&lt;/c&gt;, parallelized or not, will - by default - behave differently than &lt;c&gt;grep&lt;/c&gt; in Perl 5.0.0, except for the performance or memory usage. For a dramatically improved, but incompatible &lt;c&gt;grep&lt;/c&gt;, we can expect to see some pragma enabling it, perhaps &lt;c&gt;use feature qw(parallelgrep);&lt;/c&gt; or &lt;c&gt;use parallelgrep;&lt;/c&gt;.&lt;/p&gt;
&lt;p&gt;[id://997448], if you want to be really paranoid about &lt;c&gt;grep&lt;/c&gt; and &lt;c&gt;map&lt;/c&gt; behaviour, add a test for the expected behaviour to your installer. Something like this:&lt;/p&gt;
&lt;c&gt;
#!/usr/bin/perl
use strict;
use warnings;
use Test::More tests=&gt;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");
&lt;/c&gt;
&lt;p&gt;Alexander&lt;/p&gt;
&lt;div class="pmsig"&gt;&lt;div class="pmsig-747201"&gt;
--&lt;br&gt;
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
&lt;/div&gt;&lt;/div&gt;</field>
<field name="root_node">
997453</field>
<field name="parent_node">
997553</field>
</data>
</node>
