Internal vs. External Iterators (revisted)

re: Internal vs. External Iterators (revisted)

Fredrik Normén — Mon, 07 Jun 2004 09:38:00 GMT

I would like to se a similar “visitor” implementation into the collection classes in the System.Collection and System.Collection.Generic namepsace.

re: Internal vs. External Iterators (revisted)

Nick Schweitzer — Mon, 07 Jun 2004 13:40:00 GMT

Now that is sweet! I hadn't seen that article on MSDN Mag. with co-routines. I can just imagine the possibilities.

Keep it up. Its great to see someone who so readily provides more tools for the toolbox.

re: Internal vs. External Iterators (revisted)

Cyrus Najmabadi — Mon, 07 Jun 2004 16:35:00 GMT

Fredrik: I'll pass your comment on and see if there's an appropriate blog you can bring up your issues to.

re: Internal vs. External Iterators (revisted)

Fredrik Normén NSQUARED2 — Mon, 07 Jun 2004 17:22:00 GMT

Cyrus:

Thanks!

Don't you think it would be great if the Iterate method

public abstract class AbstractCollection {
public void Iterate(Action action) {
foreach(A element in this) {
action(element);
}
}

public abstract IEnumerator GetEnumerator();
}

is added to the collection classes? It's often I iterate through collections, and it would be nice to have this kind of "Visitor" pattern in the collection classes.

re: Internal vs. External Iterators (revisted)

SteveJS — Mon, 07 Jun 2004 19:52:00 GMT

Cyrus, I think we need to stage an intervention. Using Fibers here is nothing but crack smoking crazy.

The main gain over a Thread implemention of CoRoutines is the destabilizing factor fibers introduce. These allow you to:

1. Wail in agony as you find the debugger doesn't work.
2. Scratch your head in confusion as a fiber switch in an exception handler causes your program to do a swan dive. (Gee I wish I could debug!)
3. Go back to wailing in agony as 3 days before you are expected to ship, a tester finds your app mysteriously runs out of address space after creating one to many enumerators.

Check out CBrumme's Blog topics that touch on Fibers:
http://blogs.msdn.com/cbrumme/archive/2003/04/15/51351.aspx
http://blogs.msdn.com/cbrumme/archive/2004/02/21/77595.aspx

We're here for you Cyrus. Together we can help you shake this.

re: Internal vs. External Iterators (revisted)

Gregg Miskelly — Mon, 07 Jun 2004 20:19:00 GMT

Don't even think about doing this. I can't believe that MSDN published this article. Don't use Fibers.

http://blogs.msdn.com/greggm/archive/2004/06/07/150298.aspx

re: Internal vs. External Iterators (revisted)

doug ransom — Mon, 07 Jun 2004 23:59:00 GMT

I support the work of more iterators and better iterators for .net. I really like the way haskell does things with map, filter, fold etc. and second order programming.

It always seems silly to me in C#/C++/Java to have to write my own foreach loop when I am pretty sure someone already has done that. Unfortunately, closures or lambda expressions or simulations thereof are hard in C#. C# 2.0 looks promising here.

The yield statement of C# 2 also looks promising. They don't seem to use fibers or even continuations in their .net implementation. These would be nice, but my guess is that they don't work well on the stack architecture of the ecma runtime.

re: Internal vs. External Iterators (revisted)

damien morton — Tue, 08 Jun 2004 21:17:00 GMT

Python has had map, filter, fold, etc since its inception. Being an imperative language, for imperetive programmers, they rarely get used. Theres an ongoing debate in the Python community about dropping support for them, and for dropping support of lambda.

One of the enabling features of python that tends to reduce the need for map, filter, fold etc is list comprehensions.

Heres an example of some comprehnsions and their functional equivalent:

[x**2 for x in list] <==> map(lambda x: x**2, list)
[x for x in list if x&1] <==> filter(lambda x: x & 1, list)
[x**2 for x in list if x&1] <==> map(lambda x: x**2, filter(lambda x: x & 1, list))

As you can see, a list comprehension is much more readable than the equivalent functional form.

Heres the equivalent in c#

ArrayList res;
foreach (int x in list) if (x&1 == 1) res.Add(x);

Using c# in a functional mode:

ArrayList res;
Functional.Iterate(list, delegate(int x) { if (x&1 == 1) res.Add(x); })

Again, I put it to you that the imperative form is more readable.

Itd be nice to be able to use a yield statement inside anonymous delegates though. Youd have a nice-ish syntax for doing something like list comprehensions then.

delegate() { foreach (int x = 0; x < 20; x++) yield return x*x; }
would result in an iterator.

wonder what this should result in:
delegate() { yeild return x*x; }

eesh

re: Internal vs. External Iterators (revisted)

Cyrus Najmabadi — Thu, 10 Jun 2004 09:59:00 GMT

Damien: I disagree. I find the imperative form much more ungainly and difficult to read. It also forces the resultant list to be an ArrayList which takes the control out of the object itself.

The list comprehensions are extremely nice. But I see them as syntactic sugar (not a bad thing) over the lambda functions. I woudl still want the nice atomic operations, but am glad that the nice language syntax is there to manipulate it in readable ways.

re: Internal vs. External Iterators (revisted)

Des Kenny — Sun, 12 Jun 2005 00:19:18 GMT

About : "Python has had map, filter, fold, etc since its inception. Being an imperative language, for imperetive programmers, they rarely get used. Theres an ongoing debate in the Python community about dropping support for them, and for dropping support of lambda.

One of the enabling features of python that tends to reduce the need for map, filter, fold etc is list comprehensions.
"

Haskell has both named functions over collection domains such as map, filter ... and list comprehensions over list domains. List comprehensions are just an application of the very old mathematical form of set comprehensions used on list domains, which are not strictly sets. Haskell also has lambda expressions (nameless functions). Theoretically you could have a collection comprehension over any collection domain ( type). It is just a matter of writting the rules of logic that define the function over that collection domain and using your favourite bracket notation
So take your pick of whichever style you prefer. They are all logically equivalent.

re: Internal vs. External Iterators (revisted)

Ben — Fri, 04 Nov 2005 18:22:19 GMT

"Python has had map, filter, fold, etc since its inception. Being an imperative language, for imperetive programmers, they rarely get used. Theres an ongoing debate in the Python community about dropping support for them, and for dropping support of lambda.

One of the enabling features of python that tends to reduce the need for map, filter, fold etc is list comprehensions.

Heres an example of some comprehnsions and their functional equivalent: ..."

Um, list comprehensions are functional: http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?list+comprehension

As others have mentioned, list comprehensions are just syntactic sugar for combinations of map, filter, and concat.

Cyrus Blather Internal vs External Iterators revisted | My Site

Cyrus Blather Internal vs External Iterators revisted | My Site — Mon, 01 Jun 2009 07:08:42 GMT

PingBack from http://patiochairsite.info/story.php?id=349

Cyrus Blather Internal vs External Iterators revisted | pool toys

Cyrus Blather Internal vs External Iterators revisted | pool toys — Thu, 18 Jun 2009 12:02:55 GMT

PingBack from http://pooltoysite.info/story.php?id=2328