Re: Syntax question about closures and Perl 'sort'

Probably the parser parses sort sortby->() as "sort LIST" instead of "sort BLOCK LIST" or "sort SUBNAME LIST", see "perldoc -f sort". After that the parser expects either a ';' or a control statement like 'if', 'while', 'for'... but instead sees an array.

I get the expected error messages in this sample code:

#!/usr/bin/perl 
use strict; use warnings; 


my $sortby = setsort(1);
        for my $rec ( sort $sortby->() (2,6,1) ) {
            print $rec, "\n";
        }


sub setsort {
    my $type = shift;
    return sub { $a <=> $b } if ( uc($type) eq "PTR" );
    return sub { $a cmp $b };
}

Use of uninitialized value in string comparison (cmp) at ./t7.pl line 
+14.
Use of uninitialized value in string comparison (cmp) at ./t7.pl line 
+14.
Can't use string ("0") as a subroutine ref while "strict refs" in use 
+at ./t7.pl line 6.
[download]

By the way, using a closure in your code would make no sense. When you call setsort() it doesn't need to remember any values from previous calls to it, its return value depends solely on the parameter $_

Comment on Re: Syntax question about closures and Perl 'sort' Select or Download Code

Replies are listed 'Best First'.
Re^2: Syntax question about closures and Perl 'sort' by dwm042 (Priest) on Apr 03, 2009 at 22:40 UTC
I used a closure to avoid writing an in-line conditional that would be called with every iteration of the for loop. To me it made a great deal of sense, compared to: `for my $rec ( sort { if ($_ eq "PTR") { $a <=> $b} ; else { $a cmp $b +} } @{$dns_records{$_}} ) { # etc }` [download] David. Update: now I see the point. The function I'm using isn't really a closure..	[reply] [d/l]
Re^3: Syntax question about closures and Perl 'sort' by shmem (Chancellor) on Apr 03, 2009 at 23:55 UTC
Hm. You avoid cholera and get the pest. Not a good deal. I'd rather avoid creating and destroying an anonymous sub each time through a loop - so I'd write that as `{ my $subs = { num => sub { $a <=> $b }, cmp => sub { $a cmp $b }, }; for ( qw{ NS MX TXT HINFO SPF SRV A CNAME PTR } ) { if ( exists $dns_records{$_} ) { print_header("$_"); my $sortby = $subs->{ uc $_ eq 'PTR' ? 'num' : 'cmp' }; for my $rec ( sort { $sortby->() } @{$dns_records{$_}} ) { print $rec, "\n"; } } } }` [download] even if the optimizer would save my ass...	[reply] [d/l]
Re^3: Syntax question about closures and Perl 'sort' by jethro (Monsignor) on Apr 03, 2009 at 23:38 UTC
"isn't really a closure.." Exactly, even though it technically is a real closure. The unnamed sub will remember the value of $type as long as the sub exists (in that sense it is a closure). But since $type isn't used anywhere in the unnamed sub, it is of no consequence.	[reply]
Re^4: Syntax question about closures and Perl 'sort' by tilly (Archbishop) on Apr 04, 2009 at 04:41 UTC
Actually that is not quite right. If a variable is not visibly used in a returned subroutine, Perl cleans it up. You can verify that with this example: `sub create_closure { my $x = "x"; my $y = "y"; return sub { $y .= "y"; eval q{print "x: $x\ny: $y\n"}; }; } create_closure()->();` [download] And you will find that $x is not properly remembered, but $y is.	[reply] [d/l]
Re^5: Syntax question about closures and Perl 'sort' by jethro (Monsignor) on Apr 05, 2009 at 18:43 UTC
Re^3: Syntax question about closures and Perl 'sort' by Marshall (Canon) on Apr 05, 2009 at 05:28 UTC
How fancy you need to get is really a performance issue. The sort function takes in pairs of whatever the input list is, could be a list of anything. You provide a function that compares those "things". sort @array, use perl $a cmp $b criteria for sort sort {} @array, anon sub to provide decision function, returns <0,0,>0. sort myorder @array. myorder is a sub that provides same <0,0,>0 return values. Sticking some decision making inside the comparison function is not out of the question. I have an application that sorts some GUI columns. So I made a text or numeric comparison function so the low level's don't have to know what the data type is. This simplified the code. Most columns are alpha and this extra test in the compare really doesn't slow things down much - actually in this app, insignificant amount although my extra testing "looks" expensive. There is a fair amount of overhead in calling the comparison function but some easy "if" logic once you are there is not that expensive (your mileage may vary). Anyway I would consider embedding your test for "PTR" into the a mysortfunc. test it and see if there is any significant difference. There is no need for: return sub { $a cmp $b }, the sub you are writing is the thing that will return <0,0,>0! Don't call an anon sub within your sub. Just get on with the job of returning the required value. Oh, below I checked both $a and $b as there is some possibility of data corruption in this app. In your case, this appears to be unnecessary, just check one of them. Anyway, look at performance and you may find that something easier works very well. `sub alpha_num_cmp { my($a, $b) = @_; if (( $a =~ m/\D/) \|\| ($b =~ m/\D/) ) { #look for a non-digit return ($a cmp $b); #string compare } return ($a <=> $b); #straight numeric comparison } #used like: sort alpha_num_cmp @array;` [download]	[reply] [d/l]