Какие шаблоны я мог бы использовать в коде, чтобы упростить перевод на другой язык программирования?

Ответ 1

Я использовал инструменты для построения (DMS Software Reengineering Toolkit) для манипуляции с универсальными программами (с переводом на язык, являющимся особым случаем), поскольку 1995, при поддержке сильной команды компьютерных ученых. DMS обеспечивает общий синтаксический анализ, построение АСТ, таблицы символов, анализ управления и потока данных, применение правил перевода, регенерацию исходного текста с комментариями и т.д., Все параметры которого определяются явными определениями компьютерных языков.

Объем оборудования, который вам нужен для этого, огромен (особенно если вы хотите сделать это для нескольких языков в общем виде), а затем вам понадобятся надежные парсеры для языков с ненадежными определениями (PHP отлично пример этого).

Нет ничего плохого в том, что вы думаете о создании переводчика на языке или его попытке, но я думаю, что вы найдете это гораздо более сложной задачей для реальных языков, чем вы ожидаете. У нас есть около 100 человеко-лет, вложенных в просто DMS, а еще 6-12 месяцев в каждое "надежное" определение языка (включая ту, которую мы мучительно создаем для PHP), и многое другое для неприятных языков, таких как С++. Это будет "адский опыт"; это было для нас. (Вы можете найти раздел технических документов на вышеуказанном веб-сайте, чтобы начать с того, чтобы учиться).

Люди часто пытаются создать какой-то обобщенный механизм, начиная с какой-то технологии, с которой они знакомы, что делает часть работы. (Атрибуты Python - отличный пример). Хорошая новость заключается в том, что часть работы завершена. Плохая новость заключается в том, что в машинах есть встроенные в него предположения, большинство из которых вы не обнаружите, пока не попытаетесь бороться с чем-то другим. В этот момент вы узнаете, что оборудование подключено к тому, чтобы делать то, что оно изначально делает, и действительно будет действительно противостоять вашей попытке заставить его сделать что-то еще. (Я подозреваю, что попытка получить Python AST для моделирования PHP будет очень весело).

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

Множество людей также допускают ошибку, предполагая, что если они смогут разобрать (и, возможно, получить АСТ), они на пути к чему-то сложному. Одним из трудных уроков является то, что вам нужны таблички с символами и анализ потока для хорошего анализа или преобразования программ. АСТ необходимы, но недостаточно. Вот почему книга компилятора Aho & Ullman не останавливается на главе 2. (OP имеет это право в том плане, что он планирует построить дополнительное оборудование за пределами AST). Подробнее об этой теме см. Life After Parsing.

Замечание о том, что "мне не нужен совершенный перевод", вызывает беспокойство. То, что делают слабые переводчики, составляет "легкий" 80% кода, оставляя трудным 20% делать вручную. Если приложение, которое вы намерены преобразовать, довольно мало, и вы только намерены его конвертировать один раз, тогда 20% в порядке. Если вы хотите преобразовать многие приложения (или даже те же, что и с незначительными изменениями с течением времени), это не приятно. Если вы попытаетесь преобразовать 100K SLOC, тогда 20% - это 20 000 оригинальных строк кода, которые трудно перевести, понять и изменить в контексте еще 80 000 строк переведенной программы, которые вы уже не понимаете. Это требует огромных усилий. На уровне миллионной линии это практически невозможно на практике. (Удивительно, что есть люди, которые не доверяют автоматическим инструментам и настаивают на том, чтобы перевести миллионы линейных систем вручную, что еще сложнее, и они обычно обнаруживают мучительно длительные задержки, высокие затраты и часто прямой отказ.)

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

Еще одним ключевым соображением является размер кода для перевода. Требуется много энергии для создания надежного переводчика, даже с хорошими инструментами. Хотя кажется, что сексуально и здорово создавать переводчика вместо простого ручного преобразования, для небольших базовых кодов (например, до примерно 100 тыс. SLOC в нашем опыте) экономика просто не оправдывает это. Никто не любит этот ответ, но если вам действительно нужно перевести только 10K SLOC кода, вам, вероятно, лучше просто кусать пулю и делать это. И да, это больно.

