In the spirit of deferring execution to the last possible minute, which on .Net means using IEnumerable and in C# 2.0 the yield keyword, I've built a graphics rendering engine which returns rendered objects as an IEnumerable stream. The interface to this engine allows access to an IEnumerable of the rendered objects, which in turn delegates to an object-specific renderer, which in turn delegates to a graphics-system specific renderer. All each one does is to return an IEnumerable to the client object, and defers rendering or otherwise doing computation until the enumeration is iterated. Then it processes each object in turn. This is a nice way to stream computation, since the cost of computation is amortized over each object from the beginning, and each additional one is a marginal, predictable cost, rather than having a huge cost for the first object and then a diminishing cost for subsequent ones. Ad-hoc decision making during the streaming, such as a decision to cancel, is therefore cheaper, since you didn't have to pay for almost all of the result up front. If you've done functional programming, you already know this. We programmers who have done imperative programming most of our lives are just now catching on...

It seems that there are some technical challenges to stacking your IEnumerables high, however. VS apparently does a stack trace to figure out which debug watch language to use, and gets it wrong when it has too many to go through and you get some BCL code iterating your enumeration. Here's what I get when I call List.AddRange on the graphic engine's Render operation for some unit test:

Note that the code is C#, but the watch popup thinks it's dealing with C++/CLI.