Patrick Down wrote:

> Yes this is true.  I was trying to find a quick example that demonstrated more than one iterator.  D's opApply and foreach already provide good single iterator functionality.

"good" - yes - but still far from what Sather iterators offer. Just take a look at the opApply-example from the D-specs:

----------------------------------------
       class Foo
        {
            uint array[2];

            int opApply(int delegate(inout uint) dg)
            {   int result = 0;

                for (int i = 0; i < array.length; i++)
                {
                    result = dg(array[i]);
                    if (result)
                        break;
                }
                return result;
            }
        }

        void test()
        {
            Foo a = new Foo();

            a.array[0] = 73;
            a.array[1] = 82;

            foreach (uint u; a)
            {
                printf("%d\n", u);
            }
        }
----------------------------------------

This would translate to the following, using Sather iterators:

----------------------------------------
       class Foo
        {
            uint array[2];

            elt#()
            {
                for (int i = 0; i < array.length); i++)
                    yield array[i];
            }
        }

        void test()
        {
            Foo a = new Foo();

            a.array[0] = 73;
            a.array[1] = 82;

            loop
            {
                printf("%d\n", a.elt#());
            }
        }
----------------------------------------

and this simplification is not just because the example was so simple...

As you can see from the example: the real power of Sather iterators lies not primarily in their use, but in their definition. C++-iterators and D-foreach loops are both fairly comfortable to use, but defining them for just moderately complicated structures is rather tricky. Sather iterators actually are fun to implement yourself!

Sather iterators as described here seriously reminds me of this

http://msdn.microsoft.com/netframework/archive/default.aspx?pull=/msdnmag/issues/04/05/c20/default.aspx

<quote>
public class CityCollection : IEnumerable
{
   string[] m_Cities = {"New York","Paris","London"};
   public IEnumerator GetEnumerator()
   {
      for(int i = 0; i<m_Cities.Length; i++)
         yield return m_Cities[i];
   }
}
</quote>

Looks Satherish. The article explains "new" features of C# 2.0.

Bent Rasmussen wrote:

> Sather iterators as described here seriously reminds me of this
> 
>
http://msdn.microsoft.com/netframework/archive/default.aspx?pull=/msdnmag/issues/04/05/c20/default.aspx
> 
> <quote>
> public class CityCollection : IEnumerable
> {
>    string[] m_Cities = {"New York","Paris","London"};
>    public IEnumerator GetEnumerator()
>    {
>       for(int i = 0; i<m_Cities.Length; i++)
>          yield return m_Cities[i];
>    }
> }
> </quote>
> 
> Looks Satherish. The article explains "new" features of C# 2.0.

Indeed, this shows some similarity. I'm not really sure, whether it really captures the whole concept. Have to check that more thoroghly.

Bent Rasmussen wrote:

> Sather iterators as described here seriously reminds me of this
> 
>
http://msdn.microsoft.com/netframework/archive/default.aspx?pull=/msdnmag/issues/04/05/c20/default.aspx
> 
> <quote>
> public class CityCollection : IEnumerable
> {
>    string[] m_Cities = {"New York","Paris","London"};
>    public IEnumerator GetEnumerator()
>    {
>       for(int i = 0; i<m_Cities.Length; i++)
>          yield return m_Cities[i];
>    }
> }
> </quote>
> 
> Looks Satherish. The article explains "new" features of C# 2.0.

Took another look at it. Actually, it captures quite a bit of the idea from Sather, anyhow, there is one fundamental difference:

In C#, an enumerator is an object of a class with a certain interface. Implementing and using an iterator looks very similar to Sather. The difference lies in what happens internally: C# takes the iterator routine containing the different yields and *decomposes* it into a class with the appropriate interface in such a way that it can be used in foreach loops.

In Sather, an iterator is a basic concept of the language without any classes etc. involved. This makes it possible, to implement the whole thing completely on the stack, inline iterators and in principle allows to boost the speed of iterator loops to the same speed as plain C loops. I strongly doubt that you will ever get similar performace out of the C# iterators.

The implementation in Sather does not exploit this possibility, since this would not be possible within ANSI C. I have no idea whether the Sather developers ever realized that this might be possible, but the concept definitely allows it and it should be possible to introduce the same concept in D.

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c8nmsn$uil$1@digitaldaemon.com...
> Consider what you usually have to code to traverse a binary tree or other structures. Of course, C++ iterators allow traversal as well, but they are somewhat more complicated to use and by far more complicated to implement, especially in recursive data structures, where the iterator has to create it's own stack to keep track of the current position.

D's 'foreach' will do the same as the above in about the same amount of code
(for opApply()). Where Sather's iterators are better are:

1) multiple different iterators in the same loop
2) having multiple iterators for a class to access the members in different
orders

