in reply to Perl 6 coroutines (RFC 31)

My understanding is that co-routines are called co-routines because they are meant to be called from within another closely related routine, and they pass control back and forth between each other.

If you want to get to know them better, I would recommend playing around with a language that has them. The two most obvious ones are Scheme and Ruby. You might also find the paper Coroutines in C interesting (thanks to japhy for mentioning it once). It discusses an actual problem which coroutines would be a natural fit for, and then proceeds to show how you can mimic them in C. (The program that paper is about, PuTTY, is fairly widely used. If you are on Windows and occasionally need to telnet, or would prefer to ssh instead of telnet, then I strongly recommend looking into it.)

  • Comment on Re (tilly) 1: Perl 6 coroutines (RFC 31)

Replies are listed 'Best First'.
Re: Re (tilly) 1: Perl 6 coroutines (RFC 31)
by John M. Dlugosz (Monsignor) on Jul 13, 2001 at 18:33 UTC
    I've speculated about using "fibers" in Win32 to implement iterators that can yeild. Calling the function in its own super-lightweight thread means it can keep its stack, so it doesn't need to return but can yeild and keep looping. I never wrote up that article (yet) though.

    You can also do iterator, today, using objects. 

    my $iterator= $container->iterate();
while (my $item= $iterator++) { process $$item; }

    [download]
    The code behind ++ would have to save its state and return each time, so it's harder to write than having a yeild. But you declare the iterator instance and can use that one (or another one).

    What if yeild caused the call to return a token, and that is what you make subsequent calls on? You can have another one going without conflict.

    I agree that it doesn't sound like co-routines as described in classic literature. Those would "call" each other, rather than having a yeild statement at all. Such co-routines as members of the same object would also make sense.

    —John

[reply]
[d/l]
      Personally I don't think that the issue of avoiding conflict is that bad. If you really want multiple instances of the same thing, then just have a function that returns a closure, and each closure maintains its own state.

      Anyways the yield idea can work really nicely. As I said before, try Ruby. Ruby combines yield with a nice piece of syntactic sugar. In Ruby you can call functions 2 ways. In one way you just call the function. In the other you call the function and pass a block as an extra argument. When you do the latter then any yield will call the block. (You can also detect which way you are being called and function appropriately.)

      So what you get is effectively the same as creating a closure in your context and passing it to the function, and having it call the closure. However it works really nicely because, even though that is what you are doing, there is a lot less machinery needed to set it up. And it seems that people who have a hard time getting their heads around the idea, You encapsulate a closure and then pass it in have no problem with the idea of passing a block to a method named each and having your block called on each thing encapsulated in your object.

      As Larry Wall has noted, sometimes sugar is worth it in its own right. Even if you cannot readily use yield for the full generality of what you want, it can work really nicely.

      As I said before, you can play around with Ruby now to get a sense of what this feature will be like in Perl 6. (Of course many of the other features of Perl 6 are missing in Ruby...)

[reply]
        Yes, I looked at Ruby when it was mentioned last month. I looked at the block thing compared with Perl.

        If Perl allows the implicit sub at any position rather than only the first, we can do the same thing like Ruby. Having yield will make some things easier, like the tree traversal.

[reply]

In Section Meditations