Недавно я начал изучать ANTLR. Я знаю, что лексеры/парсеры вместе могут использоваться для построения языков программирования.
За исключением DSL или языков программирования, вы когда-либо прямо или косвенно использовали инструменты lexer/parser (и знания) для решения проблем реального мира? Возможно ли, чтобы средний программист мог решить эти проблемы без знания лексеров или парсеров?
Да, я использовал их. Да, вы можете делать что-то без них - но в любое время, когда вы выбираете неправильный инструмент для работы, вы сами будете делать ненужную боль.
Некоторые примеры нестандартных применений, которые я лично использовал для этой технологии:
Подсветка синтаксиса. Текстовый редактор Scite позволяет вам написать собственный лексер (на С++), чтобы обеспечить подсветку синтаксиса для любого пользовательского языка. Я написал свой собственный lexer для Scite в качестве переподготовки по этой теме (я изучал его некоторое время назад в своем университете).
Регулярные выражения часто используются в качестве альтернативы для сопоставления шаблонов и простой обработки языка. Это еще более распространено в последние годы благодаря улучшенной поддержке RegEx в таких рамках, как .NET. Во многих случаях разработчики могут даже не знать о методах лексинга/синтаксического анализа и, таким образом, попадать в обычное Regex по умолчанию.
Однако, как еще один ответ говорит, Regex может быстро стать неэффективным, медленным и трудным для поддержания чего-либо большего, чем просто грамматика/язык. В этой ситуации парсер/лексеры, как правило, лучший выбор.
Да, я использовал их в реальных приложениях - но в основном создание пользовательских языков, на которых вы используете лексеры и парсеры, было вытеснено языками, определенными в XML. Более подробный, но тогда вам не нужно делать все, что работает...
Да, я использовал их. Я большой поклонник ANTLR. Я даю несколько советов и рекомендаций по использованию ANTLR здесь и краткое одобрение этого . Можно вручную написать собственный синтаксический анализатор с использованием специальных методов, но это намного сложнее и займет намного больше времени, чтобы выяснить, как вносить изменения, когда вам нужно вырастить язык, который должен анализировать ваш парсер.
Любое место, где вы обрабатываете ввод текста, заканчивается использованием какого-то lexer/parser, хотя некоторые из них в конечном итоге являются вырожденным случаем (lex ничего, кроме запятой, как один тип токена, а запятая как другая). Parse Число, имя, число и конец строки. Такого рода вещи) Одним из способов взглянуть на него sscanf можно было бы считать наиболее вырожденными случаями генератора лексера/парсера.
Что касается полномасштабной операции lex/yacc? Я ожидаю, что он будет использоваться в основном для GPL и для вещей, которые подпадают под свободное определение DSL
В любой момент, когда существует статический документ (например, файл) или динамический документ (например, поток, происходящий со временем), и этот документ имеет какую-либо структуру, вы обнаружите, что вам нужен какой-то синтаксический анализатор. Для достаточно простых структур вы можете пройти с помощью ad hoc parsing (хакерство строк, регулярные выражения и т.д.). Для структур, которые не гнездятся, вы можете пройти с конечным автоматом; здесь часто помогает лексер-генератор. Для сложных структур вы в значительной степени организованный парсер. Вы можете писать парсеры вручную, если вы знакомы с парсингами рекурсивного спуска. Для действительно сложных структур генератор парсеров почти всегда является большой победой.
Если вы хотите обработать langauge компьютера, вам очень нужны лексеры и парсеры в качестве исходного места. Их недостаточно; вам нужно что-то сделать с результатом парсера.
Очень эффектное использование лексинга и синтаксического анализа, которое мы сделали, - это переводить JOVIAL, язык 1960-х годов, в C, для бомбардировщика невидимости B-2. См. http://www.semdesigns.com/Products/Services/NorthropGrummanB2.html
В Apache Lucene (библиотеке индексов поиска с открытым исходным кодом) существует отличный пример lexer/parser, который используется во многих системах. Эти анализаторы используют как анализатор запросов, так и токенизатор документа. Хотя, я думаю, вы можете классифицировать парсер запросов в Lucene как парсер dsl, он все еще используется, чтобы помочь решить реальную проблему.
В этом отношении я уверен, что Google использует какой-то lexer/parser для собственного синтаксиса запроса и анализа документа.
Это интересно -
Я просто написал lexer/parser вручную, чтобы разрешить простые выражения запросов на основе строк с помощью реализации IBindingListView. Это была первая полезная вещь вне кода, на которую я действительно смог ее использовать, а не просто слышал об этом.
Довольно пешеходный пример, но я довольно пешеходный в своем опыте с ними.
Я еще не использовал одного из больших парней, чтобы сделать какой-либо лексический анализ, однако я написал собственный лексер для проекта, над которым я работал. Нам пришлось анализировать данные, которые возвращались с компьютера данных проекта Near Space, и он был записан на SD-карту в двоичном формате. Мне пришлось разделить бит, преобразовать их из двоичного в десятичный, а затем записать все содержимое в файле с разделителями-запятыми.
Очень весело сидеть и анализировать это логически и писать машину состояний для этой задачи!
Да! Команда, с которой я работаю, внедрила структуру генерации документов, которая, среди прочего, позволяет (в основном арифметические) выражения оценивать. Мы используем парсер для извлечения выражений из входов/определений для сгенерированных документов и создания для них деревьев выражений. Впоследствии эти деревья оцениваются, и оцениваемые результаты записываются в итоговый документ.