For Python: (might help someone)
http://www.dabeaz.com/coroutines/
Coroutines and Fibers: Why and When
21–23 of 23 posts
Re: Coroutines and Fibers: Why and When
#22One caveat with coroutines and fibers is that all the code that runs on them must be fully aware that they are running on said coroutines and fibers.
Not true if one is using Haskell (or any other sufficiently expressive language)
That has nothing to do with Haskell's expressivity and everything to do with its full purity. If you look at, say, OCaml, the code (or at least the libraries) must also be aware that it's running in a fiber, just as in Java, Go or Erlang.
While full purity has its virtues, it also has serious drawbacks, and it's unclear at this point whether or not at the end of the day purity is a net-gain, neutral, or even a net-loss.
Re: Coroutines and Fibers: Why and When
#23Earlier quoted context omitted.
FSM may be a better fit for this specific application, though.
For something engineered, sure. However if you're working with designers who don't have a lot of formal education it's much easier to convey the concept of a function that "pauses" where yield() happens. Also quite a bit of gameplay code ends up as throw-away so being able to quickly put behaviors together is a plus.
You're saying a tree of FSM states is more difficult to convey than linearized coroutine code, with emphasis on informal programmers/designers?
You may want to take a look at visual FSM solutions, which do what you specify and more, easily.
You're not even wrong.
https://unity3d.com/learn/tutorials/modules/beginner/animati..., for an example in an Animation program