Есть направление Lang2Lang - конвертация одного ЯП в другой. Понятно,

что конвертацию невозможно сделать полностью корректной из-за различного синтаксиса, семантики, фичей, инфраструктуры, API у разных языков. Даже для таких похожих как C# и Java. А есть ли направление по преобразованию какого-то упрощенного универсального представления в конкретный ЯП, пусть и с ограниченным количеством фич? Какие-нибудь есть библиотеки для этого? Есть движки шаблонов (в частности, https://github.com/antlr/stringtemplate4), но они работают на текстовом представлении, что имеет свои недостатки - невозможность настройки форматирования, дублирование логики в шаблонах. А что насчет обработки непосредственно деревьев?

Кажется фейсбук уже делал подобную работу. Я тока забыл ее название. И там даже вполне себе результаты были, если мы говорим про транспиляцию кода

Сразу предупреждаю, что написанное ниже — просто то, что [неизвестные мне люди] пишут в интернетах. > Понятно, что конвертацию невозможно сделать полностью корректной Так вот есть те, которые утверждают, что им это непонятно. ;) К примеру, http://www.semanticdesigns.com/Products/Services/NorthropGrummanB2.html Цитируя оттуда (выделения мои): "the automated OFP conversion achieved 100% accurate translation, including replacement of all JOVIAL programming and data declaration constructs and calls on the legacy operating system. The SD translation tool converts the entire OFP application in a few CPU hours with no manual interaction of any kind.". И один из авторов — Ira Baxter (как на этом сайте, так и на stack overflow и т.п.) вообще любит [самоуверенно] давать понять, что решения, которые достигают, например, всего лишь 95% автоматической конвертации — просто "игрушки". ;) С другой стороны, лично мне (по примерам кода) кажется, что результаты их автоматической трансляции похожи на "Настоящий Программист может программировать на Фортране на любом языке программирования!".

> Мне кажется, это немного разные задачи Я прокомментировал одну из посылок автора сообщения. > Понятно, что можно написать 100% корректную трансляцию А вот автору сообщения кажется (казалось) иначе, нет ("Понятно, что конвертацию невозможно сделать полностью корректной из-за различного синтаксиса, семантики, фичей, инфраструктуры, API у разных языков. Даже для таких похожих как C# и Java.")? > Но вот когда мы обобщаем задачу до N-to-M трансляции То, опять-таки (имея в виду " компиляторы именно этим и занимаются") эта задача "теоретически" сводится к "N:1, 1:M", как в compiler collections, нет (и на сайте по ссылке как раз и продают решения для подобного, между прочим)? > сложность стремительно возрастает, а точность — падает Тем не менее, этим [более-менее успешно] занимаются, если я правильно понимаю (но, видимо, немногие — вот тут, например, некоторые пытаются собирать информацию об этом: http://www.program-transformation.org/ ).

> То, опять-таки (имея в виду " компиляторы именно этим и занимаются") эта задача "теоретически" сводится к "N:1, 1:M", как в compiler collections, нет (и на сайте по ссылке как раз и продают решения для подобного, между прочим)? Так на практике при этом сложность стремительно растёт, а точность падает. Или у GCC с LLVM не осталось открытых багов в трекерах? 😉 Не говоря даже о том, что оказалось невозможно написать удовлетворительный LLVM backend к GHC. Да что там, даже Rust регулярно вскрывает баги в LLVM.

Ну так "Optimizing compilers are so difficult to get right that we dare say that no optimizing compiler is completely error-free!" © Т.е. "открытые баги" есть [почти] везде, и их количество, скорее, говорит об интенсивности разработки и использования программы. Или Вы имеете в виду, что есть доказательства того, что сам подход compiler collections [намного] более сложный и менее точный?

Я не редставляю, что Вы признаёте "доказательством" при подходе > "открытые баги" есть [почти] везде, и их количество, скорее, говорит об интенсивности разработки и использования программы 😊

Эээ... а что Вас не устраивает в этом утверждении (сложность разработки [любых практических] компиляторов в нём подразумевалась, т.к. речь шла о них)? А так — например, то, что для достижения того же результата в подходе "N:1, 1:M" требуется [намного] больше усилий, и/или дефектов в трансляторе при этом получается (непропорционально) больше.

А какие проблемы у GHC с llvm? Ocaml'овский llvm проект тоже заморожен по какой-то причине.

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

Спасибо.

Ну так llvm под сишку заточен, я папир видел где его прямо си-бекэндом называли.

Насколько я понял из обсуждений - основные проблемы с GC и с доп. стеком в GHC. Цитируя lpw25: "The problem is that you cannot have GC roots in registers across points where the GC might run." То есть, если я правильно понимаю, везде, где МОЖЕТ запускаться GC, нужно "выплёвывать" (kak eto po-russky? выгружать?) по крайней мере часть переменных в стек.