Задачка: придумать язык - Философия программирования

Навеяно топиком о Лиспе.
Итак — требуется придумать язык, заточенный под кодогенерацию (не модификацию!) на современных мейнстрим языках — Java, C#, C++. Требования (не все имеет отношение к языку, но тем не менее):
1) Декларативное описание входных данных
2) Декларативное описание структуры входных данных.
3) Возможность работы с несколькими источниками входных данных.
4) Простота и лаконичность описания основных программных конструкций целевых языков.
5) Максимально декларативная сущность описаний генераторов.
5) Простота парсинга самих описаний генераторов.
6) Возможность расширения.

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

У кого какие мысли есть?

... << RSDN@Home 1.2.0 alpha rev. 565>>

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

AVK>На природу языка — императивный, функциональный и т.п. ограничений нет.
AVK>У кого какие мысли есть?

JetBrains MPS однако

Смотреть тут: http://www.jetbrains.com/mps/

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

X>JetBrains MPS однако

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

... << RSDN@Home 1.2.0 alpha rev. 565>>

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

X>>JetBrains MPS однако

AVK>Он у вас платный наверное будет. А хотелось использовать например в янусе.

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

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

X>Ну во-первых он в такой глубокой бэте, что о чем-то вообще говорить рано, а во-вторых всегда можно поговорить про отдельную licence для некоммерческой разработки

Можно. Но оно, как я понял, еще и к идее привязано. Да и здоровое оно какое то. Можно сюда прмиерчиков и скриншотов?

... << RSDN@Home 1.2.0 alpha rev. 565>>

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

AVK>Можно. Но оно, как я понял, еще и к идее привязано.

Да

AVK> Можно сюда прмиерчиков и скриншотов?

Не так сразу. Я в этой области — как поросенок в апельсинах. Самому разбираться надо, а в предверии EAP'а РеШарпера времени нет катастрофически

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

AVK>У кого какие мысли есть?

Что тут придумывать. Бери и пиши. Для твоей задачи http://www.rsdn.ru/Forum/Message.aspx?mid=1270710&only=1
Применяем слегка измененный Erlang. Я добавил туда записи в стиле Clean, для удобства — родные recordes несколько кривоваты.

Программа выполняет генерацию кода по дереву, построенному XML-парсером.

## это будет частью библиотеки. Функция принимает дерево во внутреннем представлении и возвращает строку.
## дерево представлено набором иерархических структур. У структуры есть обязательное поле tag, которое содержит
## атом - имя функции, которая должна быть вызвана для разбора элемента (почти Лисповый фокус),
##  и (для парных тэгов) поле .childs, содержащее список вложенных элементов.
parsetree( [ H | T ] ) -> parsetree( H ) ++ parsetree( T );
parsetree( [] ) -> "";
parsetree( Node ) -> Node.tag( Node ).

#обработка тэга objects
objects( Node ) -> parsetree( Node.list ).

#тег property - будем вызывать его явно.
property( Node ) -> Node.type ++ " " ++ Node.name.

#тег object
object( { Name = .name, [ H | T ] = Props = .childs } ) ->
   "public class " ++Name++ "\n"
   "{\n\n"
   "    public " ++Name++ "(" ++ propery( H ) ++ [ ", " ++ property( p ) || p <- Props] ++ ")\n"
   "   {\n" 
++["      _" ++p.name++ " = " ++p.name++ ";\n" || p <- Props ]++
   "   }\n"
++["\n    private " ++p.type++ " _" ++p.name++ ";\n\n"
   "      public " ++p.type++ " " ++capitalize( p.Name )++ "\n"
   "      {\n"
   "         get { return _" ++p.name++ "; }\n"
   "      }\n" || p <- Props ]++
   "}\n"

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

AVK>>Можно. Но оно, как я понял, еще и к идее привязано.

X>Да

Ну так значит негодится

.

AVK>> Можно сюда прмиерчиков и скриншотов?

X>Не так сразу. Я в этой области — как поросенок в апельсинах.

Ну так я не тороплю

X> Самому разбираться надо, а в предверии EAP'а РеШарпера времени нет катастрофически

