По работе пишу парсер/синтаксический/семантический анализатор языка. Внешне похож на С, но сильно проще (пока) — фактически только одни определения типов. Хотел бы посоветововаться с коллегами — насколько эта задача сложна? Руководство крайне недовольно, что ковыряюсь уже 3-й месяц и по моим планам выходит еще 2 с половиной.
Пришлось самостоятельно описывать грамматику языка, пробовал воспрльзоватсья какимими то существующими наработками типа YACC и LEX, но разбиратся с ними показалось еще сложнее и явно из пушки по воробьям. Ща ковыряю синтаксический анализ, процесс идет тяжко. Это действительно такая тривиальная задача и выпускник ВУЗа по специальности "программирование" нынче пишет свой компилятор за 2 дня?!!!

Здравствуйте, VadNuNik, Вы писали:

VNN>По работе пишу парсер/синтаксический/семантический анализатор языка. Внешне похож на С, но сильно проще (пока) — фактически только одни определения типов. Хотел бы посоветововаться с коллегами — насколько эта задача сложна?

Урвень курсовой на 3-4 курсе института.

VNN> Руководство крайне недовольно, что ковыряюсь уже 3-й месяц и по моим планам выходит еще 2 с половиной.

Да, что то многовато.

VNN>Пришлось самостоятельно описывать грамматику языка, пробовал воспрльзоватсья какимими то существующими наработками типа YACC и LEX, но разбиратся с ними показалось еще сложнее и явно из пушки по воробьям.

Это была твоя главная ошибка.

Здравствуйте, VadNuNik, Вы писали:

VNN>По работе пишу парсер/синтаксический/семантический анализатор языка. Внешне похож на С, но сильно проще (пока) — фактически только одни определения типов. Хотел бы посоветововаться с коллегами — насколько эта задача сложна? Руководство крайне недовольно, что ковыряюсь уже 3-й месяц и по моим планам выходит еще 2 с половиной.

Я свой язык программирования никогда не писал, и сейчас оценил бы это месяцев в 6 на создание интерпретатора простого С-подобного языка (в объем работ включается компилятор исходника в байткод и виртуальная машина для его исполнения).

VNN>Пришлось самостоятельно описывать грамматику языка, пробовал воспрльзоватсья какимими то существующими наработками типа YACC и LEX, но разбиратся с ними показалось еще сложнее и явно из пушки по воробьям.

Это вряд ли — задачу лексического и синтаксического анализа в большинстве случаев эти инструменты (или подобные им) решают лучше всего — как в плане "качества кода", так и в скорости разработки.

VNN>Ща ковыряю синтаксический анализ, процесс идет тяжко. Это действительно такая тривиальная задача и выпускник ВУЗа по специальности "программирование" нынче пишет свой компилятор за 2 дня?!!!

Я бы вообще не стал писать свой интерпретатор/компилятор — есть большое количество готовых, достаточно выбрать наиболее подходящий и подонать под специфические требования. Это намного проще, чем писать свой с нуля.

Здравствуйте, VadNuNik, Вы писали:

VNN>Пришлось самостоятельно описывать грамматику языка, пробовал воспрльзоватсья какимими то существующими наработками типа YACC и LEX, но разбиратся с ними показалось еще сложнее и явно из пушки по воробьям.

Напрасно. Месяц на разбирательство (максимум) + месяц на язык (опять максимум).
Даже если сейчас выкинуть все твои наработки, выйдет быстрее. Точнее, выйдет ещё быстрее, т.к. с учётом опыта тебе не понадобится месяц на въёзжание.

Не веришь — потрать неделю на antlr. Или на bison. Хотя можно и yacc-ом пользоваться. Короче, на любой один из них. Неделя при твоих сроках не так критична, а сэкономить может много.

VNN>Ща ковыряю синтаксический анализ, процесс идет тяжко. Это действительно такая тривиальная задача и выпускник ВУЗа по специальности "программирование" нынче пишет свой компилятор за 2 дня?!!!

Зависит. От выпускника, от языка, от задач стоящих перед компилятором. Синтаксический анализ и парсинг действительно хорошо автоматизируются, а вот с генерацией кода и/или интерпретацией — сложнее. В среднем — нет, конечно.

Здравствуйте, SergH, Вы писали:

SH>Не веришь — потрать неделю на antlr. Или на bison. Хотя можно и yacc-ом пользоваться. Короче, на любой один из них.

