Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Passing the new arguments in as the return value of the yield is the only way that makes sense to me. Rebinding the original arguments might be very far removed from the yield statement (the coroutine might have started in one block of code, but the yield might be the n'th sub child, where the original arguments are totally inaccessible and will not be accessible until all of the nested subs have finished yielding partial results and have returned back to the the grandparent code that actually has access to
    • Hmm, maybe the ongoing subroutine needs a &coro.next() method that simply resumes the yield, and then calling &coro(args) will pass args as yield's return value, just as you and iblech had argued for. Rebinding can then take place if the user asks for it, with an is rebound trait. What do you think of this?
      • Having both a functional and object interface to a coroutine is a separate issue. In the functional interface, if you don't have anything to pass as the return value from the yield, just pass nothing. So, &coro(args) will cause the yield to return (args) and &coro() has it return nothing. No need for a method to distinguish. Generally, I think that whenever you look to rebind the initialization arguments, you'd generally prefer to start a separate coroutine instance with different initialization args; and then resume either of the two coroutine instances as appropriate. I'd tend to prefer that a coroutine have two signatures - one for instantiating a new instance of the coroutine, the other for resume an ongoing instance. (In that regard, perl 5 with its typical lack of signatures works well.) For an object interface, these two signatures could be provided as two methods - called something like (start/init/new) and (resume/next/continue). There is also the tricky interface of creating a new instance the first time the coro is called, and then resuming it on subsequent calls, with perhaps an exception if it is called again after it terminates before creating another new instance. This interface makes for a nice sugar for simple uses and should be built on top of the more general interface, so that it doesn't get in the way for more complicated usage.