Как то он у вас подзатянулся. Обещали еще 3 недели назад.

... << RSDN@Home 1.2.0 alpha rev. 565>>

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

X>> Самому разбираться надо, а в предверии EAP'а РеШарпера времени нет катастрофически
AVK>Как то он у вас подзатянулся. Обещали еще 3 недели назад.

Угу, есть такое. Программа максимум — выпустить версию завтра. Но может и не получиться

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

AVK>>На природу языка — императивный, функциональный и т.п. ограничений нет.
AVK>>У кого какие мысли есть?

X>JetBrains MPS однако

X>Смотреть тут: http://www.jetbrains.com/mps/

Слушай, а вы не могли бы перевести все это дело на русский? Мы уже задолбались ждать от вашего начальства обещенных статей, а между тем статьи на английском присутствуют в изобили.

Подтолкни там своий. Мы же вас бесплатно отрекламируем.

... << RSDN@Home 1.2.0 alpha rev. 557>>

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

AVK>Итак — требуется придумать язык, заточенный под кодогенерацию (не модификацию!) на современных мейнстрим языках —

А я вот с удовольствием послушал бы идеи о языке для модификации.

... << RSDN@Home 1.2.0 alpha rev. 557>>

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

G>Что тут придумывать. Бери и пиши. Для твоей задачи http://www.rsdn.ru/Forum/Message.aspx?mid=1270710&only=1
G>Применяем слегка измененный Erlang. Я добавил туда записи в стиле Clean, для удобства — родные recordes несколько кривоваты.

И чем это лучше XSLT или приведенных примеров на лиспе?

... << RSDN@Home 1.2.0 alpha rev. 565>>

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

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

G>>Что тут придумывать. Бери и пиши. Для твоей задачи http://www.rsdn.ru/Forum/Message.aspx?mid=1270710&only=1
G>>Применяем слегка измененный Erlang. Я добавил туда записи в стиле Clean, для удобства — родные recordes несколько кривоваты.

AVK>И чем это лучше XSLT или приведенных примеров на лиспе?
Кажется, ты интересовался способом решить эти вопросы?

1) Декларативное описание входных данных
2) Декларативное описание структуры входных данных.
3) Возможность работы с несколькими источниками входных данных.
4) Простота и лаконичность описания основных программных конструкций целевых языков.
5) Максимально декларативная сущность описаний генераторов.
5) Простота парсинга самих описаний генераторов.
6) Возможность расширения.

А на самом деле, преимущество одно. Минимальная семантическая разница между постановкой задачи и решением. На лиспе вполне возможно приблизиться к этому варианту. На XSLT — нет, и semantic gap в случае XSLT больше.

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

AVK>И чем это лучше XSLT или приведенных примеров на лиспе?

В отличии от Лиспа я хотя бы могу понять что происходит.

Правда ХСЛТ я тоже неплохо понимаю.

... << RSDN@Home 1.2.0 alpha rev. 557>>

AVK>Можно. Но оно, как я понял, еще и к идее привязано. Да и здоровое оно какое то. Можно сюда прмиерчиков и скриншотов?
Тут Фаулер немного разбирал эту тему, у него и примерчик есть.

... << RSDN@Home 1.1.4 beta 7 rev. 467>>

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

G>А на самом деле, преимущество одно. Минимальная семантическая разница между постановкой задачи и решением. На лиспе вполне возможно приблизиться к этому варианту. На XSLT — нет, и semantic gap в случае XSLT больше.

Хотя и XSLT вполне достойно смотрится на этой задаче, надо признать. Жаль только, что он узкоспециализирован.

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

AVK>>И чем это лучше XSLT или приведенных примеров на лиспе?
G>Кажется, ты интересовался способом решить эти вопросы?

Не просто решить, а красиво решить.

G>А на самом деле, преимущество одно. Минимальная семантическая разница между постановкой задачи и решением. На лиспе вполне возможно приблизиться к этому варианту. На XSLT — нет, и semantic gap в случае XSLT больше.

А теперь то же самое и по русски.

... << RSDN@Home 1.2.0 alpha rev. 565>>

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

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

