Собственно сабж. Прочитал статью про R#, показалось удобным. Но там парсер только для C#.
Хотелось бы альтернативу lex, yacc. Чтобы со сгенерированным кодом было удобно работать. Yacc неудобен тем, что на выходе мы не получаем AST как такового. А хотелось быть иметь на выходе иерархическую структуру подобную XML, как это реализовано в R#. Но универсальную. Для построения DSL, конвертеров и др.
В идеале можно было бы, дополнить GUI оберткой с шаблонами лексики и синтаксиса.
Например раздел лексики: выбираем какие лексемы нам нужны. Строки? Выбраем, какого типа строки C-подобные, C#-подобные. Учитывая префиксы.
Числа? Бесконечные числа, X-байтные целые, Вещественные? Также из шаблона. Ключевые слова забиваем в списке.
Библиотеки, утилиты, что посоветуете. Задача, собственно иметь инструмент манипулирования AST известных языков. C++,Java,C#. А также создания собственных DSL.
L>Хотелось бы альтернативу lex, yacc. Чтобы со сгенерированным кодом было удобно работать. Yacc неудобен тем, что на выходе мы не получаем AST как такового. А хотелось быть иметь на выходе иерархическую структуру подобную XML, как это реализовано в R#. Но универсальную. Для построения DSL, конвертеров и др.
Здравствуйте, licedey, Вы писали:
L>Собственно сабж. Прочитал статью про R#, показалось удобным. Но там парсер только для C#. L>Хотелось бы альтернативу lex, yacc. Чтобы со сгенерированным кодом было удобно работать. Yacc неудобен тем, что на выходе мы не получаем AST как такового. А хотелось быть иметь на выходе иерархическую структуру подобную XML, как это реализовано в R#. Но универсальную. Для построения DSL, конвертеров и др.
R# заброшен и не развивается, так как есть куда более мощная альтернатива — Nemerle.
Как правильно сказал hi_octane, в поставку Nemerle входит очень удобный макрос PegGrammar. Это построитель парсеров нового поколения основанный на PEG. Он исключительно гибок и быстр (в отличии от АНТЛР, который еще тот тормоз).
К примеру, черновой парсер C# 4.0 был создан на базе PegGrammar за 2 недели одним человеком. Еще через месяц Nemerle уже умел компилировать C#-файлы в составе своих проектов.
Кроме того сам Nemerle — это отличное средство для создания DSL-ей и метапрограммирования. Так что возможно, что парсер может и не понадобиться.
Ну, а вообще, если хочешь получить хороший ответ, то надо не скупиться на описание задачи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Нужен удобный инструмент для построения AST
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, licedey, Вы писали:
L>>Собственно сабж. Прочитал статью про R#, показалось удобным. Но там парсер только для C#. L>>Хотелось бы альтернативу lex, yacc. Чтобы со сгенерированным кодом было удобно работать. Yacc неудобен тем, что на выходе мы не получаем AST как такового. А хотелось быть иметь на выходе иерархическую структуру подобную XML, как это реализовано в R#. Но универсальную. Для построения DSL, конвертеров и др.
VD>R# заброшен и не развивается, так как есть куда более мощная альтернатива — Nemerle.
VD>Как правильно сказал hi_octane, в поставку Nemerle входит очень удобный макрос PegGrammar. Это построитель парсеров нового поколения основанный на PEG. Он исключительно гибок и быстр (в отличии от АНТЛР, который еще тот тормоз).
VD>К примеру, черновой парсер C# 4.0 был создан на базе PegGrammar за 2 недели одним человеком. Еще через месяц Nemerle уже умел компилировать C#-файлы в составе своих проектов.
VD>Кроме того сам Nemerle — это отличное средство для создания DSL-ей и метапрограммирования. Так что возможно, что парсер может и не понадобиться.
VD>Ну, а вообще, если хочешь получить хороший ответ, то надо не скупиться на описание задачи.
Спасибо за ответ. Я в основном ридонли в этом разделе, и бороды у меня нет. Посему так скупо с описанием задачи. Только в облаках витает несколько идей. Собственно первое, что мне нужно было — это инструмент для построения/манипулирования AST как иерархией. На основе этого уже можно дальше думать о генераторах кода, преобразователях.
Из планируемого, что бы хотелось реализовать:
— Генерация GUI+DB на основе объектов предметной области. Например, мы пишем plain-текст, сверху вниз:
Person
Name
Company
Post->
Name
Salary
На выходе получаем 2 таблички, и GUI в виде двух табов. Плюс кнопки Save, Refresh. Идея не нова, но обычно натыкаюсь на велосипеды. В виде XML+скриптовый язык+C#/Delphi итд. Что-то похожее добротно реализовано в MS LightSwitch
— Вторая идея. Язык описания архитектуры приложения и компонентов. На основе чего можно генерировать слабо-связанный ООП код. Что-то вроде:
layer view
{
// тут описываем компоненты предствления
}
layer service : view
{
// компоненты сервисов, связи с компонентами из view
}
layer logic : service
{
layer facade {} // фасад приложения. Передает сообщения объектам бизнесс-процессов, бизнесс-сущностей
}
layer data : logic { // компоненты доступа к данным, связанные с логикой (моделью?) }
— Задумок еще несколько. В основном задачу, сделать код максимально независимым от реализации. Точнее мета-код. А если конкретно, поглядываю в сторону создания DSL для мобильных платформ. Пусть некоторого подмножества функционала. К примеру простой GUI+работа с контактами+передача данных. Но чтобы код генерился для iOS, Andriod SDK, WinPhone.
Кстати, есть ли еще парсилки, окромя C#4 для Peg? Если нет, могу для себя сначала заняться
Re[3]: Нужен удобный инструмент для построения AST
Здравствуйте, licedey, Вы писали:
L>Спасибо за ответ. Я в основном ридонли в этом разделе, и бороды у меня нет. Посему так скупо с описанием задачи. Только в облаках витает несколько идей. Собственно первое, что мне нужно было — это инструмент для построения/манипулирования AST как иерархией. На основе этого уже можно дальше думать о генераторах кода, преобразователях.
Тут с немерле конкурировать трудно.
1)Он потомок ML, а это значит имеет варианты и сравнение с образцом что делает работу с АСТ очень простой.
2)Есть макра PegGrammar которая позволяет очень просто делать быстрые парсеры.
L>- Вторая идея. Язык описания архитектуры приложения и компонентов. На основе чего можно генерировать слабо-связанный ООП код. Что-то вроде:
Как человек, съевший на кодогенерации не одну свору собак могу со всей ответственностью сказать, что в генерируемом коде абстракции, ООП, паттерны, слабая связанность,... и прочая чушь не нужна.
Генерируемый код должен работать правильно.
И если задача требует, то должен работать быстро и по возможности не жрать лишнюю память.
Красивость ему не нужна ваще ни разу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Нужен удобный инструмент для построения AST
Здравствуйте, WolfHound, Вы писали:
L>>- Вторая идея. Язык описания архитектуры приложения и компонентов. На основе чего можно генерировать слабо-связанный ООП код. Что-то вроде: WH>Как человек, съевший на кодогенерации не одну свору собак могу со всей ответственностью сказать, что в генерируемом коде абстракции, ООП, паттерны, слабая связанность,... и прочая чушь не нужна. WH>Генерируемый код должен работать правильно. WH>И если задача требует, то должен работать быстро и по возможности не жрать лишнюю память. WH>Красивость ему не нужна ваще ни разу.
Как съевший на кодогенерации не меньше собак могу сказать, что все зависит от конкретных требований. Одному подавай лишь правильность работу, другому экономию памяти, третьему быстроту, четвертому удобочитаемость и расширяемость (ООП, абстракции, паттерны и т.п). Некоторым реально нужен красивый и удобочитаемый генеренный код. И эти некоторые отнюдь не мелкие фирмочки.
Здравствуйте, licedey, Вы писали:
L>Библиотеки, утилиты, что посоветуете. Задача, собственно иметь инструмент манипулирования AST известных языков. C++,Java,C#. А также создания собственных DSL.
Если для создания объектных моделей и т.п. + переносимость, то EMF (http://www.eclipse.org/modeling/emf/) Хотя он кой в чем и перегружен. Можно взять за идею и сделать свою вариацию.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Как съевший на кодогенерации не меньше собак могу сказать, что все зависит от конкретных требований. Одному подавай лишь правильность работу, другому экономию памяти, третьему быстроту,
Код, который работает неправильно не нужен никому и никогда.
_O_>четвертому удобочитаемость и расширяемость (ООП, абстракции, паттерны и т.п). Некоторым реально нужен красивый и удобочитаемый генеренный код.
Зачем?
_O_>И эти некоторые отнюдь не мелкие фирмочки.
Это ничего не значит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Нужен удобный инструмент для построения AST
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, _Obelisk_, Вы писали:
_O_>>четвертому удобочитаемость и расширяемость (ООП, абстракции, паттерны и т.п). Некоторым реально нужен красивый и удобочитаемый генеренный код. WH>Зачем?
Потому как его приходится дебажить, т.к. он связан с рукописным кодом тем или иным образом.
Потому как в компаниях есть некоторые стандарты на оформление кода (буржуйские военные конторы этим грешат). Переубеждать там бесполезно.
Душа обязана трудиться! (с) Н.Заболоцкий.
Re[7]: Нужен удобный инструмент для построения AST
Здравствуйте, _Obelisk_, Вы писали:
_O_>Потому как его приходится дебажить, т.к. он связан с рукописным кодом тем или иным образом.
А не лучше ли исходный код дебажить?
_O_>Потому как в компаниях есть некоторые стандарты на оформление кода (буржуйские военные конторы этим грешат). Переубеждать там бесполезно.
Ну, это махровая некомпетентность. У них там что стандарты на то как компилятор оформляет машинные коды тоже есть?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Нужен удобный инструмент для построения AST
Здравствуйте, licedey, Вы писали:
L>Собственно первое, что мне нужно было — это инструмент для построения/манипулирования AST как иерархией. На основе этого уже можно дальше думать о генераторах кода, преобразователях.
Вот сам Nemerle и есть такой инструмент. Nemerle — это язык со встроенными возможностями метапрограммирования. Не то чтобы понацея, но конкурентов в этом деле среди статически типизированных языков у него нет. А уж о дотнете и говорить не приходится.
L>Из планируемого, что бы хотелось реализовать: L>- Генерация GUI+DB на основе объектов предметной области. Например, мы пишем plain-текст, сверху вниз: L>
L>Person
L> Name
L> Company
Post->>
L> Name
L> Salary
L>
L>На выходе получаем 2 таблички, и GUI в виде двух табов. Плюс кнопки Save, Refresh.
Это называется DSL. Подход очень правильный, так как позволяет поднять уровень разработки на максимально высокий уровень.
Только, конечно, так просто задачи не решаются. Между GUI и табличками нужны промежуточные слои. Да и просто генерировать таблички нельзя, так как есть проблема версий и имеющихся данных. Представь себе что тебе скажет заказчик, если ты переделаешь свою иерархию и пара таблиц с данными просто грохнется.
L>Идея не нова, но обычно натыкаюсь на велосипеды. В виде XML+скриптовый язык+C#/Delphi итд. Что-то похожее добротно реализовано в MS LightSwitch
Ну, да. МС так борется с полноценной интеграцией метапрограммирования и DSL-естроения в свои языки, что фанатики не признающие ничего кроме как от МС вынуждены программировать в ХМЛ.
Думаю, что в течении ближайших 10-20 лет все в корне изменится. Но пока что выбор не вилик. Nemerle на сегодня вне конкуренции в этой обсласти.
Придется, конечно, потратить некоторое время на изучение Nemerle и его маросистемы, но зато потом создавать динамичные метапрограммы будет просто как никогда.
L>- Вторая идея. Язык описания архитектуры приложения и компонентов. На основе чего можно генерировать слабо-связанный ООП код.
Ну, это примерно тоже самое, только чуть хуже, так как уровень данного DSL-я ниже чем предыдущего. В прочем, один может быть базой для другого.
L>- Задумок еще несколько. В основном задачу, сделать код максимально независимым от реализации. Точнее мета-код. А если конкретно, поглядываю в сторону создания DSL для мобильных платформ. Пусть некоторого подмножества функционала. К примеру простой GUI+работа с контактами+передача данных. Но чтобы код генерился для iOS, Andriod SDK, WinPhone.
С этим посложнее. Тут нужно использовать или Яву или Моно.
L>Кстати, есть ли еще парсилки, окромя C#4 для Peg? Если нет, могу для себя сначала заняться
Немного не понял вопроса. Есть ли другие парсеры на без PegGrammar? Есть, конечно. Например, ХМЛ-литералы (макрос немрела) использует парсер расширенного ХМЛ-я. Так же есть парсер JSON-а. Есть и другие, независимые, примеры.
Для C#4 тоже парсеров хватает. АНТЛР — это конечно предложение не серьезное. Но есть парсер из ШарпДевелопа, который используется у них для рефакторинга. Есть парсер из Моно. Ну, и ряд других. Преимущество PegGrammar в том, что это исключительно мощный формализм и бизкий к мозгу программиста, в отличии от автоматных парсеров. Ну, и конечно же преимущество в том, что Nemerle позволяет очень легко превратить парсер во что-то большее (компилятор или среду анализа).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Нужен удобный инструмент для построения AST
Здравствуйте, WolfHound, Вы писали:
WH>Как человек, съевший на кодогенерации не одну свору собак могу со всей ответственностью сказать, что в генерируемом коде абстракции, ООП, паттерны, слабая связанность,... и прочая чушь не нужна.
Ты каких-то однобоких собак кушал.
Задачи бывают разными. Например, человеку может требоваться ДСЛ который можно формировать как текстовом редакторе, так и визуально. Для визуального редактора объектное представление — это то что нужно.
Кстати, иерархия вариантов тоже в некотором смысле является объектным представлением. Тот же DOM.
WH>Генерируемый код должен работать правильно. WH>И если задача требует, то должен работать быстро и по возможности не жрать лишнюю память. WH>Красивость ему не нужна ваще ни разу.
Ему не красивость не нужна, он может обойтись без некоторых абстракций, так как макра сама по себе вводит абстракцию, причем очень гибкую.
Вот с такой постановкой я бы согласился. Но "может обойтись" еще не значит "не нужна".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Нужен удобный инструмент для построения AST
Здравствуйте, _Obelisk_, Вы писали:
_O_>Как съевший на кодогенерации не меньше собак
Устроим конкурс "У кого длиннее кодогенератор?"?
_O_>могу сказать, что все зависит от конкретных требований. Одному подавай лишь правильность работу, другому экономию памяти, третьему быстроту, четвертому удобочитаемость и расширяемость (ООП, абстракции, паттерны и т.п). Некоторым реально нужен красивый и удобочитаемый генеренный код.
Согласен в целом, но на хрена нужна удобочитаемость генерируемого кода?
_O_>И эти некоторые отнюдь не мелкие фирмочки.
Это идиоты, если они требуют удобочитаемость, а не корректность, и другие качества программы. Удобочитаемость нужна только для рукописного кода. Смотреть на сгенерированный код как на рукописный — это уже ошибка.
Генерироваться вообще может MSIL или байткод явы. Какой смысл их читать?
Удобочитаемым должны быть ДСЛ-и и другой исходный код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Нужен удобный инструмент для построения AST
_O_>>четвертому удобочитаемость и расширяемость (ООП, абстракции, паттерны и т.п). Некоторым реально нужен красивый и удобочитаемый генеренный код. WH>Зачем?
как минимум, в таком случае его проще модифицировать, расширять и взаимодействовать с ним. особенно важно как оформляются точки возможных стыков
например, с одной стороны не важно как C делает передачу параметров между функциями, как оформляется vtable, как прописываются фреймы для исключений, но всё это не важно только до тех пор, пока нет задачи писать вставки на asm-е, или стыковаться с фортраном или python-ом
или другими словами, в 1-10% случаев с целью выжимания скорости, гибкости, поддержки нестандартных случаев и т.д. приходится с высокоуровневого описания спускаться на более низкоуровневое и лезть в сгенеренный код. и тут хочется, чтобы этот сгенеренный код был простым, понятным и красивым.
Re[8]: Нужен удобный инструмент для построения AST
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, _Obelisk_, Вы писали:
_O_>>Потому как его приходится дебажить, т.к. он связан с рукописным кодом тем или иным образом. WH>А не лучше ли исходный код дебажить?
Исходный код является моделью. Связки дебага генеренного кода с моделью имеются, но бывает необходимость дебажить генеренный код на уровне генеренного кода. Потом ведь модели могут содержать рукописный код либо напрямую (как часть модели), либо путем импорта и линковки с third-party lib-ами. После генерации мы получаем микс из генеренного и рукописного кода. Генератор может быть совершенен, но проблема в семантике модели, которая не выявилась на уровне анализа и симуляции самой модели (так как модель содержит рукописный код вываливающийся за формализм модели). Тогда помогает дебаг. В общем, ситуаций довольно много.
WH>Ну, это махровая некомпетентность. У них там что стандарты на то как компилятор оформляет машинные коды тоже есть?
Боюсь имеются. Не мне их судить, деньги-то они платили. А customer всегда прав. У вас правильный девиз "Делать, чтоб работало". Вот и мы им всегда руководствовались — сколь бы странны требования не были, надо сделать, чтоб работало
Душа обязана трудиться! (с) Н.Заболоцкий.
Re[6]: Нужен удобный инструмент для построения AST
Здравствуйте, VladD2, Вы писали:
VD>Это идиоты, если они требуют удобочитаемость, а не корректность, и другие качества программы. Удобочитаемость нужна только для рукописного кода. Смотреть на сгенерированный код как на рукописный — это уже ошибка.
Реальность плоха тем, что в ней идиоты не только существуют но правят бал. Но идиоты платят деньги
Но я ведь уточнил, что разные заказчики есть. Некоторым пофиг на читаемось, а вот другим нет.
Душа обязана трудиться! (с) Н.Заболоцкий.
Re[7]: Нужен удобный инструмент для построения AST
Здравствуйте, DarkGray, Вы писали:
DG>как минимум, в таком случае его проще модифицировать, расширять и взаимодействовать с ним. особенно важно как оформляются точки возможных стыков
DG>например, с одной стороны не важно как C делает передачу параметров между функциями, как оформляется vtable, как прописываются фреймы для исключений, но всё это не важно только до тех пор, пока нет задачи писать вставки на asm-е, или стыковаться с фортраном или python-ом
DG>или другими словами, в 1-10% случаев с целью выжимания скорости, гибкости, поддержки нестандартных случаев и т.д. приходится с высокоуровневого описания спускаться на более низкоуровневое и лезть в сгенеренный код. и тут хочется, чтобы этот сгенеренный код был простым, понятным и красивым.
Если код генерируется, то проблем с расширением и взаимодействием не будет по определению, так как всегда можно сгенерировать все что нужно для этого расширения и взаимодействия.
Про ассемблер вообще какая-то ахинея, так как при генерации текста асемблер и т.п. — это тоже текст, а в системах более высокого уровня ассемблер просто не применим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
L>Собственно сабж. Прочитал статью про R#, показалось удобным. Но там парсер только для C#. L>Хотелось бы альтернативу lex, yacc. Чтобы со сгенерированным кодом было удобно работать. Yacc неудобен тем, что на выходе мы не получаем AST как такового. А хотелось быть иметь на выходе иерархическую структуру подобную XML, как это реализовано в R#. Но универсальную. Для построения DSL, конвертеров и др.
L>Библиотеки, утилиты, что посоветуете. Задача, собственно иметь инструмент манипулирования AST известных языков. C++,Java,C#. А также создания собственных DSL.
