LINUX.ORG.RU

Создание анализаторов текста при помощи yacc и lex

 , , , ,


0

0

В этой статье на примере создания простого калькулятора показано, как создать анализатор при помощи инструментов lex/flex и yacc/bison, а затем более подробно рассмотрено, как применить эти принципы к синтаксическому разбору текста. Синтаксический разбор текста - анализ и извлечение ключевых частей текста - важная часть многих приложений. В UNIX® многие элементы операционной системы зависят от синтаксического анализа текста: оболочка, которая используется для взаимодействия с системой, распространенные утилиты и команды типа awk или Perl, вплоть до компилятора Си, используемого для разработки приложений. Анализаторы собственной разработки можно использовать в UNIX-программах (и не только UNIX) для создания простых анализаторов конфигурации или даже для создания своего собственного языка программирования.

>>> Подробности

★★★

Проверено: maxcom ()

>В этой статье на примере создания простого *калькулятора* показано, как создать анализатор при помощи инструментов lex/flex и yacc/bison

не читал, но по ссылке ходить боюсь о_О

volh ★★
()

Да. Статья - Ъ.

dikiy ★★☆☆☆
()

баян.. я ещё в институте калькулятор на бизоне делал. там у них это самый главный пример был. почему то мне кажется и единственный =))

а вы используете бизон в своих проектах?

anonymous
()
Ответ на: комментарий от anonymous

Re^2: Создание анализаторов текста при помощи yacc и lex

> баян.. я ещё в институте калькулятор на бизоне делал. там у них это самый главный пример был. почему то мне кажется и единственный =))

> а вы используете бизон в своих проектах?


Допустим, не бизон, а antlr, но используем. А поцчему ви спгашиваете?

gaa ★★
()

во-первых пример создания калькулятора есть в info bison. во-вторых домащняя страничка IBM_dW сасед. если смотреть её без картинок то вместо стрелки на следующую страницу написано "на предыдущую страницу". вместо стрелки на предыдущую страницу красуется та же надпись.

а вообще разработчики gcc посчитали что бизон ацтой и выкинули его из гнуса4. в гнус3 он был. хотя может счас опять посчитают что он крут?

капча lipsed говорит что lisp - наше все

anonymous
()

О! Как ни странно, но давно хотел почитать про эти две тулзы. Как раз кстати.

Bohtvaroh ★★★★
()
Ответ на: комментарий от anonymous

> а вы используете бизон в своих проектах?
Для примера Bison используется в PostgreSQL для разбора запросов.

Korwin ★★★
()

прочитал статью и не понял: как с помощью bison/flex построить AST? В статье просто распечатываются строковые лексемы, не строится дерево разбора (CST), не строится семантическое дерево в AST. Пример с интерпретатором слишком простой, ничего не показывает. Куда интереснее пример с транслятором исходников с одного языка в другой (желательно, не как с распечаткой строковых лексем, как тот макрос с распечаткой ассемблерной вставки в статье). На таком комплексном примере понадобилось бы и построить AST из CST, трансформировать его из одного входного языка через метаязык в другой целевой, как-то обеспечить автоматическое построение CST/разных AST из единой спецификации, какая-то обработка ошибок, тестирование, профилирование и оценка производительности парсера. Для введения в предмет, впрочем, статья неплохая. Хотя на современных средствах вроде ANTLR/LLVM/HLVM/BNFC/Happy можно найти и более жизненный пример, весь цикл целиком в рамках одного инструментария.

anonymous
()
Ответ на: комментарий от anonymous

уууу.. помню прак на втором курсе.. мне от этой хрени свело мозг )))

но инструмент реально всеядный и крайне полезный.

anonymous
()
Ответ на: комментарий от anonymous

> капча lipsed говорит что lisp - наше все

Эта капча говорит, что наше все - sed, иначе жепа слипнется.

anonymous
()
Ответ на: комментарий от anonymous

> прочитал статью и не понял: как с помощью bison/flex построить AST? В статье просто распечатываются строковые лексемы, не строится дерево разбора (CST), не строится семантическое дерево в AST. Пример с интерпретатором слишком простой, ничего не показывает. Куда интереснее пример с транслятором исходников с одного языка в другой (желательно, не как с распечаткой строковых лексем, как тот макрос с распечаткой ассемблерной вставки в статье). На таком комплексном примере понадобилось бы и построить AST из CST, трансформировать его из одного входного языка через метаязык в другой целевой, как-то обеспечить автоматическое построение CST/разных AST из единой спецификации, какая-то обработка ошибок, тестирование, профилирование и оценка производительности парсера. Для введения в предмет, впрочем, статья неплохая. Хотя на современных средствах вроде ANTLR/LLVM/HLVM/BNFC/Happy можно найти и более жизненный пример, весь цикл целиком в рамках одного инструментария.

