Is it feasible to use the yield keyword to implement a simple state machine as shown here. To me it looks like the C# compiler has done the hard work for you as it internally implements a state machine to make the yield statement work.
Can you piggy-back on top of the work the compiler is already doing and get it to implement most of the state machine for you?
Has anyone done this, is it technically possible?
While this is not a state machine in the classical sense, the article about Iterator-based Micro Threading uses yield creatively for state-based actions.
It's feasible but it is a bad idea. Iterator blocks were created to help you write custom iterators for collections, not for solving the general-purpose problem of implementing state machines.
If you want to write a state machine, just write a state machine. It's not hard. If you want to write a lot of state machines, write a library of useful helper methods that let you cleanly represent state machines, and then use your library. But don't abuse a language construct intended for something completely different that just happens to use state machines as an implementation detail. That makes your state machine code hard to read, understand, debug, maintain and extend.
(And incidentally, I did a double-take when reading your name. One of the designers of C# is also named Matt Warren!)
Yes, it's absolutely possible and easy to do. You can enjoy using control flow constructs (
for
,foreach
,while
, ...goto
(usinggoto
particularly suits this scenario ;))) along withyield
s to build one.Iterator blocks do indeed implement state machines, but the tricky bit is getting the next input. How are you going to know where to move next? I guess you could have some sort of shared "current transition" variable, but that's somewhat icky.
If you don't need any input (e.g. your state machine is just cycling between states) then it's easy, but that's not the interesting kind :)
Can you describe the kind of state machine you're interested in?