Стоит задача разработки лексического, синтаксического и семантического анализаторов ( aka frontend, aka транслятор переднего плана) определенного языка c достаточно сложными языковыми конструкциями. По сложности реализации рассматриваемый язык сопоставимы с языком Си++.

Возник вопрос о выборе языка программирования на котором будет реализовано программное средство. С одной стороны критичным для данного транслятора является скорость разбора исходный текстов и требования к объему оперативной памяти (программы на этом языке достигают размеров до 15 Мб), с другой — хотелось бы отойти от традиционно применяемых в этой области Cи/Си++ в пользу чего-то более высокоуровневого и удобного, того что позволило бы упростить процесс реализации транслятора. В качестве одной из альтернатив Си/Си++ рассматривается Ocaml. Хотелось бы узнать насколько применение OCaml-а более оправдано в данной ситуации ? Насколько существеннен проигрыш в скорости программ реализованных на OCaml-е по сравнению с Си/Си++ ? Насколько повышаются требования к оперативной памяти ?

Также интересуют другие языки с декларативной составляющей, которые подойдут для данной задачи

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

C>Стоит задача разработки лексического, синтаксического и семантического анализаторов ( aka frontend, aka транслятор переднего плана) определенного языка c достаточно сложными языковыми конструкциями. По сложности реализации рассматриваемый язык сопоставимы с языком Си++.

C>Возник вопрос о выборе языка программирования на котором будет реализовано программное средство. С одной стороны критичным для данного транслятора является скорость разбора исходный текстов и требования к объему оперативной памяти (программы на этом языке достигают размеров до 15 Мб), с другой — хотелось бы отойти от традиционно применяемых в этой области Cи/Си++ в пользу чего-то более высокоуровневого и удобного, того что позволило бы упростить процесс реализации транслятора. В качестве одной из альтернатив Си/Си++ рассматривается Ocaml. Хотелось бы узнать насколько применение OCaml-а более оправдано в данной ситуации ? Насколько существеннен проигрыш в скорости программ реализованных на OCaml-е по сравнению с Си/Си++ ? Насколько повышаются требования к оперативной памяти ?

C>Также интересуют другие языки с декларативной составляющей, которые подойдут для данной задачи

Я писал на SML что-то похожее для тоже достаточно сложного языка. Могу сказать, что писать, безусловно, гораздо приятнее и быстрее за счет поддержки сложных типов данных и строгой проверки типов, но про скорость работы ничего сказать не могу, поскольку SML — интерпретатор.
Здесь есть какие-то фронт-энды для С http://www.npc.de/ocaml/linkdb/frames.html Можно посмотреть и сравнить.

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

C>Хотелось бы узнать насколько применение OCaml-а более оправдано в данной ситуации ?
OCaml является диалектом языка ML, который изначально предназначался для данного класса задач. Применение более чем оправдано — OCaml со своим препроцессором идеально подходит для вашей задачи.

C>Насколько существеннен проигрыш в скорости программ реализованных на OCaml-е по сравнению с Си/Си++ ?
Одна из основных целей разработки компилятора OCaml являлось не уступить в скорости современным компиляторам С++ и Fortran. Компилятор хорош, и генерирует очень эффективный код.

C>Насколько повышаются требования к оперативной памяти?
Насколько мне известно — результирующая программа сравнима с аналогичной на С++ как по требуемой памяти так и по скорости выполнения. Впрочем, скоро ответят спецы по OCaml.

C>Также интересуют другие языки с декларативной составляющей, которые подойдут для данной задачи
Пожалуй, OCaml подойдет лучше всего остального по совокупности параметров.

Why ML/OCaml are good for writing compilers

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

C>Также интересуют другие языки с декларативной составляющей, которые подойдут для данной задачи

К другим языкам можно отнести разве что Лисп и его диалекты. На них тоже очень удобно писать компиляторы, иногда даже удобнее, чем на ML-подобных языках. Но они динамически типизируемые и, следовательно, менее эффективны и больше подвержены ошибкам.

