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

BZ>а по-моему, RULES — это частный случай макросов, нацеленный на решение одной конкретной задачи. кстати, TH для оптимизации кода тоже использовали. при этом с одной стороны возможности RULES очень ограничены, с другой — их писать гораздо-гораздо проще, чем аналогичное решение с помощью TH. универсальность против удобства использования.

Может быть, но это уже философский спор о терминах

L>>>Чувствую придётся всё таки мне переписать Parsec на ByteString и написать какой нибудь простой лексер.

BZ>>если не ошибаюсь, это один из GSOC проектов этого года

L>Э-э-э, а там какие-то сложности?
L>Вместо CharParser написать свой (+ все комбинаторы над ним, разумеется), для этого State для GenParser сделать либо независимым от списка токенов, т.е. с возможностью использования любой коллекции, ну или сам State сделать классом, а не типом.

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

L>Кстати, уже что нибудь есть в этом проекте? Есть где почитать?

ой, это надо искать. лучше спроси в кафе/irc

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

L>Эх, ну, давай У вас ещё был JSON. Там писать совсем ничего, да и у вас он уже, насколько я помню, написан.
L>Кстати, спросить хотел. konsoletyper'а парсер пишется в отдельном файле? Это не встроенный в Немерле язык или что? Можно о его организации чуть чуть — это что то вроде изменения лиспового ридера?

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

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

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

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

То, что я видел было только во внешнем файле .bnf кажется, отсюда и вопрос. Насчёт json-а ты не ответил — это пример совсем маленький если тебя интересует запись в Parsec -- могу нарисовать.

2konsoletyper (если читаешь) — а как у тебя DSEL выглядет в коде немерле? можно пример?

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

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

L>То, что я видел было только во внешнем файле .bnf кажется, отсюда и вопрос. Насчёт json-а ты не ответил — это пример совсем маленький если тебя интересует запись в Parsec -- могу нарисовать.

Откровенно говоря я не знаю что такое json. Но наверно пойдет.

L>2konsoletyper (если читаешь) — а как у тебя DSEL выглядет в коде немерле? можно пример?

Грамматика была в виде глобального метаатрибута. Что-то типа:

[assembly: BNF(lexer
  {
      Поперли := описывать | правила;
        ...
    })]
[assembly: BNF(parser
  {
      Поперли := описывать | правила;
        ...
    })]

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

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

BZ>просто операции +, * и т.д. создают в памяти структуру, описывающую вычисляемое выражание, а собственно вычисление происходит по спец. команде. в точности то же, что делают lazy языки на уровне самой реализации

А насколко это универсальное решение?

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

VD>>Хм. Это не ДСЛ-и. Это ты реализовывал вполне себе стандарный и универсальный скриптовый язык.

BZ>а что, DSL как-то по другому устроены?

Ага. Иначе бы они вообще нужны не были бы. Любой GPL (язык общего назначения) можно было бы счиать DSL-ем.

Основное достоинство DSL-я заключается в том, что он описывает только очень узкий, а стало быть конкретный аспект решаемой проблемы. Например, грмматику языка программирования. Или форматирование строки. Или, там, высокоуровневую мат.натацию работы с матрицами. Изучение DSL-я отличается не сложнее чем изучение новой библиотеки. А изучение GPL-я — это задача очень непростая.

К тому же GPL-и слишком гибки и их ползователи сталкиваются с проблемой самовредительства. DSL-и же на против сужают рамки допуастимого и тем самым уберегают пользователей от ошибок.

BZ>>просто операции +, * и т.д. создают в памяти структуру, описывающую вычисляемое выражание, а собственно вычисление происходит по спец. команде. в точности то же, что делают lazy языки на уровне самой реализации

VD>А насколко это универсальное решение?

уточни вопрос

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

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

VD>>>Хм. Это не ДСЛ-и. Это ты реализовывал вполне себе стандарный и универсальный скриптовый язык.

BZ>>а что, DSL как-то по другому устроены?

VD>Ага. Иначе бы они вообще нужны не были бы. Любой GPL (язык общего назначения) можно было бы счиать DSL-ем.

VD>Основное достоинство DSL-я заключается в том, что он описывает только очень узкий, а стало быть конкретный аспект решаемой проблемы. Например, грмматику языка программирования. Или форматирование строки. Или, там, высокоуровневую мат.натацию работы с матрицами. Изучение DSL-я отличается не сложнее чем изучение новой библиотеки. А изучение GPL-я — это задача очень непростая.

