Currently, the parsing process relies heavily on the exception mechanism by throwing an exception every time a rule fails to match. But the exception realization is very slow, so the parsing process that has a lot of failing rules would be slow too. "Zero-cost exceptions" are only fair in such cases where no exceptions are raised (every rule always matches successfully).
The ParsingExpression class and its descendants should be rewritten to return the error explicitly. I suggest returning an error as the second return value of the parse() and _parse() methods. Since Python exceptions are announced as "zero-cost", there is a chance of backward compatibility with the previous versions of Arpeggio.
Currently, the parsing process relies heavily on the exception mechanism by throwing an exception every time a rule fails to match. But the exception realization is very slow, so the parsing process that has a lot of failing rules would be slow too. "Zero-cost exceptions" are only fair in such cases where no exceptions are raised (every rule always matches successfully).
The ParsingExpression class and its descendants should be rewritten to return the error explicitly. I suggest returning an error as the second return value of the
parse()and_parse()methods. Since Python exceptions are announced as "zero-cost", there is a chance of backward compatibility with the previous versions of Arpeggio.