Мета-программирование: запись на одном языке X, кросс-компиляция на нескольких языках, таких как С#, PHP, Java, C

Ответ 1

Haxe - это своего рода метаязык, который компилируется для разных платформ:

• JavaScript
• С++
• С#
• HashLink
• Java
• Lua
• PHP
• Python 3
• NekoVM
• Вспышка
• ActionScript 3

Ответ 2

Поскольку нет ни одного языка, который компилируется непосредственно ко всем вашим целям, не упускайте из виду самый низкий общий знаменатель. Вы можете создать свой плагин с помощью C, а затем обернуть результат для каждой платформы (PInvoke, JNI, расширение PHP). Если вам не нравится идея создания сложного подключаемого модуля на C, подумайте о том, чтобы сделать тяжелую работу с помощью небольшого, простого в использовании и встраиваемого языка сценариев. Lua кажется разумным. Конечным результатом будет C-скелет, который просто делегирует запросы и ответы на хост и скрипты и из них.

Трансформация программы связана, хотя усилия по созданию эффективной трансформации значительны. Теоретически вы можете перейти от источника к источнику и использовать компилятор, специфичный для платформы. Взгляните на TXL и Stratego/XT на получить представление о том, что связано.

Ответ 3

Я парень, ответственный за DMS, о чем я думаю, что вы ссылаетесь на свой вопрос.

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

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

Один из способов сделать это - написать отдельный переводчик для каждого языка вывода. Это работает, ценой большой работы. Другой способ сделать это - перевести язык спецификации в промежуточную область langauge/presentation/domain, в которой были обработаны большинство проблем с переводом (например, абстрактный процедурный язык), а затем построить переводчиков из промежуточного домена в отдельные цели, Это, как правило, намного проще. Если у вас есть целый ряд целей, вы можете обнаружить, что некоторые цели имеют некоторые общие черты, но не с другими; в этом случае вам нужно несколько промежуточных представлений, по одному для каждого набора общности.

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

Как мне нравится, и причина, по которой я построил DMS (и другие, построил TXL и Stratego), заключается в использовании преобразований из источника в источник, потому что таким образом вы можете записать отображение с вашего языка ввода на ваш язык вывода в качестве правил, которые вы можете проверить, которые по существу не зависят от базовых механизмов преобразования; это большая победа, если вы собираетесь написать, по сути, множество правил, что особенно часто происходит при ориентации на несколько языков. Трансформационные двигатели имеют еще одно важное преимущество над генераторами кода, которые просто выплескивают текст: вы можете обрабатывать выходные данные одного этапа транслятора, применяя больше преобразований. Это означает, что вы можете оптимизировать код, вы можете создавать более простые правила (потому что вы можете использовать цепочку правил вместо одного вычисления, которое представляет собой кросспродукт, который всегда большой и волосатый), и вы можете переводить через несколько уровней промежуточных доменов.

Теперь, другая причина, по которой я построил DMS так, как я сделал, заставляет четко разделять каждую из "доменов" (входную спецификацию, выходные домены, промежуточные домены). Вы (и трансформации) НИКОГДА не путаетесь относительно того, что представляет структура. Здесь Stratgo и TXL IMHO; они только манипулируют "одним" представлением во времени. Если вы переводите между двумя обозначениями A и B, вам необходимо создать ( "IMHO" ) "союзный" домен, в котором есть как A, так и B. И вам нужно как-то волноваться, если у вас есть синтаксис "+" в и B, означает ли "+" "+" в домене A или "+" в домене B. Если вы не можете сказать, как вы узнаете, какие преобразования применимы к нему?

Идея переделки между несколькими доменами и использование преобразований для этого, увы, не мои. Они были предложены Джеймсом Соседом (источником термина "анализ домена" ) еще в 1980-х годах, для его системы Драко. Но я встаю на плечи гигантов. DMS наследует концепции домена соседей и трансформационные основы. Разница заключается в том, что DMS предназначен для масштабирования, произвольных доменов (DSL, а также текущих языковых программ программирования, имеет предопределенные модули langauge для С++, С#, Java, JavaScript,...) и проводит глубокие анализы для поддержки преобразований.

Ответ 4

fantom компилируется в java и .net clr
Я не использовал его, просто увидел, что он появился в списке рассылки в прошлом месяце.

Ответ 5

Я был просто в проекте, который использовал метаязык, который был скомпилирован как в Java, так и в C. Он использовал синтаксис, подобный Java, и моделировал функциональность класса в C (а часть C была очень сильно зависит от макросов, Преобразовать "часть кода).

Это было ужасно. Получив эту кучу, чтобы сохранить, мы просто разделили ее на две кодовые базы и пошли оттуда. Я знаю, что у первоначальной компании были замечательные люди, но это слишком сложно сделать (особенно потому, что они собирались на встроенные платформы).