On 24 August 2017 at 06:39, Bakul Shah <[email protected]> wrote: > On Wed, 23 Aug 2017 12:11:41 BST roger peppe <[email protected]> wrote: >> On 23 August 2017 at 11:20, Bakul Shah <[email protected]> wrote: >> > >> > I find regular functions much cleaner (and a closer analog of >> > a digital FSM). See for example: > ... >> > func stateOne(i inputType) state { >> > // etc. etc. >> > } >> >> As we know, this really isn't far removed from: >> >> func (i inputType) stateOne() state >> >> The only difference is that by defining it as a method, we're >> making the association a little closer, and that using a method >> forces you to mention the type name to get a handle on the method >> (presumably that's the "boilerplate" you're talking about?) >> >> Which is nicer is just a matter of taste then, I think. In a larger package, >> the namespacing might be quite nice - it means you could easily >> have two or more FSMs with different input types but similar state >> transition names without needing disambiguation for your transition >> function names. > > I concede the namespace argument. Though I am likely to a) not > export FSM state functions and b) put each FSM in its own > package as they have a habit of getting messier over time! > > Some other things to consider: given that each FSM state > *consumes* an input, it make make sense to use a separate > argument for input. For example, for a scanner, > > func (s *Scanner)stateX(r rune) state > or > func statX(s *Scanner, r rune) state > > The Scanner object contains the current partial token among > other things -- basically the internal state of a scanner. It > doesn't make sense to first store the input rune in Scanner > and then call stateX.
Agreed. > It may also make sense to use something like > > func (s *Scanner)stateX(r rune) (state, action) > > The idea is that the second result may trigger a higher level > action. For example, when a complete token is received, call > the parser or put the last rune back etc. This way multiple > input streams may be processed concurrently. > > Finally, for better performance it may make sense to store the > FSM as a vector of vectors or vector of maps so that a slice > of inputs may be processed in one function call. Probably best > done with a FSM generator. That's interesting. What might that look like? >> > and so on. This is a Mealy machine, where the next state >> > depends on the current state and current input (in s/w not >> > much use for a Moore machine unless you are driving/simulating >> > some regular physical process, in which case you don't need >> > any input parameter). If you want a side effecting FSM, pass >> > in a ptr to some mutable state. > > Thanks to Steven Blenkinsop <[email protected]> for correcting > me on this. I should have checked instead of relying on my > faulty memory (and I should not have posted while being very > sleepy!). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
