Path: utzoo!mnetor!uunet!husc6!mit-eddie!bbn!rochester!PT.CS.CMU.EDU!IUS1.CS.CMU.EDU!edw
From: edw@IUS1.CS.CMU.EDU (Eddie Wyatt)
Newsgroups: comp.lang.misc
Subject: Re: From Modula to Oberon
Message-ID: <1131@PT.CS.CMU.EDU>
Date: 15 Mar 88 22:14:41 GMT
References: <2827@enea.se> <1557@pasteur.Berkeley.Edu> <3764@bloom-beacon.MIT.EDU> <7747@sol.ARPA>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 48

In article <7747@sol.ARPA>, crowl@cs.rochester.edu (Lawrence Crowl) writes:
> 
> Eddie Wyatt's proposal is not as general as CLU iterators.  In particular, (as
> Peter J Desnoyers points out) you can easily implement a tree traversal in CLU,
> but you must allocate and maintain a stack of nodes in order to implement tree
> traversal under the separate function scheme.

1)   For trees you could have secondary threads.  iter_func(x,START)
could traverse the tree in any order you want, setting up the threads
and returning the first element of the list. Successive  calls
could just return the next element off the list.  Point being,
with a little imagination you can do it. (Basically, the tree will
ask act as a stack, too).
  
2)   The other option is to proceed in the inverse direction. Provide
the iteration function a function to be invoke on each node.

> 
> Another problem is that objects must have distinct TERMINATOR values.  This is
> not generally true.

  The change the format to:

	BOOL iter_func(data_type,flag,ret)  

	for (ret = iter_func(data_type,START,&val); 
	     ret == TRUE; 
	     ret = iter_func(data_type,NEXT,&val)) {...}
> 
> The suggestion of using "either a static var or extra field in the data type"
> fails when two iterations may proceed on the same structure at the same time.
> (Note that this can happen without concurrency, but I admit it is rather rare.)

Option number 2 may solve this, but see final comment.

> 
> You can do all your data abstraction and programming in assembler.  The issue
> is what language constructs make such programming *effective*, not just
> possible.

FINAL COMMENT
This kind of reminds me of the critisms of Algo's iteration as being 
too barique.  And in being so, it tended to compile to very
inefficient code.  Is the same true for CLU?  Comments?

-- 

Eddie Wyatt 				e-mail: edw@ius1.cs.cmu.edu