G>>А на самом деле, преимущество одно. Минимальная семантическая разница между постановкой задачи и решением. На лиспе вполне возможно приблизиться к этому варианту. На XSLT — нет, и semantic gap в случае XSLT больше.

G>Хотя и XSLT вполне достойно смотрится на этой задаче, надо признать. Жаль только, что он узкоспециализирован.

Наверное поэтому на этой задаче он и смотрится.

... << RSDN@Home 1.1.4 stable rev. 510>>

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

AVK>>Можно. Но оно, как я понял, еще и к идее привязано. Да и здоровое оно какое то. Можно сюда прмиерчиков и скриншотов?
A>Тут Фаулер немного разбирал эту тему, у него и примерчик есть.

Понятно. Это опять не то, чего я хотел. Мне не интересны инструменты создания полномасштабных DSL, мне интересно создание утилиты для решения внутрипрограммных целей путем кодогенерации.

... << RSDN@Home 1.2.0 alpha rev. 565>>

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

VD>В отличии от Лиспа я хотя бы могу понять что происходит.

VD>Правда ХСЛТ я тоже неплохо понимаю.

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

.

... << RSDN@Home 1.2.0 alpha rev. 565>>

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

G>Хотя и XSLT вполне достойно смотрится на этой задаче, надо признать. Жаль только, что он узкоспециализирован.

Блин, для моей задачи он как раз не совсем специализирован. Основная задача XSLT — генерация из XML другого XML. С текстом у него не очень. Поэтому мне интересен еще более узкоспециализированный язык, который заточен исключительно под генерацию, причем не просто текста, а программы на императивном ООП языке. У такого текста есть определенный набор особенностей (иерархическая повторяющаяся структура, наличие отступов и т.п.), поэтому наверное их можно использовать для повышения эффективности.
А как выглядит подобный код на универсальном функциональном языке я в курсе, в свое время с F# игрался.

... << RSDN@Home 1.2.0 alpha rev. 565>>

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

E>Наверное поэтому на этой задаче он и смотрится.

требуется придумать язык, заточенный под кодогенерацию

Ы?

... << RSDN@Home 1.2.0 alpha rev. 565>>

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

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

.