Кстати, если надумаете использовать OCaml старайтесь использовать разрушительные присваивания как можно меньше, особенно в узлах деревьев. Если вы будете использовать структуры (не рекомендую), они быстро попадут во второе поколение GC и присваивания будут порождать лишний код и ссылки на первое поколение, что сильно понизит эффективность GC.

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

Q>Кстати, если надумаете использовать OCaml старайтесь использовать разрушительные присваивания как можно меньше, особенно в узлах деревьев. Если вы будете использовать структуры (не рекомендую), они быстро попадут во второе поколение GC и присваивания будут порождать лишний код и ссылки на первое поколение, что сильно понизит эффективность GC.

Интересно. Не могли бы вы поделится источником(ами) информации по этому вопросу ?

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

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

Q>>Кстати, если надумаете использовать OCaml старайтесь использовать разрушительные присваивания как можно меньше, особенно в узлах деревьев. Если вы будете использовать структуры (не рекомендую), они быстро попадут во второе поколение GC и присваивания будут порождать лишний код и ссылки на первое поколение, что сильно понизит эффективность GC.

C>Интересно. Не могли бы вы поделится источником(ами) информации по этому вопросу ?

Да, собственно, это логические выводы исходя из устройства OCaml GC + пара статей по GC. GC с поколениями вынуждены вести списки ссылок из старших поколений в младшие, а присваивание в ФЯ — это единственный способ такую ссылку создать. Ну и на практике заметно, что присваивания тормозят. Что касается узлов деревьев, то при С-шном подходе время жизни у них будет большим и они попадут во второе поколение, а их элементы при присваиваниях все время будут новыми объектами => таблица ссылок на первое поколение будет переполняться значительно быстрее, чем будет исчерпана память в первом поколении => GC будет вызываться неоправданно часто и 2-е поколение будет сильно загрязняться короткоживущими объектами.

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

Q>Да, собственно, это логические выводы исходя из устройства OCaml GC + пара статей по GC. GC с поколениями вынуждены вести списки ссылок из старших поколений в младшие, а присваивание в ФЯ — это единственный способ такую ссылку создать.

Кстати, какой GC посоветуешь для строго функционального языка?

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

M>Кстати, какой GC посоветуешь для строго функционального языка?

Собственно, у OCaml очень неплохой GC. Состоит из двух частей — minor & major. minor для каждого треда свой и работает по алгоритму копирования (т.е. копирует все, что не мусор, в major). major — работает по алгоритму mark&sweep. В строго функциональном языке могут быть сделаны упрощения за счет того, что ссылки между объектами всегда однонаправленны, так сказать. В этом случае можно, видимо, обойтись одним поколением с копированием, но за счет известной структуры связей, копирование можно производить без привлечения дополнительного куска памяти, чем страдают такого рода алгоритмы.

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

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

M>>Кстати, какой GC посоветуешь для строго функционального языка?

Q> minor для каждого треда свой и работает по алгоритму копирования (т.е. копирует все, что не мусор, в major).
Насколько я помню, такая схема называется stop-and-copy. Подобный коллектор применяется в Erlang на уровне процесса (stop&copy, 2 поколения). Таким образом получается, что в ocaml на первом поколении работает stop-and-copy а на втором — mark&sweep. Комбиниронанная схема.

Q>major — работает по алгоритму mark&sweep. В строго функциональном языке могут быть сделаны упрощения за счет того, что ссылки между объектами всегда однонаправленны, так сказать.
Это не совсем так. В "ленивых" чисто функциональных языках возможны кольцевые ссылки на данных — это штатная ситуация.

Q>В этом случае можно, видимо, обойтись одним поколением с копированием, но за счет известной структуры связей, копирование можно производить без привлечения дополнительного куска памяти, чем страдают такого рода алгоритмы.
Может быть.

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

C>Также интересуют другие языки с декларативной составляющей, которые подойдут для данной задачи

