Ваше регулярное выражение для T_STRING определенно не делает то, что вы хотите. Что он делает, ответить немного сложнее.
В принципе, он состоит только из двух утверждений нулевой длины: ^, что верно только в начале строки (если вы не предоставите re.MULTILINE флаг, который вы не указали), и длинное отрицательное утверждение с прогнозом.
Шаблон, который состоит только из утверждений нулевой длины, может соответствовать только пустой строке, если она вообще соответствует чему-либо. Но шаблоны лексера не могут совпадать с пустой строкой. Лексеры делят ввод на серию токенов, так что каждый символ на входе принадлежит некоторому токену. Каждое совпадение - а это все совпадения, а не поиски - начинается именно в конце предыдущего совпадения. Таким образом, если шаблон может соответствовать пустой строке, лексер попытается найти следующее совпадение в том же месте с тем же результатом, который будет бесконечным l oop.
Некоторые генераторы лексеров решают эту проблему путем форсирование минимального совпадения одного символа с использованием встроенного универсального шаблона ошибок, но Ply просто отказывается генерировать лексер, если шаблон соответствует пустой строке. И все же Ply не жалуется на эту спецификацию лексера. Единственное возможное объяснение состоит в том, что шаблон не может соответствовать чему-либо.
Ключ заключается в том, что Ply компилирует все шаблоны, используя флаг re.VERBOSE, который позволяет разделять элементы в регулярных выражениях с пробелами, делая регулярные выражения немного меньше нечитаемым. Как указывается в документации Python:
Пробелы в шаблоне игнорируются, за исключением случаев, когда они находятся в классе символов, или когда им предшествует неэкранированная обратная коса sh или внутри токенов, таких как *?, (?: или (?P<...>.
Пробел включает в себя новые строки и даже комментарии (начиная с символа #), поэтому вы можете разбивать шаблоны на несколько строк и вставлять комментарии о каждой части.
Фактически, мы могли бы сделать это с вашим шаблоном:
def t_STRING(t):
r'''^ # Anchor this match at the beginning of the input
(?! # Don't match if the next characters match:
\) | # Close parenthesis
\( | # Open parenthesis
\ | # !!! HERE IS THE PROBLEM
\t | # Tab character
\n | # Newline character
\\\/ | # \/ token
\/\\ # /\ token
)
'''
t.value = t
return t
Поэтому, когда я добавил пробел и комментарии к вашему шаблону, я должен был заметить, что исходный шаблон пытался соответствовать пробелу в качестве альтернативы с | |. Но поскольку шаблон скомпилирован как re.VERBOSE, этот символ пробела игнорируется, оставляя пустую альтернативу, которая соответствует пустой строке. Эта альтернатива является частью отрицательного косвенного утверждения, что означает, что утверждение не будет выполнено, если строка для сопоставления в этой точке начинается с пустой строки. Конечно, каждая строка начинается с пустой строки, поэтому отрицательное прогнозное утверждение всегда терпит неудачу, объясняя, почему Ply не жаловался (и почему шаблон никогда ничего не соответствует).
Независимо от этот конкретный сбой, шаблон не может быть полезен, потому что, как уже упоминалось, шаблон лексера должен соответствовать некоторым символам, и поэтому шаблон, который соответствует только пустой строке, не может быть полезным. То, что мы хотим сделать, - это сопоставить любой символ, при условии, что отрицательный прогноз (исправленный, как показано ниже) позволяет это. Таким образом, это означает, что за показом с отрицательным прогнозным подтверждением следует ., который будет соответствовать следующему символу.
Но вы почти наверняка не хотите совпадать только с одним символом. Предположительно, вы хотели сопоставить строку символов, которая не соответствует ни одному другому токену. Таким образом, это означает, что отрицательное прогнозное утверждение и следующие . повторяются. И помните, что это должен быть непустой повтор (+, а не *), потому что шаблоны не должны иметь пустых совпадений.
Наконец, нет абсолютно никакого смысла использовать утверждение привязки, потому что это ограничит сопоставление шаблона только в начале ввода, и это, конечно, не то, что вы хотите. Не совсем понятно, что он там делает. (Я видел рекомендации, которые предлагают использовать якорь с отрицательным прогнозом search , который, как мне кажется, в целом неверен, но это обсуждение выходит за рамки этого вопроса.)
И прежде чем писать шаблон, давайте сделаем еще одну корректировку: в регулярном выражении Python, если вы можете заменить набор альтернатив классом символов, вы должны сделать это, потому что он намного эффективнее. Это верно, даже если только некоторые из альтернатив могут быть заменены.
Так что получается следующее:
def t_STRING(t):
r'''(
(?! # Don't match if the next characters match:
[() \t\n] | # Parentheses or whitespace
\\\/ | # \/ token
\/\\ # /\ token
) . # If none of the above match, accept a character
)+ # and repeat as many times as possible (at least once)
'''
return t
Я удалил t.value = t. t - это объект токена, а не строка, и значение должно быть строкой, с которой оно сопоставлено. Если вы перезаписываете значение круглой ссылкой, вы не сможете определить, какая строка соответствует.
Это работает, но не совсем так, как вы предполагали. Поскольку пробельные символы исключаются из T_STRING, вы не получите ни одного токена, представляющего (/ 1 3) <= x_4. Вместо этого вы получаете серию токенов:
STRING b_1 1 0
AND /\ 1 4
LPAREN ( 1 7
STRING x_2 1 8
STRING <= 1 12
STRING 2 1 15
OR \/ 1 17
LPAREN ( 1 20
STRING b_3 1 21
AND /\ 1 25
LPAREN ( 1 28
LPAREN ( 1 29
STRING / 1 30
STRING 1 1 32
STRING 3 1 34
RPAREN ) 1 35
STRING <= 1 37
STRING x_4 1 40
RPAREN ) 1 43
RPAREN ) 1 44
Но я думаю, что это разумно. Как лексер мог бы сказать, что круглые скобки в (x_2 <= 2 и (b_3 являются токенами скобок, в то время как круглые скобки в (/ 1 3) <= x_4 являются частью T_STRING? Это определение нужно будет выполнить в вашем парсере.
На самом деле, я склонен полностью токенизировать входные данные, даже если вам (пока) не требуется полный токенизация. Как показывает весь этот вопрос и ответ, попытка распознать «все, кроме ...» может быть намного сложнее, чем просто распознать все токены. Попытка заставить токенизатор выяснить, какие токены полезны, а какие нет, часто сложнее , чем токенизация всего и передача его через анализатор.