Ну, "это" можно легко заменить банальным реплэйсом (в стиле ASP). Типа:

   public class #Name
   {
       public #Name(#{ propery( H ) ++ [ ", " ++ property( p ) || p <- Props] } )
      {
        #{ [ }    _#{ p.name } = { p.name }; #{ || p <- Props ] }

... << RSDN@Home 1.2.0 alpha rev. 557>>

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

G>>А на самом деле, преимущество одно. Минимальная семантическая разница между постановкой задачи и решением. На лиспе вполне возможно приблизиться к этому варианту. На XSLT — нет, и semantic gap в случае XSLT больше.

AVK>А теперь то же самое и по русски.

Кода писать больше нужно.

... << RSDN@Home 1.2.0 alpha rev. 557>>

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

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

VD>>В отличии от Лиспа я хотя бы могу понять что происходит.

VD>>Правда ХСЛТ я тоже неплохо понимаю.

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

.

Согласен, я тоже об этом думал. Но это можно поправить. Проблема, собственно, в том, что первичны у нас конструкци языка и вызовы функций, в которые внедряются текстовые константы. Можно сделать наоборот — максимольно упростить конкатенацию и разработать синтаксис для внедрения операторов в текст. Мы ведь свой язык придумываем?

Вводим "хитрые кавычки" — ``. Текст между ними — воспринимается как есть, с управляющими знаками. Но. Текст внутри кавычек '' является выражением и вычисляется. Так мы боремся с мусором типа управляющих последовательностей и конкатенаций.

object( { Name = .name, [ H | T ] = Props = .childs } ) ->
``
   public class 'Name'
   {
       public 'Name'('propery( H )' '[ ", " ++ property( p ) || p <- Props]')
       {`` ++ [ ``
          _'p.name' = 'p.name';`` || p <- Props ] ++ ``
       }`` ++ [``
       
       private 'p.type' _'p.name';

       public  'p.type' 'capitalize( p.Name )'
       {
          get { return _'p.name'; }
       }`` || p <- Props ] ++``
   }``
)

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

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

G>Вводим "хитрые кавычки" — ``. Текст между ними — воспринимается как есть, с управляющими знаками. Но. Текст внутри кавычек '' является выражением и вычисляется. Так мы боремся с мусором типа управляющих последовательностей и конкатенаций.

Перемудрил. Еще проще — достаточно ввести специальную семантику для `text` внутри строк — это должно заменяться на "++text++". И все.

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

G>Согласен, я тоже об этом думал. Но это можно поправить. Проблема, собственно, в том, что первичны у нас конструкци языка и вызовы функций, в которые внедряются текстовые константы. Можно сделать наоборот — максимольно упростить конкатенацию и разработать синтаксис для внедрения операторов в текст. Мы ведь свой язык придумываем?

Именно.

G>Вводим "хитрые кавычки" — ``. Текст между ними — воспринимается как есть, с управляющими знаками. Но. Текст внутри кавычек '' является выражением и вычисляется. Так мы боремся с мусором типа управляющих последовательностей и конкатенаций.

Не, это все припарки. Хотелось бы более кардинального решения проблем.

... << RSDN@Home 1.2.0 alpha rev. 565>>

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

G>>Вводим "хитрые кавычки" — ``. Текст между ними — воспринимается как есть, с управляющими знаками. Но. Текст внутри кавычек '' является выражением и вычисляется. Так мы боремся с мусором типа управляющих последовательностей и конкатенаций.

AVK>Не, это все припарки. Хотелось бы более кардинального решения проблем.
Сомневаюсь, что сделать радикально лучше возможно в принципе. Уже и так проще некуда — в тексте осталось только самое необходимое, и все до предела декларативно. Вот тебе вариант с последними изменениями:

object( { Name = .name, [ H | T ] = Props = .childs } ) ->
"
   public class 'Name'
   {
       public 'Name'('propery( H ) ++ [", 'property( p )'" || p <- Props]')
       {'["
          _'p.name' = 'p.name';" || p <- Props]'
       }'["
       
       private 'p.type' _'p.name';

       public  'p.type' 'capitalize( p.Name )'
       {
          get { return _'p.name'; }
       }" || p <- Props]'
   }
";

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

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

G>>Хотя и XSLT вполне достойно смотрится на этой задаче, надо признать. Жаль только, что он узкоспециализирован.

AVK>Блин, для моей задачи он как раз не совсем специализирован. Основная задача XSLT — генерация из XML другого XML. С текстом у него не очень.
Хм, пример на XSLT выглядел достаточно неплохо. Что конкретно тебе не нравится в XSLT применительно к данной задаче?

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

G>Хм, пример на XSLT выглядел достаточно неплохо. Что конкретно тебе не нравится в XSLT применительно к данной задаче?

По-моему, это очевидно. Слишком громоздкий синтаксис, невозможность нормально писать код (он же разбавлен тегами) и невозможность контроля верности кода шаблонов (по тем же причинам).

... << RSDN@Home 1.2.0 alpha rev. 557>>

G>Вводим "хитрые кавычки" — ``. Текст между ними — воспринимается как есть, с управляющими знаками. Но. Текст внутри кавычек '' является выражением и вычисляется. Так мы боремся с мусором типа управляющих последовательностей и конкатенаций.

Уж не РНР ли вы придумываете?

В РНР текст внутри " вычисляется, а внутри ' отсается, как есть

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

VD>По-моему, это очевидно. Слишком громоздкий синтаксис, невозможность нормально писать код (он же разбавлен тегами) и невозможность контроля верности кода шаблонов (по тем же причинам).

Занятно. Совсем недавно ты же и доказывал, что всё это мелочи. Есть же спец-редакторы...

... << RSDN@Home 1.1.4 stable rev. 510>>

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

AVK>У кого какие мысли есть?

Может быть, заинтересует (хотя это гораздо попроще того, что вы написали)

http://www.nedbatchelder.com/code/cog/index_ru.html

... << RSDN@Home 1.1.4 stable rev. 510>>

M>http://www.nedbatchelder.com/code/cog/index_ru.html

http://www.pythonology.com/success&story=cog

Here's a concrete but slightly contrived example. The properties are described in an XML file:

<!-- Properties.xml -->
<props>
        <property name='Id' type='String' />
        <property name='RevNum' type='Integer' />
        <property name='Subject' type='String' />
        <property name='ModDate' type='Date' />
</props>

We can write a C++ file with inlined Python code:

// SchemaPropEnum.h
enum SchemaPropEnum {
        /* [[[cog
        import cog, handyxml
        for p in handyxml.xpath('Properties.xml', '//property'):
                cog.outl("Property%s," % p.name)
        ]]] */
        // [[[end]]]
};

After running this file through Cog, it looks like this:

// SchemaPropEnum.h
enum SchemaPropEnum {
        /* [[[cog
        import cog, handyxml
        for p in handyxml.xpath('Properties.xml', '//property'):
                cog.outl("Property%s," % p.name)
        ]]] */
        PropertyId,
        PropertyRevNum,
        PropertySubject,
        PropertyModDate,
        // [[[end]]]
};

... << RSDN@Home 1.1.4 stable rev. 510>>

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

AVK>Навеяно топиком о Лиспе.
AVK>Итак — требуется придумать язык, заточенный под кодогенерацию (не модификацию!) на современных мейнстрим языках — Java, C#, C++.

Возможно тебе подойдет TXL.

Это специальный язык трансформации исходных кодов.
Есть бесплатная версия, неплохая документация, много примеров.

Программа на TXL состоит из описания грамматики в близкой к BNF форме и описания правил трансформации на специальном функциональном языке с паттерн матчингом и декларативным заданием правил трансформации.

При обработке исходного текста сначала строится синтаксическое дерево по указанной грамматике (при этом происходит поиск и вывод сообщений об ошибках с указанием точного места проблемы). Далее это дерево обрабатывается в соответсвии с правилами трансформации (при этом гарантируется что измененное дерево также соответствует грамматике). По окончании возвращается новый исходник. В грамматике можно указать правила форматирования исходного кода (отступы, переносы строки). Так что в простейшем случае при пустой трансформации мы получаем валидатор соответствия грамматике + претти принтер.

Язык имеет некоторые особенности, требует определенных усилий при изучении. Например вызов функции имеет постфиксную форму вместо F(A) нужно писать A [F], а A [F] [G] [H] соответсвует H(G(F(A))).
Также есть некоторые проблемы при трансформации из одного языка в другой (из-за требования соответсвия грамматике на каждом шаге трансформации). Самый простой способ борьбы — сформировать грамматику более высокого уровня, включающую в себя сущности верхнего уровня как из целевой так и из исходной грамматик.

Язык на мой взгляд интересный и хорошо ложится на твои требования.

AVK>1) Декларативное описание входных данных
AVK>2) Декларативное описание структуры входных данных.
AVK>3) Возможность работы с несколькими источниками входных данных.
AVK>4) Простота и лаконичность описания основных программных конструкций целевых языков.
AVK>5) Максимально декларативная сущность описаний генераторов.
AVK>5) Простота парсинга самих описаний генераторов.
AVK>6) Возможность расширения.

