Я отвечаю за DMS , о чем, я думаю, вы упоминаете в своем вопросе.
Когда вы пытаетесь сгенерировать код для нескольких целевых доменов, вам как-то приходитсяобъясните, как сопоставить спецификацию с отдельными целями, независимо от того, какой механизм вы используете для этого.
Сложные проблемы проявляются, когда семантический разрыв между языком спецификации отличается для каждого изцели.(Наиболее распространенные генераторы многоцелевого кода, с которыми я сталкивался, как правило, создают для выходных языков одного типа, что позволяет избежать этой проблемы).
Один из способов сделать это - написать отдельный переводчик для каждого выводаязык.Это работает за счет большой работы.Другой способ сделать это - перевести язык спецификации в промежуточный язык / представление / домен, в котором были обработаны большинство проблем перевода (например, абстрактный процедурный язык), а затем построить переводчики из промежуточного домена в отдельные цели,Это, как правило, намного проще.Если у вас есть реальное разнообразие целей, вы можете обнаружить, что некоторые цели имеют некоторые общие черты, но не с другими;в этом случае вам нужны несколько промежуточных представлений, по одному для каждого набора общностей.
Все это является ортогонолом того, как вы на самом деле выражаете этих переводчиков.Вы можете написать их как классические компиляторы;Вы будете заняты в течение длительного времени.Вы можете записать их в виде некоего типа синтаксически-ориентированного перевода из входной спецификации, записанной в виде графика («сканировать график, выкладывать текст для каждого узла»), что кажется довольно распространенным (большинство генераторов кода, «управляемых моделями», кажется,этот тип), но делать это таким образом не дает особой помощи, кроме понимания того, как делать это таким образом.
То, что мне нравится, и причина, по которой я построил DMS (а другие создали TXL и Stratego), заключается в использовании преобразований от источника к источнику , потому что таким образом вы можете записатьсопоставление вашего языка ввода с вашим языком вывода в качестве правил, которые вы можете проверить, которые по существу не зависят от основного механизма преобразования;Это большая победа, если вы собираетесь написать множество правил, что особенно часто происходит, когда вы ориентируетесь на несколько языков.Механизмы преобразования имеют еще одно важное преимущество по сравнению с генераторами кода, которые просто разбрызгивают текст: вы можете обработать вывод одного этапа транслятора, применив больше преобразований.Это означает, что вы можете оптимизировать код, вы можете создавать более простые правила (потому что вы можете использовать цепочку правил вместо одного вычисления, представляющего перекрестный продукт, который всегда большой и сложный), и вы можете выполнять перевод через несколько уровней промежуточных доменов.
Теперь, еще одна причина, по которой я построил DMS, - это четкое разделение каждого из «доменов» (входные спецификации, выходные домены, промежуточные домены).Вы (и преобразования) НИКОГДА не путаетесь с тем, что представляет собой структура.Stratgo и TXL ИМХО тут бредят;они манипулируют только «одним» представлением за раз.Если вы переводите между двумя обозначениями A и B, вы должны установить (IMHO screwball) «объединенный» домен, содержащий в себе как A, так и B.И вам нужно как-то беспокоиться, если у вас есть фрагмент синтаксиса "+" в обоих A и B, означает ли "+" "+" в домене A или "+" в домене B.Если вы не можете сказать, как вы узнаете, какие преобразования применить к нему?
Идея усовершенствования нескольких доменов и использования преобразований для этого, увы, не моя.Они были предложены Джеймсом Соседями ( * источник термина "анализ области") в 1980-х годах для его системы Draco .Но я стою на плечах гигантов.DMS наследует доменные концепции соседей и трансформационные основы.Разница в том, что DMS предназначен для масштабирования, произвольных доменов (DSL, а также текущих языков программирования; у него есть предопределенные модули языка для C ++, C #, Java, JavaScript, ...) и для проведения глубокого анализа для поддержки преобразований.