The reason I bring up the question of good design is because you (Sean) have mentioned that there are
infinite ways to design parser.
I though about the state variable approach but it feels working against the design principals of LPEG.
Since when you try to create a parser by hand you end up in state machine hell.
Later I understood that LPEG was created to not have to deal with creating a state machine by hand.
unless the author's of LPEG want error to be handled like that !
For example an alternative approach:
```
inner = (.....) -- inner recursive
matched = (.....) -- function for matching
unmatched = (.....) -- function for dealing with error
patt = ((P '[')*inner*(P ']'))/matched + ((P '[')*inner)/unmatched
```
> the trick to this is to include code that explicitly checks for the error conditions and record them.
Both your approach and mine requires thinking ahead of time all the ways the user can create an error.
What about situations of unknown unknown ? where we haven't explicitly modeled for an error ?
What about the minimum viable error method ? that just prints line number ?
would that just be to record line number as you go along using Carg(1) and just print out the line where your parser fails ?
I feel like the minimum viable error would handle unknown unknowns without being completely useless like nil, while keeping
parser code simple. ( I do not want to end up in a situation where the code is 50% error handling ).
Sorry about my noob questions.
best wishes,
Joy
