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
