Alt backtracking (question)

Hi! I have a question about alt which behavior surprises me.

Case 1 – “expected”

let p = P.alt(
  P.seq(P.string("a"), P.string("b")).tie(),
  P.string("ac"),
)

console.log(p.tryParse("ac")) // "ac"

My understanding of what’s going on (may help to answer the next case):

1. Parser string("a") succeeds
2. Parser string("b") fails
3. Failure bubbles to P.seq and then to P.alt
4. Alt backtracks (releasing parsed "a" char)
5. Parser string("ac") is tried and this one does match
6. !!!

Case 2 – “unexpected”

let p = P.alt(
  P.string("a").sepBy1(P.string("+")), // try to comment this line
  P.any.many(),                        // this one is never tried!
)

console.log(p.tryParse(`a+a-a`)) // exception

My understanding of what’s going on:

1. Parser P.string("a").sepBy1(P.string("+")) fails
2. For some reasone failure doesn’t bubble to P.alt this time!!!
3. Alt does not backtrack or doesn’t have a chance to backtrack!!!
4. Parsing fails despite P.any.many() parser could surely parse this string…
5. ???

Is this an expected behavior? Why sepBy1 causes this effect?

[ivan-kleshnin]

Yep, totally makes sense. My real case was much more complicated so I kinda stuck with it mentally. But it reduced to the same thing: sepBy1 which succeeds once it found at least one element.

Note for the future readers: a syntax error in the 1-st item of some list and in the 2-nd+ may lead to different parsing results. This is expected, one way to prevent that is to add more conditions after sepBy1 like sepBy1(...).lookahead(REAL_END_OF_THE_LIST) but it’s not always possible or desirable.

@wavebeem thanks for the help!

[wavebeem]

wow, ok that took some digging, but I actually don’t think this is a bug

it is weird though! i was just as confused as you for hours haha

so, the general problem here is that:

  P.seq(P.string("a"), P.string("b")).tie(),

is actually succeeding, which takes you out of the P.alt call immediately. but then .tryParse(...) is failing because there’s still leftover input.

_.parse = function(input) {
  if (typeof input !== "string" && !isBuffer(input)) {
    throw new Error(
      ".parse must be called with a string or Buffer as its argument"
    );
  }
  //
  //
  //               vvvvvvvvvv
  var result = this.skip(eof)._(input, 0);
  //               ^^^^^^^^^^
  //
  //
  if (result.status) {
    return {
      status: true,
      value: result.value
    };
  }
  return {
    status: false,
    index: makeLineColumnIndex(input, result.furthest),
    expected: result.expected
  };
};

please reference this RunKit example to see what I mean from your code sample: https://runkit.com/wavebeem/parsimmon-issue-255

does that explanation make sense? it’s a little confusing what’s going on here, but i’m not really sure there’s anything i could change to make parsimmon work better for this case