Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

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

by afoken (Prior)
on Oct 06, 2012 at 04:37 UTC ( #997576=note: print w/ replies, xml ) Need Help??


in reply to Re^3: Order in which grep/map receive elements
in thread Order in which grep/map receive elements

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". ;-)


Comment on Re^4: Order in which grep/map receive elements
Select or Download Code
Replies are listed 'Best First'.
Re^5: Order in which grep/map receive elements
by tobyink (Abbot) on Oct 08, 2012 at 22:23 UTC

    "Smart match and defined-or are disabled by default"

    Again, in the interest of nitpicking, they are not.

    #!/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'
Re^5: Order in which grep/map receive elements
by Anonymous Monk on Oct 06, 2012 at 09:03 UTC
    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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://997576]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (12)
As of 2015-07-31 16:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (279 votes), past polls