Skip to content

Latest commit

 

History

History
134 lines (91 loc) · 3.08 KB

README.md

File metadata and controls

134 lines (91 loc) · 3.08 KB

smlang: A no_std State Machine Language DSL in Rust

Build Status

A state machine language DSL based on the syntax of Boost-SML.

Aim

The aim of this DSL is to facilitate the use of state machines, as they quite fast can become overly complicated to write and get an overview of.

Transition DSL

The DSL is defined as follows (from Boost-SML):

statemachine!{
    SrcState + Event [ guard ] / action = DstState,
    *SrcState + Event [ guard ] / action = DstState, // * denotes starting state
    // ...
}

Where guard and action are optional and can be left out. A guard is a function which returns true if the state transition should happen, and false if the transition should not happen, while action are functions that are run during the transition which are guaranteed to finish before entering the new state.

This implies that any state machine must be written as a list of transitions.

Examples

Here are some examples of state machines converted from UML to the State Machine Language DSL. Runnable versions of each example is available in the examples folder.

Linear state machine

alt text

DSL implementation:

statemachine!{
    *State1 + Event1 = State2,
    State2 + Event2 = State3,
}

This example is available in ex1.rs.

Looping state machine

alt text

DSL implementation:

statemachine!{
    *State1 + Event1 = State2,
    State2 + Event2 = State3,
    State3 + Event3 = State2,
}

This example is available in ex2.rs.

Using guards and actions

alt text

DSL implementation:

statemachine!{
    *State1 + Event1 [guard] / action = State2,
}

This example is available in ex3.rs.

TODOs

Features missing:

  • Add so Events can have data associated to them which is passed to the guard and action
  • Allow guard and action to be closures
  • Have the transition DSL automatically generate a DOT graph for easier debug
  • Give the state machine a settable type
  • Look into adding a context structure into the state machine to handle user added data

Possible future straw-man syntax:

statemachine! {
    type: MyStateMachine,
    context: MyContextStruct,
    transitions: {
        *State1 + Event1 = State2,
        State2 + Event2 = State3,
    },
    values: {
        Event1: Type1,
        Event2: Type2
    }
}

or

statemachine! {
    type: MyStateMachine,
    context: MyContextStruct,
    transitions: {
        *State1 + Event1(Type1) = State2,
        State2 + Event2(Type2) = State3,
    },
}

Contributors

List of contributors in alphabetical order:


License

Licensed under either of

at your option.