AVK>На природу языка — императивный, функциональный и т.п. ограничений нет.

AVK>У кого какие мысли есть?

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

MK>Возможно тебе подойдет TXL.

MK> Это специальный язык трансформации исходных кодов.
MK>Есть бесплатная версия, неплохая документация, много примеров.

MK> Программа на TXL состоит из описания грамматики в близкой к BNF форме и описания правил трансформации на специальном функциональном языке с паттерн матчингом и декларативным заданием правил трансформации.

MK> При обработке исходного текста сначала строится синтаксическое дерево по указанной грамматике (при этом происходит поиск и вывод сообщений об ошибках с указанием точного места проблемы). Далее это дерево обрабатывается в соответсвии с правилами трансформации (при этом гарантируется что измененное дерево также соответствует грамматике). По окончании возвращается новый исходник. В грамматике можно указать правила форматирования исходного кода (отступы, переносы строки). Так что в простейшем случае при пустой трансформации мы получаем валидатор соответствия грамматике + претти принтер.

Здорово. Осталось описать грамматику шарпа на этой штуке. И тогда получится R#.

Но мне нужно не трансформации исходников, нужна прежде всего генерация и все эти сложности с грамматиками просто лишние.

... << RSDN@Home 1.2.0 alpha rev. 565>>

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

