in reply to Iterative vs Recursive Processes

Tail recursion optimization is one of those interesting subjects that seems to fascinate people (for what to me are admittedly obscure reasons :-) and generate a lot of hoopla every so often. Perl doesnt handle this type of optimization, but its not a big loss. Since all tail recursion optimization does is provide a fancy way to write a while loop you can still do the same thing without it (and IMO have clearer code, but thats another story....) I guess my point here is not to get too hung up on the recursion vs iteration.

Incidentally I should mention that it is very much worth the challenge to take recursive routines and reimplement them iteratively in my opinion. A really good example is implementing tied hashes. If you are using a tree for the underlying data structure, the inclination is to implement your algorithms recursively, (FETCH, STORE and the like). However you are then stuck with a problem: how to implement FIRSTKEY() and NEXTKEY(). Typically you need a way to represent the stack state of the recursion internally to the object. This essentially necessitates implementing the standard tree recursion iteratively with your own stack, which can be quite tricky if you've been thinking heavily recursively immediately before.

Also in cases of optimization often eliminating recursive algorithms produces signifigant speedups because of the fine grained resource management that iteration both provides and requires. Just the other day I reworked a recusive tree algortihm to use iteration and saw over 150% speedup for my efforts. Although granted the original code was hardly as efficient as it could be.

I find that a lot of the time ill code something the first time recursively, and then rewrite it iteratively given what ive learned. Anyway. :-)

I hope you keep posting issues from your reading. So far its been interesting stuff. Cheers.


---
demerphq

<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...