Iterator Blocks, Part Two: Why no ref or out parameters?

re: Iterator Blocks, Part Two: Why no ref or out parameters?

Rich — Fri, 18 Jun 2010 14:45:44 GMT

I'll tell you why we need it, recursive inheritance.

Consider an XML document where element may (optionall) inherit from their parents and you need to parse this with a streaming approach (not DOM)....you'll need to keep track of the most specific values that might apply to a child as you recurse through the document each time you find something more specific you overwrite what you previously found until you find the leaf you're looking for and it'll have the most specific inherited properties nicely ready to yield return...that's why!

re: Iterator Blocks, Part Two: Why no ref or out parameters?

Jack — Tue, 21 Jul 2009 10:52:08 GMT

Great, I also read Jon’s article, learn a lot from it

re: Iterator Blocks, Part Two: Why no ref or out parameters?

Alexey Romanov — Thu, 16 Jul 2009 21:00:56 GMT

If I may ask, was anything like generalized interfaces from the paper "JavaGI: Generalized Interfaces for Java" (Stefan Wehr, Ralf Lämmel, Peter Thiemann) ever on the list?

re: Iterator Blocks, Part Two: Why no ref or out parameters?

Daniel Smith — Wed, 15 Jul 2009 17:57:24 GMT

Out of interest, what are the current "top 5" features that haven't yet made it into the language yet?

Yeah, I wish I knew too. (No joke!)

It is way too early to speculate on that, and we don't know ourselves. The last time I mentioned an idea that we were kicking around in the hallway, I got 50+ comments criticizing the fact that we were even considering it. I don't want to get 250+ negative comments by discussing a possible feature set for an unannounced, hypothetical product. Talking about feature sets of hypothetical future versions would be extremely irresponsible at this point in the process. We haven't even shipped C# 4.0 yet. -- Eric

re: Iterator Blocks, Part Two: Why no ref or out parameters?

Leopold Bushkin — Wed, 15 Jul 2009 17:35:00 GMT

Perhaps you already aluded to this, but iterator blocks make it possible to implement continuations in C# programs without any additional language features. In, fact, I've done so on several occasions. The syntax isn't always the clearest, but it works quite well.

The basic pattern I've used is to create an iterator block that returns a Func<> of some sort that encapsulates the individual sequences of computations that represent the continuation. Each is returned by the iterator block and then invoked by the caller. It's by the way, not dissimilar from the CCR implementation in the MS robotics library.

Here's a simple example of a factorial using CPS programming:

public class Continuations

{

public static void Main(string[] args)

{

var i = 0;

var val = 0;

// output each step in the Factorial function until you compute the final value

foreach( var facStep in FactorialCPS.Factorial( 8 ) )

Console.WriteLine( "Step {0} = {1}", ++i, val = facStep() );

Console.WriteLine( "Factorial of 8 is {0}", val );

}

public static class FactorialCPS

{

public static IEnumerable<Func<int>> Factorial( int n )

{

int q = 1, f = 1;

while( q <= n )

yield return () => f *= q++; // Note: uses closures to capture state

}

re: Iterator Blocks, Part Two: Why no ref or out parameters?

aaron — Tue, 14 Jul 2009 19:27:18 GMT

> The designers of the CLR were faced with three choices

I think you missed a couple of other choices that are well established options in this area, which appears closely related to the "downward funargs problem". 4) detect when the lifetime of the object being referenced has expired, and prevent accesses after that point. 5) lift the object to the heap when its current storage location is expiring.

Good point. I normally end lists of options with "do something I haven't thought of". I'll update the text. -- Eric

re: Iterator Blocks, Part Two: Why no ref or out parameters?

ShuggyCoUk — Tue, 14 Jul 2009 11:41:38 GMT

"if it ever makes it into the top five, we'll probably implement it. -- Eric"

This is one of the reasons that, despite the very long incubation period associated with f# I'm glad it had that time to be used in the real world with everyone using it knowing it was, in effect, beta and subject to change as feedback allowed it to grow/change.

Do you think things would have been different with c# had it had a more extensive beta period(*)?

(*) obviously this is hypothetical, I don't believe it would be as successful had it had anything like as long a beta as f#.

re: Iterator Blocks, Part Two: Why no ref or out parameters?

Alexey Romanov — Tue, 14 Jul 2009 00:43:59 GMT

What I really want to know is, why no "yield foreach"? The paper on design on CLR iterators explains its advantages and how to implement it. What are downsides to implementing it?

The downside is that we'd have to cut something better. We have a list of a couple hundred possible new language features for any given version of C#. We have the design, implementation, testing, documentation and management resources available to actually implement maybe four or five of them in any one version. "yield foreach" is an awesome feature that I would love to do; it is certainly in the top fifty, but has never made it into the top ten. If it ever makes it into the top five, we'll probably implement it. -- Eric