Я бы все таки советовал начать с LL парсеров, т.е. c antlr или CoCo/R

Здравствуйте, AndrewVK, Вы писали:

AVK>Я бы все таки советовал начать с LL парсеров, т.е. c antlr или CoCo/R

Хм, мне было проще пользоваться bison, чем antlr.

SH>>Не веришь — потрать неделю на antlr. Или на bison. Хотя можно и yacc-ом пользоваться. Короче, на любой один из них.

AVK>Я бы все таки советовал начать с LL парсеров, т.е. c antlr или CoCo/R

если у него там язык "похож на Си" (хоть и "проще") ("пока"), то LL ему не поможет да и вообще.. мало что поможет

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

Здравствуйте, VadNuNik, Вы писали:

VNN>По работе пишу парсер/синтаксический/семантический анализатор языка. Внешне похож на С, но сильно проще (пока) — фактически только одни определения типов. Хотел бы посоветововаться с коллегами — насколько эта задача сложна? Руководство крайне недовольно, что ковыряюсь уже 3-й месяц и по моим планам выходит еще 2 с половиной.

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

VNN>Пришлось самостоятельно описывать грамматику языка, пробовал воспрльзоватсья какимими то существующими наработками типа YACC и LEX, но разбиратся с ними показалось еще сложнее и явно из пушки по воробьям. Ща ковыряю синтаксический анализ, процесс идет тяжко.

Вот это совсем плохо. Существующими наработками стоит воспользоваться. Хотя бы вот из каких соображений. Даже если пишут парсер вручную (если по к-л причинам не удаётся воспользоваться yacc), вначале записывают грамматику в BNF, а потом делают всю "чёрную" работу (там даже не надо думать, только шпарить по имеющемуся алгоритму генератора LL-парсера). Так какая разница: записать грамматику неформально, или на языке, используемом yacc?

Думаю, основная причина, по которой у тебя ничего не получается — незнание теоретических основ компиляторостроения. Вот хотя бы нужно понимать, что такое язык, грамматика, как она описывается в BNF, уметь проектировать её и т.п. Для этого хватит основ — первых двух глав красного дракона. На прочтение и вникание должно хватить трёх дней. Там же, кстати, даётся введение в то, как пишутся компиляторы. Не поленись потратить неделю на изучение, и следующей недели тебе хватит на то, чтобы закончить работу.

Здравствуйте, VadNuNik, Вы писали:

VNN>По работе пишу парсер/синтаксический/семантический анализатор языка. Внешне похож на С, но сильно проще (пока) — фактически только одни определения типов. Хотел бы посоветововаться с коллегами — насколько эта задача сложна? Руководство крайне недовольно, что ковыряюсь уже 3-й месяц и по моим планам выходит еще 2 с половиной.
VNN>Пришлось самостоятельно описывать грамматику языка, пробовал воспрльзоватсья какимими то существующими наработками типа YACC и LEX, но разбиратся с ними показалось еще сложнее и явно из пушки по воробьям. Ща ковыряю синтаксический анализ, процесс идет тяжко. Это действительно такая тривиальная задача и выпускник ВУЗа по специальности "программирование" нынче пишет свой компилятор за 2 дня?!!!

Ну, лексический анализатор пишется за вечер Я в свое время написал, до сих пор им пользуюсь в разных проектах. Без LEX, естественно.
С синаксическим сложнее, особенно для си-подобных языков. Но если подумать, то можно обойтись безо всяких YACC. Я недавно создавал компилятор для некоего гибрида basic и c, вполне рабочий, умеет находить ошибки во всей программе, а не останавливаться на первой попавшейся. По сути — метод рекурсивного спуска. А вообще в этих задачах главное — не сам анализатор, а очень грамотно продуманная система классов для хранения всех структур.

Здравствуйте, VadNuNik, Вы писали:

VNN>По работе пишу парсер/синтаксический/семантический анализатор языка. Внешне похож на С, но сильно проще (пока) — фактически только одни определения типов. Хотел бы посоветововаться с коллегами — насколько эта задача сложна? Руководство крайне недовольно, что ковыряюсь уже 3-й месяц и по моим планам выходит еще 2 с половиной.
VNN>Пришлось самостоятельно описывать грамматику языка, пробовал воспрльзоватсья какимими то существующими наработками типа YACC и LEX, но разбиратся с ними показалось еще сложнее и явно из пушки по воробьям. Ща ковыряю синтаксический анализ, процесс идет тяжко. Это действительно такая тривиальная задача и выпускник ВУЗа по специальности "программирование" нынче пишет свой компилятор за 2 дня?!!!
Вы, к сожалению, не написали на каком языке пишете свой анализатор языка. Тогда было бы проще посоветовать где глянуть существующие реализации. Вот, к примеру, подборка реализаций языков программирования на Java:
здесь.