Чесно говоря, я сильно сомневаюсь что любой ФЯ может что-то противопоставить хорошему коммерческому построителю парсеров, особенно использующих алгоритмы вроде GLR.

Что до сложности языка, то С++ архи-сложен для разбора в слудствии кучи неоднозначностей и зависимости от конекста. Ручной их обход задача не для слабонервных. Но почему-то мне кажется, что ты приувеличивашь сложность своего языка. Ты бы хоть привел примен выражения на этом языке и объяснил бы чем же он так сложен.

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

G>Это не совсем так. В "ленивых" чисто функциональных языках возможны кольцевые ссылки на данных — это штатная ситуация.

Кольцевые ссылки для ЖЦ не проблема. Или умрут все объекты из кольца, или будут жить если на кольцо есть ссылки.

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

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

C>>Также интересуют другие языки с декларативной составляющей, которые подойдут для данной задачи

VD>Чесно говоря, я сильно сомневаюсь что любой ФЯ может что-то противопоставить хорошему коммерческому построителю парсеров, особенно использующих алгоритмы вроде GLR.

Причем тут построитель парсеров? Парсер — это вообще незначительная часть на фоне остальных в компиляторе.

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

Q>Причем тут построитель парсеров? Парсер — это вообще незначительная часть на фоне остальных в компиляторе.

Случаи-то разные бывают... Просто парсер — единственная нетривиальная И обязательная часть компилятора.

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

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

Q>>Причем тут построитель парсеров? Парсер — это вообще незначительная часть на фоне остальных в компиляторе.

M>Случаи-то разные бывают... Просто парсер — единственная нетривиальная И обязательная часть компилятора.

Никак не могу согласится. Парсер как раз достаточно тривиальная часть, даже с учетом исправления шероховатостей граматики. Про него все известно заранее — что делать, как делать.

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

M>>Случаи-то разные бывают... Просто парсер — единственная нетривиальная И обязательная часть компилятора.

Q>Никак не могу согласится. Парсер как раз достаточно тривиальная часть, даже с учетом исправления шероховатостей граматики. Про него все известно заранее — что делать, как делать.

Sigh.. ОК. Скажем так. Парсер — единственная обязательная часть компилятора.

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

Q>Причем тут построитель парсеров?

Да, как бы при том. Это первая встающая задача. В С++ парсер как раз самая сложная часть. И если язык действительно имеет сложность плюсов, то это просто первоочередная задача.

Q> Парсер — это вообще незначительная часть на фоне остальных в компиляторе.

Как бы то нибыло. Окамл вряд ли будет золотой пулей вне области парсинга. А в области парсинга я опять бы предпочел мощьный построитель пасреров.

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

Q>Никак не могу согласится. Парсер как раз достаточно тривиальная часть, даже с учетом исправления шероховатостей граматики. Про него все известно заранее — что делать, как делать.

Скромный вопрос. А что же на горизонте нет ни кодного С++-ного парсера удовлетворяющего стандарту?

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

Q>> Парсер — это вообще незначительная часть на фоне остальных в компиляторе.

VD>Как бы то нибыло. Окамл вряд ли будет золотой пулей вне области парсинга. А в области парсинга я опять бы предпочел мощьный построитель пасреров.

Пример мощного построителя парсера?

Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, chukichuki, Вы писали:

C>>Также интересуют другие языки с декларативной составляющей, которые подойдут для данной задачи

VD>Чесно говоря, я сильно сомневаюсь что любой ФЯ может что-то противопоставить хорошему коммерческому построителю парсеров, особенно использующих алгоритмы вроде GLR.

Тут надо разобраться. Любой frontend компилятора современного языка программирования есть лексический анализатор + синтаксический анализатор + семантический анализатор. Что понимается под генератором парсера ? Генератор лексического/синтаксического разборщика ? Если да, то возражение немного
не по адресу. Основную сложность при реализации транслятора языка будет составлять именно семантический анализатор, генерацию которого автоматизировать мягко говоря проблематично. Основная нагрузка здесь ляжет именно на программиста и необходимо подобрать ему более или менее нормальное средство разработки.

