Common interface for all automaton types

[zwergziege]

In AALpy helper functions that work on automata (e.g. make_input_complete) we always need to check which kind of automaton we are handling. Usually there is a big fat if-then-else thingy that has options for each automaton type and often those code paths are only needed to account for the miniature differences between automaton state (data) structures. For a while now I've been thinking that it would be nice to have a common interface for automata to get rid of this and make future development easier.
One thing that we could do is to implement a method for each automaton type that exposes a dynamic view of the automaton as an LTS with a common structure for labels for states and transitions. Transition labels could be behave like a dictionary with different keys for each automaton type. Moore machine transitions would have a single key "input". Transitions of stochastic Mealy machines would have "output" and "probability" in addition to that.
Take for example the part of make_input_complete that adds a new transition after having identified some state s where input i is missing. Currently, this has 24 lines of ifs. Using the proposed LTS view, we could write code similar to this:

target_state = s if missing_transition_go_to == 'self_loop' else sink_state
label = dict(input=i)
if isinstance(automaton, (MealyMachine, Onfsm, StochasticMealyMachine)):
  label["output"] = "epsilon"
if isinstance(automaton, (Mdp, StochasticMealyMachine)):
  label["probability"] = 1.
new_transition = lts_view.add_transition(source=s, target=target_state, label=label)

Ideally minus the magic strings :D

If we use mixins for the distinctions moore vs mealy and det vs non-det vs stochastic the comparison gets even simpler and more robust. Then we could replace e.g. isinstance(automaton, (MealyMachine, Onfsm, StochasticMealyMachine)) by - let's say - isinstance(automaton, MealyMachineLike).

Let me know what you think.

[emuskardin]

I agree this can be simplified. But it might not be so important, and adds bit of "overhead" to this "should be simple" automaton classes.
But in the long run, I agree. But I do not like this MealyMachineLike, there is nothing like Mealy Machines, they are the best.

Lets talk in few days in the office.