[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Elegant design for creating error messages in LPEG parser
- From: joy mondal <joykrishnamondal@...>
- Date: Thu, 4 Apr 2019 01:46:14 +0400
Just a side question.
Under what design consideration do we use 'Cmt(patt,f) ' vs 'patt/f' ?
I noticed you used Cmt , why not 'patt/f' ?
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.
> 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
> 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)
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.