Я считаю, что наши инструменты очень хороши (но тогда я довольно предвзятый). И еще очень сложно построить хорошего переводчика; это занимает около 1,5-2 человеко-лет, и мы знаем, как использовать наши инструменты. Разница в том, что с помощью этого большого механизма мы добились успеха значительно чаще, чем мы терпим неудачу.

Ответ 2

В моем ответе будет рассмотрена конкретная задача синтаксического анализа Python, чтобы перевести его на другой язык, а не на аспекты более высокого уровня, которые Ира хорошо ответила в своем ответе.

Короче: не использовать модуль синтаксического анализа, есть более простой способ.

Модуль ast, доступный, поскольку Python 2.6 намного более подходит для ваших нужд, поскольку он дает вам готовый АСТ для работы. В прошлом году я написал статью в этом, но, короче говоря, используйте метод parse ast для анализа исходного кода Python в АСТ. Модуль parser даст вам дерево разбора, а не AST. Остерегайтесь разницы.

Теперь, поскольку Атрибуты Python достаточно подробны, учитывая AST, внешняя работа не является ужасно трудной. Я полагаю, что вы можете иметь простой прототип для некоторых частей функциональности, готовых довольно быстро. Однако для получения полного решения потребуется больше времени, главным образом потому, что семантика языков различна. Простое подмножество языка (функции, базовые типы и т.д.) Можно легко перевести, но как только вы зайдете в более сложные слои, вам понадобится тяжелая техника для эмуляции одного языкового ядра в другом. Например, рассмотрим генераторы Python и списки, которые не существуют в PHP (к моим лучшим знаниям, которые, по общему признанию, являются слабыми при использовании PHP).

Чтобы дать вам один последний отзыв, рассмотрите инструмент 2to3, созданный разработчиками Python для перевода кода Python 2 на код Python 3. Во-первых, у него есть большинство элементов, которые нужно перевести на Python. Однако, поскольку ядра Python 2 и 3 аналогичны, там не требуется эмуляционное оборудование.

Ответ 3

Написание переводчика не является невозможным, особенно учитывая, что Joel Intern сделал это в течение лета.

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

Например:

word = 'This is not a word'
print word[::-2]

требуется много кода на С++ для дублирования (хорошо, вы можете сделать это довольно коротко с некоторыми конструкциями цикла, но все же).

Что-то в стороне, я думаю.

Вы когда-нибудь писали токенизатор/парсер на основе грамматики языка? Вероятно, вам захочется узнать, как это сделать, если вы этого не сделали, потому что основная часть этого проекта. То, что я хотел бы сделать, это создать базовый синтаксис Turing - нечто довольно похожее на Python bytecode. Затем вы создаете лексер/парсер, который принимает грамматику языка (возможно, используя BNF) и на основе грамматики компилирует язык на ваш промежуточный язык, Тогда то, что вы хотите сделать, это сделать наоборот - создать парсер с вашего языка на целевые языки на основе грамматики.

Наиболее очевидной проблемой, которую я вижу, является то, что сначала вы, вероятно, создадите ужасно неэффективный код, особенно на более мощных * языках, таких как Python.

Но если вы сделаете это так, то вы, вероятно, сможете найти способы оптимизации вывода по мере продвижения. Подводя итог:

• прочитанная грамматика
• компилировать программу в промежуточный (но также полный) Tutorial
• компилировать промежуточную программу на конечный язык (на основе предоставленной грамматики)
• ...
• Profit! (?)

* мощным я имею в виду, что это занимает 4 строки:

myinput = raw_input("Enter something: ")
print myinput.replace('a', 'A')
print sum(ord(c) for c in myinput)
print myinput[::-1]

Покажите мне другой язык, который может сделать что-то подобное в 4 строках, и я покажу вам язык, столь же мощный, как Python.

Ответ 4

Есть несколько ответов, в которых вам не нужно беспокоиться. Ну, как это полезно? Ты хочешь учиться? Ты можешь выучить. Это компиляция. Так получилось, что ваш целевой язык не является машинным кодом, а другим языком высокого уровня. Это делается все время.

