В текущей реализации ПЕГ парсера есть бага.
При генерации конечных автоматов / рассматривается как недетерминированный выбор.
В результате получается вот что:

  [PegGrammar(s,
  grammar
  {
    x : int = "x"*;
    s : int = ("x" / "xx") x;
  })]
  public class TestPraser
  {
    x(t : Nemerle.Peg.NToken) : int
    {
      t.EndPos - t.StartPos;
    }
    s(_ : Nemerle.Peg.NToken, n : int) : int
    {
      n
    }
  }

      WriteLine(test.Parse(""));
      WriteLine(test.Parse("x"));
      WriteLine(test.Parse("xx"));
      WriteLine(test.Parse("xxx"));
      WriteLine(test.Parse("xxxx"));

дебаг

None
Some (0)
Some (1)
Some (2)
Some (3)

релиз

None
Some (0)
Some (0)
Some (1)
Some (2)

По большому счету это происходит из-за ошибки в грамматеке ("x" / "xx")
По правилам ПЕГ "xx" накогда не сматчится.
Но генератор FSM не различает приоритеты правил.

Для того чтобы это починить придется что-то изобретать.
Вопрос в том нужно ли?

Здравствуйте, WolfHound, Вы писали:

WH>По большому счету это происходит из-за ошибки в грамматеке ("x" / "xx")
WH>По правилам ПЕГ "xx" накогда не сматчится.
WH>Но генератор FSM не различает приоритеты правил.

WH>Для того чтобы это починить придется что-то изобретать.
WH>Вопрос в том нужно ли?

В таких ситуациях самым правильным было бы выдавать сообщения об ошибке.
Ты можешь выявлять случаи когда в списке литералов более длинные идут после более коротких?

Здравствуйте, VladD2, Вы писали:

VD>В таких ситуациях самым правильным было бы выдавать сообщения об ошибке.

Это позволило бы делать оптимизации не учитывая особенностей расположения литералов.