Re: LPeg: inconsistencies regarding empty captures

[Roberto Ierusalimschy <roberto@...>]

> /number skips captures with no values, whereas /string counts them. Example:
> 
>     > (Cg(Cc"foo", "z") * Cb"z" / 1):match"" --> "foo"
> 
>     > (Cg(Cc"foo", "z") * Cb"z" / "%1"):match""
>     stdin:2: no values in capture index 1
> 
>     > (Cg(Cc"foo", "z") * Cb"z" / "%2"):match"" --> "foo"

This is really weird, although compatible with the documentation :). One
counts values, the other counts captures. The difference is not only for
captures with no values:

  ((m.Cg(m.Cc'a' * m.Cc'b') * m.Cg(m.Cc'c' * m.Cc'd')) / 2):match('')
    --> b

  ((m.Cg(m.Cc'a' * m.Cc'b') * m.Cg(m.Cc'c' * m.Cc'd')) / "%2"):match('')
    --> c


> In a similar vein, while Cf complains if the first capture is empty, a
> Cg whose only captures are empty will behave as if there were no
> captures in it, and produce his whole match...
> 
>     > Cg(Cc""/{}*1):match"R" --> "R"
> 
> but
> 
>     > Cf(Cc""/{}*C(1),print):match"R"
>     stdin:1: no initial value for fold capture

This seems to be a different case. Cg works like other captures that
take a variable number of captures (e.g., function captures and
table captures): when there is no values, they use the entire capture as
a single value. Cf also works with a variable number of captures, but,
unlike the other captures, it handles its first value in a very special
way. So, it makes sense for it to complain when that value is missing.
Moreover, for Cg (and Ct and /function), the behavior of using the
entire match is quite convenient. For Cf, it seems useless.

-- Roberto