Implement NFA features (e.g. input reading) for GNFA
See original GitHub issue@abhinavsinha-adrino I’m starting to wonder if I misunderstood the purpose of GNFAs when I suggested that we subclass GNFA from NFA. Let me explain the context:
I was trying to write a test for GNFA just now to verify that GNFA.read_input_stepwise()
operates as expected. However, I was encountering one error after another in trying to accomplish this. I then realized that, because GNFAs can have non-state values (i.e. regex strings and None
) in the transition map, maybe it doesn’t make sense to use methods like read_input_stepwise
on a GNFA.
This then made me wonder if it was a mistake to subclass GNFA
from NFA
, since it seems like there could be a whole bunch of methods (like read_input_stepwise
) that either would fail or just wouldn’t make sense to have available on GNFA
.
What do you think? Given what you know about Automata theory and the purpose of GNFAs, would it make sense to have functional methods like GNFA.read_input_stepwise
? Would it make more sense semantically to subclass GNFA
from FA
instead of NFA
?
Issue Analytics
- State:
- Created a year ago
- Comments:12 (12 by maintainers)
@caleb531 It’s absolutely the fact that GNFAs are only used for conversion to regex so yes I’m of the same opinion that we do not implement input reading methods.
And again, there is no other feasible way to implement such method without using NFA. Let me explain, we cannot jump from one state to another in a GNFA from one input, because the transition takes a regex and each regex corresponds a whole set of states (basically NFA). Either as a whole or piece wise, we cannot implement input reading methods without NFAs.
I very much support your proposal, this keeps things simple but yet complete.
@abhinavsinha-adrino That’s fine! School should be a priority.
I’ll see if I can take a stab at it, and perhaps submit you a PR for you to review.