Filtering exceptions inside an iterator method

This was an interesting Stack Overflow question from last week. At first glance it seems to be impossible, but if you think about what yield return actually does, an answer presents itself.

Unification of async, await and yield return

The new await facility in the C# 5 CTP is mightly reminiscent of the iterator methods (yield return) added in C# 2. So much so that it is irresistable (to someone like me, anyway) to see if I can reinvent one using the other.

For many years now people have already been implementing something a lot like await using yield return, and I’ve blogged about that before. It’s quite possible to write a simple library such that yield return can play much the same role as await, except for some irritating limitations.

But can we go the other way, and write a library that provides the capability of yield return using only the new await feature?

Short answer: yes.

Long answer: (now read on…)

Ruby’s yield

One of the great things in C# is yield return. It’s a form of continuation implemented atop the CLR in an ingeniously lightweight way, purely by transforming the body of an ordinary method into a state machine class.

Generic Value Object With Yield Return

Inspired by this and this, here’s my version.

Jan Van Ryswyck is right to use static reflection, and to do that he "registers" the properties in a list. On the other hand, assuming you’d have a lot of these objects building up in the GC, it might prove important to reduce the number of ancillary allocations going on, so it may be better to avoid creating a list of the properties in every single instance.

Lazy Sequence Generation without using Yield Return

C# has the yield return feature, which makes it easy to write state machines as if they were plain old methods:

Other Examples of Iterators and Async IO

The idea of returning functions via yield return to simply asynchronous IO programming has a precedent in Microsoft’s Concurrency and Coordination Runtime:

http://msdn.microsoft.com/en-us/library/bb648753.aspx

Although they are yielding interfaces, really they are yielding functions:

http://msdn.microsoft.com/en-us/library/microsoft.ccr.core.itask_members.aspx

The ITask interface has only one really important method: Execute, which means that really it’s a function (a delegate in C# terms). I think the functional style makes the whole thing cleaner, but the point is that the idea was already in use in the Microsoft’s CCR, perhaps as long ago as 2005 (although that’s difficult to verify).

More on Jeffrey Richter’s AsyncEnumerator and Functional Programming

If you do asynchronous programming (or have been put off it in the past by the complexity) and you haven’t already looked at this, then you really should:

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

I blogged yesterday about an idea for doing the same kind of thing but using lambdas to encapsulate the last remaining bit of complexity. Today I’ve applied the same idea, but with the goal of providing a thin layer that works along with Jeffrey Richter’s AsyncEnumerator class, essentially providing an optional new way of working with it. As I am not especially familiar with the asynchronous APIs, it would be especially stupid for me to try and reinvent the wheel instead of building on the work Jeffrey has already done.

Asynchronous Sockets with Yield Return of Lambdas

Update: More in-depth stuff about this

I just watched this video of Jeffrey Richter demonstrating his AsyncEnumerator class:

http://channel9.msdn.com/posts/Charles/Jeffrey-Richter-and-his-AsyncEnumerator

The key idea is the realisation that yield return takes care of turning a single function into a continuation that can be resumed under the control of some other code, but still provides a natural way to write procedurally. This is just what is needed to manage asynchronous communication. Great stuff.

Coroutines with IEnumerable and yield return

There was a brief flurry of excitement about the fancy yield return syntax when the C# 2.0 specification was first published some years ago, and the idea of it being used for creating coroutines.

This quickly died down, as far as I can see anyway. Either people forgot the idea, or it became such boringly standard practice that no one ever thinks to discuss it anymore. I don’t know which, but I think it deserves more attention either way.

There were a few people at the time saying that it was a shame that C# appeared to only support coroutines in a special case where the function returns some weird IEnumerable<T> thing, and wouldn’t it have been better if it was more general?