VD>К тому же GPL-и слишком гибки и их ползователи сталкиваются с проблемой самовредительства. DSL-и же на против сужают рамки допуастимого и тем самым уберегают пользователей от ошибок.

вопрос был в том, почему опыт в реализации "стандарный и универсальный скриптовый язык" делает ошибочными утверждения относящиеся к DSL. кроме того, по-моему, DSL вовсе не обязан быть узким языком. скажем, Lua используемый в игре для скриптования ботов — вполне себе пример DSL. имхо их отличает только то, что реализация языка является только частью общей решаемой задачи, тогда как для колмпилятора это единственная решаемая задача. с этой точки зрения компилятор delphi, встроенный в среду разработки — это тоже DSL

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

VD>Откровенно говоря я не знаю что такое json. Но наверно пойдет.

Да лёгкая замена xml-ю. JavaScript Object Notation

Там, кстати, есть решение на Хаскеле, только что то низкоуровневое. Лексер то могли и наворовать.
Сейчас попробую нарисовать.

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

L>>2konsoletyper (если читаешь) — а как у тебя DSEL выглядет в коде немерле? можно пример?

VD>Грамматика была в виде глобального метаатрибута. Что-то типа:

Прикольное решение. А в виде чего тогда приходит на макрос BNF параметр после lexer/parser внутри фигурных скобок?
Строка? Или уже разобранное лексером от Немерле? Если второе, то разобранное в каком виде? Идентификатор/символ? Можно ли там использовать внешние функции? Можно ли правила использовать снаружи? (последние два вопроса — это насколько правила first-order).

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

Не понял, как он ловит ambiguity?

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

L>>Так в том то и дело, что макросы не надо эмулировать, если язык позволяет обойтись без них.

K>Дык, а чем, скажем, шаблоны C++ хуже макросов? Я так понимаю,

K>

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

K>направлен не на макросы, а на метапрограмиирование вообще? Типа, любое добавление фичи в язык приводит к неподдерживаемому коду. А чем же в этом смысле монады, тьюринг-полные типы и шаблоны лучше?

Even worse. Шаблоны и тьюринг-полные типы в том смысле совершенно так же плохи, как и макросы — даже хуже — они удаляют те же гланды, но через задний проход. Лучше уж честные макросы.

Немного лучше чем макросы и тьюринг-полные типы более гражданские "макросоподобные" языковые свойства — такие как функции высокого порядка и перегруженные операторы. Монады там, то, се. Но ими лучше не увлекаться, и применть мотивировано — а то можно запросто исходный текст зашифровать до нечитабельности. Меру короче надо знать. И зная это меру, для "макросоподобных" свойств все еще находится повседневное применение, а вот для собственно макросов — нет. Все применения редкие и экзотические.

Короче, макросы и раные там навороченные шаблоны конечно крутая штука для шифрования исходного кода и чесания левой пяткой за правым ухом, только на практике не нужная. Думаете, почему в большинстве современных языков нет макросов? В 70-х годах вот были популярны развитые макросистемы. Сейчас — нет, потому что нафиг не нужны. Рынок, так сказать, голосует.

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

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

G>>Я воспользуюсь flex, или любой подобной тулзой. По ним хотя-бы документация есть, и мой код все поймут, а в велисипеде на макросах еще рабираться надо будет стороннему программеру. Недостатка в генераторах лексеров и парсеров нет ни для какого языка. Буквально для любого языка есть выбор.

VD>Ты бы попробовал, а потом обсудили бы. А то как-то не смешно. Я вот попробовал и готов потратить время на изучение, чтобы не испытывать тех проблем, что есть с тулзами вроде flex-а.

Я пробовал. И могу сказать, что реальная необходимость писать сложные лексеры-парсеры до такой степени редка в моей работе, что я не буду выбирать язык по критерию чтобы он круто позволял такие задачи решать. Это глупость. Я лучше в том редком случае, когда надо что-то сложное разобрать, воспользуюсь flex/byson или подобными.

