[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: LPEG 0.12 bug?
- From: Sean Conner <sean@...>
- Date: Sat, 5 Jul 2014 01:21:21 -0400
It was thus said that the Great Solra Bizna once stated:
> I'm not sure this is the right place to send this, or even that it's a
> bug in LPEG and not in my understanding of LPEG. I've got a simplified
> test case that reproduces an (apparent) bug I encountered while using
> LPEG to write a Base64-like decoder.
>
> As in this test case, I was able to get my by decoder working by
> adding a dummy capture, but it doesn't seem like it should be
> necessary. I could be wrong... if I am, where's the flaw in my
> understanding?
It's your understanding. Try adding the following to the script you sent
to the list:
local Cg = lpeg.Cg
local fixed_pattern = P{
"fixed_pattern",
fixed_pattern = Cg(V"capture_A_or_B" * V"capture_A_or_B")
/ do_something,
capture_A_or_B = C(R"AB"),
}
fixed_pattern:match("AA")
lpeg.Cg() does a group capture, which is what you are trying to do here,
trying to group multiple captures of "capture_A_or_B" and passing them all
into a single function.
You could also write this as:
capture_A_or_B = C(R"AB")
fixed_pattern = Cg(capture_A_or_B * capture_A_orB)
/ do_something
Unless you are writing recursive patterns [1] you don't really need the
extra baggage of using grammars (in my opinion).
-spc
[1] Like (not LPeg grammar; more like a pseudoBNF format):
expr = term '+' term
term = factor '*' factor
factor = NUMBER | '(' expr ')'
Note that factor referrs to expr, making this a recursive
pattern.