invoke_list

[ForNeVeR]

Нашёл в Grammar.txt потенциально опасную конструкцию:

invoke_list         = { value_expr } | ( { NL "<|" value_expr } NL )

Она опасна тем, что под форму { value_expr } подходит пустая строка - следовательно, эта форма будет матчиться вечно (на самом деле, fparsec просто бросит исключение, обнаружив такой парсер). Необходимо чем-то укрепить эту ветвь, чтобы она не могла сматчиться на пустом месте.

[ForNeVeR]

Аналогичная проблема есть в определении type:

type                = [ namespace "." ] identifier [ ( { "[]" } | type_params ) ]

(на месте { "[]" } парсер просто завязнет, если до него доберётся).

[impworks]

Не понимаю сути проблемы. Один литерал в фигурных скобках - самый лучший пример конструкции "0 или больше". В регулярках конструкция x* не вызывает никаких проблем, почему тут они возникают? И вообще, как тогда использовать { ... } ?

[ForNeVeR]

А вообще, я рано поднял тревогу, наверное. Нужно потестировать те определения, которые есть - авось прокатит.

(Ранее у меня упал fparsec на конструкции many <| pchar ' ', что и вызвало у меня острое желание обезопасить тылы.)

[ForNeVeR]

type                = [ namespace "." ] identifier [ ( { "[]" } | type_params ) ]

С этим уже вышла проблема вот на этом месте:

Tuple<Suit, int>

Парсер работал так:

1. Нашёл "Tuple" : identifier.
2. Попробовал заматчить кусочек из квадратных скобок:
3. - увидел { "[]" }, успешно заматчил с пустой строкой;
4. - пошёл дальше, упал и умер.

Я решил эту проблему, переставив узлы в грамматике примерно вот так:

type                = [ namespace "." ] identifier [ ( type_params | { "[]" } ) ]

[impworks]

Первая мысль была как раз переставить их местами. Неужели сработало?

[ForNeVeR]

В связи с этим, кстати, нужно поменять эти токены местами в грамматике тоже. @impworks, займись, пожалуйста.

[ForNeVeR]

Поменяли грамматику, проблема условно решена.