C# 4 idea: Iterator blocks and parameter checking

re: C# 4 idea: Iterator blocks and parameter checking

skeet — Sun, 31 Aug 2008 06:31:13 GMT

@al0: That's fine for cases which can be easily expressed without extra logic, e.g. null argument checks - but what about more complicated cases?

re: C# 4 idea: Iterator blocks and parameter checking

al0 — Sat, 30 Aug 2008 21:35:54 GMT

There are enough "one-off" solutions in C# already. It would be much better to introduce a general construct that allow clearly specify contract. And it would be even better if this construct would be part of the method specification and not of the method body. I. e. it should be possible to include it into declaration of the methods in interfaces as well as into declaration of delegates.

Daily Bits - March 6, 2008 | Alvin Ashcraft's Daily Geek Bits

Daily Bits - March 6, 2008 | Alvin Ashcraft's Daily Geek Bits — Thu, 06 Mar 2008 12:46:09 GMT

Pingback from Daily Bits - March 6, 2008 | Alvin Ashcraft's Daily Geek Bits

re: C# 4 idea: Iterator blocks and parameter checking

Ollie Riches — Wed, 05 Mar 2008 15:29:17 GMT

It's clear enough :) I get the idea of only fetching the data when it is asked for and the issue involved if it wasn't deferred.

re: C# 4 idea: Iterator blocks and parameter checking

skeet — Wed, 05 Mar 2008 14:41:52 GMT

Imagine they didn't defer execution, and examine a LINQ to SQL example which contains multiple method calls (Where, Select etc). If each method call had to operate immediately, you would never get the benefits of LINQ - you wouldn't get the whole query translated into SQL, you'd get one part at a time.

For instance, if you do a join and then a where, you'd end up getting the whole contents of the join back from the database - far from ideal!

Likewise deferred execution is necessary for streaming. Imagine if (in LINQ to Objects) Select had to execute immediately. It would have to store the data somewhere, making a copy. Because it only actually fetches data when it's asked for it, it is able to only process data as it flows through.

Sorry, that's not terribly clear - but I suspect if you think about it further, you'll get it. Just imagine trying to write it in a non-deferred fashion, and then see how evil the whole thing gets.

re: C# 4 idea: Iterator blocks and parameter checking

Ollie Riches — Wed, 05 Mar 2008 14:34:33 GMT

This may be a stupid question but why are iterators, LINQ queries etc deferred execution?

re: C# 4 idea: Iterator blocks and parameter checking

skeet — Mon, 03 Mar 2008 19:35:29 GMT

Jared: I seem to remember there's a good reason for the second part of a "yield-statement-phrase" being a keyword. I can't think of any ways in which "yield validate" followed by a block would be valid code, but "yield validate;" certainly would be if you had a type called yield. Using a keyword as the second part prevents that situation.

Fortunately, this kind of detail is one for the language designers, if they decide to go with the idea at all. (I strongly suspect it's an idea which has come up before - I'm not daft enough to think I'm likely to invent genuinely original concepts in this area.)

re: C# 4 idea: Iterator blocks and parameter checking

skeet — Mon, 03 Mar 2008 19:32:58 GMT

Neil: using the Spec# approach certainly makes sense if contracts like this make it into the main body of the language. I don't think I'd want them to be introduced *just* for iterator blocks though. Of course, one problem of implementing my proposal (without Spec# contracts) is that if contracts are added later, my syntax becomes obsolete.

On the other hand, it's possible that there are other things which *might* make sense to do immediately, beside parameter checking. Logging is the only one I can think of immediately...

re: C# 4 idea: Iterator blocks and parameter checking

Fabrice — Mon, 03 Mar 2008 19:18:14 GMT

"One solution to this is to check the parameters in the public method and then call a private method which is implemented with an iterator block."

As a side note, this is similar to what Microsoft did when they wrote the LINQ query operators. Some operator methods check the parameters, and then delegate the processing to private classes.

re: C# 4 idea: Iterator blocks and parameter checking

Jared Parsons — Mon, 03 Mar 2008 18:52:10 GMT

I really like the idea and the design. I've hit this several times in the past and it usuually takes me a second or two to get past the idea of MoveNext() throwing an Argument*Exception.

Separating this out into a completing seperate block provides a nice clean way to do validation.

I'm stuck on the word "do" though because I don't feel like it's instructive enough. This would be a contextual keyword so why limit it to existing keywords. How about "yield validate"?

re: C# 4 idea: Iterator blocks and parameter checking

Neil — Sun, 02 Mar 2008 23:08:47 GMT

Could an approach similar to that used in Spec# be adopted with explicit detailing of preconditions for entry, together with details of the exception to throw if these preconditions are not met?

E.g.

public static IEnumerable<TResult> Repeat<TResult>(TResult element, int count)

requires count > 1 otherwise ArgumentException;

{

...

}

or from (research.microsoft.com/.../Iterators.pdf)

IEnumerable<int> FromTo(int b, int e)

requires b e + 1;

invariant values.Count e + 1 − b;

invariant forall{int i in (0 : values.Count); values == b + i};

ensures values.Count == e + 1 − b;

{

for (int x = b; x e; x++)

invariant values.Count == x − b;

{ yield return x; }

}

I've always liked Spec#'s way of approaching these things (when I get a chance to look) and would be very interested to hear what you think.

BTW - started subscribing to your blog after the excellent evening at Ascot with Iterative - thoroughly enjoyed your engaging talk and being a small part of a linq expression! Thank you.

Neil