Re: Elegant design for creating error messages in LPEG parser

[Sean Conner <sean@...>]

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