Re: LPEG output

[Kees Jan Hermans <foxkjhermans@...>]

You are completely right; the happy flow always has the commit see the
backtrack as the top element on the stack; it's the failures that
might see other elements in between. Other question: I see in the code
(llvm.c):

      case IChar: {
        if ((byte)*s == p->i.aux && s < e) { p++; s++; }
        else goto fail;
        continue;
      }
      case ITestChar: {
        if ((byte)*s == p->i.aux && s < e) p += 2;
        else p += getoffset(p);
        continue;
      }

And in the white paper:

TestChar char label
Checks whether the character in the current subject position is equal
to char. If it is equal, the machine consumes the current character
and goes to the next instruction. Otherwise it jumps to label.

I've just looked at it, but is the 'testchar' behaviour still the same
as in the paper? The code seems to suggest that 'testchar' jumps two
instructions on a match?

On Tue, 25 Jun 2019 at 22:27, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>
> > "There cannot be a 'call' instruction in between. A commit is always in
> > the same rule that generated the corresponding choice; so, any call
> > between a choice and its corresponding commit must have returned."
> >
> > Ok. But what if the failure happens during the call? Then the cleaning
> > up of the stack encounters the 'call' stack element first.
> > So, instructions encountered are: 1) choice, 2) call, 3) commit, and
> > the failure (no match) happens between 2 and 3.
>
> Then the commit is not executed. You asked about commit, not about fail.
> A commit always find the choice at the top of the stack.
>
> A fail (unlike a commit) must remove any call in the stack before
> getting to a choice, which may not exist. This is all explained in the
> paper.
>
> -- Roberto
>