Iterator Blocks, Part One

re: Iterator Blocks, Part One

arnshea — Thu, 09 Jul 2009 23:41:20 GMT

It's exactly that kind of attitude that has made for a programming language that feels light years more productive for building a very large class of applications than so many of its ancestor languages. People don't realize that there's so much software to be built and so much hardware to throw around that the weak link in the chain is human comprehension.

It strikes me that a similar analysis could be made of C# generics vs C++ templates.

re: Iterator Blocks, Part One

catbert — Fri, 10 Jul 2009 00:20:53 GMT

Let me guess :-)

Iterator blocks cannot take ref or out parameters because those cannot be warped into fields inside a helper class which implements the iterator interface.

You cannot put a yield in a finally because you cannot goto into finally. Or maybe because that would break the invariant of finally clause: statements after yield might never be executed.

You cannot put unsafe code in the iterator block because then you could run into a situation where one part of code that e. g. allocates non-GC-ed memory is executed, and the other part that frees it is not executed, leading to memory leaks and other scary unsafe and unmanaged stuff.

(sorry for my English, I am not quite native speaker)

re: Iterator Blocks, Part One

sambo99 — Fri, 10 Jul 2009 01:47:38 GMT

A similar argument could have been made about IDisposable and using blocks,

The big problem I see with this is that .Net now has 2 specific structures (foreach and using) which both could have been implemented as continuations.

The restrictive nature of the implementation, kind of hurts you, you can not intercept and track exceptions in using blocks, you can not pass around foreach blocks (or track exceptions)

re: Iterator Blocks, Part One

Ajai Shankar — Fri, 10 Jul 2009 06:59:09 GMT

Eric

Guess being one of the "adventurous people" iterators & async have worked great for the last 5 years for me :-)

http://codeplex.com/easyasync

Look forward to the rest of the posts in this series.

Could you also elaborate on how you determine if a feature such as coroutine or continuation should be implemented in the *language or the run time*?

I remember in 1.1 the undocumented hosting API hack I used to implement coroutines for .NET

http://msdn.microsoft.com/en-us/magazine/cc164086.aspx

Also in 2.0 the hosting API was revamped to support different tasking models to address similar continuation based scenarios (and also SQL server fiber mode)

Where does the language designer fit into all this?

Ajai

re: Iterator Blocks, Part One

Daniel Earwicker — Sat, 11 Jul 2009 10:50:31 GMT

What's the likelihood of being able to yield inside the try of a try/catch block in a future version? Or is there some basic reason why that can't make sense. Aside from that I think iterator methods are fine as they are - close enough to general coroutines, and lacking the "spooky" aspects of general continuations.

As for yield return in a finally block, that would be odd because finally blocks run if the iterator is abandoned via Dispose. Yielding more items wouldn't be the sanest response to that.

re: Iterator Blocks, Part One

Aaron — Sat, 11 Jul 2009 20:46:53 GMT

What's the likelihood of getting working coroutines in a future version of C# or CLR? the problem with using iterator syntax has been demonstrated by you before:

IEnumerator InOrderTraverseTree() {

if (this.left != null)

foreach(object o in this.left.InOrderTraverseTree()) yield return o;

yield return this.value;

if (this.right != null)

foreach(object o in this.right.InOrderTraverseTree()) yield return o;

}

The problem being that you zip up and down the co-routine's call stack on every iteration step.

Don't get me wrong, the iteration syntax captures a nice pattern. But people have noticed that it doesn't get you as far as 'something else', though maybe they don't know the name of that 'something else' yet, having never worked in a language that has coroutines or first class continuations.

I'm curious if you'd agree, but I've always thought of the thing missing from iterator syntax is the method call abstraction. In a hypothetical co-routine environment, instead of 'yield return x', you would 'push(x)', where 'push' is some sort of callable thing -- delegate in C# parlance -- where you could pass that delegate to recursive calls.

// in hypothetical C#++

[Coroutine(IEnumerable)]

void InOrderTraverseTree(Action<object> push) {

if (this.left != null)

this.left.InOrderTraverseTree(push);

yield return this.value;

if (this.right != null)

this.right.InOrderTraverseTree(push);

}

Slightly improved readibility, drastically improved asymptotic performance.

One alternate approach I've heard suggested is chainable iterators -- that 'yield return' could be passed an IEnumerable to fold in. I'm curious which you'd prefer.

re: Iterator Blocks, Part One

Gabe — Sun, 12 Jul 2009 09:19:31 GMT

You can't yield from a finally block because yield is really a return, and you cannot return from a finally block -- you must leave the block to go to a return outside of it. And once you leave that block, there's no way to get back into the finally to resume execution on the next iteration.

And if there was an unhandled exception, when would it propogate to the caller? After all the yields in the finally block had been enumerated? But what if you never finished enumerating them? And where would you put the exception in the mean time?

re: Iterator Blocks, Part One

Bob Denny — Wed, 26 Aug 2009 03:24:46 GMT

I'm a dyed-in-the-wool YAGNI guy. Thank you for everything, including Windows Script!!! Some time I'd like you to see what I did with (every bit of) Windows Script in my astronomy automation system. You'll probably not believe it. I even found named parameters, ha ha.

I love C# and have used the hell out of it for the last 5 years or so. Keep up the great work, and keep blogging. I'm reading all of the parts to this interesting article on iterators now.