"For the first time, we can achieve semantic-level code reuse through type composition." is, to me, mostly meaningless. This almost certainly isn't the first time someone has done whatever it is you are claiming. What is *semantic-level" code reuse? Calling a library function is code reuse, and I expect that function to have the same semantics every time I call it. Why is type composition necessary to achieve this?
"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." How does the specifying behavior at the type level follow from composition? I can use composition, at the value level, just fine without types (e.g. in Javascript).
1, https://github.com/sdzx-1/polystate?tab=readme-ov-file#2-imp...
This shows what composition means, and even complex nested selects are described quite precisely by type.
2, https://github.com/sdzx-1/polystate?tab=readme-ov-file#1-com...
Yes, this effect can be achieved without using composite types. But if it is convenient and easy to achieve this effect through composite types, is it worth it?
Regarding composition, there are at least three ways to compose FSMs:
* Sequential: when one FSM finishes (reaches a final state) it transitions to the start state of another FSM.
* Parallel: two FSMs transition in parallel from the same input
* Nested: when a FSM reaches a certain state, another FSM starts responding to the input. When the second FSM reaches a final state, control returns to the original FSM.
It would help your description if you were clear about the kinds of composition your library supports. The terminology of FSMs is quite consistent and well defined, so I think you should be able to use it to describe what the library does.
Higher order finite state machines that require other states as parameters to work.
https://github.com/sdzx-1/ray-game/blob/master/src/select.zi...
The select, inside, and hover states here are all high-level states, and all require two state parameters. And these three states form a small state machine for handling mouse interactive selection.
Can I think of this way of using higher-order state machines as a kind of composition? A semantic composition.
Take function composition, which is perhaps the best known example of composition. Let's say we have
f(x) = x + 1
g(x) = x * x
The composition (f o g) = g(f(x)) could be called a "semantic" composition because the result has the semantics of the two functions (it increments then doubles). So what does your use of the term actually mean?
In general I feel you need more precision in your description. There is standard terminology for finite state machines and for programming languages that I think you could use. Take, for example, your statement "all require two state parameters". I think these are not value level parameters, but type level parameters. This is an important difference, and you should mention it.
Going back to FSMs, there are several ways you can encode a FSM in a typed programming language. For example:
1. A FSM is a type constructor parameterized by the type of states. This means the FSM cannot transition to states that are not of the correct type, but it does not otherwise constrain transitions.
2. States themselves are type constructors parameterized by the type of states they can transition to. This adds more constraints (and requires more complex types) than the approach above.
Do you see the difference between these and hence the need for clarity and precision in descriptions?
I’ve seen category theory papers on this and related topics, but I haven’t seen code in the wild. Have you?
IME this kind of finite state machine business code (as opposed to a FSM embedded in an algorithm somewhere) is written as a one-off each time.
E.g., https://arxiv.org/abs/1808.05415 comes to mind. David I. Spivak has also done some work on composition of systems that is relevant.
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.