А вот если я провожу масштабные исследования в области языков и компиляторов, то тогда да. Тогда я воспользуюсь каким-нибудь OCaml — он позволяет клево с языковыми расширениями играться, в том числе и на чужой, не окамловкой грамматике. Это свойство мне существенно съекономит время. Тем более, что есть замечательная книга — Compilers Construction with ML с примерами, которую можно почитать и новичкам потом дать.

Только я в своей работе не провожу исследований в области языков и компиляторов. Поэтому я в крайней и редкой ситуации — когда припрет — воспользуюсь flex и bison. Чем офигенно обрадую тех людей, кто будет потом разбираться в моем коде — они его поймут.

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

VD>Откровенно говоря я не знаю что такое json. Но наверно пойдет.

Так! Парсер написал. Думал дольше времени уйдёт, наверное, рука набита

Если у тебя есть установленный Haskell, то это сообщение можешь просто скопировать в файл, обозвать его, дав ему расширение lhs, и запустить. В этом файле весь код идёт после '>'.
Он ожидает один аргумент с командной строки -- имя файла, который будет парситься. Твою задачу -- подсчитать кол-во токенов -- я немного изменил, чтобы можно было показать как парситься структура (а то можно было просто накапливать счётчик да и всё).

Сейчас задание такое -- подсчитать кол-во значений в иерархии.

Вроде всё, остальные замечания дальше.

Итак, нам потребуются кое какие библиотеки, например, сам Parsec.

> import Control.Monad (liftM)
> import Data.Char (isControl)
> import System.Environment (getArgs)
> import Text.ParserCombinators.Parsec
> import Text.ParserCombinators.Parsec.Language (emptyDef)
> import qualified Text.ParserCombinators.Parsec.Token as P

Парсить мы будем JSON-овскую структуру, которая состоит из неких значений. Значения могут быть объектом (набор пар — имя/значение), массивом (набор значений), строкой, числом, логическим значением или null.
Всё это выражено в следующем АТД.

> data JsonValue = JObject [(String, JsonValue)]
> | JArray [JsonValue]
> | JString String
> | JNumber Double
> | JBool Bool
> | JNull

Программа, как уже говорилось, берёт единственный аргумент из командной строки -- имя файла -- и парсит его.
Никакой обработки ошибок по кол-ву аргументов я не писал.

> main = do
> [fname] <- getArgs
> parseJson fname

Шаблонная для таких целей функция. Читаем файл, парсим его (parseFromFile), если были ошибки -- выводим их, нет -- обрабатываем (handle) распаршенное.

> parseJson :: SourceName -> IO ()
> parseJson fname =
> do parsed <- parseFromFile jsonSource fname
> case parsed of
> Left err -> print err
> Right v -> print (handle v)

Обработка в нашем случае -- это подсчёт всех переданных значений.

> handle = countJsonValue

Собственно сам подсчёт. Ничего сложного. Все значения (даже null) имеют цену 1, массив и объект ещё добавляют к ней колво потрохов.

> countJsonValue (JObject xs) = 1 + sum (map (countJsonValue . snd) xs)
> countJsonValue (JArray xs) = 1 + sum (map countJsonValue xs)
> countJsonValue _ = 1

Та-а-а-ак. Теперь начинается интересное. Для лексера в Parsec есть удобная штука, которая называется TokenParser.
Это просто набор полезных комбинаторов. Для каждого языка он разумеется свой, но ничто не мешает нам воспользоваться чужим.
Комбинаторов этих много, некоторые, которые нам пригодятся, я описал их ниже.

Сначала создадим сам лексер, задав ключевые слова (в принципе нужды в них нет, ну да пусть будут).
Если в json есть комментарии, то их тоже можно было бы здесь задать. И ещё несколько параметров.

> lexer :: P.TokenParser ()
> lexer = P.makeTokenParser $ emptyDef
> {
> P.reservedNames = ["true", "false", "null"]
> }

А вот и сами комбинаторы. Названия в принципе говорят сами за себя.
stringLiteral я здесь закомментировал, а ниже написал свой, т.к. родной не подходит (увы) для парсинга строк именно JSON-а.
Заодно, возможно, будет интересно поглядеть, как пишут лексер. Названия комбинаторов погляди — это инструменты, с которыми мы будем работать.

> lexeme = P.lexeme lexer
> --stringLiteral = P.stringLiteral lexer
> symbol = P.symbol lexer
> float = P.float lexer
> reserved = P.reserved lexer
> brackets = P.brackets lexer
> braces = P.braces lexer
> commaSep = P.commaSep lexer

