General architecture improvement

[bygu4]

Continuing the finite_automaton redesign I think we should go on and rework the relations of the rest of the modules as well, making the architecture clearer and removing the cyclic imports. For now, I think this is the general design we could try to implement:

In more detail, firstly I think we should build CFG from PDA in the CFG class instead:

pyformlang/pyformlang/pda/pda.py

Line 330 in 9d576c8

def to_cfg(self) -> "cfg.CFG":

Then, I think we should define the PDA intersection with the DFA explicitly, to avoid unnecessary checks, and so that Regex -> ENFA -> DFA transition chain can be used:

pyformlang/pyformlang/pda/pda.py

Line 443 in 9d576c8

def intersection(self, other: Any) -> "PDA":

And also we can do the same thing in the CFG class:

pyformlang/pyformlang/cfg/cfg.py

Line 791 in 9d576c8

def intersection(self, other: Any) -> "CFG":

On a side note, I think the CFG Variable Converter should take place in the cfg module. To rework it in a stricter way, I think we can move the object classes (i. g. finite_automaton objects, regex objects, etc.) to a separate module, and that way I think we could also avoid some potential design issues.

Moving on to indexed_grammar, I think we should implement the intersection explicitly with FST (in a way similar to CFG):

pyformlang/pyformlang/indexed_grammar/indexed_grammar.py

Line 335 in 9d576c8

def intersection(self, other: Any) -> "IndexedGrammar":

In that case the Regex -> ENFA -> FST transition chain could be used. Then we can remove the intersection method from the FST class. I think it shouldn't be there if it returns IndexedGrammar.
Also I would suggest using CFG objects in indexed_grammar, and FA objects in fst to add stricter type annotations.

If you agree with these changes, I would like to take this issue and try to implement them.

[bygu4]

Alternatively, we can add from_cfg method to PDA. It might be better because:

• it is probably a more natural design choice
• it is easier to refactor
• CFG class is already quite large.

But on other hand, it would bring inconsistency to the architecture. I think, it would have made more sense if we had regular grammar representation that finite_automaton module would depend on. Maybe that's an idea for future updates.