rename class: FiniteStateMachine -> Transducer
rename class: FiniteStateMachine -> Transducer

because that is less ambiguous and shorter. It is intended to mean a sequential (causal) transducer, instead of a general transducer. In general, a transducer can include an acceptance condition and path quantification. In other words, an automaton that describes a relation, instead of a set of sequences (which is a special case). Such an automaton is essentially another representation of a game, i.e., equivalent to a game graph.

But it is not ready to be used for implementation, because it doesn't tell us how to play now, before learning the future. The relevant technical details will be elaborated in a separate document. For this reason, we call the class "transducer" to avoid long names that are unlikely to be used in practice (a non-sequential transducer is not very useful to be called the end result of synthesis, and the same holds for a transducer equipped with an acceptance condition).

By "machine" we will understand a construction ready to be deployed. So a machine represents *constructively* a transduction that serves our purpose (we don't have to solve based on the future, in order to decide what to do next). As such, a machine has universal path quantification. Any output-non-determinism corresponds to multiple conjuncts with the same direction but different target node.

For this reason, we retain the appellations `MealyMachine` and `MooreMachine`.
necozay/tulip-control,tulip-control/tulip-control,tulip-control/tulip-control,necozay/tulip-control,necozay/tulip-control,necozay/tulip-control,tulip-control/tulip-control,necozay/tulip-control,tulip-control/tulip-control