3

是否有一種編程語言,具有可用的交互式解釋器,即使它可以編譯爲機器碼?編譯解釋語言

+0

「可用的互動翻譯」是什麼意思?大多數解釋型語言實際上都是*翻譯*。 – staticsan 2010-07-06 23:35:53

+0

@staticsan通過交互式解釋器,我的意思是類似shell的環境,在這裏你可以交互式地在運行時工作。通過機器碼,我不是指字節碼。 (對不起,如果我的術語不是最精確的) – mykhal 2010-07-06 23:41:58

+3

您正在尋找的術語是「REPL」(Read-Eval-Print-Loop)。 – Artelius 2010-07-07 00:19:12

回答

14

編譯與「解釋」本質上是一個實現問題,而不是語言本身。例如,MRI Ruby 1.8被解釋,而MacRuby被編譯爲本機機器碼。兩者都包含互動式REPL。我所知道的語言有至少一個機器代碼的編譯器和至少一個REPL:

  • 紅寶石
  • 的Python
  • 幾乎所有的Lisp(Lisp的是開創這種技術的語言,據我所知)
  • OCaml的
  • 哈斯克爾
  • 第四

如果我們報數摹編譯成字節碼,以及機器代碼,這是絕大多數流行的字節碼編譯語言的真實:

  • 的Java
  • 斯卡拉
  • Groovy的
  • 二郎
  • C#
  • F#
  • Smalltalk
+0

Smalltalk具有REPL – mathk 2010-07-07 06:45:01

+0

這就是爲什麼Smalltalk位於具有REPL的字節碼編譯語言列表中的原因。 – Chuck 2010-07-07 18:17:56

1

不完全是機器碼,但Java可以編譯,也可以通過BeanShell使用。

+0

賽門鐵克Java IDE(忘了它的名字)曾經有一個Java編譯器。 – 2010-07-06 23:56:43

1

我已經使用Ruby與解釋器,似乎有編譯器here

+0

我相當確定這實際上只是一個用解釋器捆綁你的ruby代碼的工具,它實際上並沒有編譯到機器代碼中。稱它爲編譯器是誤導和不正確的。 – Benson 2010-07-07 00:08:18

+0

我只是讀廣告的網站。不過,好點,因爲除非他們深入到實施細節中,否則大多數人都不知道其中的差別。 – 2010-07-07 00:32:45

5

許多風格的Lisp提供了兩種選擇,包括Clojure。

+0

請注意,Clojure已編譯爲JVM字節碼。 – Greg 2010-07-06 23:51:05

+0

Clojure被編譯爲字節碼,而不是機器代碼(除非您計算某些Java實現中的抖動)。但在其他語言中卻是如此。 – Chuck 2010-07-06 23:51:19

+0

@Chuck是的,當我編寫原始答案時,他沒有添加註釋排除字節碼...... – Greg 2010-07-07 00:02:23

3

兩個來到我的腦海裏:ocaml和scala(〜= java),但我確信那裏肯定還有更多。

+0

順便說一句:將ocaml編譯爲本地代碼的命令是「ocamlopt」(ocamlc將編譯爲字節碼)。至於scala,我不確定gcj是否可以編譯它兼容的java字節碼,所以如果有人有更多的信息.​​.? – Shautieh 2010-07-06 23:53:19

1

圖標曾經有一個編譯器,但它落入和離開維護。它可能仍然有效。

1

Python可以編譯爲windows可執行文件。

+0

與「RubyScript2Exe」的情況一樣,您所指的工具實際上只是將python代碼與python解釋器捆綁在一起。這不是編譯;稱它爲編譯器是對這個術語的濫用。然而,它*是非常有用的,所以從實際的角度來看可能並不重要。 :-) – Benson 2010-07-07 00:09:53

1

C#可以使用SnippetCompiler進行編譯,也許這會作爲您的交互式解釋器?

+0

linqpad也將工作... – Alan 2010-07-07 00:22:02

12

Haskell,使用Glasgow Haskell Compiler,它有一個名爲GHCi的交互式「外殼」。

+0

+1實際編譯爲機器碼。 :-) – Benson 2010-07-07 00:11:15

+0

實際上與QuickBasic一樣,但是生成16位機器代碼,所以本註釋僅供參考。 – Artelius 2010-07-07 00:16:09

+0

我不記得qbasic的交互式shell :) – mykhal 2010-07-07 00:17:52

2

Lua有單線和實驗的交互模式。它通常編譯爲字節碼以供其VM執行。 LuaJIT是一個Lua虛擬機的獨立實現,它也適用於32位x86的即時編譯。對64位的支持正在進行中,並且經常要求支持ARM。

編譯爲字節碼通常是純解釋器和純編譯器之間的合理折中。VM可以根據語言的需要進行調整,JIT技術可以在執行時分析VM代碼,並專注於經常執行的代碼路徑和內部循環。

1

你的問題有點含糊。連渣會適應它:通過交互式解釋

,我的意思是 殼般的環境,在那裏你可以在運行時 工作互動。

Java有這個,例如,在Eclipse的「剪貼簿頁面」中,您可以在其中輸入Java表達式並立即對其進行評估。 Java當然也是一種編譯語言(雖然它通常編譯爲字節碼,但有各種編譯器輸出機器碼)。

那麼你在找什麼?也許你可以解釋你的問題或興趣。

+0

我期待着各種各樣的答案提及的語言都能夠被編譯爲一個可執行文件,並擁有完備的交互式解釋器 – mykhal 2010-07-07 00:15:29

1

我嘗試使用mono/.net一點,發現隨機GC暫停是不愉快的(至少在我硬皮的舊筆記本電腦上)。我研究了使用gambit-c實現的可以編譯爲C的方案,但由於文檔有點受限以及軟件包不易安裝和使用,似乎很難合作。

我通常只是堅持使用像Python這樣的解釋語言綁定到C/C++,這更加痛苦,但至少我知道我在做什麼。

2

正如其他人所說,OCaml。

如果託管代碼(.NET CLI)足夠接近機器碼,F#也將成爲候選人。可能還有其他符合要求的.NET/Mono語言。

2

您可能會後悔問您:

C和C++。

爲什麼?

,並有可能是其他人在那裏爲好。

2

大量的語言提供了一個實現,它們既可以交互,也可以編譯爲機器代碼,但很少一次完成。 Standard ML of New Jersey是一個具有交互式循環但沒有字節碼的程序:它只是編譯爲內存中的機器代碼,然後分支到它。

3

這裏還有另外一個燒你的房子:

x86彙編

是啊,這是你的翻譯也是如此。

此時你在模擬器土地真的,但它確實符合你的國家的要求。

我想知道是否更容易命名編譯語言,有人還沒有拼湊了一個工作的解釋器。 :-)