VD>Что до сложности языка, то С++ архи-сложен для разбора в слудствии кучи неоднозначностей и зависимости от конекста. Ручной их обход задача не для слабонервных.

Контексто-зависимость грамматики не самая большая проблема. Есть хуже. Например, шаблоны.

VD> Но почему-то мне кажется, что ты приувеличивашь сложность своего языка. Ты бы хоть привел примен выражения на этом языке и объяснил бы чем же он так сложен.

Эх. Не хотел я говорить. Сейчас заклюют. Реализую я некоторый, отличный от стандартного диалект C++ ( практически со всеми наворотами, включая шаблоны ). В приницпе "первый блин" уже сделан (на Си++), теперь пытаемся осмыслить то что получилось, выбрать более правильные технологические подходы для реализации второй версии.

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

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

M>>>Случаи-то разные бывают... Просто парсер — единственная нетривиальная И обязательная часть компилятора.

Q>>Никак не могу согласится. Парсер как раз достаточно тривиальная часть, даже с учетом исправления шероховатостей граматики. Про него все известно заранее — что делать, как делать.

M>Sigh.. ОК. Скажем так. Парсер — единственная обязательная часть компилятора.
Никак не могу согласиться. Парсер мало того что самая тривиальная часть современного компилятора, так еще и ни разу необязательная. Компиляторы Лисп и Forth преспокойно существуют, и не содержат парсеров. Кстати, ранние компиляторы фортрана были устроены по принципу ассемблеров, которые тоже обходятся без парсера.

Что еще осталось от вашего тезиса?

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

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

Q>>Причем тут построитель парсеров?
VD>Да, как бы при том. Это первая встающая задача. В С++ парсер как раз самая сложная часть. И если язык действительно имеет сложность плюсов, то это просто первоочередная задача.

Это, что называется, тупая сложность. Т.е. просто долго надо махать лопатой и ничего другого не сделаешь.

Q>> Парсер — это вообще незначительная часть на фоне остальных в компиляторе.
VD>Как бы то нибыло. Окамл вряд ли будет золотой пулей вне области парсинга. А в области парсинга я опять бы предпочел мощьный построитель пасреров.

OCaml к парсингу отношения не имеет. Его специализация — синтаксический анализ полученного дерева, оптимизация, символьные вычисления.

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

M>>Sigh.. ОК. Скажем так. Парсер — единственная обязательная часть компилятора.
G>Никак не могу согласиться. Парсер мало того что самая тривиальная часть современного компилятора, так еще и ни разу необязательная. Компиляторы Лисп и Forth преспокойно существуют, и не содержат парсеров. Кстати, ранние компиляторы фортрана были устроены по принципу ассемблеров, которые тоже обходятся без парсера.

Совсем без парсера нельзя. ННадо же хотя бы лексемы разбирать.

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

VD>Скромный вопрос. А что же на горизонте нет ни кодного С++-ного парсера удовлетворяющего стандарту?
Нет ни одного С++-компилятора, удовлетворяющего стандарту. Стандарта на парсеры С++ просто не существует.

Рискну предположить, что С++ как раз из-за своих неоднозначностей как раз и не укладывается в рамки модели синтаксический анализ=>семантический анализ=>...

Построить парсер по корректной грамматике, удовлетворяющей определенным ограничениям (LL(k), LALR,...), — задача давно решенная, только с С++ проблема в том, что неоднозначности синтаксиса разрешаются на семантическом уровне.

Кстати, статью "Редкая профессия", на форуме ссылки пробегали, не читали?

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

M>>Sigh.. ОК. Скажем так. Парсер — единственная обязательная часть компилятора.
G>Никак не могу согласиться. Парсер мало того что самая тривиальная часть современного компилятора, так еще и ни разу необязательная. Компиляторы Лисп и Forth преспокойно существуют, и не содержат парсеров. Кстати, ранние компиляторы фортрана были устроены по принципу ассемблеров, которые тоже обходятся без парсера.

