[go-nuts] seeking idiomatic advice for nested literal data structure

On Tuesday, November 19, 2013 4:02:35 PM UTC-8, Stephen Waits wrote:

Nuts,

I'm looking to implement a statechart (aka "hierarchical state
machine") package.

This requires that my data convey hierarchy as well as specifics about
each state; how it responds to various events, etc. As a very trivial
example, that data looks something like this:

State(TrafficSignalRoot) {
Entry(DoPOST) // call DoPOST() on entry to perform power on self test
Default(Red) // default transition into Red sub state first state is
Red
Idle(CheckForError) // call CheckForError() on Idle event poll for a
FAILURE event
Terminate(FAILURE) // exit all states on FAILURE event machine exits
on FAILURE event
Exit(EnableRedFlashMode) // call EnableRedFlashMode() on exit to
switch to Flash Mode

// red light state, a substate of TrafficSignalRoot
State(Red) {
Entry(RedOn) // call RedOn() on Entry
Exit(RedOff) // call RedOff() on Exit
Transition(5.0,Green) // transition to Green state on a "5 second
timer" event
}

// green light state, a substate of TrafficSignalRoot
State(Green) {
Entry(GreenOn) // call GreenOn() on Entry
Exit(GreenOff) // call GreenOff() on Exit
Transition(5,Yellow) // transition to Yellow state on a "5 second
timer" event
}

// yellow light state, a substate of TrafficSignalRoot
State(Yellow) {
Entry(YellowOn) // call YellowOn() on Entry
Exit(YellowOff) // call YellowOff() on Exit
Transition(1.5,Red) // transition to Red state on a "1.5 second timer"
event
}
}


Translated to Go, I'm thinking this data may work as a nested literal
structure. But, I'm not sure I even know where to start to pull that off.
And further, I definitely have no idea if that's a nice path to choose. So,
I'm looking for your advice on how to approach this.

Any and all ideas and comments are very welcome. Thank you in advance
for your time and consideration!

--Steve

On Wednesday, November 20, 2013 3:55:46 AM UTC+2, Stephen Waits wrote:
Thought I'd follow up to try to add a little clarity to what I'm doing here.

I want to implement hierarchical state machines, also known as statecharts. This type of state machine can have arbitrarily nested states. For example, you may have a device that can, at a high level, be "connect" to the network, or "disconnected". Within each of those states, you may have several other states. In "connected", you may progress through a default (i.e. first state) of "negotiating", "synchronizing time", "authenticating", etc.

What's interesting about these is that Events processed by the machine are sent initially to the current state, which may or may not handle it. Then the same events are sent to each state walking up the hierarchy until you finally send the event to the Root State.

This makes for some very nice state organization. Again using my stupid example from above, in the highest level state "connected", you may set a transition to happen on any error straight to the "disconnected state". Such a transition would cause each of the current states to exit up to the first common ancestor to the new state, and entry actions for each state back down to the final new state.

(whew.. that's the quick HSM intro). You can read plenty more about this basically everywhere. It's not a new idea. :)

Now, to my specific problem. I'm trying to implement these in a way that keeps the main state diagram concise, in one place, and fairly readable. When working with HSMs, it's very useful to be able to view and conceptualize the entire machine flow, without distraction of various implementation code.

With this in mind, I believe my Traffic Light example (quoted below) may make more sense.

What I'm after is a way to represent this data (states, each having an ordered map of event -> function callbacks; which states being arbitrarily nestable). I thought I may be able to pull this off with composite literals, but I'm struggling to see it.

Any ideas?

Thanks,
Steve