Here's your multimap BLOCK LIST, LIST... (with a practical limitation).

#! perl -slw
use strict;

sub multimap (&\@;\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@\@) {
    my $code = shift;
    map {
        my $i = $_;
        $code->( map{ $_->[ $i ] } @_ )
    } 0 .. $#{ $_[ 0 ] };
}
my @l = 'a' .. 'z';
my @u = 'A' .. 'Z';
my @n = 1 .. 26;

print for multimap { join ', ', @_ } @u, @n, @l;
__END__
P:\test>464573
A, 1, a
B, 2, b
C, 3, c
D, 4, d
E, 5, e
F, 6, f
G, 7, g
H, 8, h
I, 9, i
J, 10, j
K, 11, k
L, 12, l
M, 13, m
N, 14, n
O, 15, o
P, 16, p
Q, 17, q
R, 18, r
S, 19, s
T, 20, t
U, 21, u
V, 22, v
W, 23, w
X, 24, x
Y, 25, y
Z, 26, z
[download]

I must admit, I frowned at your prototype.. but then i checked, and I found out that the author of List::MoreUtils has implemented a couple of his functions in exactly the same way - though his prototypes are with 25 arrays.. I find it mildly disturbing that he did not bother with documenting this...

I don't like the prototype in this case either, it heralds too many limitations in use. The practical ones of artificially limiting the number of arrays it can operate on, but more fundementally, the fact that you can only use real arrays.

With the caveat of requiring the user to pass an AoA ref, the function becomes much more flexible and makes writing transpose LOL trivial:

#! perl -slw
use strict;
use Data::Dumper::SLC;

sub multimap (&$) {
    my( $code, $aref ) = @_;
    return unless ref $aref eq 'ARRAY';
    map {
        my $i = $_;
        $code->( map{ $_->[ $i ] } @$aref )
    } 0 .. $#{ $aref->[ 0 ] };
}
my @l = 'a' .. 'h';
my @u = 'A' .. 'H';
my @n = 1 .. 8;

print for multimap { join ', ', @_ } [ \( @u, @n, @l ) ];

sub transpose {
    return multimap{ [ @_ ] } $_[ 0 ];
}

my @LoL = ([1,2,3],[2,3,5]);
my @transposed = transpose \@LoL;

Dump \@transposed;

__END__
P:\test>464573
A, 1, a
B, 2, b
C, 3, c
D, 4, d
E, 5, e
F, 6, f
G, 7, g
H, 8, h
[ [ '1', '2',  ], [ '2', '3',  ], [ '3', '5',  ],  ]
[download]

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

use Algorithm::Loops 'MapCar';

my $wide = [[1,2,3],[2,3,5]];
my $tall = [ MapCar {[@_]} @$wide ];
[download]

Thank you for finding MapCar. That does a lot of what I need.

So yeah, I just realized that fold_left can be written by simply calling reduce with the same arguments (so that fold_left's initial becomes the first element of reduce's input). But fold_right does require two reverses, in the following sense: suppose I wanted to compare left- and right-associative subtraction. Then, I have to reverse once to change a call of fold_right into fold_left but then I also have to change the order of arguments into the block.

Well, I really want sum to be reduce { $a + $b } 0, @input, so that would make multiplication reduce { $a * $b }, 1, @input. Note that sum is not reduce internally. Here's the code:

sum(...)
PROTOTYPE: @
CODE:
{
    SV *sv;
    int index;
    if(!items) {
        XSRETURN_UNDEF;
    }
    sv = ST(0);
    RETVAL = slu_sv_value(sv);
    for(index = 1 ; index < items ; index++) {
        sv = ST(index);
        RETVAL += slu_sv_value(sv);
    }
}
OUTPUT:
    RETVAL
[download]

Within List::Util source, sum is defined:

sub sum (@) { reduce { $a + $b } @_ }
[download]

Where is the code you quoted from?

---

Caution: Contents may have been coded under pressure.

nah, you can't, you'd also have to keep the sign information and short-circuit on 0s.. unless you promise to only multiply positive numbers..

other than that, all points are spot on.