Это и исправление ошибок Kaz, и вотум доверия для ОП.
В своем первоначальном ответе Каз утверждает порядок приоритета Unix lex
точно в обратном порядке.Из документации lex
:
Lex может справиться с неоднозначными спецификациями.Когда более чем одно выражение может соответствовать текущему вводу, Лекс выбирает следующее:
Предпочтительнее самое длинное совпадение.
Среди правил, которые соответствуюттакое же количество символов, правило, данное первым, является предпочтительным.
Кроме того, Kaz не прав, чтобы критиковать решение OP, заключающееся в использовании сопоставления границ слов в Perl-regex.Когда это происходит, вам разрешается (без мучительной вины) сопоставлять слова любым способом, который будет поддерживать ваш генератор лексеров.CL-LEX использует регулярные выражения Perl, которые используют \b
в качестве удобного синтаксиса для более громоздкого lex
приблизительного значения:
%{
#include <stdio.h>
%}
WC [A-Za-z']
NW [^A-Za-z']
%start INW NIW
{WC} { BEGIN INW; REJECT; }
{NW} { BEGIN NIW; REJECT; }
<INW>a { printf("'a' in wordn"); }
<NIW>a { printf("'a' not in wordn"); }
При всех равных условиях, поиск способа однозначно сопоставить его слова, вероятно,лучше, чем альтернатива.
Несмотря на то, что Каз хотел ударить его, ОП правильно ответил на свой вопрос, придумав решение, которое использует гибкость выбранного им генератора лексера.