А что почитать более полноценного посоветуете по теме?

Bohtvaroh ★★★★
()
Ответ на: комментарий от anonymous

или более современную Абеля "Modern compiler construction in Java/ML/C". Примеры на ML прикольные.

anonymous
()
Ответ на: комментарий от volh

Да и нечего там по ссылке делать. Все дружно читаем первые 3-4-е главы Керниган/Пайк "Введение в UNIХ" от 19хх-лохматого года. Потом в руки берётся двухтомник Д.Грис "Создание компиляторов" и вдумчиво читается до потери пульса. Потом всё это, убирается в дальний угол, присыпается другой макулатурой, и все дружно идём работать. Т.к. жить на что-то надо.

Капча:nerwed - поди догадайся на что она намекает ....

anonymous
()
Ответ на: комментарий от anonymous

> Есть GPB

можно ссылку или расшифровку акронима?

anonymous
()
Ответ на: комментарий от volh

>не читал, но по ссылке ходить боюсь о_О

И праина.

Системные требования

Нет.


Продолжительность

2 часа

Форматы
html

Проснулись! Усцыкуха!

vada ★★★★★
()

для программирующих на С++ рекомендую boost.spirit - удобная штука, при этом никаких зависимостей от внешних утилит

ott ★★★★★
()

Юзаю yapp - yacc для перла. (Там есть AST, если кому надо.)

Но мощностей yacc не хватает, так как грамматика внезапно перестала быть LRn. Что можно использовать в таком случае?

anonymous
()
Ответ на: комментарий от ott

> для программирующих на С++ рекомендую boost.spirit - удобная штука, при этом никаких зависимостей от внешних утилит

Ты бы видел как оно тормозит при компиляции грамматике языка большего чем язык калькулятора. Bison2.3 с шаблоном для С++ (lalr1) и ручным сканером неплохо работают, но тоже есть недостатки.

