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.
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.
> > 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.
