 |
lua-l archive |
|
|
||
|
It was thus said that the Great joy mondal once stated:
> The reason I bring up the question of good design is because you (Sean)
> have mentioned that there are
>
> infinite ways to design parser.
Pretty much.
> I though about the state variable approach but it feels working against the
> design principals of LPEG.
It's supported, so I don't think it's necessarily against the principles
of LPEG. It may look weird because it's not used often, but I'm glad it
does exist.
> 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 ?
Unfortunately, LPEG can be used to parse binary data so a "line number"
might not make any sense.
I'm thinking that the minimum to return on a failed match is both nil
*and* the position of the failure. So something like:
pattern = lpeg.P"a"^1 * lpeg.P"b"^1 * lpeg.P(-1)
print(pattern:match "aabb")
print(pattern:match "aacbb")
would output:
4
nil 3
Any failed pattern would return nil,position, but as long as there are
alternatives, it won't matter. But on a failure, at least you get the
offset into the string being parsed where the error was.
That's about the minimum I could see for LPEG. How about it Roberto?
> 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 ).
For the majority of my LPEG programs, I've been able to get away with
parsed vs. failed, as there wasn't much I could do about a failed parse
(especially when parsing SIP messages---log the failure, drop it and move on
to the next message). But having a position of failure would be nice.
> Sorry about my noob questions.
Not a noob question at all. It's been something I've thought about for
some time, which is why I was able to answer your question with code.
-spc