А antlr3 для С++ так никто еще и не сделал :(

anonymous
()
Ответ на: комментарий от anonymous

> Но мощностей yacc не хватает, так как грамматика внезапно перестала быть LRn. Что можно использовать в таком случае?

А что за язык такой?

anonymous
()
Ответ на: комментарий от bernoulli

> а ты попробуй написать полноценный шелл с паплайнами, эндами, орами, ковычками без лекса\бисона

Вот как раз пазбор синтаксиса шелла замечательно реализуется при помощи ручного рекурсивного разбора.

anonymous
()

Классно! А я еще много-много лет назад читал книжицу Кернигана и Пайка. И надо же, там тоже калькулятор на lex + yacc рассматривался. Вот оказывается, кто идеи у ИбэМе ворует! И если бы не IBM EE/A сидели бы мы тут без знания, что "UNIX - универсальная среда программирования".

Bioreactor ★★★★★
()
Ответ на: комментарий от anonymous

это значит закладку оставить. типа бабёр. хорошо еще не писец.

anonymous
()
Ответ на: комментарий от anonymous

> Потом всё это, убирается в дальний угол, присыпается другой макулатурой, и все дружно идём работать. Т.к. жить на что-то надо.

Лузерство.

sv75 ★★★★★
()
Ответ на: комментарий от sv75

>> А antlr3 для С++ так никто еще и не сделал :(

> То есть оно только для жавы/C#, ни С, ни С++?


Для C есть, для C++ обещают, но пока что не сделали.

gaa ★★
()
Ответ на: комментарий от gaa

> Для C есть, для C++ обещают, но пока что не сделали.

А! То есть там именно голый С? Очень хорошо, а то в apt-cache show antlr3 что-то нехорошеее пишут про С...

sv75 ★★★★★
()
Ответ на: комментарий от sv75

Есть вроде Antlr2.7/C++ http://antlr.org/grammar/list "C++ David Wigg Wed Dec 19, 2007 03:48 This is my final update of the CPP_parser (V3.2) using ANTLR V2.7 to generate C++ parser in C++. I now wish to hand it on to someone else for maintenance and further development (eg. to use ANTLR V3.0). David Wigg, wiggjd@bcs.org.uk"

есть D, тоже 2.7

anonymous
()

Нда, в то время, как прогрессивное человечество использует packrat и GLR, пользуется прогрессивными генераторами парсеров, такими, как Antlr, IBM решили осчастливить нас рассказом о технологии тридцатилетней давности.

anonymous
()
Ответ на: комментарий от ott

> boost.spirit - удобная штука, при этом никаких зависимостей

... при этом - O(exp(n)) worst case. Парсер для терпеливых!

anonymous
()
Ответ на: комментарий от anonymous

> А antlr3 для С++ так никто еще и не сделал :(

И не надо, есть elkhound.

anonymous
()
Ответ на: комментарий от anonymous

> Есть вроде Antlr2.7/C++

Нет, мне именно С нужен.

sv75 ★★★★★
()
Ответ на: комментарий от anonymous

> Потом всё это, убирается в дальний угол, присыпается другой макулатурой, и все дружно идём работать. Т.к. жить на что-то надо.

Намекаешь, что ты лузер, работаешь быдлокодером, и тебе всё это в работе ни разу не пригдилось? Так тут кроме тебя самого никто и не виноват.

anonymous
()
Ответ на: комментарий от anonymous

А вот можно ли как-то обзорно рассказать о современных парсерах, средах и направлениях развития?
Вот одно направление "классический LALR парсер". В духе YACC/Golden Parser/Ragel/lemon/ANTLR/SableCC и т.п. В итоге, конечный автомат для разбора. Куда оно развивается? В сторону большей "инструментальности" -- готовые грамматики, IDE вроде ANTLR Works или GoldParser Builder, для отладки грамматики, интеграция на разных этапах от грамматики до CST/AST/кодогенератора.
Вот второе направление -- комбинаторные парсеры, GLR, Packrat. Куда оно развивается? Парсер на Хаскелле в принципе можно вывести неявно из единой спецификации (в которой и грамматика, и кодогенератор, и подписанные узлы для AST вроде LBNF из BNFC). Сама программа -- расширяемый парсер. Куда развиваются они, в сторону лучших O(n), в сторону более широких грамматик?
В общем не очень понятно как отлаживать парсер, по производительности, в худшем/лучшем/реальном случае. Что-то вроде юниттестов. Не очень понятен процесс отладки (расширения самого парсера). Ну типа проверка на не описанные типы и использование замыканий/switch..case/системы типов для отлова этого момента. Не очень понятен процесс диагностики ошибок для функционального парсера, на лиспе, или там хаскелле.
Да, в OCaML вроде есть какой-то встроенный lex. Где его место, для чего он годится, а для чего -- не очень применим?

anonymous
()
Ответ на: комментарий от anonymous

точнее, генератор LL(k) парсеров.

Tokenizer есть и в стандартной библиотеке С и в Java и это не далеко ушло от lex который есть в каком то там Lisp-е.

anonymous
()

опять калькулятор! сколько можно? это уже даже не боян -- это классика.

beastie ★★★★★
()
Ответ на: комментарий от sprite_13

LL грамматики поуже LR будут.

anonymous
()
Ответ на: комментарий от sv75

Re^2: Создание анализаторов текста при помощи yacc и lex

>> Для C есть, для C++ обещают, но пока что не сделали.

> А! То есть там именно голый С? Очень хорошо, а то в apt-cache show antlr3 что-то нехорошеее пишут про С...


Я какой вообще смысл юзать antlr для C при живом yacc?

gaa ★★
()

> Я какой вообще смысл юзать antlr для C при живом yacc?

Например, для генерации боле понятных пользователю сообщений об ошибках. yacc/bison во многих случаев позволяет писать сообщения уровня unexpected 'TOKEN'".

anonymous
()

А мы в свое время в универе делали компилятор на бизоне чего-угодно в Java байт-код... У меня objective-c был, у других ПХП, смоллтолк и т.д.

И ничо, работало.

alexey_
()
Ответ на: комментарий от anonymous

>ANTLR - это LL(k) парсер.

да, напутал, LALR -- это GoldParser. Не суть, вопрос всё тот же: чем так интересен именно GLR и Packrat, и куда развивается это направление? И почему выбрал именно их, из-за более широкого класса грамматик или из-за более быстрого алгоритма?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.