FAQ
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

--
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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Stephen Waits at Nov 20, 2013 at 1:55 am
    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
    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
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Tamás Gulácsi at Nov 20, 2013 at 8:36 am
    Maybe you should use reflect to parse the nested structure, and build a flattened state machine from it.

    This nested thing is just hiding the outer states, thus you can write states seemingly free from the outer scope - but in reality all inner states are prefixed with "connected-" or "disconnected-" eg.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Egon at Nov 20, 2013 at 9:24 am
    Here's how you can define such
    structure http://play.golang.org/p/gOoyOQh9Y5.

    Also, I would recommend finding a more complicated example than traffic
    signals for trying to define them. One of the benefits of state machines is
    their visual part, i.e. either add a possibility to create a state diagram
    or do it the other way around... define a state diagram and generate the
    code from that.

    + egon
    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
    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
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Stephen Waits at Nov 20, 2013 at 7:12 pm
    Thanks.

    I honestly don't think I would have ever come up with the idea of using of
    variadic parameters in such a way.

    --Steve
    On Wednesday, November 20, 2013 1:24:00 AM UTC-8, egon wrote:

    Here's how you can define such structure
    http://play.golang.org/p/gOoyOQh9Y5.

    Also, I would recommend finding a more complicated example than traffic
    signals for trying to define them. One of the benefits of state machines is
    their visual part, i.e. either add a possibility to create a state diagram
    or do it the other way around... define a state diagram and generate the
    code from that.

    + egon
    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
    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
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Egon at Nov 20, 2013 at 10:45 pm
    You can do it without variadics... and with a potential benefit to speed.
    But the syntax would be unwieldy... e.g. " State{ [...]Property{ a, b,
    c....} } "
    On Wednesday, November 20, 2013 9:12:14 PM UTC+2, Stephen Waits wrote:

    Thanks.

    I honestly don't think I would have ever come up with the idea of using of
    variadic parameters in such a way.

    --Steve
    On Wednesday, November 20, 2013 1:24:00 AM UTC-8, egon wrote:

    Here's how you can define such structure
    http://play.golang.org/p/gOoyOQh9Y5.

    Also, I would recommend finding a more complicated example than traffic
    signals for trying to define them. One of the benefits of state machines is
    their visual part, i.e. either add a possibility to create a state diagram
    or do it the other way around... define a state diagram and generate the
    code from that.

    + egon
    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
    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
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Matt Harden at Nov 23, 2013 at 1:38 am
    Actually, replacing NState(...) with State{...} achieves exactly the same
    result without a function call (or variadics).

    http://play.golang.org/p/Ya6QguLWhG

    That said, I think I would do something with a bit more structure.

    http://play.golang.org/p/ZkBfHsx9yj

    On Wed, Nov 20, 2013 at 4:45 PM, egon wrote:

    You can do it without variadics... and with a potential benefit to speed.
    But the syntax would be unwieldy... e.g. " State{ [...]Property{ a, b,
    c....} } "

    On Wednesday, November 20, 2013 9:12:14 PM UTC+2, Stephen Waits wrote:

    Thanks.

    I honestly don't think I would have ever come up with the idea of using
    of variadic parameters in such a way.

    --Steve
    On Wednesday, November 20, 2013 1:24:00 AM UTC-8, egon wrote:

    Here's how you can define such structure http://play.golang.
    org/p/gOoyOQh9Y5.

    Also, I would recommend finding a more complicated example than traffic
    signals for trying to define them. One of the benefits of state machines is
    their visual part, i.e. either add a possibility to create a state diagram
    or do it the other way around... define a state diagram and generate the
    code from that.

    + egon
    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
    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
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Stephen Waits at Nov 23, 2013 at 5:47 am
    Thanks man. This is great stuff!

    Your more structured version is nice and clean.

    --
    Steve
    🏁🚴
    On Nov 22, 2013, at 17:37, Matt Harden wrote:

    Actually, replacing NState(...) with State{...} achieves exactly the same result without a function call (or variadics).

    http://play.golang.org/p/Ya6QguLWhG

    That said, I think I would do something with a bit more structure.

    http://play.golang.org/p/ZkBfHsx9yj

    On Wed, Nov 20, 2013 at 4:45 PM, egon wrote:
    You can do it without variadics... and with a potential benefit to speed. But the syntax would be unwieldy... e.g. " State{ [...]Property{ a, b, c....} } "

    On Wednesday, November 20, 2013 9:12:14 PM UTC+2, Stephen Waits wrote:
    Thanks.

    I honestly don't think I would have ever come up with the idea of using of variadic parameters in such a way.

    --Steve
    On Wednesday, November 20, 2013 1:24:00 AM UTC-8, egon wrote:
    Here's how you can define such structure http://play.golang.org/p/gOoyOQh9Y5.

    Also, I would recommend finding a more complicated example than traffic signals for trying to define them. One of the benefits of state machines is their visual part, i.e. either add a possibility to create a state diagram or do it the other way around... define a state diagram and generate the code from that.

    + egon
    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
    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
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/Ps0y2g56naM/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 20, '13 at 12:02a
activeNov 23, '13 at 5:47a
posts8
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase