If your concern is $a and $b, then see other replies.

If your concern is the first line of your usage documentation:

reduce \&f @x
[download]

then you are out of luck. Part of the point of that syntax is that the function name is optional. And that is one of the "prototypes" that is available to built-ins but isn't available to user functions. Note that prototype("CORE::sort") returns undef to indicate that its calling conventions can't be expressed in a sub prototype.

Check opcode.pl in the Perl source and you'll see that sort's argument processing is defined by "dm@ C? L". User defined functions don't have access to all of those flags. The "?" means that you can just leave off the code part, which would make no sense for a "reduce" implementation.

If you use the typical "sub reduce(&@)" prototype, then you can always pass a code ref to your function via &reduce( \&f, ... ). You can also usually drop the & or even the parens, but I suspect that might vary between versions of Perl. See Algorithm::Loops for some comments on quirks in what types of arguments sort can deal with on different versions of Perl, since the quirks appear to be similar. But it looks like you can get away with that syntax except for leaving off the comma on all recent Perls. The lack of the comma has to do with sort making the subroutine name optional so you shouldn't emulate that part anyway.

I think you have to enter the local variables $a and $b into the caller's namespace.

so should Language::Functional

---

Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

Is the problem you are having in placing this function into a module? If that is the case, then the problem is getting ahold of the caller's $a and $b. Check out the code from reduce in List::Util.

sub reduce (&@) {
  my $code = shift;
  no strict 'refs';

  return shift unless @_ > 1;

  use vars qw($a $b);

  my $caller = caller;
  local(*{$caller."::a"}) = \my $a;
  local(*{$caller."::b"}) = \my $b;

  $a = shift;
  foreach (@_) {
    $b = $_;
    $a = &{$code}();
  }

  $a;
}
[download]

Update: D'oh, a day late and a dollar short.

The use vars isn't necessary, since you're using a lexical $a and $b.

I was wondering about that when I copied the code over. My conjecture was that use vars was needed for an older version of perl, but I have no guess as to why an older perl might need it or what version of perl needs it.

Good Day,
    Dean

My question is how can I get it to have semantics exactly like sort?

my @A = mysort { lc $a cmp lc $b } @list;
my @B = mysort @list;
[download]

I don't think you can, as the mandatory arguments must occur before the optional.

Also note that sort is missing from the list of examples in perlsub. grep is listed, but grep's code block is mandatory.

sub mysort(&@) {
  my $func = shift;
  sort $func @_
}
[download]

What exactly do you mean by "sort-like semantics"?

What do you mean by "mean"?

Are you looking how to do "If the subroutine's prototype is ($$)"? prototype.

use strict;
use warnings;

sub reduce(&@) {
   my $f = shift;
   my $a = shift;

   if (prototype($f)||'' eq '$$') {
      $a = $f->($a, shift) while @_;
   } else {
      my $b;
      no strict 'refs';
      my $caller = caller();
      local *{$caller."::a"} = \$a;
      local *{$caller."::b"} = \$b;
      $b = shift, $a = $f->() while @_;
   }

   return $a;
}


sub prototyped($$) { $_[0] * $_[1] }
sub unprototyped   { $a * $b }


$\ = "\n";
print reduce { $a * $b }     1..6;  # 720
print reduce \&prototyped,   1..6;  # 720
print reduce \&unprototyped, 1..6;  # 720
[download]

Update: Adjusted to use the caller's package.

What if we skipped checking the prototype and set up both @_, and $a and $b?

sub reduce(&@) {
   my $f = shift;
   my $a = shift;
   my $b;

   our @args;
   (local *_, local *args) = (sub { \@_ }->($a, $b), \@_);

   no strict 'refs';
   my $caller = caller();
   local *{$caller."::a"} = \$a;
   local *{$caller."::b"} = \$b;

   $b = shift(@args), $a = &$f while @args;
   return $a;
}
[download]

Turns out it's negligeably faster for moderately long lists.

          Rate ike1_p ike1_n ike2_p ike1_i ike2_i ike2_n
ike1_p 6.34/ms     --    -2%    -2%    -4%    -6%     -7%
ike1_n 6.46/ms     2%     --    -1%    -3%    -4%     -5%
ike2_p 6.50/ms     3%     1%     --    -2%    -3%     -4%
ike1_i 6.63/ms     5%     3%     2%     --    -1%     -2%
ike2_i 6.72/ms     6%     4%     3%     1%     --     -1%
ike2_n 6.79/ms     7%     5%     4%     2%     1%      --

(I)nline:        reduce { $a * $b }     1..100;
(P)rototype:     reduce \&prototyped,   1..100;
(N)o prototype:  reduce \&unprototyped, 1..100;
[download]

Full Results

Benchmark code