[syntheweave]

That is a description of flow-based programming, minus the generalization to "arbitrary packets of data in bounded buffers" - that is, your only data type is true/false and your only buffer size is 1, which lets you get some very clean syntax on it. It's a good invention!

FBP adapts the physical concept of unit record machines that operate over punchcard stacks, which predisposes it to thinking in terms of processing and transforming richer data like "characters in a string" or "records in an array", but it basically works for truth-signalling logic too - let truth packets wait in a buffer, and then when the node signals that the packets are able to move, that is the transition.

The emphasis does differ in that if we are thinking "FSM", the rest of the program and the data it handles have been abstracted, while if we are thinking "FBP" we're engaged with designing specific machines to connect together in terms of I/O, which is more helpful when you have a library of data operations to reuse.

[samsquire]

Thank you syntheweave for an interesting reply.

You're right about the buffers with a truth value in a buffer. I actually use a style of promises or my own count down latch.

I am inspired by Prolog and Drools, a rule engine. I want to "fire" and "retract" facts and the state machine shall work out what to do next.

Here's something that I find especially useful about the formulation: the state machine only moves in one direction, from left to right, but there are multiple transition signals available (facts/atoms) that can be fired to cause the state machine to move forwards.

If you define multiple independent state machines it should be possible to detect "stuck states" where it is impossible for the state machine to continue progressing! This is useful for liveness analysis.

I want the state machine formulation to be useful in designing distributed systems such as Raft.