G>Что еще осталось от вашего тезиса?

Что было, то и осталось То, что в Lisp парсер элементарный, не значит, что его там нет.

Хотя, строго говоря, определяющим свойством компилятора является не парсинг, а синтез кода. Например, компилятор может компилировать из уже рапарсенного AST.

Но тем не менее, парсинг остается "общим" местом для компиляторов. Остальные части более специфичны для конкретных языков, платформ и целей и решаются персонально.

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

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

M>>>Sigh.. ОК. Скажем так. Парсер — единственная обязательная часть компилятора.
G>>Никак не могу согласиться. Парсер мало того что самая тривиальная часть современного компилятора, так еще и ни разу необязательная. Компиляторы Лисп и Forth преспокойно существуют, и не содержат парсеров. Кстати, ранние компиляторы фортрана были устроены по принципу ассемблеров, которые тоже обходятся без парсера.

Т>Совсем без парсера нельзя. ННадо же хотя бы лексемы разбирать.
Трурль, ну что ж я, совсем без понятия штоли . Когда говорят о компиляторах, парсером обыкновенно называют синтаксический анализатор (нет грамматики — нет парсера). А лексический — он так, как бы не считается. Кстати, а форт-машине нет и лексического анализатора как выделенной части (гы!).

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

M>Пример мощного построителя парсера?

В философии пробегали. Ищи по "GLR".

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

M>>Пример мощного построителя парсера?

VD>В философии пробегали. Ищи по "GLR".

Интересный подход
Elkhound is written in C++, and can generate parsers written in either C++ or Ocaml.

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

G>Кстати, а форт-машине нет и лексического анализатора как выделенной части (гы!).

Ну как же нет. А WORD и NUMBER?

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

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

G>>Кстати, а форт-машине нет и лексического анализатора как выделенной части (гы!).

Т>Ну как же нет. А WORD и NUMBER?
Нету риально. В интерпретаторе (слово такое) сначала отделяются последовательности символов от пробела до пробела. Потом считается что это слово. А вот если оно в словаре не нашлось, интерпретатор пытается привести его к числу, и выполняет это как LIT NUMBER — делается это в последнюю очередь.

В результате ты вполне можешь определить слово с именем в виде числа. Более того, так часто и делается для 1 и 2 и других частоупотребимых констант — для скорости. Этот эксперимент наглядно демонстрирует отсутствие лексического анализатора в виде, обычном для языков с грамматикой.

Как видишь, разбор "слово"/"число" происходит в разных частях интерпретатора, и отдельной специализированной части, занимающейся этим и которая может быть названной "лексическим анализатором", действительно нет.

Вот так.

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

Ну, тогда и в си нет "отдельной специализированной части", патамушта

 # define if printf("Hello World!\n");

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

Q>Это, что называется, тупая сложность. Т.е. просто долго надо махать лопатой и ничего другого не сделаешь.

Не совсем так. Построить корректное дерево разбора для сложного языка задача не тривиальная и может занять не иодин год. Хотя "тупая сложность" тоже сложность. И ее тоже нужно уменьшать.

Q>OCaml к парсингу отношения не имеет. Его специализация — синтаксический анализ полученного дерева, оптимизация, символьные вычисления.

Тогда возможно разумным было бы использовать мощьный парсер и Окамл в качестве средств анализа и трансформации.

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

Т>Ну, тогда и в си нет "отдельной специализированной части", патамушта

 # define if printf("Hello World!\n");

Хе. А слабо в С определить макрос с именем 824? А вот с таким "+"? То-то же.

А вообще, батенька, это патамушта в Си есть дополнительная "специализированная часть" — препроцессор, которая работает до всех стадий анализа, в то время как в форте кроме примитовного лексического анализа нет ничего, да и тот не локализован, так что выделенного "анализатора" там нет.

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

M>Интересный подход



M>Elkhound is written in C++, and can generate parsers written in either C++ or Ocaml.

