-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix architecture issues #9
Comments
This should be in pyformlang/pyformlang/finite_automaton/finite_automaton.py Lines 497 to 504 in 176a609
pyformlang/pyformlang/finite_automaton/finite_automaton.py Lines 531 to 533 in 176a609
|
We have to get rid of this abstract method, otherwise we are bound to have cyclic imports: pyformlang/pyformlang/finite_automaton/finite_automaton.py Lines 644 to 648 in 176a609
|
This shouldn't return None: pyformlang/pyformlang/finite_automaton/finite_automaton.py Lines 688 to 702 in 176a609
|
Probably should be for Any type, because we cast these parameters to State and Symbol anyway: pyformlang/pyformlang/finite_automaton/finite_automaton.py Lines 46 to 49 in 176a609
pyformlang/pyformlang/finite_automaton/finite_automaton.py Lines 77 to 81 in 176a609
|
Same as previous: pyformlang/pyformlang/finite_automaton/finite_automaton.py Lines 121 to 124 in 176a609
|
Maybe it's a good idea to rename pyformlang/pyformlang/finite_automaton/transition_function.py Lines 17 to 22 in 176a609
|
I think it would be better to make an overload for this method, as it's output type is different depending on the number of input parameters: pyformlang/pyformlang/finite_automaton/transition_function.py Lines 123 to 126 in 176a609
Also probably should return Set rather than List |
pyformlang/pyformlang/finite_automaton/epsilon_nfa.py Lines 121 to 123 in 176a609
|
Add same method for pyformlang/pyformlang/finite_automaton/nondeterministic_transition_function.py Lines 149 to 152 in 176a609
|
I think we can try moving this to NFA and making it a classmethod (like pyformlang/pyformlang/finite_automaton/epsilon_nfa.py Lines 253 to 266 in 176a609
|
Same here with pyformlang/pyformlang/finite_automaton/epsilon_nfa.py Lines 332 to 341 in 176a609
But it will require some refactoring to make sure we don't use protected enfa members |
Same story: pyformlang/pyformlang/finite_automaton/nondeterministic_finite_automaton.py Lines 118 to 127 in 176a609
|
Cyclic import here between pyformlang/pyformlang/finite_automaton/epsilon_nfa.py Lines 398 to 421 in 176a609
|
Same in |
We should also rework pyformlang/pyformlang/finite_automaton/doubly_linked_node.py Lines 6 to 20 in 176a609
|
This is strange, probably should be in |
I think we could rework |
https://github.com/Aunsiels/pyformlang/blob/4f36e28492a529d67129dcecaf9d07ca69fb0cf6/pyformlang/finite_automaton/deterministic_finite_automaton.py#L448-L453 |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as resolved.
This comment was marked as resolved.
pyformlang/pyformlang/regular_expression/regex.py Lines 310 to 327 in 176a609
self.head may be None here, maybe we can set it as Empty Symbol in the constructor
|
|
|
The idea to store ENFA in regex looks strange. Conversion of regex to ENFA is just yet another conversion, similar to ENFA to NFA conversion and so on. Yes, analysis of relations between CFG, Regexps, RSM, and automata required before final architecture proposal.
Maybe not now, but why not. The final goal is to make whole pyformlang better. |
I thought more about it, and maybe it's better to leave |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Maybe it's better to move it to |
This is meant to return pyformlang/pyformlang/cfg/pda_object_creator.py Lines 30 to 41 in 176a609
|
I would suggest building context free grammar from PDA in the pyformlang/pyformlang/pda/pda.py Lines 332 to 358 in 176a609
|
This class is used both for converting PDA to CFG and for intersecting CFG with a deterministic FA. To prevent ambiguity, let's use it for converting PDA only. Also, for simplicity, I would suggest removing CFG/DFA intersection, leaving an option of turning CFG to PDA: pyformlang/pyformlang/cfg/cfg.py Line 791 in 176a609
With that we could get rid of importing Regex . I think regex module depending on cfg is the right way to go
|
I think it would be better to define intersection of PDA with DFA explicitly: pyformlang/pyformlang/pda/pda.py Line 445 in 176a609
And then we can use Regex -> ENFA -> DFA transition chain |
On other hand, that would mean converting CFG to PDA and back again, so maybe we can just use less strict annotations for the variable converter |
pyformlang/pyformlang/fst/fst.py Lines 120 to 123 in 176a609
|
If it returns pyformlang/pyformlang/fst/fst.py Line 209 in 176a609
|
We should define this for FST only, and then transition chain Regex -> ENFA -> FST can be used:
|
pyformlang/pyformlang/rsa/recursive_automaton.py Lines 79 to 83 in bffade7
set(self._nonterminal_to_box.values()) if we want to return a set of Boxes
|
Some modules of pyformlang have a strange design that makes this project hard to maintain and develop, and we should think about what we can do to make the architecture cleaner and more concise.
The text was updated successfully, but these errors were encountered: