Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!uoft02.utoledo.edu!desire.wright.edu!ctodd
From: ctodd@desire.wright.edu
Newsgroups: comp.edu
Subject: Re: Recursion Summary
Message-ID: <1990Oct29.172158.1670@desire.wright.edu>
Date: 29 Oct 90 22:21:58 GMT
References: <1990Oct23.211651.10227@contact.uucp> <9868@milton.u.washington.edu> 
 <9882@milton.u.washington.edu> <9893@milton.u.washington.edu> <9898@milton.u.washington.edu>
Distribution: na
Organization: University Computing Services, Wright State University
Lines: 23

In article <9898@milton.u.washington.edu>, mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:

> 
> However, in some cases the only nonrecursive way to implement an
> algorithm involves, in effect, emulating recursion.  These are
> algorithms which have significant intermediate state which is needed
> after the recursive call completes.  This requires a stack, or at
> least a vector, and control logic for two iterations.  Let's not
> forget algorithms in which the recursion takes place several routines
> deep (foo->bar->zap->rag->foo).
> 
> Matters are further complicated in a multi-tasking environment, where
> a particular routine must be reentrant and hence cannot use any global
> variables.  Here, a stack is mandatory.  You don't even need multiple
> processes; co-routines will do just fine.
> 

Who cares? The original statement was a simple expression of truth. 

Anything that can be done recursively can be implemented in a non-recursive
manner! Anything! Of course the implementation is going to take more code!!!
If it didn't why would we need recursion. And isn't anything which takes the
place of recursion, "in effect, emulating recursion."