AVK>Здравствуйте, Mikl Kurkov, Вы писали:

MK>>Возможно тебе подойдет TXL.

MK>> Это специальный язык трансформации исходных кодов.
MK>>Есть бесплатная версия, неплохая документация, много примеров.

AVK>Здорово. Осталось описать грамматику шарпа на этой штуке. И тогда получится R#.

Но мне нужно не трансформации исходников, нужна прежде всего генерация и все эти сложности с грамматиками просто лишние.

Тебе не угодишь...

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

AVK>Здравствуйте, Mikl Kurkov, Вы писали:

MK>>Возможно тебе подойдет TXL.

MK>> Это специальный язык трансформации исходных кодов.
MK>> ...

AVK>Здорово. Осталось описать грамматику шарпа на этой штуке. И тогда получится R#.

Но мне нужно не трансформации исходников, нужна прежде всего генерация и все эти сложности с грамматиками просто лишние.

Если объединить грамматики исходного и целевого языка, то генерация станет трансформацией.

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

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

AVK>Навеяно топиком о Лиспе.
AVK>Итак — требуется придумать язык, заточенный под кодогенерацию (не модификацию!) на современных мейнстрим языках — Java, C#, C++. Требования (не все имеет отношение к языку, но тем не менее):

ИМХО, из популярных Пролог вполне подходит.

AVK>1) Декларативное описание входных данных
AVK>2) Декларативное описание структуры входных данных.

Разработай форматы входных данных вместе с кодогенератором (по мере скурпулезного уточнения требований к формату)

Попутный вопрос — исходные данные для кодогенерации хранятся в некоем репозитории? Какой к нему интерфейс?

AVK>3) Возможность работы с несколькими источниками входных данных.

В смыле — с различными форматами? Или имеются ввиду физические источники. Добавлю, что у себя в одном из проектов мы хостили Пролог-машину (их навалом), подготавливали данные извне в основной программе (ибо эту часть работы удобнее делать на "обычном" языке), а затем натравливали пролог-машину на подготовленные данные.

AVK>4) Простота и лаконичность описания основных программных конструкций целевых языков.

Довольно лаконично.

AVK>5) Максимально декларативная сущность описаний генераторов.

Почти BNF

AVK>5) Простота парсинга самих описаний генераторов.

Сам парсит по грамматике

AVK>6) Возможность расширения.

если хостишь некую пролог-машину — то практически неограниченные

Реализацию символов можно описать на внешнем языке и использовать из пролога.

----------
Я еще не смотрел имеющееся под .Net, но сдается мне, что должно быть все еще проще (мы использовали в связке с С++)

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

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

AVK>>Итак — требуется придумать язык, заточенный под кодогенерацию (не модификацию!) на современных мейнстрим языках —

VD>А я вот с удовольствием послушал бы идеи о языке для модификации.

Пролог

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

Последний вариант от Gapteron можно переписать "близко к тексту" для кодогенератора на основе ASP.Net — движка.

Это, ИМХО, немного не то (вернее — совсем не то).

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

В то время как в том же Пролог достаточно будет просто добавить очередное правило.

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

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

V>Последний вариант от Gapteron можно переписать "близко к тексту" для кодогенератора на основе ASP.Net — движка.

Да ну?

Попробуй переписать на ASP.NET вот эти три строки — на самом деле все дело в них, а не в отдельной функции, генерирующей текст для одного узла.

parsetree( [ H | T ] ) -> parsetree( H ) ++ parsetree( T );
parsetree( [] ) -> "";
parsetree( Node ) -> Node.tag( Node ).

V>Это, ИМХО, немного не то (вернее — совсем не то).

