Вы когда-нибудь эффективно использовали lexer/parser в реальном мире?

Ответ 1

Да, я использовал их. Да, вы можете делать что-то без них - но в любое время, когда вы выбираете неправильный инструмент для работы, вы сами будете делать ненужную боль.

Некоторые примеры нестандартных применений, которые я лично использовал для этой технологии:

• очистка данных из отчетов, созданных устаревшими системами.
• выбор шаблонов в данных, слишком сложных для регулярного выражения
• анализ протокола
• текстовые приключенческие игры
• API метапрограммирования, который ел Толедо (не настоящее имя)
• анализ кода/анализ журнала
• выделение полей "свободной формы" в базе данных
• и scads больше Я забываю (я стар)

Ответ 2

Подсветка синтаксиса. Текстовый редактор Scite позволяет вам написать собственный лексер (на С++), чтобы обеспечить подсветку синтаксиса для любого пользовательского языка. Я написал свой собственный lexer для Scite в качестве переподготовки по этой теме (я изучал его некоторое время назад в своем университете).

Регулярные выражения часто используются в качестве альтернативы для сопоставления шаблонов и простой обработки языка. Это еще более распространено в последние годы благодаря улучшенной поддержке RegEx в таких рамках, как .NET. Во многих случаях разработчики могут даже не знать о методах лексинга/синтаксического анализа и, таким образом, попадать в обычное Regex по умолчанию.

Однако, как еще один ответ говорит, Regex может быстро стать неэффективным, медленным и трудным для поддержания чего-либо большего, чем просто грамматика/язык. В этой ситуации парсер/лексеры, как правило, лучший выбор.

Ответ 3

Да, я использовал их в реальных приложениях - но в основном создание пользовательских языков, на которых вы используете лексеры и парсеры, было вытеснено языками, определенными в XML. Более подробный, но тогда вам не нужно делать все, что работает...

Ответ 4

Да, я использовал их. Я большой поклонник ANTLR. Я даю несколько советов и рекомендаций по использованию ANTLR здесь и краткое одобрение этого . Можно вручную написать собственный синтаксический анализатор с использованием специальных методов, но это намного сложнее и займет намного больше времени, чтобы выяснить, как вносить изменения, когда вам нужно вырастить язык, который должен анализировать ваш парсер.

Ответ 5

Любое место, где вы обрабатываете ввод текста, заканчивается использованием какого-то lexer/parser, хотя некоторые из них в конечном итоге являются вырожденным случаем (lex ничего, кроме запятой, как один тип токена, а запятая как другая). Parse Число, имя, число и конец строки. Такого рода вещи) Одним из способов взглянуть на него sscanf можно было бы считать наиболее вырожденными случаями генератора лексера/парсера.

Что касается полномасштабной операции lex/yacc? Я ожидаю, что он будет использоваться в основном для GPL и для вещей, которые подпадают под свободное определение DSL

Ответ 6

В любой момент, когда существует статический документ (например, файл) или динамический документ (например, поток, происходящий со временем), и этот документ имеет какую-либо структуру, вы обнаружите, что вам нужен какой-то синтаксический анализатор. Для достаточно простых структур вы можете пройти с помощью ad hoc parsing (хакерство строк, регулярные выражения и т.д.). Для структур, которые не гнездятся, вы можете пройти с конечным автоматом; здесь часто помогает лексер-генератор. Для сложных структур вы в значительной степени организованный парсер. Вы можете писать парсеры вручную, если вы знакомы с парсингами рекурсивного спуска. Для действительно сложных структур генератор парсеров почти всегда является большой победой.

Если вы хотите обработать langauge компьютера, вам очень нужны лексеры и парсеры в качестве исходного места. Их недостаточно; вам нужно что-то сделать с результатом парсера.

Очень эффектное использование лексинга и синтаксического анализа, которое мы сделали, - это переводить JOVIAL, язык 1960-х годов, в C, для бомбардировщика невидимости B-2. См. http://www.semdesigns.com/Products/Services/NorthropGrummanB2.html

Ответ 7

В Apache Lucene (библиотеке индексов поиска с открытым исходным кодом) существует отличный пример lexer/parser, который используется во многих системах. Эти анализаторы используют как анализатор запросов, так и токенизатор документа. Хотя, я думаю, вы можете классифицировать парсер запросов в Lucene как парсер dsl, он все еще используется, чтобы помочь решить реальную проблему.

В этом отношении я уверен, что Google использует какой-то lexer/parser для собственного синтаксиса запроса и анализа документа.

Ответ 8

Это интересно -

Я просто написал lexer/parser вручную, чтобы разрешить простые выражения запросов на основе строк с помощью реализации IBindingListView. Это была первая полезная вещь вне кода, на которую я действительно смог ее использовать, а не просто слышал об этом.

Довольно пешеходный пример, но я довольно пешеходный в своем опыте с ними.

Ответ 9

Я еще не использовал одного из больших парней, чтобы сделать какой-либо лексический анализ, однако я написал собственный лексер для проекта, над которым я работал. Нам пришлось анализировать данные, которые возвращались с компьютера данных проекта Near Space, и он был записан на SD-карту в двоичном формате. Мне пришлось разделить бит, преобразовать их из двоичного в десятичный, а затем записать все содержимое в файле с разделителями-запятыми.

Очень весело сидеть и анализировать это логически и писать машину состояний для этой задачи!

Ответ 10

Да! Команда, с которой я работаю, внедрила структуру генерации документов, которая, среди прочего, позволяет (в основном арифметические) выражения оценивать. Мы используем парсер для извлечения выражений из входов/определений для сгенерированных документов и создания для них деревьев выражений. Впоследствии эти деревья оцениваются, и оцениваемые результаты записываются в итоговый документ.