[goless]

Is there a way to combine:

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.

[noelwelsh]

You keep using the term "semantic composition", which does not have any meaning for me.

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?

[goless]

Haha, thanks for your reply, I will improve my documentation to make the descriptions more accurate, and you may raise some issues to help this library better.

As for why semantic composition is used, the following example may be instructive：

yes_or_no(exit,a) This means confirm once before exiting

yes_or_no(yes_or_no(exit,a),a) Confirm twice before exiting

yes_or_no(yes_or_no(yes_or_no(exit,a),a),a) Confirm three times before exiting

This is very similar to the composition you describe.

This is the actual code: https://github.com/sdzx-1/polystate-examples/blob/fecaffb5b7...

If there is no name for this way of using state machines, then semantic composition seems appropriate.

Exceptionally, combining two states in a polystate may actually be combining two small state machines, and I think nested selects are sufficient to illustrate this.

https://github.com/sdzx-1/ray-game/blob/9646bc3c0f1c11314aaf...

How do you understand such behavior?

[goless]

https://github.com/sdzx-1/polystate/raw/master/data/graph.pn...

This is the state diagram combining two selects!

[goless]

Due to my submission yesterday, this diagram can no longer fully accurately express the current state machine, but it can probably be used as an approximate reference.

[mxkopy]

This sounds more like a product than a composition but I’m not sure. I think the parent is hinting to use established compcomp language. Sipser is a good read for this

[goless]

I'm not sure if this is a new form of state machine.

If you look at the code here you'll see that the select state uses some functions from the parameter state.

https://github.com/sdzx-1/ray-game/blob/master/src/select.zi...

So you can see that the select state itself is incomplete, and the parameter state completes it.

It doesn't seem to be any of the 3 described above.

Perhaps it is reasonable to call it semantic composition.

[goless]

Here I must mention the great advantage of the Zig language: it has the expressiveness of a dynamic language and the type safety of a static language.

[goless]

From this perspective, do you think my previous description is accurate?