Re: Re: Perl 6 coroutines (RFC 31)

[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