1. Record the state machine's status at the type level.
2. Achieve composable state machines through type composition.
Practical Effects of Polystate
1. Define the program's overall behavior through compositional declarations. This means we gain the ability to specify the program's overall behavior at the type level. This significantly improves the correctness of imperative program structures. This programming style also encourages us to redesign the program's state from the perspective of types and composition, thereby enhancing code composability.
2. Build complex state machines by composing simple states. For the first time, we can achieve semantic-level code reuse through type composition. In other words, we have found a way to express semantic-level code reuse at the type level. This approach achieves three effects simultaneously: conciseness, correctness, and safety.
3. Automatically generate state diagrams. Since the program's overall behavior is determined by declarations, polystate can automatically generate state diagrams. Users can intuitively understand the program's overall behavior through these diagrams.
chrisweekly · 3h ago
Looks interesting.
Note the README repeats a typo, twice, "ploystate" - the 1st two references to the package name. You'll def want to fix that pronto, it reduces confidence in quality of do s.
goless · 2h ago
Fixed, thanks for your reminder!!
goless · 4h ago
Hi everyone, I developed an interesting library Polystate: Composable Finite State Machines
Since I only have experience in haskell and zig, I'm curious if there are other languages or libraries with similar implementations?
physix · 32m ago
We developed an Entity DBMS where the entities are FSMs.
I believe that FSMs are a very powerful approach, even for building entire systems. So much so, that it forms a core part of our product.
goless · 24m ago
Yes, FSMs are underestimated in imperative programming. Of course this is probably because before type-safe state machines were available, manual coding was very error-prone.
crq-yml · 1h ago
Typically it's done through source code generation or a runtime interpreter - state machine systems implementing a "DSL->source code" mechanism have been around for nearly as long as high level languages, and by taking this approach they have a lot of freedom to include compiler techniques of their choosing. If dynamism is called for then the diagram is typically kept in memory and interpreted at runtime.
Doing it through types is intellectually interesting and makes the result more integrated into the edit-compile loop instead of involving a step in the build process or a step of invoking an interpreter, but it might not change the practical state of the art.
goless · 21m ago
Yes, but their expressiveness may vary. An important role of polystate is code reuse. It can express more complex states and still be type-safe.
solomonb · 3h ago
I'm having trouble reading zig code, so I'm not sure how much overlap there is but I have done some work with mealy and moore encoded as co-algebras in haskell:
Right on, I'll take a look at your haskell code this week.
goless · 4h ago
It relies heavily on compile-time evaluation of zig to achieve this, and I'm not sure if the same effect can be achieved in other languages.
tcoff91 · 1h ago
Looks kind of like a Zig version of XState, a typescript library that I really have enjoyed using.
goless · 18m ago
I don't know much about XState but it looks more like a dynamically interpreted execution state machine.
jasonthorsness · 2h ago
The automatic diagrams are great. Almost worth using a library like this just for that, since then you know the diagram actually reflects the implementation.
goless · 2h ago
Yes, all my examples have state diagrams, they are automatically generated and are an effective way for me to understand the structure of the program.
1. Record the state machine's status at the type level.
2. Achieve composable state machines through type composition.
Practical Effects of Polystate
1. Define the program's overall behavior through compositional declarations. This means we gain the ability to specify the program's overall behavior at the type level. This significantly improves the correctness of imperative program structures. This programming style also encourages us to redesign the program's state from the perspective of types and composition, thereby enhancing code composability.
2. Build complex state machines by composing simple states. For the first time, we can achieve semantic-level code reuse through type composition. In other words, we have found a way to express semantic-level code reuse at the type level. This approach achieves three effects simultaneously: conciseness, correctness, and safety.
3. Automatically generate state diagrams. Since the program's overall behavior is determined by declarations, polystate can automatically generate state diagrams. Users can intuitively understand the program's overall behavior through these diagrams.
Note the README repeats a typo, twice, "ploystate" - the 1st two references to the package name. You'll def want to fix that pronto, it reduces confidence in quality of do s.
Since I only have experience in haskell and zig, I'm curious if there are other languages or libraries with similar implementations?
https://medium.com/@paul_42036/entity-workflows-for-event-dr...
I believe that FSMs are a very powerful approach, even for building entire systems. So much so, that it forms a core part of our product.
Doing it through types is intellectually interesting and makes the result more integrated into the edit-compile loop instead of involving a step in the build process or a step of invoking an interpreter, but it might not change the practical state of the art.
https://blog.cofree.coffee/2025-03-05-chat-bots-revisited/ https://github.com/cofree-coffee/cofree-bot
Also using the lens library to encode moore machines as polynomial functors: https://blog.cofree.coffee/2024-07-02-lensy-moore/
I have a raw haskell prototype of polystate here, maybe it will help you. https://github.com/sdzx-1/typed-gui/blob/main/examples/todoL...