State Machines in Rust
blog.yoshuawuyts.com
State Machines in Rust
1–10 of 119 posts
Re: State Machines in Rust
#2They link to the `P` language, which I did not know about.
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`.
Re: State Machines in Rust
#3They 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.
Re: State Machines in Rust
#4Once upon a time I have implemented POP3 server protocol state machine in Clojure.
180 lines in total, of which 40 were FSM declaration, 140 command handling functions.
Not sure I'll ever want to approach FSM in any other language, unless no other choice.
Re: State Machines in Rust
#5However one big limitation of this is that this pattern cannot store the state inside another struct; it can only exist on the stack this way. So we cannot do the following:
struct Foo {
state: State,
}
Couldn't you just declare a trait that S must implement and then declare the member in Foo as State? That trait would probably also include the next() method mentioned in the example. Of course you'd be adding dynamic dispatch here, but it should work, right?
Re: State Machines in Rust
#6However one big limitation of this is that this pattern cannot store the state inside another struct; it can only exist on the stack this way. So we cannot do the following: struct Foo { state: State , } The moment we initialize Foo to take e.g. Green as its parameter, it can now no longer switch to Red in safe Rust. This is what enums are for, and unfortunately we can't use those here. Couldn't you just declare a tr…
I think that the whole point is to do this statically.
Re: State Machines in Rust
#7However one big limitation of this is that this pattern cannot store the state inside another struct; it can only exist on the stack this way. So we cannot do the following: struct Foo { state: State , } The moment we initialize Foo to take e.g. Green as its parameter, it can now no longer switch to Red in safe Rust. This is what enums are for, and unfortunately we can't use those here. Couldn't you just declare a tr…
The cited post[1] recommends an enum for this job, which avoids the dynamic dispatch and makes it easier to get at a specific state’s data when you have the whole machine.
Re: State Machines in Rust
#8Advocating for programmer ergonomics is always a good thing. And I think more people should advocate and try to design languages in such a way that the way of programming more closely resembles the actual real thing [1, 2].
As you might recall in cognitive psychology there's a specific idea that translating a problem to a more recognizable problem (or simply changing the symbols) is a good thing [3]. Having less working memory is a good thing.
Reading your post, I believe those principles are behind it.
[1] http://worrydream.com/LearnableProgramming/
[2] Sublime's feature of showing a color when you give a hex value.
[3] Chapter 12 - Cognitive Psychology (3rd edition) by Bruce Goldstein
Re: State Machines in Rust
#9However one big limitation of this is that this pattern cannot store the state inside another struct; it can only exist on the stack this way. So we cannot do the following: struct Foo { state: State , } The moment we initialize Foo to take e.g. Green as its parameter, it can now no longer switch to Red in safe Rust. This is what enums are for, and unfortunately we can't use those here. Couldn't you just declare a tr…
The cited post[1] recommends an enum for this job, which avoids the dynamic dispatch and makes it easier to get at a specific state’s data when you have the whole machine. [1] https://hoverbear.org/blog/rust-state-machine-pattern/
That is probably the way to go, agreed.
Re: State Machines in Rust
#10However one big limitation of this is that this pattern cannot store the state inside another struct; it can only exist on the stack this way. So we cannot do the following: struct Foo { state: State , } The moment we initialize Foo to take e.g. Green as its parameter, it can now no longer switch to Red in safe Rust. This is what enums are for, and unfortunately we can't use those here. Couldn't you just declare a tr…
Of course dynamic dispatch helps, but using it for a state machine is going to raise eyebrows and kill performance.