Re: LPEG output

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

Ok. Never mind that. I see now that any test* instruction (as well as
choice and call, etc) keep a single instruction space ahead of them.
So p += 2 actually means 'jump to the next instruction'. But am I
correct in assuming that, contrary to the white paper, the test*
functions never consume input?

On Thu, 27 Jun 2019 at 15:03, Kees Jan Hermans <foxkjhermans@gmail.com> wrote:
>
> 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
> >