Re: Any interest in lightweight coroutines in Java ala C# 2.0 iterators?

From: John C. Bollinger (jobollin_at_indiana.edu)
Date: 10/28/03 

Date: Tue, 28 Oct 2003 10:22:50 -0500

Ken wrote:
> The Microsoft C# web page is:
>
>
>
> http://msdn.microsoft.com/vcsharp/team/language/default.aspx
>
>
>
> There is a link on that page to the proposed C# 2.0 Language Specification,
> which has an example. The Python generator concept (pretty much the same as
> C#'s iterators) is explained at:
>
>
>
> http://www.python.org/peps/pep-0255.html
>
>
>
> The implementation of these language constructs is analogous to the type
> safe enum construct proposed for Java 1.5. An enum declaration such as:
>
>
>
> enum Season { spring, summer, fall, winter }
>
>
>
> is converted by the Java compiler, behind the scenes, to a class. Joshua
> Bloch, in his book "Effective Java", describes such a class in item 21, the
> Typesafe Enum pattern. This allows the user to replace dozens of lines of
> tedious boilerplate code with one line of code that succinctly expresses the
> concept.

I have no general objection to this kind of thing; my questions and
concerns have to do with this specific thing. I think it is right and
reasonable to approach any new language feature proposal with a degree
of skepticism and critical analysis.

> The C# 2.0 Language Specification gives an example of a C# iterator:
>
>
>
> public IEnumerator<T> GetEnumerator() {
>
> for (int i = count - 1; i >= 0; --i) yield items[i];
>
> }
>
>
>
> The C# 2.0 Specification gives the code for the inner class that this would
> be converted to, I won't repeat it here. It is worthwhile to note that
> again, the compiler turns a couple of lines of code into dozens, or even a
> hundred or more, lines of code. The compiler saves the user from having to
> write a lot of tedious and moderately tricky code that completely obscures
> the intended algorithm.

I observe that both the examples that Microsoft provides contain exactly
one yield return statement, no yield break statements, and no try /
catch blocks. Much of the autogenerated code provided with the examples
supports the general state machine specification described for this type
of construct, and in many cases would be rather superfluous. The
several dozen autogenerated lines of code replace about a dozen that I
would have written by hand (only that many because of observation of
coding conventions).

> For programs that could potentially use hundreds of types of
> iterators/generators , such as games and discrete event simulators, this
> language feature would end up saving the programmer from writing tens of
> thousands of lines of code, while simultaneously making the resultant code
> far clearer.

There is room, and evidently at least some desire, for a feature of this
sort. After reviewing the Python PEP and the C# 2.0 spec, however, I
find that I do not like some of the specific semantics of the construct
in those languages (see below), and I think there would be some
significant challenges to implementing it in Java in an analogous way.
(And I'm quite curious about how C# will get around similar challenges.)

> There is also some discussion in the Python community about how generators
> easily allow complex, hierarchical data structures to be iterated over.
> These can be viewed by doing a web search on "python generator". Such a
> feature would fit in nicely with the new Java 1.5 "foreach" construct. The
> following example assumes the ComplexXMLDocument class has a method that
> produces an iterator, in a manner similar to the C# 2.0 IEnumerator.
>
>
>
> Public void processDoc(ComplexXMLDocument doc) {
>
> // An iterator is implicitly created by the doc
> object.
>
> for (node n: doc) {
>
> // Process each node of the document.
>
> .
>
> }
>
> }

Yes, that makes the top level code very simple indeed. I'm not quite
persuaded, however, that the code that would then go into an iterator /
generator declaration would be particularly simpler. Indeed, it seems
to me that the more complex the iterator body, the less, proportionally,
is gained from the autogeneration of an iterator framework around it.
And the less complex the iterator body, the less useful autogeneration
would be in the first place.

I furthermore think there is a particular problem with the way C#
specifies that its implementation interacts with exceptions and try /
catch. Observe that a yield return exits a try block _without the
finally clause being executed_. Control then might or might not later
resume in the try block from the point at which it left. This is ugly,
and I predict that it would be a source of problems in Java and will be
a source of problems in C#.

The general idea of a yield return is also strange -- it is like a
hybrid of return and invocation of a callback, with uncertainty even at
runtime as to which character it will exhibit.

I think that there are also potential implementation problems related to
using multiple yield return and / or yield break statements in one
iterator, and related to iterators with more complex internal state.

It might be nice to have a code-assist type language feature to simplify
creation of iterators, but I don't think that the specific design of the
Python / C# feature is appropriate for Java. (And I'm not convinced
that it's appropriate for C#, either.)

John Bollinger
jobollin@indiana.edu

Relevant Pages

  • Re: I need a lot of help
    ... > math problem in MAPLE and had plenty of success unfortunately I am ... and assembly language faster still. ... while iterator < n do ... end facmod yielding result ...
    (comp.programming)
  • Re: Haskell - Transforming a String in a function
    ... An iterator is equally as ... so you're dissing static types because they were done with a convoluted syntax in C++. ... having to write down types is a bother even if it is done well. ... Oh, and, of course, you don't have iterators in a functional language anyway. ...
    (comp.lang.functional)
  • Re: for-else
    ... come from just its bad naming. ... The converge language is yet another ... Rather than adding new keywords, I think the above would be better ... # the iterator exited abnormally, ...
    (comp.lang.python)
  • Re: I need a lot of help
    ... and assembly language faster still. ... >> have had no luck in finding what I need. ... > while iterator < n do ...
    (comp.programming)
  • Re: C# iterators and suspend/resume in Simula 67
    ... ooops--Forgot the updated iterator syntax in my examples...not that it ... I was just saying that rather than doing a bunch of "yield return new ... But the yield statement has to be in the iterator method, ... be compiled IEnumerable classes and not true fibers or coroutines. ...
    (microsoft.public.dotnet.languages.csharp)