Ды что там будет на генерировано это уже второй вопрос. Главное, чтобы оно было сгенерировано.

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

VD>Тогда возможно разумным было бы использовать мощьный парсер и Окамл в качестве средств анализа и трансформации.

Так изначально и планировалось

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

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

VD>>Тогда возможно разумным было бы использовать мощьный парсер и Окамл в качестве средств анализа и трансформации.

C>Так изначально и планировалось

Тем не менее, разберитесь сначала со стандартным окамловым препроцессором camlp4. Его использование — это рекомендуемый для OCaml способ писать парсеры.

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

G>Тем не менее, разберитесь сначала со стандартным окамловым препроцессором camlp4. Его использование — это рекомендуемый для OCaml способ писать парсеры.

Насколько я понял он обеспечивает построение LL(k)-, а то и LL(1)-парсеров. Что для С++ явно недостаточно.

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

M>>Sigh.. ОК. Скажем так. Парсер — единственная обязательная часть компилятора.
G>Никак не могу согласиться. Парсер мало того что самая тривиальная часть современного компилятора, так еще и ни разу необязательная. Компиляторы Лисп и Forth преспокойно существуют, и не содержат парсеров. Кстати, ранние компиляторы фортрана были устроены по принципу ассемблеров, которые тоже обходятся без парсера.

G>Что еще осталось от вашего тезиса?

Все осталось. Языки без синтаксиса парсера действительно не требуею. Ну, почти. Но С++ к таким точно не отностися. Задача парсинга этого языка очень сложная. Так что эти аргументы не прокатывают.

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


C>Эх. Не хотел я говорить. Сейчас заклюют. Реализую я некоторый, отличный от стандартного диалект C++ ( практически со всеми наворотами, включая шаблоны ). В приницпе "первый блин" уже сделан (на Си++), теперь пытаемся осмыслить то что получилось, выбрать более правильные технологические подходы для реализации второй версии.

А стоит ли это все труда — если в том же OCAML есть возможность динамического разбора и подключения кода на нем же.
Может стоит подумать о такой возможности?
Не зная всеех целей я не хочу ничего говорить, но на C++ свет клином не сошелся ведь.

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

C>Стоит задача разработки лексического, синтаксического и семантического анализаторов ( aka frontend, aka транслятор переднего плана) определенного языка c достаточно сложными языковыми конструкциями. По сложности реализации рассматриваемый язык сопоставимы с языком Си++.

Сложными "языковыми" или "смысловыми"? Немножко разное.

C> В качестве одной из альтернатив Си/Си++ рассматривается Ocaml.

Хоршая альтернатива. Мы при решении подобной задачи ее рассматривали...

C> Насколько существеннен проигрыш в скорости программ реализованных на OCaml-е по сравнению с Си/Си++ ?

Думаю, что будет выигрыш — на плюсах сделать оптимальный алгоритм очень не просто...

C>Также интересуют другие языки с декларативной составляющей, которые подойдут для данной задачи

Lisp, Erlang
Мы остановились на последнем. Там кстати лексер и парсер в комплекте вполне нормальные.

Здравствуйте, Аноним, Вы писали:

А>Lisp, Erlang
А>Мы остановились на последнем. Там кстати лексер и парсер в комплекте вполне нормальные.
Остановились на Erlang для создания компилятора?! При альтернативах Lisp и OCaml?! Жжоте.

Я не ставлю под сомнение то, что вы сделали осознанный выбор. Просто он мне кажется невероятно странным, особенно на фоне названных альтернатив. Не могли бы вы объяснить, как вы пришли именно к такому варианту для данной задачи — Erlang? Почему так?

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

G>Здравствуйте, Аноним, Вы писали:

А>>Lisp, Erlang
А>>Мы остановились на последнем. Там кстати лексер и парсер в комплекте вполне нормальные.
G>Остановились на Erlang для создания компилятора?! При альтернативах Lisp и OCaml?! Жжоте.

