основе lookahead (в основном). Т.е. текущий шаблон(шаблон1) жрет строку, пока текущий символ не удовлетворит следующий шаблон(шаблон2).
Получается, что когда шаблон1 будет сопоставлен, мы можем быть уверены, что шаблон2 тоже сапоставлен и повторно его проверять не нужно, достаточно "сдвинуть строку".
Правильно ли понимаю это и используется ли подобный подход?
С бэктрэкингом или без?
Кажется, в PEG такое есть
Это какой из комбинаторов-то?
И не строку, а инпут, в приличных домах токенайзеры ставят перед парсером
Что ты имеешь в виду? Такие штуки я так понимаю это частная реализация. Но хочу понять делают ли вообще так и какие подводные камни
Делают как угодно
Тогда давай подробнее - что ты имеешь ввиду под "ленивым режимом сопоставления"?
Вот такую ситуацию
Это ж просто deterministic FSM, ему lookahead не нужен. 🤷♀️
Нуу lookahead тоже является FSM в целом? Чекаешь текущий символ и следующий
Следущий чекают когда текущий неоднозначен
Тут не нужно смотреть следующий — только текущий.
В данном случае это не важно. Как мы без lookahead узнаем, что это последний ';'
Да, всё классно. 👍
А нам без разницы, последний он или нет. Имеет смысл подробнее изучить, какие FSM строятся по регулярным выражениям и как они работают.
Когда в регулярных выражениях появляются группы, и надо сохранять позиции их начала и конца, построение FSM сильно усложняется
а подобный тоже без lookahead?
Если мы чтобы распарсить выражение return 125;;; по анагалогии с регексом return (.*); убедились, что ; после группы есть можем не парсить эту ; повторно
Рекомендую от регулярок отказаться, взять парсер языка, над которым проводятся операции и работать с его AST
регулярки не юзаю, онли парсер комбинаторы
Ещё раз - за что ты себя так не любишь, что гоняешь регулярки по исходному коду, который по определению является CFG а не регулярной грамматикой?
.*? напиши, ну ты чо.
Обсуждают сегодня