Итак, это было стандартное вступление, не особо интересное. Сейчас будем писать собственно парсер.
Смотреть, начиная отсюда Комментировать буду уж совсем непонятное.

> jsonSource = object <|> array

Объект это что то вроде:
object ::= '{' members '}' , вернуть JObject members

'{' members '}' -- это braces members
а liftM JObject возвращает нужное нам значение объекта.

> object = liftM JObject $ braces members

члены -- это разделённые запятыми пары.

> members = commaSep pair

pair, думаю, понятно — читаем строку, пропускаем ':', читаем значение, возвращаем пару.

> pair = do name <- stringLiteral
> symbol ":"
> val <- value
> return (name, val)

array аналогично object.

> array = liftM JArray $ brackets elements

elements аналогично members

> elements = commaSep value

value просто перечисляет возможные JSON-значения.
Функция choice разворачивает свои аргументы, разделяя их <|>. Тупой options, в общем.

> value = choice [object, array, jstring, jnumber, jtrue, jfalse, jnull]

jstring, jnumber -- возвращают соответствующее распаршенному значение.
Т.е. float распарсит нам d :: Double, а jnumber вернёт (JNumber d).

> jstring = liftM JString stringLiteral

> jnumber = liftM JNumber float

Для keyword-ов написал отдельную функцию, в принципе это делать было необязательно. Так для удобства.

> keyword kw ctr = reserved kw >> return ctr

> jtrue = keyword "true" (JBool True)

> jfalse = keyword "false" (JBool False)

> jnull = keyword "null" JNull

А теперь более низкий уровень. Как разбирается строка.
Сам stringLiteral — это просто лексема, у которой между кавычками куча символов:

> stringLiteral = lexeme $ between quote quote (many stringChar)
> where
> quote = char '"'

Символ -- это либо заэскейпленный символ, либо обычная буква.

> stringChar = stringEscape <|> stringLetter

Заэскейпленный символ -- читаем '\', дальше меняем букву на соответствующий символ.
См. два списка в функции. Кстати, на разбор строки на konsoletyper-овском парсере было бы интересно посмотреть.

> stringEscape = do
> char '\\'
> choice $ zipWith escaped ['\\', '/', '"', 'b', 'f', 'n', 'r', 't']
> ['\\', '/', '"', '\b', '\f', '\n', '\r', '\t']
> where
> escaped chr sym = char chr >> return sym

Буква — это не кавычка, на слеш, не управляющий символ. Юникод пропустил -- лень писать, там ещё одна-две строчки.

> stringLetter = satisfy (\c -> c /= '"' && c /= '\\' && not (isControl c))

Отличие, которое заметно сразу -- это то, что у меня структуру (АТД) Parsec не генерит в отличие от.
Насчёт first-class правил в парсере konsoletyper-а было бы интересно узнать. Они позволяют делать то, что в bnf нельзя.

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

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

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

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

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

G>>Я говорил не о замене метапрограммирования чем-то там, а о повседневной необходимости в нем. Разницу чувствуешь? Объясняю. Где-то придется для "паттерна" конечного автомата заводить макрос, чтоб красиво было. А кое-где — это совершенно обычная задача, не требующая ни выверта, ни паттерна. Смотри:

G>>switch_state( State, Message ) -> State( Message ).

G>>state1( msg1 ) -> ...;
G>>state1( msg2 ) -> ...;

G>>И все. Никаких "через жопу автогеном".

VD>Вообще-то уже через жопу и уже автогеном. Ты ведь с автоматами вручную копаться стал. Понятно, что паттерн-матчинг тут хоршее подспорье, но я бы предпочел работать с EBNF или другим ДСЛ-ем.

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

Есть масса самых разных задач, где встречается КА — например, связанных с реализацией сетевых протоколов. Так что не через жопу и не автогеном. Программеру, который под каждый случай разработки КА будет свое языковое расширение или ДСЛ писать, довольно быстро коллеги отстрелят то, что ему танцевать мешает.

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

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

G>>Мой тезис говорит о том, что макросистемы — темная сторона силы. Настоящий джедай управится и без них...

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

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

Группа джедаев судя по всему программит встроенную систему на С. Если все настолько плохо, я бы посоветовал этой группе разработать свое расширение С и написать свой макропроцессор для С. Код от этого бы только выиграл — макросистема в С полный отстой.

