Further, "coroutine", like so many other programming terms, has suffered from a certain fuzziness. There's a reasonably precise term used by programming language researchers, which very few languages have. Things like Python's generators do not conform entirely to this definition, but you get people calling them coroutines anyhow, along with so many other things.

So, rather than try to justify the exact PL-research definition, let me try to explain the interesting thing about the more sloppy, broad definition. In a nutshell:

When you call a function, you pass in certain arguments. Then you start at the beginning, generating state or values in response to the input, before finally returning some more values. You then discard all the intermediate state the function generated. The idea here is that there are times when you may want to not discard the state, and/or you may want to be able to not start the function at the beginning. You may also want to pass fresh values into the middle of the function.

One of the most clear examples of where this is useful is when you create a pipeline of functions within your code. Using "functions" that can get more input as they go along, and generate output without discarding all their intermediate state, makes it very easy to compose functions together into a pipeline that only know they are in a pipeline. You can take input from a user, apply a "coroutine" that then parses their input into numbers, feed that into a "coroutine" that groups them together into a run-length delimited format, then feed that into a coroutine that writes the results to a file. Each of these routines holds on to a little bit of state, instead of discarding it. Each of these routines is "pluggable"; you can take the same pipeline, pop the "user input" bit off the front, and read from a file, or stream from the network, and the same for all the little bits. You get a composable system of functions that all know just barely enough to function (which is what makes composition easy), instead of a set of functions that knows "A ha, I'm going to get this sort of linked list, traverse it, do 'my thing', and then return a new sort of linked list", which doesn't work on network streams, or hash tables, etc. This also is an easy way to operate on a "stream" without having to have the whole stream loaded into memory, and is more cache/memory-bandwidth friendly because you're only traversing it once.

Of course, if you work at it enough, you can do this with conventional functions. But you're going to write a lot of boilerplate, you're going to get it wrong, and it probably still won't be as composable in the end. Or you'll end up manually re-implementing "coroutine"ish things yourself.

This is only one example, but it's one of the clearer ones where having things able to retain state without being forced into the strict call hierarchy that conventional function stacks require is obviously a good idea.

(Pendant note: I've tried to keep this comment very language agnostic. There's a world of difference between Haskell and Python here, for instance. I'm going for the essence of the pattern in general, not in a particular language.)

A classic example is iterators. Its very natural to write an iterator like

    for(i=0; i<10; i++){
       yield i
    }

    i = 0
    int getNext(){
        if(i >= 10){
           return Done
        }else{
           temp = i
           i = i + 1
           return temp
        }
    }

    iterate_tree(t){
        if(t.isLeaf){
           yield t.value
        }else{
           iterate_tree(t.left)
           yield t.key
           iterate_tree(t.right)
        }
    }

---------

One way to prevent the inversion of control is to use internal iterators, where you pass a code block to the iterator:

    void iterate(callback){
       for(i=0; i<10; i++){
          callback(i)
       }
    }

    foreach(url in list){
       var x = await getUrl(url)
       console.log(x)
    }
    restOfTheCode();

    function go(i){
        if(i >= urls.length){
           restOfTheCode();
        }else{
           getUrl(function(x){
               print(x)
               go(i+1)
           })
        }
    }

I find them useful when conjoining function A with produces a sequence of results and function B which consumes the sequence†. Without coroutines you either have to turn one of the functions inside out to use it as a callback or break into threads and pass data between them.

With coroutines you can leave the functions in a more readable form and keep your cache footprint small by consuming the result as soon as it is produced.

␄

† I don't mean that I call A or B for each element of the sequence. A and B may have internal state and fill produce or consume the whole sequence in a single call. They could be organized to have a create function, a context structure, a "do one" call, and a destroy function… but that is a lot of noise and a lot of places for someone to make a mistake using them. A coroutine is cleaner.

for example, in the matasano crypto challenge i needed to simulate a message protocol between various actors (and then break it). i could have written client and server as separate threaded entities, but it was simpler to just have them each be a coroutine.

think of them like thread, state and bi-directional queue, in one easy package.

another example is lazy sequences. you could start up a separate thread that generates the sequences, but then you need to talk to it, throttle it in some way, and close it down. using a generator (a simple co-routine) you can still have your code for generating the sequence in one clean place, but it's easier to call and control.

if you've ever thought "it would be kinda cool if threads were simple, so i could structure my code like..." then you probably would have appreciated a coroutine.

[update: blog post on the protocol bit - http://www.acooke.org/cute/UsingCorou0.html - although really it doesn't say much more than the above]

  1. Imagine the control flow you actually want.
  2. Manually perform some subset of a CPS transform around the parts that would block.
  3. Write the result of 2 and check it in.

  a. Read the code.
  b. Attempt to reconstruct a mental model of the originally-desired control flow from the mess.
  c. goto 1.