Дифференцирование деления от регулярных выражений при лексировании кода gawk
Я пишу гибкий синтаксический анализатор для сценариев gawk. Я сталкиваюсь с проблемой, различающей использование для символа косой черты (/).
Очевидно, один / будет оператором для деления, но две косые черты могут быть как регулярным выражением, так и делением. Щас разбирает
int((r-1)/3)*3+int((c-1)/3)+1
как с регулярным выражением
/3)*3+int((c-1)/
вместо предполагаемых операций деления. Как мне согнуться, чтобы распознать его как математическое выражение?
Прямо сейчас, это мое гибкое регулярное выражение для распознавания регулярных выражений в gawk:
EXT_REG_EXP "\/"("\\\/"|[^\/\n])*"\/"и оператор деления должен быть пойман моим списком операторов:
OPERATOR "+"|"-"|"*"|"/"|"%"|"^"|"!"|">"|"<"|"|"|"?"|":"|"~"|"$"|"="Но так как регулярные выражения flex являются жадными, я думаю, они рассматривают два деления как регулярное выражение.
Решение
Я не думаю, что можно определить простое выражение токена для однозначной идентификации регулярных выражений. Спецификация Posix для Awk отмечает двусмысленность таким образом:
В некоторых контекстах косая черта (‘/’) используется для обозначения ERE
также может быть оператором деления. Это должно быть решено в такой
Таким образом, где бы ни появился оператор деления, косая черта
Предполагается, что оператор деления. (Унарного деления нет
оператор).
И позже:
Существует лексическая двусмысленность между токеном ERE и токенами ‘/’
и DIV_ASSIGN. Когда последовательность ввода начинается с символа косой черты
в любом синтаксическом контексте, где токен ‘/’ или DIV_ASSIGN может
появляются в качестве следующего токена в допустимой программе, более длинный из этих двух
токены, которые могут быть распознаны, должны быть распознаны. В любом другом
синтаксический контекст, в котором токен ERE может появиться как следующий токен
в действующей программе токен ERE должен быть распознан.
(«ERE» означает «расширенное регулярное выражение».) Из этого, я думаю, вы можете с уверенностью заключить, что токенизатор для Awk должен знать о синтаксическом контексте, и, следовательно, нет никакого возможного регулярного выражения, которое могло бы успешно идентифицировать регулярное выражение. жетоны.
Также стоит посмотреть, как определен сам Awk (или хотя бы одна из реализаций) для разбора регулярных выражений. В оригинальном Awk (иногда называемом One True Awk) определение регулярных выражений является задачей парсер, который явно устанавливает лексер в «режим регулярных выражений», когда выяснил, что следует ожидать чтения регулярных выражений:
reg_expr:
'/' {startreg();} REGEXPR '/' { $$ = $3; }
;
(startreg() это функция, определенная в lex.c.) reg_expr Само правило сопоставляется только в тех случаях, когда оператор деления будет недопустимым.
Извините, что разочаровал, но я надеюсь, что это помогает тем не менее.
Другие решения
Других решений пока нет …
detector