V>Я вижу основную идею в том, чтобы просто иметь правила трансформации одних структур в другие.
Любая программа на ФЯ, обрабатывающая дерево, является ни чем другим как декларативным описанием этих правил трансформации. Код я привел на измененном Erlang, который — ФЯ.

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

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

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

AVK>>>Итак — требуется придумать язык, заточенный под кодогенерацию (не модификацию!) на современных мейнстрим языках —

VD>>А я вот с удовольствием послушал бы идеи о языке для модификации.

V>Пролог

Реши на нем эту задачку.

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

V>ИМХО, из популярных Пролог вполне подходит.

Пример?

V>Разработай форматы входных данных вместе с кодогенератором (по мере скурпулезного уточнения требований к формату)

Мне не нужен один едиснтвенный формат, мне нужна возможность работать с тем форматом, который наиболее удобен в каждом конкретном случае.

V>Попутный вопрос — исходные данные для кодогенерации хранятся в некоем репозитории? Какой к нему интерфейс?

Неважно. Пусть это будет текстовый файл.

AVK>>3) Возможность работы с несколькими источниками входных данных.

V>В смыле — с различными форматами?

В смысле одновременно с несколькими источниками. Например с несколькими файлами.

... << RSDN@Home 1.2.0 alpha rev. 572>>

Вспомнил одну штуку, которую где то видел. Итак, задачка из топика про лисп.

public class SampleCodegen : Codegen
{
    [Match("/objects")]
    private void Objects(ICodegenContext context)
    {
        ApplyTemplates(context);
    }
    
    [Match("object")]
    private void Object(ICodegenContext context)
    {
        WriteLine("public class {0}", context.Select("@name"));
        WriteLine("{");
        MakeCtor(context);
        ApplyTemplates(context);
        WriteLine("}");
    }
    
    [Match("property")]
    private void Property(ICodegenContext context)
    {
        string type = context.Select("@type");
        string name = context.Select("@name");
        WriteLine(@"
    private {0} _{1};
    public {0}, {2}
    {
        get
        {
            return _{1};
        }
    }", type, name, Capitalize(name));
    }
    
    private void MakeCtor(ICodegenContext context)
    {
        Write("public {0}(", node.Name);
        bool first = true;
        foreach (ICodegenContext child in context.Select("property"))
        {
            if (!first)
            {
                Write(", ");
                first = false
            }
            Write("{0} {1}", child.Select("@type"), child.Select("@name"));
        }
    }
    
    private static void Main(string[] args)
    {
        new SampleCodegen("c:\objects.xml").Transform(Console.Out);
    }
}

... << RSDN@Home 1.2.0 alpha rev. 572>>

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

MK>Если объединить грамматики исходного и целевого языка, то генерация станет трансформацией.

MK>Кроме того не обязательно сразу расписывать полную грамматику, можно начать с упрощенной, постепенно усложняя по мере необходимости. А строгая проверка типов может сильно облегчить этот процесс. Кстати язык имеет встроенные стредства такого постепенного уточнения грамматик.

А ты им сам пользовался? Меня вот интересует их язык трасформаций. Насколько он удобен?

... << RSDN@Home 1.2.0 alpha rev. 557>>

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

AVK>Вспомнил одну штуку, которую где то видел. Итак, задачка из топика про лисп...
И? Что ты хотел этим сказать?

... << RSDN@Home 1.2.0 alpha rev. 557>>

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

> А ты им сам пользовался? Меня вот интересует их язык трасформаций.
> Насколько он удобен?

Серьезного ничего я с ним не делал. Так поигрался немного.
Правила трансформации описываются на чистом функциональном языке с паттерн матчингом. Эти правила имеют вид:

rule NByN 
  replace [number]
    1
  by
    2
end rule

Основные отличия от функций в других языках:

1. Всегда есть неявный параметр — обрабатываемый участок дерева (scope). Его тип указан сразу после replace , затем идет образец для сопоставления.

2. Возвращаемое значение должно быть того же типа что указано после replace. Это гарантирует корректность всего дерева на каждом этапе преобразования.

3. Правило всегда возвращает какое-то значение. Т.е. если сопоставление с образцом не было удачным, не происходит ошибки времени исполнения (как в большинстве ФЯ), а возвращается неизмененный участок дерева. Если же сопоставление произошло, то возращается новая структура.

4. Правило применяется не только к дереву верхнего уровня, но и осуществляет обход всей его структуры (слева-направо,сверху вниз). Это позволяет писать простые правила, каждое из которых делает свою часть работы в тех местах где нужно. Правило применяется и к результату своей работы, что в принципе может привести к зацикливанию.
Cамоприменение можно отключить, поставив сразу после replace значок $ .

Кроме правил есть еще обычные функции.

function NByN 
  replace [number]
    1
  by
    2
end function

Функции не делают полный обход дерева (как правила) но могут осуществлять поиск (для этого после replace нужно поставить *). Т.е. дерево будет обходиться до тех пор, пока не будет найден узел, подходящий под образец.
Работа программы начинается с правила или функции с именем main.

По удобству могу сказать, что язык немного отстал в развитии, не хватает возможностей которые уже давно стандартны в других языках.
Также по началу сбивает с толку работа со списками. Для их представления неявно используются S-выражения, но было бы гораздо естественнее использовать R-выражения, как в Рефале.
Тогда кроме разрешенного паттерна

