Re: lpeg.U ?

[albertmcchan <albertmcchan@...>]

On Jan 25, 2018, at 8:03 PM, Sean Conner <sean@conman.org> wrote:

>  If you are looking for a final "and" (which ends the input), then this
> works:
> 
>    last_and = P"and" * P(-1)
>    char     = R("\0\96","b\255")^1
>                 + -last_and * P"a"
>    pat      = C((char)^0) * last_and
> 
>    print(pat:match(string.rep("this and that land",400) .. "and"))

Just for fun I disable lpeg.B so it only produce behind n instruction 
without doing matching:

comment out line 662 in lpcode.c and recompile (YES, just 1 line)
// codegen(compst, sib1(tree), 0, NOINST, fullset)

-- should use P(1)^3, but I want to see what happen with bad input
pat = C(P(1)^0 * B(3)) * P'and'

= lpeg.pcode(pat)
00 opencapture simple (idx = 0)
01 span [(00-ff)]
10 behind 3
11 closecapture
12 char 'a'
13 char 'n'
14 char 'd'
15 end

for _, v in pairs {'', 'a', 'an', 'and', 'aand'} do print( pat:match(v) ) end
nil
nil
nil

a

Again, just for fun, try string.rep("this and that land",400) .. "and")),
and this patched_B version speed is 15X of last_and version above.

Question: is B(-n) has any meaning ?, if no, this could be use for U(n)