Re^3: reduce like iterators

Your reduce_list is named similarly to reduce, but bears no resemblance since it doesn't to reduce at all.

reduce allows an arbitrary state to be passed from one pass to another. Your reduce_list doesn't.
reduce can return any value, not just the input. reduce_list can return at most one scalar, and it can only be the input. (That's not very "listy"!)

Because of those reasons, reduce is a general purpose function. (It can implement any other function in List::Util.) Your reduce_list is just grep with access to the last element.

This accounts for the differences with what I suggested it should look like.

Comment on Re^3: reduce like iterators Select or Download Code

Replies are listed 'Best First'.
Re^4: reduce like iterators by LanX (Saint) on Jan 03, 2011 at 22:08 UTC
As already stated in the OP the need to appropiately name a whole new family of reduce-like iterators is an extra problem. At least for me it's more complicated than implementing them. But if it's easier for you to baptize reduce-like `map`s, `grep`s, `part`s, and so on in a quick post, I would appreciate to hear your suggestions If I was forced to chose only one implementation I would certainly chose a reduce like `map`, like you did, because it has the biggest flexibility. But I'd prefer to have a solution where map is still named map and grep ist still grep! IMHO extra options and special vars should activate and supply the needed functionality. Cheers Rolf	[reply] [d/l] [select]
Re^5: reduce like iterators by ikegami (Patriarch) on Jan 03, 2011 at 23:17 UTC
As already stated in the OP the need to appropiately name a whole new family of reduce-like iterators is an extra problem. Your always free to not give it a name, leaving it as `my @b; for (@a) { push @b, $_ if !@b \|\| $_ ne $b[-1]; }` [download] or `my @b = list_reduce { 0, $a \|\| $b ne $_->[-1] ? $b : () } 1, @a;` [download] But they're not very readable. But I'd prefer to have a solution where map is still named map and grep ist still grep You complain that there's "a lack of iterators allowing to compare successive elements", yet you wouldn't want to use them if they existed?	[reply] [d/l] [select]