Там относительно простой способ начать работу. Сначала перейдите http://sourceforge.net/projects/lime-php/ (если вы хотите работать на PHP) или некоторые из них, и пройдите код примера. Затем вы можете написать лексический анализатор, используя последовательность регулярных выражений и токенов подачи для создаваемого парсера. Ваши семантические действия могут либо выводить код непосредственно на другом языке, либо создавать некоторую структуру данных (думаю, объекты, человек), которые вы можете массировать и перемещаться для генерации выходного кода.

Вам повезло с PHP и Python, потому что во многом они являются одним и тем же языком, как и другие, но с различным синтаксисом. Жесткая часть преодолевает семантические различия между форматами грамматики и структурами данных. Например, у Python есть списки и словари, тогда как PHP имеет только массивы-члены.

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

О, и поскольку у вас нет статических типов в Python, лучше всего писать и полагаться на функции PHP, такие как "python_add", который добавляет числа, строки или объекты в соответствии с тем, как это делает Python.

Очевидно, что это может стать намного больше, если вы позволите.

Ответ 5

Я буду второй точкой зрения @EliBendersky относительно использования ast.parse вместо парсера (о котором я раньше не знал). Я также рекомендую вам пересмотреть свой блог. Я использовал ast.parse для создания Python- > JavaScript-переводчика (@https://bitbucket.org/amirouche/pythonium). Я придумал дизайн Pythonium несколько, рассмотрев другие реализации и попробовав их самостоятельно. Я разветкил Pythonium из https://github.com/PythonJS/PythonJS, который я также начал, на самом деле это полная переписывание. Общий дизайн вдохновлен PyPy и http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-89-1.pdf.

Все, что я пробовал, от начала до наилучшего решения, даже если это похоже на маркетинг Pythonium, на самом деле это не так (не стесняйтесь сказать мне, если что-то не кажется правильным для сетевого этикета):

• Реализация семантики Python в обычном старом JavaScript с использованием наследования прототипов: AFAIK невозможно реализовать многократное наследование Python с использованием объектной системы прототипа JS. Я попытался сделать это, используя другие трюки позже (см. Getattribute). Насколько я знаю, в JavaScript нет реализации множественного наследования Python, лучшее, что существует, это Single inhertance + mixins, и я не уверен, что они справляются с наложением алмазов. Вид похож на Skulpt, но без google clojure.

• Я пробовал с Google clojure, как и Skulpt (компилятор), вместо того, чтобы фактически читать код Skulpt #fail. В любом случае из-за объектной системы на основе прототипа JS все еще невозможно. Создание привязки было очень сложным, вам нужно написать JavaScript и много шаблонов (см. https://github.com/skulpt/skulpt/issues/50, где я - призрак), В то время не было четкого способа интеграции привязки в систему сборки. Я думаю, что Skulpt - это библиотека, и вам просто нужно включить ваши .py файлы в html, который должен быть выполнен, и не требуется фаза компиляции, которую должен выполнить разработчик.

• Пробовал pyjaco (компилятор), но создавал привязки (вызывая код Javascript из кода Python), было очень сложно, было создано слишком много шаблонов, чтобы создавать каждый раз. Теперь я думаю, что пияко - это тот, который ближе к Pythonium. pyjaco написан на Python (ast.parse тоже), но много написано на JavaScript и использует прототипное наследование.

Мне никогда не удалось запустить Pajamas #fail и никогда не пытались снова прочитать код #fail. Но, на мой взгляд, в пижаме делались API- > API tranlation (или framework для фреймворка), а не Python для перевода JavaScript. Структура JavaScript использует данные, которые уже находятся на странице или данные с сервера. Код Python - только "сантехника". После этого я обнаружил, что пижама - настоящий переводчик python- > js.

Тем не менее, я думаю, что возможно сделать API- > API (или фреймворк- > фреймворк) и что в основном то, что я делаю в Pythonium, но на более низком уровне. Вероятно, пижама использует тот же алгоритм, что и Pythonium...

Затем я обнаружил, что brython полностью написан в Javascript, таком как Skulpt, нет необходимости в компиляции и много пуха... но написан на JavaScript.

Начиная с начальной строки, написанной в ходе этого проекта, я знал о PyPy, даже бэкэнде JavaScript для PyPy. Да, вы можете, если найдете его, напрямую сгенерировать интерпретатор Python в JavaScript из PyPy. Люди говорят, что это была катастрофа. Я не читал, почему. Но я думаю, что причина в том, что промежуточный язык, который они используют для реализации интерпретатора, RPython, является подмножеством Python, предназначенным для перевода на C (и, возможно, asm). Ира Бакстер говорит, что вы всегда делаете предположения, когда вы что-то строите, и, возможно, вы точно настроите ее, чтобы быть лучшим в том, что она должна была делать в случае перевода PyPy: Python- > C. Эти предположения могут быть неактуальными в другом контексте, хуже того, что они могут вызывать накладные расходы, в противном случае прямой перевод, скорее всего, всегда будет лучше.

Наличие интерпретатора, написанного на Python, звучало как (очень) хорошая идея. Но меня больше интересовал компилятор по соображениям производительности, и на самом деле проще скомпилировать Python для JavaScript, чем интерпретировать его.

Я начал PythonJS с идеи собрать подмножество Python, которое я мог бы легко перевести на JavaScript. Сначала я даже не потрудился внедрить систему OO из-за прошлого опыта. Подмножество Python, которое я достиг, чтобы перевести на JavaScript:

• с полными параметрами, семантическими как в определении, так и при вызове. Это та часть, которой я больше всего горжусь.
• в то время как/если/Элиф/другое
• Типы Python были преобразованы в типы JavaScript (нет типов python любого типа)
• for может выполнять итерацию только по массивам Javascript (для массива)
• Прозрачный доступ к JavaScript: если вы пишете Array в коде Python, он будет переведен в Array в javascript. Это самое большое достижение в плане удобства использования над конкурентами.
• Вы можете передать функцию, определенную в источнике Python, в функции javascript. Аргументы по умолчанию будут учтены.
• Он добавляет специальную функцию new, которая переводится на новый JavaScript: например, новый (Python) (1, 2, спам, "яйцо" ) переводится на "новый Python (1, 2, спам," яйцо ").
• "var" автоматически обрабатывается переводчиком. (очень хороший вывод от Бретта (вкладчик PythonJS).
• глобальное ключевое слово
• закрытие
• лямбды
• список понятий
• импорт поддерживается через requirejs
• наследование одного класса + mixin через classyjs

Это кажется очень много, но на самом деле очень узким по сравнению с полной размытой семантикой Python. Это действительно JavaScript с синтаксисом Python.

Сгенерированный JS совершенен, т.е. нет накладных расходов, он не может быть улучшен с точки зрения производительности путем дальнейшего его редактирования. Если вы можете улучшить сгенерированный код, вы можете сделать это и из исходного файла Python. Кроме того, компилятор не полагался на какие-либо трюки JS, которые вы можете найти в .js, написанные http://superherojs.com/, поэтому он очень читаем.

Прямым потомком этой части PythonJS является режим Pythonium Veloce. Полную реализацию можно найти @https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pythonium/veloce/veloce.py?at=master 793 SLOC + около 100 SLOC общего кода с другим переводчиком.

Адаптированная версия pystones.py может быть переведена в режиме Veloce cf. https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pystone/?at=master

После настройки базового перевода Python- > JavaScript я выбрал другой путь для перевода полного Python на JavaScript. Способ glib, делающий объектно-ориентированный код на основе класса, за исключением целевого языка, - это JS, поэтому у вас есть доступ к массивам, объектам, подобным карте, и многим другим трюкам, и вся эта часть была написана на Python. IIRC отсутствует код javascript, написанный переводчиком Pythonium. Получение одиночного наследования не представляет трудностей в том, что Pythonium полностью совместим с Python:

• spam.egg в Python всегда переводится на getattribute(spam, "egg") Я не рассматривал это в частности, но я думаю, что там, где он потерял много времени, и я не уверен, что смогу улучшить его с помощью asm.js или чего-нибудь еще иначе.
• порядок разрешения порядка: даже с алгоритмом, написанным на Python, перевод его на совместимый с Python Veloce код был большим делом.
• getattributre: фактический алгоритм разрешения getattribute является довольно сложным и он по-прежнему не поддерживает дескрипторы данных
• класс метакласса: я знаю, где подключить код, но все же...
• last bu не менее: some_callable (...) всегда транслируется на "call (some_callable)". AFAIK переводчик не использует вывод вообще, поэтому каждый раз, когда вы делаете вызов, вам нужно проверить, какой именно объект он должен назвать, как он должен был называться.

Эта часть учитывается в https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pythonium/compliant/runtime.py?at=master Она написана на Python, совместимом с Python Veloce.

Фактически совместимый переводчик https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pythonium/compliant/compliant.py?at=master не генерирует JavaScript-код напрямую и, самое главное, не делает трансформацию ast- > ast. Я попробовал ast- > ast и ast, даже если лучше, чем cst, не очень приятно работать даже с ast.NodeTransformer и, что более важно, мне не нужно делать ast- > ast.

Выполнение python ast для python ast в моем случае, по крайней мере, может быть улучшением производительности, поскольку я когда-нибудь проверяю содержимое блока перед созданием связанного с ним кода, например:

• var/global: чтобы иметь возможность var что-то, я должен знать, что мне нужно, а не var. Вместо того, чтобы генерировать отслеживание блока, какая переменная создается в данном блоке и вставляя его поверх сгенерированного функционального блока, я просто ищу назначение перераспределения переменных при входе в блок до фактического посещения дочернего элемента node для генерации связанного кода.
• yield, генераторы пока еще имеют специальный синтаксис в JS, поэтому мне нужно знать, какая функция Python является генератором, когда я хочу написать "var my_generator = function"

Поэтому я не посещаю каждый node один раз для каждой фазы перевода.

Общий процесс можно описать как:

Python source code -> Python ast -> Python source code compatible with Veloce mode -> Python ast -> JavaScript source code

Встроенные Python написаны в коде Python (!), IIRC существует несколько ограничений, связанных с типами bootstraping, но у вас есть доступ ко всему, что может перевести Pythonium в совместимый режим. Посмотрите https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pythonium/compliant/builtins/?at=master

Чтение JS-кода, сгенерированного из совместимого с pythonium, можно понять, но исходные карты очень помогут.

Ценный совет, который я могу дать вам в свете этого опыта, - добрые старые пучки:

• широко рассматривать предмет как в литературе, так и в существующих проектах с закрытым исходным кодом или бесплатно. Когда я рассмотрел различные существующие проекты, я должен был дать ему больше времени и мотивации.
• задавайте вопросы! Если бы я заранее знал, что бэкэнд PyPy бесполезен из-за накладных расходов из-за семантического несоответствия C/Javascript. Возможно, у меня была идея идеи Pythonium до 6 месяцев назад, возможно, 3 года назад.
• знать, что вы хотите сделать, иметь цель. Для этого проекта у меня были разные цели: немного оценить javascript, узнать больше о Python и уметь писать код Python, который будет запускаться в браузере (подробнее и ниже).
• Ошибка - это опыт.
• небольшой шаг - это шаг
• начать с малого
• сон большой
• делать демонстрации
• итерация

Только в режиме Python Veloce я очень счастлив! Но по пути я обнаружил, что то, что я действительно искал, освобождает меня и других от Javascript, но более важно, чтобы создать в удобном виде. Это привело меня к схемам, DSL, моделям и, в конечном счете, к конкретным объектам (см. http://dsmforum.org/).

О том, что ответ Ира Бакстера:

Оценки вообще не помогают. Я взял у меня более или менее 6 месяцев свободного времени для PythonJS и Pythonium. Поэтому я могу ожидать большего от полного времени 6 месяцев. Я думаю, мы все знаем, что 100 человеко-года в контексте предприятия могут означать и не означать вообще...

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

Если это не представляется невозможным, это оставляет место для воображения:

• найти доказательство, доказывающее невозможность

и

• Если это невозможно, может быть проблема "хуже", которая может иметь решение.

или

• если это не невозможно, найти решение

Это не просто оптимистическое мышление. Когда я начал Python- > Javascript, все говорили, что это невозможно. PyPy невозможно. Метаклассы слишком сложны. и т.д. Я думаю, что единственная революция, которая приносит PyPy над бумагой Scheme- > C (которая составляет 25 лет), - это некоторая автоматическая генерация JIT (основанные на подсказках, написанные интерпретатором RPython, я думаю).

Большинство людей, которые говорят, что вещь "трудная" или "невозможная", не приводят причин. С++ сложно разобрать? Я знаю, что они все еще являются (свободным) парсером С++. Зло в деталях? Я знаю это. Сказать, что это невозможно в одиночку, не помогает, это даже хуже, чем "не полезно", это обескураживает, а некоторые люди препятствуют другим. Я слышал об этом вопросе через https://stackoverflow.com/questions/22621164/how-to-automatically-generate-a-parser-code-to-code-translator-from-a-corpus.

Что для вас было бы совершенным ? Это то, как вы определяете следующую цель и, возможно, достигаете общей цели.

Мне больше интересно узнать, какие шаблоны я мог бы применить на код, чтобы упростить перевод (т.е.: IoC, SOA?) код чем делать перевод.

Я не вижу шаблонов, которые нельзя перевести с одного языка на другой, по крайней мере, менее совершенным способом. Поскольку языковой перевод возможен, вам лучше ориентироваться на этом. Поскольку, я думаю, согласно http://en.wikipedia.org/wiki/Graph_isomorphism_problem, перевод между двумя компьютерными языками является изоморфизмом дерева или DAG. Даже если мы уже знаем, что они оба завершены, так что...

Framework- > Framework, который я лучше визуализирую как API- > API-перевод, может все же быть тем, что вы можете иметь в виду как способ улучшить сгенерированный код. Например: Prolog как очень специфический синтаксис, но все же вы можете делать Prolog как вычисление, описывая один и тот же граф в Python... Если бы я должен был реализовать Prolog для Python-переводчика, я бы не реализовал унификацию в Python, а в библиотеке C и пришел с синтаксисом Python, который очень читается для Pythonist. В конце концов, синтаксис - это только "живопись", для которой мы даем смысл (вот почему я начал схему). Зло в деталях языка, и я не говорю о синтаксисе. Концепции, которые используются в языке getattribute (вы можете жить без него), но требуемые функции VM, такие как оптимизация хвостовой рекурсии, могут быть трудными для решения. Вас не волнует, если исходная программа не использует хвостовую рекурсию, и даже если на целевом языке нет рекурсии хвоста, вы можете эмулировать ее с помощью greenlets/loop событий.

Для целевых и исходных языков найдите:

• Большие и конкретные идеи
• Крошечные и общие общие идеи

Из этого выйдет:

• Вещи, которые легко перевести
• Вещи, которые трудно перевести

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

Существует также вопрос о stdlib или любой библиотеке, но нет четкого ответа, это зависит от ваших целей.

Идиоматический код или считываемый сгенерированный код также имеют решения...

Ориентация на платформу, подобную PHP, намного проще, чем таргетинг на браузеры, поскольку вы можете обеспечить C-реализацию медленного и/или критического пути.

Учитывая, что вы первый проект переводите Python на PHP, по крайней мере для подмножества PHP3, о котором я знаю, настройка veloce.py - ваш лучший выбор. Если вы можете реализовать veloce.py для PHP, то, вероятно, вы сможете запустить совместимый режим... Также, если вы можете перевести PHP на подмножество PHP, которое вы можете сгенерировать с помощью php_veloce.py, это означает, что вы можете перевести PHP на подмножество Python, которое может использовать veloce.py, что означало бы, что вы можете перевести PHP на Javascript. Просто говорю...

Вы также можете посмотреть эти библиотеки:

• https://bitbucket.org/logilab/astroid
• https://bitbucket.org/logilab/pylint-brain

Также вам может быть интересно это сообщение в блоге (и комментарии): https://www.rfk.id.au/blog/entry/pypy-js-poc-jit/

• Этот Google Tech Talk от Иры Бакстер интересен https://www.youtube.com/watch?v=C-_dw9iEzhA

Ответ 6

Вы можете взглянуть на Vala compiler, который переводит Vala (С# -подобный язык) в C.