  replace [repeat number]
    N [number] R [repeat number]
  by
    1 R

Можно бы было использовать и

  replace [repeat number]  
    R [repeat number] N [number]
  by 
    R 1

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

Но несмотря на все эти недочеты, для своих задач язык очень подходящий. Кода приходится писать несколько больше, но напрягаешся при этом меньше. Все части программы изолированы друг от друга и это позволяет лучше сосредотачиваться на конкретных задачах.
Например мне очень понравилось, что форматирование кода (отступы и переносы строки) задается при описании грамматики. Это позволяет совершенно не задумываться об этом при формировании выходных структур — вся работа по форматированию будет сделана автоматически при выводе результата.

Конечно, есть куча программ и библиотек, решающих те же задачи, что и TXL, но здесь они удачно объединены в один инструмент.

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

Вся документация, форум, примеры и реализации для нескольких платформ доступны с сайта www.txl.ca.

--
Mikl

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

А свои мысли по этому пводу у тебя есть? Во второй половине этого года и в следующем я хотел бы прикрутить к R#-у некий язык (или что-то иное) трасформации. И меня интересуют любые мысли по этому поводу.

... << RSDN@Home 1.2.0 alpha rev. 578>>

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

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

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

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

AVK>>>>Итак — требуется придумать язык, заточенный под кодогенерацию (не модификацию!) на современных мейнстрим языках —

VD>>>А я вот с удовольствием послушал бы идеи о языке для модификации.

V>>Пролог

G>Реши на нем эту задачку.

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

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

V>Автор позже оговорился — что входной формат не важен, и это естественно, т.к. входной формат мы разрабатываем вместе с системой.

Да я вобщем от своих слов не отказываюсь. Требования к входному формату я высказал — текстовый, декларативный, с декларативным описанием синтаксической структуры.

... << RSDN@Home 1.2.0 alpha rev. 585>>

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

AVK>Да я вобщем от своих слов не отказываюсь. Требования к входному формату я высказал — текстовый, декларативный, с декларативным описанием синтаксической структуры.

EBNF?

... << RSDN@Home 1.2.0 alpha rev. 578>>

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	14.07.05 11:58
Оценка:	3 (2)

От:	xvost	http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата:	14.07.05 12:12
Оценка:	53 (4)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	14.07.05 12:25
Оценка:

От:	xvost	http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата:	14.07.05 12:29
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	14.07.05 13:20
Оценка:

От:	Gaperton	http://gaperton.livejournal.com
Дата:	14.07.05 13:35
Оценка:	10 (1)

От:	VladD2	www.nemerle.org
Дата:	14.07.05 13:47
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	14.07.05 14:34
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	15.07.05 06:35
Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	15.07.05 06:36
Оценка:	+1 -2

	От:	Mikl Kurkov
	Дата:	15.07.05 09:00
	Оценка:	2 (1)