Re: Improve foreach with help of map?

I am having a conceptual problem with this question. Or, perhaps more significantly, I suspect this question may itself reflect a conceptual problem.

As I understand it, map is a functional programming construct. One of the tenets of functional programming (at least in "pure" form) is that actions do not have side-effects. Because of this, functional constructs are inherently parallelizable.

In other words:

for/foreach runs through a list of items sequentially, allowing each one to affect the environment as it goes. This includes alterations to the loop control, such as terminating the loop early with last.
map operates on all elements of the list independently and these operations should not affect the outside world. It is not a loop per se and this independence, if maintained, potentially allows for such things as handling elements concurrently in different contexts (multithreading/multiple CPUs/distributed systems/etc.) or optimizing the process by handling elements out-of-order. Allowing one element to abort or otherwise affect the handling of other elements violates this independence.

Based on this understanding, map is the wrong tool for this job, even if the implementation artifacts of current Perl implementations of map (i.e., behaving as if it's a loop) allow it to be coerced into doing it successfully.

Or have I misunderstood something here?

Comment on Re: Improve foreach with help of map? Select or Download Code

Replies are listed 'Best First'.
Re^2: Improve foreach with help of map? by Porculus (Hermit) on Oct 13, 2009 at 22:33 UTC
You're overthinking this. No need to worry about functional programming, purity, parallelisation, or any of that. The "map" concept in purely-functional programming languages is very interesting in its own right, but it has no more in common with Perl's `map` than mathematical functions have with Perl functions. Perl's `map` is the wrong tool for the job purely because it does not do the job very well. It is good at iterating over a complete array and returning a new array, while the job was, IIUC, to iterate over part of an array and return a scalar. If Perl's `map` did happen to do the job very well, then how could it be the wrong tool for it? For example, the pure FP map function must always produce exactly the same number of elements as it consumes. Perl's `map` can produce as many output elements as it likes for each input element, or it can skip it completely and produce nothing. In cases where that's desirable, it's perfectly appropriate to do it, without feeling guilty because a pure FP language would require an additional filtering step after the mapping was complete!	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Improve foreach with help of map?
by Porculus (Hermit) on Oct 13, 2009 at 22:33 UTC

You're overthinking this. No need to worry about functional programming, purity, parallelisation, or any of that. The "map" concept in purely-functional programming languages is very interesting in its own right, but it has no more in common with Perl's map than mathematical functions have with Perl functions.

Perl's map is the wrong tool for the job purely because it does not do the job very well. It is good at iterating over a complete array and returning a new array, while the job was, IIUC, to iterate over part of an array and return a scalar.

If Perl's map did happen to do the job very well, then how could it be the wrong tool for it? For example, the pure FP map function must always produce exactly the same number of elements as it consumes. Perl's map can produce as many output elements as it likes for each input element, or it can skip it completely and produce nothing. In cases where that's desirable, it's perfectly appropriate to do it, without feeling guilty because a pure FP language would require an additional filtering step after the mapping was complete!

[reply]
[d/l]
[select]