Здравствуйте, konsoletyper, Вы писали:

K>Если же нужен статический контроль типов, составление всяческих таблиц, графов и т.п., то может потребоваться масса времени.
Ну вопщем да, типы данных имеют место быть. Собсно вот описание языка OIL.

K>Вот это совсем плохо. Существующими наработками стоит воспользоваться. Хотя бы вот из каких соображений.
Плохо то, что у меня действительно нет теоретических знаний в компиляторах, да и программироваие как таковое в институте изучалось слабо (в силу специальности) и давно. Для большинства задач пока вполне хватало самообразования, но вот тут явно орешек достался не по зубам :-(

K>вначале записывают грамматику в BNF, а потом делают всю "чёрную" работу (там даже не надо думать, только шпарить по имеющемуся алгоритму генератора LL-парсера).
Собсно, в вышепреведенном PDF-файле сам OIL так уже описан, честно говоря, это сильно не помогло. Мне нужно не просто прочитать (проверить синтаксическую верность) программу на OIL, а создать ее модель в памяти для последующего "визуального программирования", мне показалось, что в данном случае yacc мне совсем не помощник. Вот на следующем этапе когда нужно будет транслировать OIL в стандартый Си, тут наверное готовые анализаторы и кодогенераторы помогут. Я прав?

ЗЫ
Блин, дочего же тяжко себя ощущать по пояс деревянным :-(

Здравствуйте, fplab, Вы писали:

F>Вы, к сожалению, не написали на каком языке пишете свой анализатор языка. Тогда было бы проще посоветовать где глянуть существующие реализации.
Да, вот как раз сейчас и занят проектированием системы классов для синтаксического разбора. Вообще у меня уже какой-то зверинец из паралелльных иерархий получается — описание грамматики и сущностей (в виде XML — мне так было проще), соответсвенно система проверки файла описания языка (подразумевается, что язык может модифицироваться под конкретный случай), иераррхия описания документа, иерархия синтаксического анализатора, семантическая иерархия... Песец, голова пухнет, первый раз такое. Ощущение напоминает момент когда после 10летнего перерыва занялся программированием и втыкался в ООП, но тогда дедлайн не маячил вот так близко :-(

Здравствуйте, VadNuNik, Вы писали:

VNN>Здравствуйте, fplab, Вы писали:

F>>Вы, к сожалению, не написали на каком языке пишете свой анализатор языка. Тогда было бы проще посоветовать где глянуть существующие реализации.
VNN>Да, вот как раз сейчас и занят проектированием системы классов для синтаксического разбора. Вообще у меня уже какой-то зверинец из паралелльных иерархий получается — описание грамматики и сущностей (в виде XML — мне так было проще), соответсвенно система проверки файла описания языка (подразумевается, что язык может модифицироваться под конкретный случай), иераррхия описания документа, иерархия синтаксического анализатора, семантическая иерархия... Песец, голова пухнет, первый раз такое. Ощущение напоминает момент когда после 10летнего перерыва занялся программированием и втыкался в ООП, но тогда дедлайн не маячил вот так близко
Ох уж эти классы Да еще "системы классов" Ей-богу, не понимаю: зачем усложнять то, что прекрасно делается на самом обыкновенном и надежном С. Поищите хотя бы "книгу дракона" и просмотрите первые главы. Пусть вы потратите пару недель на это, но зато поймете что ничего сверхзаумного там нет. Вы же сами писали, что анализируете С-подобный язык. А примеров реализаций языков такого типа — вагон. Можно глянуть к примеру здесь. Человек собрал довольно неплохую коллекцию свободнх компиляторов/интерпретаторов.

VadNuNik wrote:
>
> По работе пишу парсер/синтаксический/семантический анализатор языка.
> Внешне похож на С, но сильно проще (пока) — фактически только одни
> определения типов. Хотел бы посоветововаться с коллегами — насколько эта
> задача сложна? Руководство крайне недовольно, что ковыряюсь уже 3-й
> месяц и по моим планам выходит еще 2 с половиной.
> Пришлось самостоятельно описывать грамматику языка, пробовал
> воспрльзоватсья какимими то существующими наработками типа YACC и LEX,
> но разбиратся с ними показалось еще сложнее и явно из пушки по воробьям.
> Ща ковыряю синтаксический анализ, процесс идет тяжко. Это действительно
> такая тривиальная задача и выпускник ВУЗа по специальности
> "программирование" нынче пишет свой компилятор за 2 дня?!!!

Из опыта. Достаточно простой с-подобный язык: спецификация языка,
разработка компилятора в байт код, виртуальной машины и библиотеки
поддержки — 3 месяца. При этом в компиляторе реализована полная
инфраструктура — AST, гибкая поддержка типов (наподобие ML), разного
рода оптимизации, подключение различных backend-ов и т.д.

Что касается lex и yacc — я бы сказал, что отказываться от них можно,
но, как правило — нежелательно, и нужно точно знать на что идешь, и,
главное — почему lex/yacc не устраивают. Вобще задача синтаксического и
лексического анализа не самая сложная часть компиляции, и, как правило,
нет смысла на ней заостряться. Если говорить о сложности изучения lex и
yacc, то (опять же из опыта), очное обучение человека, незнакомого с
этой областью вообще, занимает минимальное количество времени —
буквально пару-тройку дней. Тем более, что с грамматиками все так или
иначе знакомы, нужно только пояснить отдельные принципы самого yacc,
LALR анализа и дать набор базовых решений типовых ситуаций.

Так-что, если хотите — еще не поздно этим заняться.

VadNuNik wrote:
> K>вначале записывают грамматику в BNF, а потом делают всю "чёрную"
> работу (там даже не надо думать, только шпарить по имеющемуся алгоритму
> генератора LL-парсера).
> Собсно, в вышепреведенном PDF-файле сам OIL так уже описан, честно
> говоря, это сильно не помогло. Мне нужно не просто прочитать (проверить
> синтаксическую верность) программу на OIL, а создать ее модель в памяти
> для последующего "визуального программирования", мне показалось, что в
> данном случае yacc мне совсем не помощник. Вот на следующем этапе когда
> нужно будет транслировать OIL в стандартый Си, тут наверное готовые
> анализаторы и кодогенераторы помогут. Я прав?

Не, lex/yacc тут — самое то. их основная задача — помочь структурировать
вход, а именно такая задача перед вами и стоит. И еще не поздно
переключиться — по приведенной грамматике действительно можно очень
быстро написать анализатор, строящий отражение структуры в памяти. а
затем и добавить компиляцию.

Здравствуйте, hexis, Вы писали:

H>Что касается lex и yacc — я бы сказал, что отказываться от них можно,
H>но, как правило — нежелательно, и нужно точно знать на что идешь, и,
H>главное — почему lex/yacc не устраивают.
Я не врубился как при помощи этих тулов получить модель в памяти. Один же черт нужно будет получать такое представление для визуального отображения и редактирования.

H>Так-что, если хотите — еще не поздно этим заняться.
Я хочу реализовать эту систему и желательно уложиться в срок :-)

Тут уже не раз помянали некого "красного дракона", пардон за невежество, это что? :-) Гугл все больше какой-то фильм подсовывает.

Здравствуйте, VadNuNik, Вы писали:

VNN>Здравствуйте, hexis, Вы писали:

H>>Что касается lex и yacc — я бы сказал, что отказываться от них можно,
H>>но, как правило — нежелательно, и нужно точно знать на что идешь, и,
H>>главное — почему lex/yacc не устраивают.
VNN>Я не врубился как при помощи этих тулов получить модель в памяти. Один же черт нужно будет получать такое представление для визуального отображения и редактирования.

H>>Так-что, если хотите — еще не поздно этим заняться.
VNN>Я хочу реализовать эту систему и желательно уложиться в срок

VNN>Тут уже не раз помянали некого "красного дракона", пардон за невежество, это что? Гугл все больше какой-то фильм подсовывает.
Не "красный дракон", а "книга дракона":
Альфред Ахо, Рави Сети, Джеффри Ульман. Компиляторы. Принципы, технологии, инструменты. Издательство Вильямс, 2003

VadNuNik wrote:
>
> Здравствуйте, hexis, Вы писали:
>
> H>Что касается lex и yacc — я бы сказал, что отказываться от них можно,
> H>но, как правило — нежелательно, и нужно точно знать на что идешь, и,
> H>главное — почему lex/yacc не устраивают.
> Я не врубился как при помощи этих тулов получить модель в памяти. Один
> же черт нужно будет получать такое представление для визуального
> отображения и редактирования.

Тут нужно определиться с тем, какое представление вам хочется получить.
Наиболее естественное для yacc — это трансформация в связанный набор
классов, который затем можно преобразовать в что угодно.

Выглядит примерно так:
Берем исходную грамматику в BNF:

<enumeration> ::=
    "[" <enumerator_list> "]"
<enumerator_list> ::=
    <enumerator>
    | <enumerator_list> "," <enumerator>
<enumerator> ::=
    <name> <description>
    | <name> <impl_parameter_list> <description>

Создаем классы для преставления перечисления в памяти:

#define optional /* optional */

struct Enumerator
{
    Enumerator(char * _name,
        optional ImplParameterList * _plist,
        optional char * _description)
    : name(_name), plist(_plist), description(_description)
    {
    }

    char * name;
    optional ImplParameterList * plist;
    optional char * description;
};

struct Enum
{
    Enum(Enumerator * e)
    {
        add_enumerator(e);
    }

    void add_enumerator(Enumerator* e)
    {
        enumerators.push_back(e);
    }

    std::list<Enumerator*> enumerators;
};

и связываем все это в yacc

%union
{
    Enum       _enum;
    Enumerator _enumerator;
};

%type <_enum>        enumeration enumerator_list
%type <_enumerator>     enumerator
%type <string>        string description

%%
enumeration: '[' enumerator_list ']'
        { $$ = $2; }
    ;

enumerator_list : enumerator
        { $$ = new Enum($1); }
    | enumerator_list ',' enumerator
        { $1->add_enumerator($3); $$ = $1; }
    ;

enumerator: name description
        { $$ = new Enumerator($1, NULL, $2); }
    | name impl_parameter_list description
        { $$ = new Enumerator($1, $2, $2); }
    ;

description:
    /* empty definition */    { $$ = NULL; }
    | ':' string        { $$ = $2; }
    ;

Как видите, чем ближе промежуточное представление к исходной грамматике
— тем проще его получить. Единственное, с чем есть сложности — это то,
что yacc не позволяет использовать наследуемые атрибуты. Если они нужны,
что придется взять или LL (antlr, coco/R, LLgen) или расширение yacc (на
вскидку имена не помню, но если надо — покопаюсь в архивах), или
обойтись — просто получится чуть сложнее.

>
> H>Так-что, если хотите — еще не поздно этим заняться.
> Я хочу реализовать эту систему и желательно уложиться в срок
>
> Тут уже не раз помянали некого "красного дракона", пардон за невежество,
> это что? Гугл все больше какой-то фильм подсовывает.

Это книга Ахо, Сети, Ульман "Компиляторы: принципы, технологии,
инструменты". Там на обложке дракон нарисован.

VNN>По работе пишу парсер/синтаксический/семантический анализатор языка. Внешне похож на С, но сильно проще (пока) — VNN>фактически только одни определения типов.

Если только декларация типов — то где-то максимум две недели. Что с генератором парсеров, что вручную.
Берешь готовый пример для соответствующего или похожего синтаксиса и вперед.

Вообще по описанию, очень похоже на какой-нибудь IDL или Slice. И для того и для другого полно парсеров — бери любой, допиливай (отпиливай лишнее) и готово. Ну и вообще готовых решений, которые используют синтаксис типа

identifier {
   type identifier ;
}

тьма.

VNN>Хотел бы посоветововаться с коллегами — насколько эта задача сложна? Руководство крайне недовольно, что ковыряюсь VNN>уже 3-й месяц и по моим планам выходит еще 2 с половиной.

Их можно понять, хотя конечно надо видеть что у вас там за язык на самом деле. По приведенному описанию — ничего такого, что бы тянуло на 5 месяцев работы нет.


VNN>Это действительно такая тривиальная задача и выпускник ВУЗа по специальности "программирование" нынче пишет свой VNN>компилятор за 2 дня?!!!

компилятор — это компилятор, а вот парсер/анализатор пишется быстро с использованием средств. Примеры парсеров C/C++ есть по моему, в любом генераторе парсеров — что в SPIRIT, что в ANTLR. Что мешало их взять и допилить?

И кстати, язык-то сам для чего?