Re: Perl 6 coroutines (RFC 31)

[Abigail]

Basically, a line like

    while (my $node = $root->next_inorder()) {
        print $node->{data};
    }

found in a module will test fine, but will suddenly and mysteriously fail if that code is called (even indirectly, by many levels) from another use of the iterator, even if it's on a different collection.

Are you aware that *exactly* the same problem already exists in Perl? We have several iterators in Perl, for instance, each, readdir, <>, m//g, globbing, and I probably forgot a few. They already act as coroutines. All Damian is proposing is to make that available in Perls user space too.

You should also realize that someone who uses coroutines knows what he/she is doing. Programmers don't randomly call subs. They call subs because they know what the sub does - and they should also know a sub is a coroutine, and program appropriately.

We also need a "quit" feature. Say I'm iterating over a collection and break out of the loop when I find the element I want. Just last it, and don't look at the rest. Well, next time that code is called, it will still be incomplete...

Eh, no we don't. For two reasons. First there is of course return, but more to the point, coroutine like behaviour only happens when yield is used. In the example you present, no yield happens, so it will behave like any other subroutine.

-- Abigail

[John M. Dlugosz]

Yea, I know each has a similar problem, but it's not as bad because it has a separate state per hash. Called code can iterate over a different hash without messing it up.

Likewise, readdir is given a handle, and you can have multiple handles open. It's no different from a normal file read, really. m//g is even better, in that not only is it per string (and a string can be copied to a local temp so nobody else will even try to iterate over the same copy), but you can use pos() to reset the state, or cancel it by matching a RE without a /g. How is any of that "*exactly* the same"?

My issue with the proposal is that the iterator would be global for all instances. It would be like each maintaining a single global state, rather than per-hash. IAC, Perl 6 will fix nested each's on the same collection.

but more to the point, coroutine like behaviour only happens when yield is used. In the example you present, no yield happens, so it will behave like any other subroutine

Why do you say that? next_inorder() yeilds.

there is of course return ah, that makes sence. You can't pass parameters into the iteration in-progress, but you could have a separate reset function that sets a shared global and calls the iterator, which sees the flag and returns.

—John

[Abigail]

My issue with the proposal is that the iterator would be global for all instances. It would be like each maintaining a single global state, rather than per-hash.

Ah, but not if you create your iterators as anonymous closures! Then you can have several instances, each working on separate data, and each keeping state.

but more to the point, coroutine like behaviour only happens when yield is used. In the example you present, no yield happens, so it will behave like any other subroutine

Why do you say that? next_inorder() yeilds.

I was referring to your:

Say I'm iterating over a collection and break out of the loop when I find the element I want. Just last it, and don't look at the rest.

No yield here.

-- Abigail

[John M. Dlugosz]

I see... I thought about wrapping the iterator in a closure, but that won't help. It would work if yeild was called from the closure's block (not from a reusable helper function).

My example means that my loop is calling next_inorder() to loop. It does not wait for next_inorder() to return undef, but breaks out of the loop when it sees the element it's looking for. next_inorder yields. Caller want's to quit early. Get it?

—John