Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State Machines in Rust

blog.yoshuawuyts.com

Post reply on HN
Print view View original

41–50 of 119 posts

Re: State Machines in Rust

#41

Post by DougBTX »

Arnavion wrote: post #27
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…

Rust will also support it one day, as part of the const generics feature. Partial support is there behind a feature flag. https://play.rust-lang.org/?version=nightly&mode=debug&editi... #![feature(const_generics)] #[derive(PartialEq, Eq)] // enums used as const generics must be Eq enum Color { Green, Yellow, Red } struct State ; impl State { fn next(self) -> State { State } } impl std::fmt::Debug for State { fn fmt(&…

Are the braces around the const expressions planned to be optional in future? I'm wondering if this will work:

    impl State {
        fn next(self) -> State { ... }
    }

Re: State Machines in Rust

#42

Post by palotasb »

wiz21c wrote: post #3
Phlogistique wrote: post #2

They link to the `P` language, which I did not know about. https://github.com/p-org/P I found the link interesting because I have at times wondered what it would look likes if FSM were first class control flow features, akin to `if` and `while`.

the ping pong program is very easy to read. I don't know if it scales to bigger ones, but this one is really nice.

https://github.com/p-org/P/wiki/PingPong-program for anyone else wondering

Re: State Machines in Rust

#43

Post by Arnavion »

DougBTX wrote: post #41
Arnavion wrote: post #27

Earlier quoted context omitted.

Rust will also support it one day, as part of the const generics feature. Partial support is there behind a feature flag. https://play.rust-lang.org/?version=nightly&mode=debug&editi... #![feature(const_generics)] #[derive(PartialEq, Eq)] // enums used as const generics must be Eq enum Color { Green, Yellow, Red } struct State ; impl State { fn next(self) -> State { State } } impl std::fmt::Debug for State { fn fmt(&…

Are the braces around the const expressions planned to be optional in future? I'm wondering if this will work: impl State { fn next(self) -> State { ... } }

I believe they're intentional, to disambiguate from `mod Color { struct Green; }`, and because they can be arbitrarily complex expressions.

Re: State Machines in Rust

#44

Post by jcelerier »

logicchains wrote: post #36
jcelerier wrote: post #33

Earlier quoted context omitted.

> C++20 supports enums as non-type template parameters, so I think it'd be possible to do it with enums there. Something like: Even c++98 supported that already : https://gcc.godbolt.org/z/7xma_u

Good point, I suppose of course it does, since enums are just ints. But C++20 adds support for enum classes (and also variants when they can be defined as value types with a defaulted operator ).

> But C++20 adds support for enum classes

It seems to work fine with `enum class` under C++11 ? your code works almost inchanged in g++ 4.7. I don't see anything here : https://en.cppreference.com/w/cpp/language/template_paramete... that adds specific support for that in C++20

Re: State Machines in Rust

#45

Post by epage »

Coroutines are another interesting way of expressing state machines. They can make certain classes of state machines easier to read because the flow reads like a normal function. So far I've only used the technique once in Python using generators. There were some ergonomic aspects that were less than ideal but serve as one example of why I look forward to generators being added to Rust.

Re: State Machines in Rust

#46

Post by logicchains »

jcelerier wrote: post #44
logicchains wrote: post #36

Earlier quoted context omitted.

Good point, I suppose of course it does, since enums are just ints. But C++20 adds support for enum classes (and also variants when they can be defined as value types with a defaulted operator ).

> But C++20 adds support for enum classes It seems to work fine with `enum class` under C++11 ? your code works almost inchanged in g++ 4.7. I don't see anything here : https://en.cppreference.com/w/cpp/language/template_paramete... that adds specific support for that in C++20

Wow it does too, not sure where I got it into my head that it didn't then.

Re: State Machines in Rust

#47

Post by trevyn »

epage wrote: post #45

Coroutines are another interesting way of expressing state machines. They can make certain classes of state machines easier to read because the flow reads like a normal function. So far I've only used the technique once in Python using generators. There were some ergonomic aspects that were less than ideal but serve as one example of why I look forward to generators being added to Rust.

Async/await in Rust compiles down to a state machine (and to my understanding, uses generators under the hood):

https://rust-lang.github.io/async-book/01_getting_started/04...

Re: State Machines in Rust

#48

Post by grenoire »

Arnavion wrote: post #43
DougBTX wrote: post #41

Earlier quoted context omitted.

Are the braces around the const expressions planned to be optional in future? I'm wondering if this will work: impl State { fn next(self) -> State { ... } }

I believe they're intentional, to disambiguate from `mod Color { struct Green; }`, and because they can be arbitrarily complex expressions.

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.

Re: State Machines in Rust

#49

Post by alvarelle »

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…

In C++ you can't hide a variable with another of the same name in the same scope. So you'd want to give different names to all the 'state' variables.

Re: State Machines in Rust

#50

Post by hobofan »

grenoire wrote: post #48
Arnavion wrote: post #43

Earlier quoted context omitted.

I believe they're intentional, to disambiguate from `mod Color { struct Green; }`, and because they can be arbitrarily complex expressions.

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.

It's a block though, isn't it?

Color::Green is an enum variant while { Color::Green } is a (constant) block (expression) that evaluates to an instance which is used as a generic type parameter.

The difference might be more easily understandable if we look at an enum variant that holds a value, where the syntactic differences between variant and instance constructor are more clearly visible.

Color::RGB(u64, u64, u64) vs { Color::RGB(10, 20, 30) }

Post reply on HN