Здравствуйте, Gaperton, Вы писали:
G>Хотя и XSLT вполне достойно смотрится на этой задаче, надо признать. Жаль только, что он узкоспециализирован.
Блин, для моей задачи он как раз не совсем специализирован. Основная задача XSLT — генерация из XML другого XML. С текстом у него не очень. Поэтому мне интересен еще более узкоспециализированный язык, который заточен исключительно под генерацию, причем не просто текста, а программы на императивном ООП языке. У такого текста есть определенный набор особенностей (иерархическая повторяющаяся структура, наличие отступов и т.п.), поэтому наверное их можно использовать для повышения эффективности.
А как выглядит подобный код на универсальном функциональном языке я в курсе, в свое время с F# игрался.
Здравствуйте, 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>Вводим "хитрые кавычки" — ``. Текст между ними — воспринимается как есть, с управляющими знаками. Но. Текст внутри кавычек '' является выражением и вычисляется. Так мы боремся с мусором типа управляющих последовательностей и конкатенаций.
Не, это все припарки. Хотелось бы более кардинального решения проблем.
Здравствуйте, 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>По-моему, это очевидно. Слишком громоздкий синтаксис, невозможность нормально писать код (он же разбавлен тегами) и невозможность контроля верности кода шаблонов (по тем же причинам).
Занятно. Совсем недавно ты же и доказывал, что всё это мелочи. Есть же спец-редакторы...
Здравствуйте, AndrewVK, Вы писали:
AVK>Навеяно топиком о Лиспе. AVK>Итак — требуется придумать язык, заточенный под кодогенерацию (не модификацию!) на современных мейнстрим языках — Java, C#, C++.
Это специальный язык трансформации исходных кодов.
Есть бесплатная версия, неплохая документация, много примеров.
Программа на 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#. Но мне нужно не трансформации исходников, нужна прежде всего генерация и все эти сложности с грамматиками просто лишние.
Здравствуйте, 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>А я вот с удовольствием послушал бы идеи о языке для модификации.
.