Или могу предложить джедаям совсем радикальный и нестандартный ход, но вот он даст вам в перспективе рывок в производительности труда. Если система работает не на пределе производительности, в качестве языка для высокоуровневого кодирования применить Форт (есть такой жутко гибкий макроязык для встраиваемых систем — по гибкости не уступает LISP, по близости к железу — ассемблеру и С). При таком подходе джедаи будут писать критичные к скорости и просто монолитные функционально законченные куски на С, а компоновать их вместе на FORTH. Живые мертвым позавидуют, реально, и производительность сильно не должна просесть.

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

VD>>Грамматика была в виде глобального метаатрибута. Что-то типа:

L>Прикольное решение. А в виде чего тогда приходит на макрос BNF параметр после lexer/parser внутри фигурных скобок?
L>Строка? Или уже разобранное лексером от Немерле? Если второе, то разобранное в каком виде? Идентификатор/символ? Можно ли там использовать внешние функции? Можно ли правила использовать снаружи? (последние два вопроса — это насколько правила first-order).

В макрос приходит лексемное дерево. Однако, т.к. версия с генерацией парсера по внешнему описанию использует свои лексер/парсер, то я, чтобы достичь унификации и снизить объём кода, сначала выравниваю лексемное дерево и направляю полученный поток лексем парсеру BNF. Внешние функции нельзя использовать, но это сделано намеренно, чтобы не смешивать грамматику и код — ИМХО, от этого одна только головная боль. Наоборот, я приложил максимум усилий к тому, чтобы можно было писать код/грамматику отдельно, и чтобы это было удобно. Собственно, вот ссылка на рабочий пример — я написал небольшой бенчмарк

Автор: konsoletyper
Дата: 01.05.07

.

К сожалению, сейчас совсем нет времени, так что макрос поддерживает только генерацию лексера. На работе завал. А вот теперь только-только от ICFP отошёл и опять на работе завал Вообще, проблема именно в нехватке времени. Никаких особых технических проблем нет. В своё время поддержку генерации лексера я сделал за пару дней. Если найдётся пара дней, сделаю поддержку парсера. Дело там нехитрое — AST уже есть готовое, надо по нему грамматику и LR-таблицы получить, а по таблицам — сгенерить класс. Последнее — 99% всего, что нужно сделать.

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

L>Не понял, как он ловит ambiguity?

Какой ambiguity?

K>К сожалению, сейчас совсем нет времени, так что макрос поддерживает только генерацию лексера. На работе завал. А вот теперь только-только от ICFP отошёл и опять на работе завал Вообще, проблема именно в нехватке времени. Никаких особых технических проблем нет. В своё время поддержку генерации лексера я сделал за пару дней. Если найдётся пара дней, сделаю поддержку парсера. Дело там нехитрое — AST уже есть готовое, надо по нему грамматику и LR-таблицы получить, а по таблицам — сгенерить класс. Последнее — 99% всего, что нужно сделать.

а чем это лучше lex/yacc?

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

BZ>а чем это лучше lex/yacc?

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

Ну, кроме этого в lex/yacc код смешивается со спецификацией, что, ИМХО, не есть хорошо. Я попытался решить эту проблему. В результате, получается действительно понятная грамматика и понятный и короткий код, в декларативном стиле.

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

G>Короче, макросы и раные там навороченные шаблоны конечно крутая штука для шифрования исходного кода и чесания левой пяткой за правым ухом, только на практике не нужная. Думаете, почему в большинстве современных языков нет макросов? В 70-х годах вот были популярны развитые макросистемы. Сейчас — нет, потому что нафиг не нужны. Рынок, так сказать, голосует.
Наверное я программы писать не умею... ибо мне постоянно попадаются задачки которые без кодогенератора не решить... вот буквально недавно написал кодогенератор который парсит ~12К кода и генерит еще ~70К (из которых примерно 44К вызовы сишных макросов те в конце концов кода получается еще больше).
Внутри есть алгоритм со сложностью O(N^4)... На данный момент N == 19 но будет рости по ходу добавления функциональности.
И делать ручками то для чего нужен алгоритм четвертой степени при малейших изменениях исходных деклараций мне мягко говоря не хочется. Особенно при том что машина это делает за доли секунды и без ошибок.