or one man's bate is another mans meal ;)

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c8pji6$k82$1@digitaldaemon.com...
> 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.

Auto classes are just like stack classes in C++ - they are cleaned up on exit from the block.

> 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.

That is one solution - just disallow them.

> 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++...

I can see how they'd encourage a different way of thinking about iteration <g>.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c8p5i7$303j$1@digitaldaemon.com...
> Oh, please!

I think he was just kidding. It's in the same category as:

    #define BEGIN {
    #define END }

which was popular practice in the mid 1980's. As Pascal asymptotically approached 0 users (*), people got bored with trying to remake C in Pascal's image and the community began to realize that it was better to write things in the C style when using C.

(*) Pascal was all but dead and buried when Borland briefly re-animated it with Turbo Pascal. TP burned white hot for a couple years, but the C blob inevitably absorbed it as well. I suspect that having to type BEGIN END instead of { } was its downfall <g>.

In article <c8kemm$24vv$1@digitaldaemon.com>, Norbert Nemec says...
>
>Conclusion: If Walter is willing to invest some time in looking into the concept of Sather iterators, I promise that he will find the absolute killer feature for D with extremely high addiction potential. Otherwise, I don't think there is much point in discussing the matter on this list.

I guess Walter is 130% busy right now.

Better would be to write a few short but powerful examples!

If Walter sees the important guys here getting convinced, then he probably will pay attention. (And that is as it shoud!)

>>> [...] But maybe the
>>> language should have a special "endless loop" construct?
>> 
>> Why a special? Sather, a very sympathic language (though by far not as useful as D), only has one looping construct. Exactly, it's an endless loop, called "loop". Then the only other thing you need is to break out of it. For example using an iterator. "i ::= 1.upto!(5);" will loop 5 times assigning increasing values to i from 1 to 5. There are also many other itaertors defined. After it's finished, it breaks out of the loop automatically. You can have multiple interators within 1 loop as well, and well, the one that breaks first wins. :>
>
>Don't underestimate the complexity behind this. Sather loops/iterators are the most powerful loop concept of any language and allow lots of stuff, that simply is not even remotely possible in other languages.
>
>Anyone who has ever used Sather and tried to return to some other language afterward will have experienced the problem of expressing their ideas without Sather iterators. Anyhow: I doubt that there is a chance to make someone, who has never actually used Sather understand the idea and the power of it.
>
>The concept could certainly be added cleanly to D and it would definitely mean an unbelievable boost of the power of the language, but I see little chance to ever convince Walter to even think about it.
>
>B.t.w: "Sather iterators" are something completely different from "C++ iterators". They cannot be simulated in C++ at all. There is some similarity to coroutines in Modula, but unlike some clumsy coroutine implementations in C++, Sather iterators are not based upon expensive frame switches, but work cleanly on one stack. I do not know whether the intermediate languages of the DM/gcc backend are powerful enough to support them, or whether you would have to go down to assembler language.
>
>Conclusion: If Walter is willing to invest some time in looking into the concept of Sather iterators, I promise that he will find the absolute killer feature for D with extremely high addiction potential. Otherwise, I don't think there is much point in discussing the matter on this list.
>

Anyway, CLU has have such a construct decades before. ICON has them, too. So it's not a new idea of sather. They just copied it.

Matthias Becker wrote:
> Anyway, CLU has have such a construct decades before. ICON has them, too. So it's not a new idea of sather. They just copied it.

I know neither CLU nor ICON. Of course, language constructs are hardly every new. Languages evolve from each other, copying ideas and improving them.

Anyhow: I know many languages have features similar to Sather iterators, but none of them (as far as I have found it) captures the full power.

Python "generators" seem to come very close, but they are fundamentally based on using an exception to break the iteration, which is inacceptable for a compiled language striving for performance. Also, Python iterators can only be used in the head of a "for-in" loop.

Modula-III Coroutines seem similar, but they are only loosely synchronized and demand expensive frame-switching.

Several functional languages with infinite lists allow similar constructs, but the concept is closely tied to the functional character of the language and can not easily be translated to multiparadigm languages.

About any modern language has something that is called "iterator" but usually, it has little to do with Sather iterators.

The genius idea in Sather (or wherever it came from originally) is the interplay of iterators and loops, which allows for semantics very similar to coroutines with an implementation that works completely on the stack. This kind of implementation, though, depends strongly on the details of the calling convention of functions, the placement of local variables, etc. It can definitely not be done in the library or with a preprocessor without loosing efficiency. Whether existing compiler-backends would support this kind of code is something I still have to determine.

In article <c8lutu$1blp$1@digitaldaemon.com>, Walter says...
>
>Sather iterators are pretty cool. But I have no idea how they can be implemented without doing coroutines.
>

I'm wondering how foreach/opApply is implemented in D.  Their behaviour looks very much like coroutines: i.e. each keeps its own stack frame.  Is there any stack frame switching involved?

no@where.com wrote:

> I'm wondering how foreach/opApply is implemented in D.  Their behaviour
> looks
> very much like coroutines: i.e. each keeps its own stack frame.  Is there
> any stack frame switching involved?

No coroutine, no frame-switching: The loop body is wrapped up as function and the opApply gets a pointer to that function which is then called for each element in the list. Neat and simple idea, but it cannot be expanded to more than one opApply routine running in for one loop. Furthermore, the handling of function pointers means a certain overhead, making foreach-loops questionable for performance critical work.