Google Closureは本当のコンパイラですか？

この質問は、このStack Overflow質問に関するコメントの議論に触発されました。Googleの閉鎖コンパイラのマニュアルは、次の（強調追加）を述べています：

Closure Compilerは、JavaScriptのダウンロードと実行を高速化するためのツールです。JavaScript用の真のコンパイラです。ソース言語からマシンコードにコンパイルする代わりに、JavaScriptからより良いJavaScriptにコンパイルします。

ただし、ウィキペディアには、「コンパイラ」の次の定義があります。

コンパイラは、プログラミング言語（ソース言語）で記述されたソースコードを別のコンピューター言語に変換するコンピュータープログラム（またはプログラムのセット）です。言語リライタは、通常、言語。

それに基づいて、私はGoogle Closureはコンパイラではないと言うでしょう。しかし、Googleがそれが実際に「本当のコンパイラ」であると明示的に述べているという事実は、それ以上のものがあるのだろうかと思うようになります。Google Closureは本当にJavaScriptコンパイラですか？

Closure Compilerは、ミニファイヤ、オプティマイザ、およびバリデータのオールインワンです。コンパイラーは、少なくとも現在の形式では実行されないものを取り、それを（ECMAScriptベースの例ではTypeScriptを使用する）ものに変換する必要があることは正しいからです。

しかし、用語を拡張したことでGoogleを非難していますか？彼らはそれを他に何と呼ぶつもりでしたか？Google Minifier？いいえ、それだけではありません。何百人もいます。Google Optimiser？それだけではありません。Google Validator？いいえ、それ以上の方法です。

だから選択は

• それをGoogle Closure Foogleと呼び、まったく新しい意味のない単語をレキシコンに導入します。
• これをGoogle Closure Minoptivalidatorと呼びます。これは意図は明確ですが、覚えにくいです。
• それをGoogle Closure Compilerと呼んでください。これは真実に非常に近いものです。

セマンティックの違いを除いて、コンパイラに期待するすべてを実行します。そして、最終的に、すべての単語はある程度、その使用法によって定義されます。したがって、Googleが人々にこれをコンパイラと呼ぶよう説得できれば、コンパイラの定義はわずかに変わります。確かに、問題を引き起こすような方法ではありません。

または、前の例に戻ると、TypeScriptについて「真のコンパイラー」と呼ばれる重要な何かを見つけることができますが、Google Closure Compilerは「ほぼコンパイラー」に制限されるべきですか？

それに基づいて、私はGoogle Closureはコンパイラではないと言うでしょう。

そうですね...しかし、ウィキペディアはこの点で権威があると仮定しています。

そして、ウィキペディアの定義へのカウンターとして、いくつかの辞書定義を検討してください（http://www.thefreedictionary.com/compilerから）：

2）（コンピューターサイエンス） -高級言語で記述された別のプログラムを機械語に翻訳して実行できるようにするプログラム。

2）（Electronics＆Computer Science / Computer Science） COBOLやFORTRANなどの高レベルプログラミング言語を、コンピューターが操作できる機械語に変換するコンピュータープログラム。

特定のプログラミング言語に関連付けられたコンピュータープログラム。これらの言語で書かれた命令を、後でコンピューターで直接実行できるマシンコードに変換します。

確かにこれらの定義は少し古いものですが、「真の意味」は存在しないことを示しています...実際、「コンパイラ」などの用語の意味は時間とともに変化します。（そして、この場合には正確な定義を実際に必要としないので、IMOはまったく問題ありません。）

Closureコンパイラが「真のコンパイラ」であるかどうかを議論することは（IMO）実りある活動ではありません。その文脈において、Googleの人々が「真のコンパイラ」とはどういう意味かを理解することは、より有益でしょう。

「本当のコンパイラ」と呼ぶことができるのは、プログラムから完全なAST（抽象セマンティックツリー）を構築し、それを使用して新しいテキストを生成するためだと思います。

元のテキストと結果のテキストの両方が有効なJavaScriptであるという事実は単なる偶然です。

これは重要です。なぜなら、コードのテキスト操作のみを行うツール（ミニファイアー、プリティファイアーなど）がありますが、ASTの処理は行わず、コードの再生成ははるかに少ないためです。これらのツールがますます強力になっても、それらは同じ種類のソフトウェアではなく、制限は異なります。

私の意見ではセマンティクスです。従来の意味では、コンパイラではありません。ただし、同じウィキペディアのリンクには、

コンパイラは、次の操作の多くまたはすべてを実行する可能性があります：字句解析、前処理、解析、セマンティック分析（構文指向翻訳）、コード生成、およびコード最適化。

クロージャーは、これらの操作の一部またはすべてを実行します。

ウィキペディアの記事を少し下に

ただし、実行時に再解釈に依存する言語を設計することは可能ですが、実際には、言語を排他的にコンパイルまたは排他的に解釈する必要がある言語についてはほとんど何もありません。

そうは言っても、「クロージャーオプティマイザー」よりも「クロージャーコンパイラー」と呼ぶ方が簡単だったと思います。実際には、ブラウザー用にJavaScriptを最適化するだけで、別の言語やバイトコードに変換する必要はありません。

名詞としてのClosure Compilerは、非sequiturです。

まず、ソースからソースへのコンパイラが存在する方法からこれを取得しましょう。最終結果が下位レベルのコードではないため、何かがコンパイラーではないと言うことはできません。

Closure CompilerがASTを生成し、コード生成フレーズを持っていることは正しいですが、多くのJavascriptミニマイザーは既にそれを行っており、おそらくコンパイラとも呼ばないでしょう。

Closure Compilerを際立たせているのは、エラーの検出と最適化における多くの有名なコンパイラー手法の適用です。ここではいくつかの例を示します。

型システム：

Closure Compilerは、注釈付きの型システムを定義します。多くのコンパイラがプログラムのエラーをチェックするために使用する型推論手法を利用します。

プロシージャー間の最適化

Closure Compilerは、コールグラフを作成して、プログラムレベル全体でデッドコードの名前を変更し、削除します。

手続き内の最適化

Closure Compilerは、さまざまな制御フロー分析とデータフロー分析を適用して、Javascriptを最適化します。インライン化、レジスター割り当て、ライブ変数分析などの従来のコンパイラー手法はすべて、出力Javascriptからその最後のバイトを圧縮するために利用されます。

モジュールシステム

Closure Compilerのあまり知られていない部分で、コードを個別のダウンロードに分割して起動時間を短縮するために使用できます。多くのグラフアルゴリズムも利用します。「従来の」コンパイラでは、何かが非常に一般的です。

これらすべてのコンパイラーおよび静的分析手法は、クロージャーコンパイラーを他のJavascriptミニマイザーと区別するものです。ターゲットの入力言語と出力言語が同じであるという事実から離れると、なぜ「真のコンパイラ」として分類されないのかわかりません。