> Sather iterators are generally only "forward iterators", best compared to streams, that yield one element after the other until they quit. There is no need to check for the end of the stream, since the loop is
automatically
> broken as one iterator quits. (Even in the middle of an expression, like
in
> the above case, where there is no additional "garbage line" printed.)

I don't get that. When an iterator ends, exactly when is this checked for in the loop? The middle of the expression?

Thanks. Your explanation makes sense, but I have to think about it some more. There are other issues at stake, like cleanup of auto classes on the stack.

Oh, please!

That's one of the most stupid things I've ever heard. Almost, but not quite, as bad as the idiot I used to work with who did

    #define retrun return

just because he mistyped it so often.

for(;;) is a recognised and recommended way of defining a non-claused loop. Why would you not use that?

Remember, one man's cool is many other's naff/trite/stupid/etc.

"James McComb" <alan@jamesmccomb.id.au> wrote in message news:c8hast$1nt7$1@digitaldaemon.com...
> Here's another thing the preprocessor can do that mixins can't do.
>
> This is the kewl way I used to write forever loops:
>
> #define EVER ;;
>
> for(EVER) { /* more kewl code */ }
>
> So much for mixins. ;)
>
> James McComb

> Convincing Walter is not too hard, it just means making some work, which is:
> - sum up the usage cases;
> - propose an implementtion strategy;
> - convince Mr. Wilson.
>
> Which should usually result in the Walter being convinced, or the proposer un-convinced. :>

Who's this _Mr_ Wilson, then, eh?

:-)

Walter wrote:

> 
> "Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c8nmsn$uil$1@digitaldaemon.com...
>> Consider what you usually have to code to traverse a binary tree or other structures. Of course, C++ iterators allow traversal as well, but they are somewhat more complicated to use and by far more complicated to implement, especially in recursive data structures, where the iterator has to create it's own stack to keep track of the current position.
> 
> D's 'foreach' will do the same as the above in about the same amount of
> code (for opApply()).

True, when I wrote the above, I had not yet fully understood opApply. Anyhow: Sather iterator definitions are yet more compact than the definition of opApply.

>> Sather iterators are generally only "forward iterators", best compared to streams, that yield one element after the other until they quit. There is no need to check for the end of the stream, since the loop is
> automatically
>> broken as one iterator quits. (Even in the middle of an expression, like
> in
>> the above case, where there is no additional "garbage line" printed.)
> 
> I don't get that. When an iterator ends, exactly when is this checked for in the loop? The middle of the expression?

Exactly. When the iterator quits, it does not return any value at all, but instead causes the enclosing loop to jump directly out of the loop and clean up the loop-stackframe.

If this happens within an expression, this expression can, of course, not be continued, since there is no value that could be used, so the loop is broken in the middle of that expression.

In expressions with side-effects, this may, of course, cause some undefined behaviour, but that is just a matter of D not guaranteeing the order of calls within an expression.

Walter wrote:

> Thanks. Your explanation makes sense, but I have to think about it some more. There are other issues at stake, like cleanup of auto classes on the stack.

Sather disallows yield-statements in the middle of try/catch blocks. Auto classes probably are a similar issue.

Are auto classes bound to a function or to a block? I cannot find that documented in the specs.

If they are bound to blocks, you might want to disallow yield statements within a block that contains auto classes. Otherwise you would have to completely prohibit auto classes in iterators.

In any case, the principle is, that you never know whether execution will continue after a yield statement. The cleanup of the stackframe can be done be the enclosing loop. Any other cleanup must not be necessary.

Anyhow: It is clear that this whole thing will need a lot of consideration. Iterators are a rather orthogonal addition to the existing language, but once they are used, the will affect the language rather fundamentally. Did I talk about that high addiction-potential? After using Sather for some time, I really had a hard time to do without iterators in C++...