G>Я не ставлю под сомнение то, что вы сделали осознанный выбор. Просто он мне кажется невероятно странным, особенно на фоне названных альтернатив. Не могли бы вы объяснить, как вы пришли именно к такому варианту для данной задачи — Erlang? Почему так?

Нам так было удобнее, поскольку мы сочли ErlangOPT-среду пригоной, в качестве движка ниженего уровня (прикладного сервера). То есть прикладной язык компилируется erlang-ом и _В_ erlang. "Единообразнее" получается.

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

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

G>>Здравствуйте, Аноним, Вы писали:

А>>>Lisp, Erlang
А>>>Мы остановились на последнем. Там кстати лексер и парсер в комплекте вполне нормальные.
G>>Остановились на Erlang для создания компилятора?! При альтернативах Lisp и OCaml?! Жжоте.

G>>Я не ставлю под сомнение то, что вы сделали осознанный выбор. Просто он мне кажется невероятно странным, особенно на фоне названных альтернатив. Не могли бы вы объяснить, как вы пришли именно к такому варианту для данной задачи — Erlang? Почему так?

EXO>Нам так было удобнее, поскольку мы сочли ErlangOPT-среду пригоной, в качестве движка ниженего уровня (прикладного сервера). То есть прикладной язык компилируется erlang-ом и _В_ erlang. "Единообразнее" получается.

Ах вот оно что. Понятно, спасибо.

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

EXO>Нам так было удобнее, поскольку мы сочли ErlangOPT-среду пригоной, в качестве движка ниженего уровня (прикладного сервера). То есть прикладной язык компилируется erlang-ом и _В_ erlang. "Единообразнее" получается.

Не могли бы вы рассказать в общих чертах о проекте, вашей компании, и впечатлениях от платформы?

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

G>Не могли бы вы рассказать в общих чертах о проекте, вашей компании, и впечатлениях от платформы?

Могу. Но чтобы не сочли рекламой, буду краток.

Область проектов — "Насислеия за ЖКХ" (и иже с ним в комлексе "монетизация льгот", "субсидии" и прочее).
Собственно это уже не перый проект "Контура" в этой области — внутренне условеное название "5-я версия". Предидущий ( версия 4.3 ) был на MS-технологиях... по итогам — не понравилось. "5-версия" во многом эксперимент.
Технологии перечислены здесь,
а здесь лежит пара презенташек.

По Erlang-OTP, пока еще сказать могу не очень много, но предварительно нравится. Глюков пока не обнаружено ни одного, так что с надежностью все нормально. Быстродействие и ресурсоемкость тоже порадовали, хотя здесь трудно придумать какой-либо объективный тест, поскольку это нужно рассматривать среду в целом (и язык, и сетевые протоколы, и БД, и веб-сервер). Пока могу сказать, что переведенный с MS-SQL + Delphy + VBA на Mnesia + Erlang небольшой кусочек нашей задачи ускорился раз в 8. Но это пока все предварительное.
Из сложностей — на тут пугали, что Erlang далеко не все программисты способны освоить и что все очень сложно... Для "старых" программистов это оказалось действительно так. А вот если посадить за Erlang студентов и сказать им, что дескать "простой язычек, ничего особенного", то каких либо сложностей у них и правда не возникает.
Так что похоже сие лишь стереотипы и страхи.

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

C>Стоит задача разработки лексического, синтаксического и семантического анализаторов ( aka frontend, aka транслятор переднего плана) определенного языка c достаточно сложными языковыми конструкциями. По сложности реализации рассматриваемый язык сопоставимы с языком Си++.

http://www.venge.net/graydon/talks/mkc/html/index.html

Здравствуйте, Аноним, Вы писали:

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

C>>Стоит задача разработки лексического, синтаксического и семантического анализаторов ( aka frontend, aka транслятор переднего плана) определенного языка c достаточно сложными языковыми конструкциями. По сложности реализации рассматриваемый язык сопоставимы с языком Си++.

А>http://www.venge.net/graydon/talks/mkc/html/index.html

Хорошо разжевано, спасибо.