What do you guys think about having a kind of guided for-each loop, where the iterator can provide different ways you can go from current, and a parameter to the foreach loop decides which branch to take every iteration? You could iterate trees;  you could plug in different algorithms like depth-first or breadth-first walks.

You would need some kind of switch inside to decide which path to take.  And maybe it shouldn't be called foreach but maybe rather some kind of guided loop, that doesn't necessarily iterate over the entire container but rather follows a path, kind of like a search.  You could write a linear first to last traversal pretty easily.

Any ideas what this might look like in D?  I think we are going to need something more flexible than foreach, and bidirectional or unidirectional iteration.

Then again the apply() function might already be capable of this? Interesting...  You could certainly make a kind of iterator adapter class.

Sean

I like the idea of being able to page through the objects in a collection using different algorithms. Particularly, I think it's useful to be able to choose depth-first or bredth-first traversals for trees (I'm actually thinking specifically about xml documents). And I like the idea of being able to use a foreach construct to do the iterating.

But I don't think it warrants a specific language feature.

I think it would be more appropriate to create a templated Cursor class that could be instantiated with 1) the type of class to be iterated over, and 2) the type of algorithm to use inside of the iteration. The templated class would have an apply function for each of the different algorithms.

[NOTE: I'm not sure if you can use template syntax to decide which version of a function to use inside of a class. And I'm pretty sure you can't have more than one apply() function, so you might have to create a different template for each algorithm that you might want to instantiate.]

--Benji Smith

In article <bkom9h$2018$1@digitaldaemon.com>, Sean L. Palmer says...
>
>What do you guys think about having a kind of guided for-each loop, where the iterator can provide different ways you can go from current,
> [...]

I'm sorry but I have to show my ignorance...

Should this kind of cursor be implemented at the language level?
Can't you make some decisions in a while(){} cycle?
Are there examples of other languages with these complex cursors?

this idea is completly new to me...

When do we (Walter) decide that some feature is too high level for
a language?

Ant

Sean L. Palmer wrote:
> What do you guys think about having a kind of guided for-each loop, where
> the iterator can provide different ways you can go from current, and a
> parameter to the foreach loop decides which branch to take every iteration?
> You could iterate trees;  you could plug in different algorithms like
> depth-first or breadth-first walks.
> 
> You would need some kind of switch inside to decide which path to take.  And
> maybe it shouldn't be called foreach but maybe rather some kind of guided
> loop, that doesn't necessarily iterate over the entire container but rather
> follows a path, kind of like a search.  You could write a linear first to
> last traversal pretty easily.

My intuition is that this should be done using a wrapper iterator object.

Something like this:

foreach(TreeElement el ; new DepthFirstTreeIterator(someTree))
	...

That way you can implement the traversal any way you like but at the same time the language constructs are kept simple.

Hauke

It probably is too high level for the core language... I was just wondering if that, since it doesn't really appear to fit under foreach, might warrant some new kind of language construct..  But yeah, I guess good old while will work.

Sean

"Ant" <Ant_member@pathlink.com> wrote in message news:bkonvm$22b0$1@digitaldaemon.com...
> In article <bkom9h$2018$1@digitaldaemon.com>, Sean L. Palmer says...
> >
> >What do you guys think about having a kind of guided for-each loop, where the iterator can provide different ways you can go from current,
> > [...]
>
> I'm sorry but I have to show my ignorance...
>
> Should this kind of cursor be implemented at the language level?
> Can't you make some decisions in a while(){} cycle?
> Are there examples of other languages with these complex cursors?
>
> this idea is completly new to me...
>
> When do we (Walter) decide that some feature is too high level for
> a language?
>
> Ant

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bkom9h$2018$1@digitaldaemon.com...
> Then again the apply() function might already be capable of this?

Yes, it is!

> Interesting...  You could certainly make a kind of iterator adapter class.

Yes.

"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bkp153$2fsv$1@digitaldaemon.com...
> My intuition is that this should be done using a wrapper iterator object.
>
> Something like this:
>
> foreach(TreeElement el ; new DepthFirstTreeIterator(someTree))
> ...
>
> That way you can implement the traversal any way you like but at the same time the language constructs are kept simple.

Yes. In fact, I have an example somewhere that shows how you can use this to iterate over an array in reverse!

"Walter" <walter@digitalmars.com> wrote in message news:bkr33g$2ajg$1@digitaldaemon.com...
>
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
> > That way you can implement the traversal any way you like but at the same time the language constructs are kept simple.
>
> Yes. In fact, I have an example somewhere that shows how you can use this
to
> iterate over an array in reverse!

You just need to know some other avenue of accessing the values than apply().  operator[] or something.  But then you get into inefficiency again, going through the public interface, using indexing.  And in the end we'll end up with a profusion of access functions, with each container specifying different, incompatible interfaces.

Sean

Sean L. Palmer wrote:
> You just need to know some other avenue of accessing the values than
> apply().  operator[] or something.  But then you get into inefficiency
> again, going through the public interface, using indexing.  And in the end
> we'll end up with a profusion of access functions, with each container
> specifying different, incompatible interfaces.

Well, the obvious solution would be that the Tree itself provides the iterator object, so it can work directly on the internal data structures.

But this gave me another idea:

Walter, what do you think about allowing delegates to be passed to foreach? That way one could simply define different public iterator methods that could be specified directly.

For example:

class Tree
{
public:
	int depthSearch(int delegate(inout TreeElement) dg);
	int breadthSearch(int delegate(inout TreeElement) dg);
};

Tree someTree=new Tree;

foreach( TreeElement el; &someTree.depthSearch )
	...


Sometimes this may be come in handy.


Hauke