Re: [LPeg] How can I signal parsing errors with LPeg?

[Sean Conner <sean@...>]

It was thus said that the Great Soni L. once stated:
> On 30/07/16 03:25 AM, Sean Conner wrote:
> >It was thus said that the Great Soni L. once stated:
> >>Right. Does the "utf-8" on the MDXML spec[1] not mean anything to you?
> >   Right.  Does example code that shows you how one would go about doing it
> >not mean anythign to you?  Does "then you can do something like this" mean
> >any thing to you? Do you always expect everything to be handed to you on a
> >silver plate, complete and working 100% as you would expect them to?  I
> >almost quit a job because of this attitude [2].
> >
> >   But FINE!  Here you go!
> >
> >	-- -----------------------------------------------------------------
> >	-- And just because YOU asked for it, this is GPL!  If you use this,
> >	-- you MUST make your code GPL as well.  Oh, is the GPL too
> >	-- restrictive for you?  So sorry, you asked ME for this code, so I
> >	-- get to slap whatever license I want on it.
> >	--
> >	-- DEAL WITH IT!
> >	--
> >	-- And no, I WILL NOT MAKE AN EXCEPTION FOR YOU!
> >	-- -----------------------------------------------------------------
> >
> >	local char = lpeg.R(" [","]~")
> >                    + lpeg.R("\194\223") * lpeg.R("\128\191")
> >                    + lpeg.P("\224")     * lpeg.R("\160\191") * 
> >                    lpeg.R("\128\191")
> >                    + lpeg.R("\225\236") * lpeg.R("\128\191") * 
> >                    lpeg.R("\128\191")
> >                    + lpeg.P("\237")     * lpeg.R("\128\159") * 
> >                    lpeg.R("\128\191")
> >                    + lpeg.R("\238\239") * lpeg.R("\128\191") * 
> >                    lpeg.R("\128\191")
> >                    + lpeg.P("\240")     * lpeg.R("\144\191") * 
> >                    lpeg.R("\128\191") * lpeg.R("\128\191")
> >                    + lpeg.R("\241\243") * lpeg.R("\128\191") * 
> >                    lpeg.R("\128\191") * lpeg.R("\128\191")
> >                    + lpeg.P("\224")     * lpeg.R("\128\142") * 
> >                    lpeg.R("\128\191") * lpeg.R("\128\191")
> That's even more overcomplicated than the previous example.

  Soni,

  I can't read your mind.  You asked about UTF-8.  Okay, I presented you
with UTF-8.  It errors out on invalid UTF-8.  If you didn't care about that,
why even bring it up?  Or better yet, recognize it as sample code and modify
accordingly.

> My point wasn't to overcomplicate it, it was to simplify it. E.g.
> 
> local char = 1 - lpeg.S("\\") (because this handles literally every 
> possible use-case, including nonprintables)

  No, the above does not explicitely handle UTF-8.  It handles everything. 
Besides that, it's not the simplest.  That would be:

	lpeg.P(1) - lpeg.P("\\")

But if you want performance, then:

	lpeg.R("\0[","]\255")

is better as it's one operation.

Neither one will validate UTF-8 though.  I'm not here to write your code for
you.  You were clearly capable of changing the code to suite your needs.

> >>> I'm using lpeg.Carg() to pass in a table to accumulate the errors
> >>> (this keeps this reentrant).  lpeg.Cmt() does a match-time capture and
> >>> if this returns nil, then that particular capture fails.  I've set up
> >>> this example such that if cleanup returns nil, then the passed in
> >>> table will contain the error.
> >>
> >>I see. I'd still prefer :match itself to emit nil, errmsg with a
> >>dynamically generated errmsg.

  And here is the *FIRST* time you mention dynamically generated error
messages.  

> >   Yeah, and I'd prefer you would do your own damn homework too!
> >
> >   -spc (I'm beginning to come around to Dirk's point of view---is it too
> >	hard to say "Thank you" and work to adapt the code to your project?)
> >
> >[1]	Not my footnote
> >
> >[2]	The "YOU #$@#$@# FAILED TO READ MY MIND AND IMPLEMENT THE CODE AS I
> >	WOULD HAVE, YOU @#@$#@$#@ WORK SLAVE!" attitude.
> >
> >	Sorry, ... no, I'm not sorry.  I gave you an example, and you @#$@#$
> >	threw it back in my face for not doing everything you deemed
> >	necessary.
> >
> >

> My post clearly indicated I wanted to replace a specific error() call 
> with something that made :match() return nil, errmsg.
                                           ^^^^^^^^^^^
  Where does that state "dynamic error messages"?  Furthremore, the sample
code I gave did just that, have the :match() call return "nil, errmsg".  You
keep moving the goal posts.  I can't read your mind.  No one can.

> Your first solution returns a fixed error message, which is not what was 
> asked.

  You asked, and I quote:

> I'm writing an LPeg-based parser. How can I make it so a parsing error
> returns `Nil, errmsg`?

  Nothing at all about "dynamic" error messages.  It's only later, when I
gave you an answer, did you move the goal posts and add the dynamic
behavior.  But why should I have to do that?  You have a solution, not one
you like, but *a* solution.  I would think it would be your job to expand on
that.

> Your second solution uses Carg(1). Last time I used Carg(1) I had issues 
> getting it to do what I wanted, but as soon as I got rid of it 
> everything worked like a charm.

  Here is what lpeg.Carg() does, straight from the manual:

	Creates an argument capture. This pattern matches the empty string
	and produces the value given as the nth extra argument given in the
	call to lpeg.match.

  I used it initially to provide a table to return the results in.  The
second time was to accumulate the error at the point where it happened.
That's it.  If it didn't work for you, it didn't work for you.

> I don't know how to use LPeg. That's the reason why I'm asking here. I 
> tried to write the whole parser in LPeg but I couldn't get that to work 
> (I also couldn't understand any of it) so I went with a simpler approach 
> by using LPeg as a tokenizer of sorts.
> 
> I "threw it back in [your] face" because I don't understand it.

  I think this is coming down to a difference in learning styles.  Growing
up, I was interested in computers (got my first one at age 15).  But the
thing was, I had no one to ask questions.  I didn't have access to the
Internet (it was 1984, general access to the Internet was still a decade
away), no adult I knew except one used a computer (and that one used it for
business; he himself wasn't a programmer).  I only had one friend that had a
computer, but it was different from mine (his was an IBM PC; mine was a
Tandy Color Computer).  So yeah, not much in the way of help.  The only
thing I did have was manuals and magazines.  So I got good at reading
between the lines and writing a ton of code.  If something was confusing,
well, that just meant I had to keep plugging away at it.  That's why, to me,
your behavior is puzzling---you just aren't willing to work for the
solution, you just want *the solution* (and then complain when no one reads
your mind correctly).

  What follows are links to the only two LPeg related questions I asked in
the mail list.  It might be instructive to read the threads.

	http://lua-users.org/lists/lua-l/2013-10/msg00617.html
	http://lua-users.org/lists/lua-l/2015-08/msg00024.html

  -spc