Tracy R Reed wrote:
Tracy R Reed wrote:
So for the past year or two I have been reading up on functional
programming. I still haven't written anything useful with it but I
hope that will change soon. Here is an exchange I had with Chris
Seberino on IRC last night which I thought some of you might enjoy.
Summary: Anywhere you would iterate you can also recurse.
I don't believe that is true, but I'd have to think about it.
The problem is in cases where side effects are the end result.
Also, iteration is *by definition* O(1) in space. That is not true for
generalized recursion; it is true only for tail recursion.
But it usually results in less code and
fewer opportunities for bugs among other nice properties.
I don't believe that. The main problem is that iteration is overloaded.
One of the main uses for iteration in an imperative language is "do
action X to every element of Y". This always winds up with fencepost
and side effect errors.
Recursion doesn't solve this. The fact that functional languages
generally have "apply", "map", or "collect" generally is what removes
that type of bug. Imperative languages are finally growing "foreach"
which can be used equivalently.
Even so, in a functional language without iteration, when you have to
maintain multiple pieces of state simultaneously, those algorithms break
down and you wind up carrying a *lot* of extra state into a recursion to
do the same actions as you would with an iteration.
There is a reason why "loop" exists in Common Lisp. There is also a
reason why its existence therein is so contentious.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg