Front page | perl.perl5.porters |
Postings from April 2008
* David Nicol <davidnicol@gmail.com> [2008-04-12 06:26]:
> Here cmap is like map but it runs its block in scalar context
> and the block is expected to provide one output for each input,
> also the array expression needs to be in parentheses.
Of course, the fact that Perl’s `map` can produce an arbitrary
number of output elements per input element is an extremely
useful property that I explicitly rely on quite a lot:
my %foo = map { split /:/, $_, 2 } @bar;
That’s an example where each input element corresponds to more
than one output element, but always corresponds to the same
number. However, even that isn’t always a given; in particular,
the ability to return 0 output elements for some input elements
but not for others can be extremely useful:
my @kw = map { /^keyword: *(.*)/ } @props;
Expressing this particular idiom in any other fashion is
significantly more cumbersome. Finally, sometimes you have both
cases combined:
my @n = map { /(\d+)/g } @m;
It is also sometimes convenient that the following are
equivalent:
my @match = map { foo($_) } grep { bar($_) } @candidate;
my @match = map { bar($_) ? foo($_) : () } @candidate;
Depending on circumstances the second one is sometimes easier to
write/read.
Of course, there is another very obvious and clearly useful case
that is impossible to write with `map` if you enforce 1:1
correspondence:
sub flatten { map @$_, @_ }
All of these cases are so useful and common that I would greatly
resent having them taken away in the name of performance.
In many of them, particularly if they happen in a chain of maps
and filters, and especially if several 1:m mappings happen, it
seems to me that deforestation can improve the best case and help
a good deal with the average case, but will have the same worst
case behaviour as before.
Of course, that still presents a potentially worthwhile goal.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Thread Previous
|
Thread Next