Bart Lateur wrote:
>
> I have some reservations about this reduce() thing. Plain and simple
> incorporating it into the core language would introduce the chance for
> lots of buggy programs, like the example Arial gave. In fact, I think
> that *most* programs that use reduce() would be buggy.
Whenever people try to use language features with which they are but
passingly familiar (or grossly unfamiliar), buggy programs result.
Again, your argument could also be applied to OO -- but perl isn't
dropping OO any time soon.
> We are used to thinking of associative operators, like "+" and "*",
> where [operator order] makes no difference.
>
> Besides, in functions like map() and grep(), execution order shouldn't
> matter. I think that *still* the processing order of the arguments isn't
> officially stated as "always from left to right" ...
> So, what's it going to be here?
The answer to this objection is simply to declare an official order
of execution. Left-to-right.
> I think that if your code depends on execution order, you
> shouldn't be using this functional programming paradigm.
Wrong. Functional programming is in some sense merely procedural
programming but without side-effects. There's no golden rule of FP
saying execution order is irrelevant; and I don't see how there could
be. Maybe you're getting it confused with declarative programming...
> I think we don't really need reduce().
Some people thought perl would have been better off without OO, too.
Should Larry of listened to them? Or should he have listened to the
significantly larger number of people (including himself) who though
OO would be a good addition to perl?
> There are well working,
> relatively simple, and *far more transparent* alternatives, at least,
> for Perl.
So, you're saying recursion should be eliminated from perl.
I don't think that's gonna fly.
> $total = 0;
> map { $total += $_ } @list; # if you insist...
> return $total;
>
> How is this so bad, compared to:
>
> reduce { $_[0] + $_[1] } @list
>
> Is the latter shorter? Hardly.
Huh? It's significantly shorter. It's one statement vs. three, and
requires no temporary variables.
> Would it be faster? I doubt it.
What do you base that on? The fact that the reduce() version would
involve so many more costly perl OPs?
--
John Porter
