Соответствующее использование для yacc/byacc/bison и закона/гибкого провода
Большинство сообщений, что я читал имение отношение к этим утилитам обычно, предлагает использовать некоторый другой метод для получения того же эффекта. Например, вопросы упоминая эти обычные инструменты имеют по крайней мере один ответ, содержащий часть следующего:
- Пользуйтесь библиотекой повышения (введите соответствующую библиотеку повышения здесь),
- Не создавайте использование DSL (вставьте любимый язык сценариев здесь),
- Antlr лучше
Принятие разработчика...
- ... довольно языком C
- ... действительно знает по крайней мере один язык сценариев (например, Python, Perl, и т.д.)
- ... должен написать некоторый код парсинга почти в каждом продолжившем работать проекте
Таким образом, мои вопросы:
- Что такое соответствующие ситуации, которые хорошо подходят для этих утилит?
- Есть ли какие-либо (разумные) ситуации, где нет лучшей альтернативы проблеме, чем yacc и закон (или производные)?
- Как часто в фактических проблемах парсинга можно ожидать сталкиваться с какими-либо короткими прибытиями в yacc и законе, которые лучше обращены более свежими решениями?
- Для разработчика, который не уже знаком с этими инструментами, это стоящий того, чтобы они инвестировали время в изучение их синтаксиса/идиом? Как они соответствуют другим решениям?
5 ответов
Причины, по которым lex / yacc и производные от них сегодня кажутся настолько распространенными, заключаются в том, что они существуют гораздо дольше, чем другие инструменты, и что они охватывают гораздо больше литературе и что они традиционно поставлялись с операционными системами Unix. Это не имеет ничего общего с тем, как они сравниваются с другими инструментами генератора лексических и синтаксических анализаторов.
Независимо от того, какой инструмент вы выберете, всегда придется много учиться. Таким образом, после того, как вы использовали данный инструмент несколько раз и стали относительно комфортно пользоваться им, вам вряд ли захочется тратить дополнительные усилия на изучение другого инструмента. Это естественно.
Кроме того, в конце 1960-х - начале 1970-х годов, когда были созданы lex / yacc, аппаратные ограничения представляли серьезную проблему для синтаксического анализа. Метод анализа LR, управляемый таблицами, используемый Yacc, был наиболее подходящим в то время, поскольку его можно было реализовать с небольшим объемом памяти, используя относительно небольшую общую логику программы и сохраняя состояние в файлах на ленте или диске. Управляемые кодом методы синтаксического анализа, такие как LL, имеют больший минимальный объем памяти, потому что сам код программы синтаксического анализатора представляет грамматику, и поэтому он должен полностью помещаться в ОЗУ для выполнения и сохраняет состояние в стеке в ОЗУ.
Когда памяти стало больше, гораздо больше исследований было посвящено различным методам синтаксического анализа, таким как LL и PEG, и тому, как создавать инструменты с использованием этих методов. Это означает, что многие альтернативные инструменты, которые были созданы после семейства lex / yacc, используют разные типы грамматик. Однако переключение типов грамматики также требует значительного обучения. Если вы знакомы с одним типом грамматики, например, с грамматиками LR или LALR, вы с меньшей вероятностью захотите переключиться на инструмент, который использует другой тип грамматики, например, грамматики LL.
В целом, семейство инструментов lex / yacc, как правило, более элементарно, чем более поздние разработки, которые часто имеют сложные пользовательские интерфейсы для графической визуализации грамматик и грамматических конфликтов или даже разрешения конфликтов посредством автоматического рефакторинга.
Итак, если у вас нет предыдущего опыта работы с какими-либо инструментами парсера, если вам все равно нужно изучить новый инструмент, вам, вероятно, следует обратить внимание на другие факторы, такие как графическая визуализация грамматик и конфликтов, авторефакторинг, наличие хороших документация, языки, на которых можно выводить сгенерированные лексеры / парсеры и т. д. Не выбирайте никаких инструментов просто потому, что «это то, что, кажется, используют все остальные».
Вот несколько причин, по которым я мог бы подумать об использовании lex / yacc или flex / bison:
- разработчик уже знаком с lex / yacc или flex / bison
- разработчик наиболее знаком и удобен с LR / Грамматики LALR
- у разработчика есть много книг, посвященных lex / yacc, но нет книг, посвященных другим
- , у разработчика есть перспективное предложение о работе, и ему сказали, что навыки lex / yacc увеличат его шансы получить работу
- разработчику не удалось получить одобрение участников проекта / заинтересованных лиц на использование других инструментов
- в среде установлен lex / yacc, и по какой-то причине невозможно установить другие инструменты
В предыдущем проекте мне нужен был способ иметь возможность генерировать запросы к произвольным данным таким образом, чтобы его мог использовать относительно нетехнический человек. Это были данные типа CRM (например, имя, фамилия, адрес электронной почты и т. Д.), Но они предназначались для работы с несколькими разными базами данных, все с разными схемами.
Поэтому я разработал небольшой DSL для указания запросов (например, [FirstName] = 'Joe' AND [LastName] = 'Bloggs' выберет всех, кого зовут «Joe Bloggs»). У него были несколько более сложных опций, например, был синтаксис «optedout (medium)», который выбирал всех людей, которые отказались от получения сообщений на определенном носителе (электронная почта, sms и т. Д.). Была «внутренняя группа (xyz)», которая выбирала всех в определенной группе и т. Д.
По сути, она позволяла нам указывать такие запросы, как «внутренняя группа ('GroupA'), а не внутренняя группа ('GroupB')», которая будет переводится в SQL-запрос, подобный этому:
SELECT
*
FROM
Users
WHERE
Users.UserID IN (SELECT UserID FROM GroupMemberships WHERE GroupID=2) AND
Users.UserID NOT IN (SELECT UserID GroupMemberships WHERE GroupID=3)
(Как видите, запросы не настолько эффективны, насколько это возможно, но это то, что вы получаете с машинной генерацией, я думаю).
Я не использовал для этого flex / bison, но использовал генератор парсеров (имя которого сейчас ускользнуло от меня ...)
Я думаю, что это очень хороший совет - избегать создания новых языков только для поддержки языка, специфичного для домена. Будет лучше использовать ваше время, чтобы взять существующий язык и расширить его функциональностью домена.
Если вы пытаетесь создать новый язык по какой-то другой причине, например, для исследования языкового дизайна, то эти инструменты немного устарели. Новые генераторы, такие как antlr, или даже новые языки реализации, такие как ML, значительно упрощают разработку языков.
Если есть веская причина для использования этих инструментов, то, вероятно, это из-за их наследия. Возможно, у вас уже есть скелет языка, который нужно улучшить, который уже реализован в одном из этих инструментов. Вы также можете извлечь пользу из огромных объемов учебной информации, написанной об этих старых инструментах, для которых не так уж много написано для более новых и изящных способов реализации языков.
У меня в офисе реализован целый язык программирования. Мы используем его для этого. Я думаю, это был быстрый и простой способ писать интерпретаторы для разных вещей. Вы могли бы написать с их помощью практически любой текстовый синтаксический анализатор, но во многих случаях либо A) проще быстро написать его, либо B) вам нужна большая гибкость, чем они предоставляют.
Стоит ли изучать эти инструменты или нет, будет сильно зависеть (почти полностью от того, сколько кода синтаксического анализа вы пишете или насколько вы заинтересованы в написании большего количества кода в этом общем порядке. Я использовал их довольно много и обнаружил они чрезвычайно полезны.
Инструмент, который вы используете, на самом деле не имеет такого большого значения, как многие думают. Примерно для 95% входных данных, с которыми мне приходилось иметь дело, существует достаточно небольшая разница между одним и другим, чтобы лучший выбор - это тот, который мне наиболее знаком и удобен.
Конечно, lex и yacc производят (и требуют, чтобы вы писали свои действия) C (или C ++). Если вам не нравится их, инструмент, который использует и производит язык, который вы предпочитаете (например, Python или Java), несомненно, будет гораздо лучшим выбором. Я, например, не советовал бы пытаться использовать такой инструмент с языком, с которым вы незнакомы. или неудобно. В частности, если вы напишете код в действии, которое вызывает ошибку компилятора, вы при отслеживании проблемы компилятор, вероятно, будет получать значительно меньше помощи, чем обычно, поэтому вам действительно нужно быть достаточно знакомым с языком, чтобы распознать проблему с минимальным намеком на то, где компилятор заметил что-то не так.