沒有“編譯語言”或“解釋語言”這樣的東西

Question

“沒有”編譯語言“或”解釋語言“這樣的東西。語言實現者是選擇編寫編譯器，解釋器還是其中的任何東西都是實現細節，而與語言無關。

以上陳述是真的嗎？

Answer 1

是的，這是最嚴格的解釋。 例如，您可以找到C ++解釋器和Javascript編譯器 。 但是，您會發現某些類型的語言（例如靜態類型）非常適合本機代碼編譯。 其他語言（例如，動態類型）通常使用字節碼編譯與虛擬機執行環境相結合來實現。

Answer 2

有點。 通常，解釋器和編譯器首先需要解析源代碼並將其轉換為表示，稱為AST（抽象語法樹）。 編譯器然后將AST轉換為可執行代碼（通過各種轉換），而解釋器可能只是直接“解釋”AST或有時編譯並執行它（即時編譯）。

該陳述是正確的，因為這與語言無關：理論上，您可以為任何語言編寫解釋器和編譯器。 使用哪一個真正取決於用例，場景和環境。

編譯器的優勢在於，無論您執行程序的頻率如何，他只需要完成一次工作。 解釋器需要每次解析源（或進行一些緩存），因此每次執行都會產生開銷，這可能比最終程序的實際執行時間長。 另一方面，解釋器更靈活（它可以考慮當前環境，因此不允許編譯器進行優化）。 但差異並不止於此，這只是兩個顯而易見的要點。

Answer 3

語言設計與較高級別輸入部分的語法和在目標上執行的較低級別輸出代碼有關。

兩者之間有一個抽象的語法樹。

傳統上，如果您編寫較低級別的輸出代碼以在特定硬件平台及其特定指令集上執行，則輸出將被“編譯”。

如果有人決定編寫解釋器作為目標，則輸出代碼是解釋器期望的指令集或字節代碼。 額外的間接級別意味着解釋的代碼可以在具有解釋器實現的任何硬件平台上運行。

因此，如果我們將“語言設計”稱為語法和詞法分析器/解析器片段，則該語句是正確的。

如果我們談論代碼生成器，那么這不是嚴格正確的。

只需通過調用不同的代碼生成器來遍歷AST，就可以發出特定語言，只需解釋和編譯即可。

也許這就是區別模糊的方式。 但我認為它仍然存在。

Answer 4

以上陳述屬實。

再說一次，人們可能會認為它在現實世界中不夠真實。 如果語言的所有現有實現都依賴於編譯，則該語言可以合法地稱為編譯語言。

Answer 5

它的真實性僅在於編譯語言和解釋語言最終都必須生成機器代碼。 它確實對語言有影響，因為傳統上某些范例在一個方面比另一方更容易。 例如，通常，閉包或塊在編譯語言中比編譯語言更容易實現。 這是正確的，因為在解釋語言中編譯時間和運行時范圍之間實際上沒有區別。 因此動態范圍TENDS更易於在解釋語言中實現。

Answer 6

語言的給定實現將是“純”編譯器（其輸出由處理器作為代碼執行），“純”解釋器（每個語句首次檢查，原始源形式，因為它是執行，沒有任何關於解釋的緩存），或兩者之間的混合。 將“純粹”案例與混合案件區分開來很容易，但有些混合物比其他混合物“更接近”。 “編譯”混合與“解釋”混合之間的界限可能相當模糊。

除了匯編語言之外，我認為任何語言都沒有實際用處（“匯編程序”一詞通常優先於“編譯器”使用），這種語言在混合解釋器中至少在某種程度上無法實現（性能）一個“純粹”的解釋器，除了最簡單的循環結構之外，很容易變得可怕。 但是，有些語言允許以不適合編譯的方式生成動態代碼。

順便說一句，當我說“原始來源”表格時，我並不總是指文字格式。 我的第一個可編程計算器有99個程序步驟，每個步驟都可以配置擊鍵或一些特殊的排序指令。 該程序本身不會以人類可讀的文本形式存在，而是作為一系列關鍵數字存在。 盡管如此，我會將其描述為純粹解釋的“語言”，因為每個程序步驟都是完全獨立評估的。

Answer 7

整個編譯器/解釋器的東西取決於你對程序的意圖。 已編譯的程序是一個轉換為機器代碼的程序。 解釋器用於讀取中間語言並在計算機上運行。 例如，當您編譯Java時，它將轉換為Java字節碼並由解釋器讀取並運行（與C ++相比，這也解釋了速度劣勢）。

我真的不認為你關於它與語言無關的陳述是完全正確的。 關於Java的一個主要問題是它應該可以在不同的體系結構上運行。 如果編譯是不可能的。

Answer 8

值得注意的是，對於（某些？）包含“eval”類型語句的語言（特別是如果直到運行時無法確定給定塊是代碼還是數據），甚至是給定程序的最純編譯版本必須部分解釋。 對於這樣的語言，不可能完全編譯它們（編譯的代碼必須包含該語言的解釋器）。

例如，請考慮以下代碼：

set s [eval {sum $a $b $c}]

對於上面的Tcl代碼，直到運行時才能確定塊（在{}內）是否是代碼。