в первую очередь кури РБНФ и далее по списку

Книга Дракона.

Это какая книга?

>интерпритатор, язык c++, с чего начать?

С чего-нибудь попроще. BASIC например.

Для начала найди руководство по написанию слова «интерпрЕтатор»

>>Для начала найди руководство по написанию слова «интерпрЕтатор»

Нашел, спасибо за подсказку.

С чего-нибудь попроще. BASIC например.

Не, я синтаксиса базика не знаю, я лучше свой придумаю.

>>С чего-нибудь попроще. BASIC например.

вы так говорите как будто хотите использовать сотни if strcmp(some_token, current_token) == 0 а не описывать синтаксис в РБНФ и генерить парсер.

Да. Ахо, Сети, Ульман в авторах.

> Это какая книга?
http://en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools
Переведена на русский язык.

Генератор парсеров сделает убогий год, это пруть для лентяев. Чтобы научиться писать нормальные парсеры нужно начинать с чего-нибудь проще, ибо плюсовый синтаксис довольно геморный.

В смысле? Я же не интерпритатор C++ писать собираюсь О_о.

>Не, я синтаксиса базика не знаю, я лучше свой придумаю.

Всё уже придумано 40 лет назад.

man forth

>>Генератор парсеров сделает убогий год, это пруть для лентяев.

ага. еще скажи что flex, bison, yacc нинужны а то авторы компиляторов об это не знают или они лентяи.

>язык c++

Тут кто-то писал что c++ дико сложный для компиляции.

А понял, тогда boost.spirit

Это одна из тех книг, которую все активно советуют, но никто из советчиков её как правило не читал.

http://flex.sourceforge.net/manual/

Начать можно со стандартного упражнения: написание метациклического интерпретатора, на тех языках, которые это позволяют (лисп, пролог).

Синтаксический анализ это, конечно, интересно, но и завязнуть в нем можно надолго.

>вы так говорите как будто хотите использовать сотни if strcmp(some_token, current_token) == 0 а не описывать синтаксис в РБНФ и генерить парсер.

Ты говоришь так, будто ТС это хочет для работы, а не для учёбы.

ага. еще скажи что flex, bison, yacc нинужны а то авторы компиляторов об это не знают или они лентяи.

Да, скажу именно так. Имею опыт работы с этими тулзами и, мягко говоря, не в востороге от их кодогенерации. Все серьёзные проекты имеют свои, руками написанные, парсеры. А кодогенераторы в основном встречаю только в по, где парсеры используются эпизодически.

Судя по твоим вопросам по руби лучше не надо, документацию ты читать не умеешь и не хочешь.

Дрэгон Бук

Книга очень годная, но сложная - наскоком не возьмешь. Если не осилил, просто пройди мимо.

Если не понял, о чем я, просто не комментируй.

> Да, скажу именно так. Имею опыт работы с этими тулзами и, мягко говоря, не в востороге от их кодогенерации. Все серьёзные проекты имеют свои, руками написанные, парсеры. А кодогенераторы в основном встречаю только в по, где парсеры используются эпизодически.

gcc довольно долго использовали два парсера - один из них был написан на связке lex + yacc и служил для парсинга объявлений.

И о какой кодогенерации может идти речь, если вы говорите про lex/yacc??? Это table driven вещи, там генерятся таблицы, все темплейты кода уже давно написанны и не генерятся. Вы явно не знаете, о чём говорите.

Еще вот эта книжка довольно хорошая, правда там все примеры на Java и ANTLR.

Если написание предполагается для своего развития, то рекомендую An Incremental Approach To Compiler Construction (http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf).

Могу еще предложить написать виртуальную машину для Lua, для её байт-кода есть подробное описание. Плюс в том, что не придется писать компилятор, что довольно скучно.

Ссылка на документацию по байткоду: http://luaforge.net/docman/index.php?group_id=83&selected_doc_group_id=102&la...

«The UNIX Programming Environment» Кернигана-Пайка описывает простой пример интерпретатора - как отправная точка сойдёт.

SICP, 4я глава.

C++ не нужен

Write Yourself a Scheme in 48 Hours

Essentials of Programming Languages

У Шилдта неплохие книги. Если не изменяет память, в одной из его книг по C я читал главу посвященную написания простого интерпретатора Basic-подобного языка. В «Искусство программирования на C++» рассмотрен интерпретатор с рекурсивно-нисходящим анализатором языка Mini C++ (хотя манера его реализации в стиле языка C).

gcc довольно долго использовали два парсера - один из них был написан на связке lex + yacc и служил для парсинга объявлений.

А потом lex + yacc выкинули и написали парсеры руками, да и то они там были из-за тяги GNU-шников к своим велосипедам. А все современные компиляторы обходятся бкз них прекрасно, так как синтаксис языков в LR(1) не ложится.

интерпретатор лиспа на питоне - http://norvig.com/lispy.html
интерпретатор лиспа на хаскеле - http://www.defmacro.org/ramblings/lisp-in-haskell.html
интерпретатор лиспа на лиспе - тоже где-то есть в сети

> интерпретатор лиспа на лиспе

Самый сок - интерпретатор брейнфака на брейнфаке. Попадался где-то.

интерпретатор лиспа на руби - https://github.com/tmountain/Liby

>Самый сок - интерпретатор брейнфака на брейнфаке. Попадался где-то.

он был на бабрабабре, но моя религия не позволяет туда ходить

> он был на бабрабабре

Не, я где-то в другом месте видел.

>> он был на бабрабабре

Не, я где-то в другом месте видел.

это был сон

интерпретатор баш на баше было бы реально самое бесполезное ололо :3

http://code.google.com/p/awib/

только это компилятор.

для простых интерпретаторов достаточно хорошо подходит boost.spirit для описания парсинга

читал. советую.

> А потом lex + yacc выкинули и написали парсеры руками, да и то они там были из-за тяги GNU-шников к своим велосипедам. А все современные компиляторы обходятся бкз них прекрасно, так как синтаксис языков в LR(1) не ложится.

А потом люди взяли и написали более десятка лексеров+парсеров для разных нужд в бинутилс. Дураки, да? Куда им до познаний alexru! Срочно пиши разработчикам, чтоб они перестали заниматься ерундой и перестали использовать lex/yacc ;)

пи#*еть - не мешки ворочать

> потом lex + yacc выкинули и написали парсеры руками, да и то они там были из-за тяги GNU-шников к своим велосипедам. А все современные компиляторы обходятся бкз них прекрасно, так как синтаксис языков в LR(1) не ложится.

1) вы путаете понятия синтаксиса и грамматики

2) вы путаете LR(1) & LALR(1)

3) bison поддерживает GLR

4) дело не «в тяге к своим велосипедам», а в обработке ошибок.

Советую не писать о том, о чём не имеете ни малейшего представления.

Я не утверждал, что lex+yacc не нужны совсем, даже наоборот. Но вот для компиляторов современных ЯВУ они не подходят.

gcc довольно долго использовали два парсера - один из них был написан на связке lex + yacc и служил для парсинга объявлений.

Тут ключевое слово 'использовали' и так всегда делают с CC с развитием по.

А что, генераторы парсеров более сложную грамматику описывать не дают?

Не все удается описать грамматикой и иногда приходится параллельно делать семантический анализ в процессе грамматического разбора. Классический пример из Си: конструкция «zzz * a;» может быть просто выражением (умножение переменных «zzz» и «a»), а может быть объявлением переменной «a» как указателя типа «zzz». И красивая цепочка лексический-грамматический-семантический разбор-кодогенерация превращается в невероятное месиво, за которым очень тяжело следить глядя только на правила записанные у yacc-описании.