State Machines in Rust

Post by jfkebwjsbx » Wed, Apr 01, 2020, 6:35 PM UTC

fluffything wrote: post #70

grenoire wrote: post #48

Earlier quoted context omitted.

Currently the compiler gives "not a type" when the brackets are removed; I agree that it might be to disambiguate, but it's confusing and redundant syntax. I expect { } to be used strictly for blocks in Rust.

C++ requires using the template keyword to disambiguate, i.e., one has to write `foo.template bar 2>()` as opposed to `foo.bar 2>()` (did you mean `(foo.bar ()` ?). The main reason Rust meta-programming is so much better than D and C++ is that Rust has an LL(k) grammar that's trivial to parse into ASTs that can be easily manipulated. That feature alone is definitely worth the annoyance of having to use an editor that…

Post by jfkebwjsbx » Wed, Apr 01, 2020, 6:47 PM UTC

fluffything wrote: post #73

logicchains wrote: post #16

C++20 supports enums as non-type template parameters, so I think it'd be possible to do it with enums there. Something like: enum class Color{Green, Yellow, Red}; template struct State{}; auto newState() -> State {...}; auto next(State ) -> State {...} auto next(State ) -> State {...} auto next(State ) -> State {...} int main(){ const auto state = newState(); // Green const auto state = next(state); // Yellow const a…

That example does not work, because declaring `state` multiple times creates an illegal C++ program (redeclaration of local variable - notice that this is not the case in Rust). You need to declare variables with different names: const auto state0 = newState(); const auto state1 = next(state0); const auto state2 = next(state1); const auto state3 = next(state); // TYPO -> BOOM use after move I don't think this can be…

Post by lewisinc » Wed, Apr 01, 2020, 7:28 PM UTC

unlinked_dll wrote: post #76

jstrong wrote: post #59

Earlier quoted context omitted.

the article includes a section on the state as a generic type parameter, though? in general, state as a type parameter is useful when there's some data that you want for every state (say, unique id, time of event), so those can be normal fields on the State struct, and then each event type can hold event-specific data. You can tie it together with From and TryFrom implementations that enable the specific transitions…

Associated types are slightly different than generic types. trait State { type NextState; fn transition(self) -> Self::NextState; } In this example one consumes the current state to yield the next state (one could use From/TryFrom, but I don't think that makes sense semantically, imo). The advantage of this approach is that if you design your State types such that they can only be constructed by transitioning from a…

Post by dpbriggs » Wed, Apr 01, 2020, 7:54 PM UTC

    trait State: std::fmt::Debug {
        fn transition(&self) -> Option>;
    }

    #[derive(Debug)]
    struct FirstState {
        foo: u32,
    }
    
    impl State for FirstState {
        fn transition(&self) -> Option> {
            println!("First State Hit {}", self.foo);
            Some(Box::new(SecondState {
                bar: "Hello".to_owned(),
            })) // transition to second state
        }
    }

    struct StateIterator {
        curr_state: Option>,
    }
    
    impl StateIterator {
        fn new(curr_state: Option>) -> Self {
            Self { curr_state }
        }
    }
    
    impl Iterator for StateIterator {
        type Item = Box;
        fn next(&mut self) -> Option {
            let next_state = self
                .curr_state
                .as_ref()
                .and_then(|state| state.transition());
            std::mem::replace(&mut self.curr_state, next_state)
        }
    }

    fn main() {
        let first_state = Box::new(FirstState { foo: 0 });
        for state in StateIterator::new(Some(first_state)) {
            println!("{:?}", state);
        }
    }

    ~ state-machine git:(master)  cargo run
    First State Hit 0
    FirstState { foo: 0 }
    Second State Hit: Hello
    SecondState { bar: "Hello" }

Post by papaf » Wed, Apr 01, 2020, 8:16 PM UTC

jstrong wrote: post #61

papaf wrote: post #17

Earlier quoted context omitted.

I am not a fan of the hoverbear state machine pattern. I find that it makes simple things complicated and hard things impossible. I used it and I had problems with: - Reusing code between states. - Making callbacks to other APIs during state changes. I ended up using the standard state pattern described here: https://doc.rust-lang.org/book/ch17-03-oo-design-patterns.ht... The state pattern is not considered to be idi…

for reusing code between states, did you try impl blocks that are generic over the state type parameter? for struct State { state: T } with possible states struct A { id: Uuid } struct B { id: Uuid } use a trait trait HasId { fn id_mut(&mut self) -> &mut Uuid; } now you can impl over both A and B impl for State { fn new_id(&mut self) { *self.state.id_mut() = Uuid::new_v4() } } simplistic example but enough to communi…