トランスコンパイラ
コンパイラの一つ ウィキペディアから
トランスコンパイラ（他にトランスパイラ、ソース・トゥ・ソースコンパイラ、などとも）は、あるプログラミング言語で書かれたプログラムのソースコードを入力として受け取り、別のプログラミング言語の同等のコードを目的コードとして生成する、ある種のコンパイラである。一般に、コンパイラが「比較すると高水準な言語のソースコード」を入力とし、「比較すると低水準な言語の目的コード」を、コンパイル結果として出力するものであったのに対し、トランスコンパイラは同じ程度の（抽象化の）水準のコードをコンパイル結果として出力する。
 | この項目「トランスコンパイラ」は翻訳されたばかりのものです。不自然あるいは曖昧な表現などが含まれる可能性があり、このままでは読みづらいかもしれません。（原文：英語版 "Source-to-source compiler" (02:48, 20 October 2016 UTC)） 修正、加筆に協力し、現在の表現をより自然な表現にして下さる方を求めています。ノートページや履歴も参照してください。（2016年10月） |
 |
それらの処理系における具体的なコンパイルの処理、すなわち、入力から出力への変換において実際に行われることは、それぞれの処理系によってさまざまである。字句のレキシカルな変換やsyntactic sugar（糖衣構文）の展開といったような程度の場合もあれば、高度なコンパイラ最適化を施して機械語をコード生成するような、通常のコンパイラと全く同様の処理をおこなっているものもある。
たとえば、PascalのコードをCのコードへと変換するといったものや、「自動並列化コンパイラ」のように、見た目としては逐次的なfor文などで書かれいているコードを、OpenMPのような並列化メタデータやFortranのforall文のような言語構造に変換する[1]、といったものがある。
トランスコンパイルの別の目的は、基本的なプログラミング言語の次期バージョンを使う場合や、APIの後方互換性が壊れた場合などに、レガシーなコードから変換することである。プログラムの実行環境が変わる場合(例えば、Python 2からPython 3に変換する場合や古いAPIから新しいAPIに変換する場合)や、コンパイルによりプログラムのサイズが極端に大きくなったり実行速度が遅くなったりした場合はリファクタリングを行う。
トランスコンパイラは、元のソースコードの開発やデバッグを簡単に行うことができるよう、元のコードをコメントなどに残す（ことができる）ものもある。また、元のコードから変換した際に構文が大幅に変わった場合は、同等のコードには見えないようなコードに変換されることもある[2]。元のコードから変換されたソースコードにマッピングを行うデバッグツールもある。
トランスコンパイラを主たる実装として開発されている言語の例としてはClosure Compiler, Coccinelle, CoffeeScript, Dart, Haxe, TypeScript[3], Emscripten[4]がある。
歴史
ここでは1980年前後以降の例を示す。
1981年にゲイリー・キルドールによって書かれたデジタルリサーチのXLT86がある。それはIntel 8080用の.ASMソースコードからIntel 8086用の.A86ソースコードに変換した。8080のレジスターを用いた全体的なデータフロー解析を用い、出力されるコードサイズを最適化し、CP/M-80とMP/M-80のプログラムが自動的にCP/M-86とMP/M-86に移行できるよう呼び出しを処理した。XLT86自体はPL/I-80でかかれ、CP/M-80環境のみならず、DEC VMS (for VAX 11/750 or 11/780)でも動くようになっていた[5]。
似たような、しかしもっと洗練されていないプログラムは1980年に86-DOSの一部としてティム・パターソンによって書かれたTRANS.COMがある。それは、いくつかのZ80アセンブラのソースコードを8086用の.ASMソースコードに変換した。しかし、これは制御コード、レジスタ、モードのサブセットのみをサポートしており、かなりの手動変換や手直しを必要とした。それはレジスタやジャンプの最適化を行わなかった[6][7]。
言語実装
要約
視点
いくつかの言語実装は当初トランスコンパイラとして開発され、それらの言語実装の中には2016年現在もトランスコンパイラのものもある。以下の表に加え、CoffeeScriptのメンテナがJavaScriptに変換できる言語の一覧を提供している[8]。
コード変換
開発者が、既存コードの大部分を別の言語に変換する場合、すべてを手動変換するよりもトランスコンパイラを使用するほうがよい場合が多い。「機械的」に変換が可能なのであれば、手動変換するのは単に手数を掛けるだけ無駄なばかりではなく、手作業にはミスがつきものだからである。一方で機械的な変換が不可能な場合もまたあり、ソース言語と目的の言語の組み合わせや、実際のコード次第でもあるがケースバイケースであって、一般論としては何も決定的なことは言えない。
| ツール | 変換元言語 | 変換先言語 | 備考 |
|---|---|---|---|
| 2to3 script | Python 2 | Python 3 | 2to3は自動変換プロセスはきわめて優れているが、それでも手動変換が必要となる場合はある。 |
| Emscripten | LLVMバイトコード | ECMAScript | これはC/C++バイトコードをブラウザ等で実行することを可能にする |
| Google Web Toolkit | 特別なAPIを用いたJava | JavaScript | このJavaコードを普通のJavaコードと同等とみなすことは難しい |
| OcsigenのJs_of_ocaml[22] | OCaml | JavaScript | |
| J2Eif[23] | Java | Eiffel | 変換時、Javaに類似したクラスと構造を持つEiffelの構文や慣習を解決する。 |
| C2Eif[24] | C | Eiffel | 変換時、可能な限りクラスと構造をきれいにしようとする。このツールは完璧であり、適切に処理できないCの組み込み関数やアセンブルを除去する。 |
| Swiftify[25] | Objective-C | Swift | Swiftifyはオンラインのコード変換ツールで、主にiOSコードベースの一部または全体の移行を支援する。 |
関連リンク
- C to HDL
- 言語相互運用性
- バイナリ・リコンパイラ
- コード生成
- プログラム変換
- ROSE (コンパイラ)
- パーサジェネレータ
- 言語バインディング
- Monkey (プログラミング言語)
- 中間言語
- 再帰的トランスコンパイル
- Extensible Markup Language (XML)・XSL Transformations (XSLT)
脚注
Wikiwand - on
Seamless Wikipedia browsing. On steroids.