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

use Perl Log In

Log In

[ Create a new account ]

autrijus (1505)

autrijus
  (email not shown publicly)
http://pugs.blogs.com/

Journal of autrijus (1505)

Sunday November 06, 2005
04:28 PM

Day 247: Final day at Liz's - Coroutines, siglists, rebindable bindings

[ #27490 ]
Today is the last day of my stay at Liz and Wendy's. It was very enjoyable and productive, and I'm very grateful to their warm hospitality.

Liz and I had a SubEthaEdit session on coroutines today, with the brief notes merged to S17 (Liz is working on Englishify them at this moment).

Basically, a coroutine is an object that supports a .start method that initiates the lightweight thread behind it, and return a object that may be manipulated like any other threads. If you call it like a nullary function, it activates the thread until it hits yield, in which case it gives the control back to the caller. The return inside the thread will end itself immediately. Either way, if you attempt to call a finished thread, an exception will be thrown.

Then we get the extra magic of calling a Coroutine objects like a Code object. This will trigger &Coroutine::postcircumfix<( )>, which will take care of calling .start again after the thread has finished, and arrange it so the next call to the coroutine will resume the ongoing thread instead of starting a new one.

Finally, there is the question of calling an ongoing coroutine with parameters. I think rebinding the parameters makes sense (as you can inhibit it using is copy or explicit { my $x := $OUTER::x }), but iblech's idea of having yield returning the Arglist makes sense too. In any case this is userland code, so one can change the behaviour with a trait or a subclass of Coroutines.

On the PIL2 front, I looked at the three special forms (Assignment, Binding, Apply) and decided to unify them into method calls, so the user can override them all inside the same object model -- "Everything is an object."

The Apply form is easiest, as it's just method postcircumfix<( )> that takes an Arglist and gives back an Arglist. See the new S03 for more about the cool things you can do with Arglists.

Assignment is also manageable under the container model. It will be method infix:<=> on Array, Hash, Scalar objects. The List objects constructed with infix:<,> will also respond to this method, to implement the ($a, $b, $c) = (1, 2, 3) forms.

Binding almost feel like it should be a non-user-overridable special form, except we remembered the permanently-semi-official idea of Siglist objects, constructed with the :() notation. It turns out that if we specify binding as a method on the Siglist object, and that the compiler desugars LHS := RHS always as :(LHS).infix:<:=>(RHS), it will all Just Work. Under this regime, 3 := 4 will still be a compile-time error, as :(3) would make no sense -- the macro that turns sub (3) {...} into sub ($ where {$_ ~~ 3}) {...} would not apply to bare Siglist construction forms.

So, PIL2 is looking good with fewer nodes and tighter object integration now. Maybe we are not yet at io's zero keywords level, but it's getting dangerously close. Note that all of this is outside specced domain -- we'll need to work them back to Synopses and tests, and run them through p6l and @Larry.

Of course, to recover a respectible performance under this regime, we need to rely on optimizers, early binding, and/or type inference. But that's two milestones ahead, so let's get the dynamism part right first...

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
    • Additionally, it makes sense that the argument list for "start a new sequence" is different from "continue to find the next sequence element". The first argument list will contain arguments that are global to the entire sequence; while the second will be more local in meaning. The canonical coroutine example is a walker for a binary tree. The call that starts walking the tree might have an argument that chooses pre-order, in-order, or post-order traversal. That argument would not make sense for one of t
    • 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