The end state could be a map[string]struct{}, since it is only used to test the presence of the string. The bool value is unused, and an empty struct takes no memory, so it would be an admittedly tiny optimization.<p>Related: Rob Pikes' lexical scanning talk (state machines in Go): <a href="http://blog.golang.org/2011/09/two-go-talks-lexical-scanning-in-go-and.html" rel="nofollow">http://blog.golang.org/2011/09/two-go-talks-lexical-scanning...</a>
Personally I'd model a state machine in Go as<p><pre><code> type State int
type Transition int
func (s State) Next(t Transition) (State, error) {
/* doubly nested switch goes here */
}</code></pre>
Ragel supports Go output. There's been some recent fixes according to the mailing list, so you may need to get a recent version straight from git: <a href="http://www.complang.org/pipermail/ragel-users/2013-February/002939.html" rel="nofollow">http://www.complang.org/pipermail/ragel-users/2013-February/...</a>
It's interesting to contrast this design with what Rob Pike presented in his talk on the Go template lexer. Some differences:<p>(1) Pike's is more static: there is no Machine struct and states are identified with handlers so that there is no table lookup in the loop.<p>(2) Pike chose to go with a modifiable lexer struct rather than threading a cargo value through the machine.<p>(3) Pike used nil for all end states.<p>The main design questions are probably:<p>(a) Do you need to construct machines at runtime?<p>(b) Do you need state names available at runtime?
please consider adding an 'fsm-trace' or some such, which is basically an array of values, each having time, input-msg, current-state and next-state (at the very least), so that debugging these becomes easier...
Since Go has goroutines, I wonder if you can do something like this:<p><a href="http://eli.thegreenplace.net/2009/08/29/co-routines-as-an-alternative-to-state-machines/" rel="nofollow">http://eli.thegreenplace.net/2009/08/29/co-routines-as-an-al...</a><p>Basically use stack state and goroutines to avoid explicit states. Unlike Python, Go might take multiple threads to do this?