🚀 go-pugleaf

In article <1139@PT.CS.CMU.EDU> edw@IUS1.CS.CMU.EDU (Eddie Wyatt) writes:
]The debate about CLU iterators misses an important point: CLU iterators are
]coroutines, which C does not have.  The implication is that per-iteration
]state is nicely hidden in CLU ("on the stack" in the coroutine local
]variables), and has to be explicitly managed in C (or any other coroutine-free
]language) by putting the state into globals or making the user hang on to the
]state.

In article <22162@bbn.COM> schooler@oak.bbn.com (Richard Schooler) writes:
>But do you need coroutines to implimented generalized iteration?  I think not.
>The optional solution I posted should allow you to perform the same task.  

The CLU iterators are not general coroutines, but a special case that allows
them to be implemented with the conventional activation stack.  The use of
iterators reduces programmer effort.  It does not make something possible that
was not previous possible.

>The optional solution was to provide the iteration function a function to
>invoke on each member of the enumerated list.  A single call would be made to
>iterate through the list. ... [inorder tree traversal example deleted] ...
>I do see one problem though, which is dealing with variable referenced inside
>the loop.  They would have to become global.  Comments as to why this method
>might not work in general?

The method can work in general.  In fact, it is very powerful in general. 
However, it requires nested functions so that the loop-body-function can gain
access to the local variables of the code wanting the loop.  This only becomes
convenient when the language allows inline function defininition (something
like BCPL's value-yielding blocks).  
-- 
  Lawrence Crowl		716-275-9499	University of Rochester
		      crowl@cs.rochester.edu	Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl	Rochester, New York,  14627