REPL、解释器和编译器之间的关系是什么？

Question

REPL、解释器和编译器之间的关系是什么？

compiler-constructioninterpreterread-eval-print-loop

4

来自维基百科:

REPL通常被错误地称为解释器。这是一个错误的叫法-许多使用编译（包括字节码编译）的编程语言都有REPL，例如Common Lisp和Python。

来自对此帖子的回复

交互式解释器使用REPLs。解释器不需要使用REPL. 例如，您可以在非交互模式下运行Python（在文件上），它将不使用读取-求值-打印循环。

我想知道REPL [删除]总是存在[/删除]仅存在于解释器中吗？维基百科是否说REPL也适用于编译器？如果是，那会是怎样的呢？

谢谢和问候！

我的意思是执行编译后立即执行的解释器。

- Tim

3个回答

1

这可能不是一个好的答案，只是一些笔记：

IE 6.0 中的 JavaScript 没有 REPL。
编译器的 REPL 可能看起来像解释器，如果语言可以在一次解析中完成，只能向前。编译器可能会在每个已编译语句后插入断点，执行直到达到断点，然后返回给用户，等待下一个输入行，并重复。最后，所有输入行都被编译并执行。

- Lenik

谢谢！那么在第二种情况下，带有REPL的编译器总是解释器吗？ - Tim

@Tim：编译器不是解释器，无论它是否用于构建REPL。 - user395760

@Tim，不是的，例如在SBCL中根本没有解释器，只有编译器，但仍然有一个不错的REPL。 - SK-logic

@delnan：谢谢！解释器是否定义为在编译后立即执行的程序？我是这么想的。 - Tim

@Tim：我认为不是。在第二种情况下，编译器不会进行解释，它只是编译代码，并让 CPU 进行解释，因此它不是一个解释器。 - Lenik

1

REPL代表Read-Eval-Print-Loop。解释器和编译器都可以用来执行eval部分 - 可以在后台运行解释器实例并将其输入，也可以使用编译器逐步编译（尽管这需要更多的工作和一些编译器编写者的合作，但是像无数实例一样，这是可能的 - 通常只编译为字节码）。其余部分主要是I/O和一些粘合剂，以使所有先前输入的定义可用于下一个命令。

- user395760

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Danny Milosavljevic · Accepted Answer

我不确定你是在问常用词汇还是其他什么。无论如何，REPL是指“读取-评估-打印-循环”（见首字母缩写）。如果你的解释器不会读取你的程序或不会对其进行评估（即“理解”你想要它做什么并执行），或者不会在任何地方打印结果，那么它有什么用呢？

如果你什么都看不到也听不到，并且它不会按照你的意愿执行，或者你只有一次尝试，那么你可以把一块石头放在桌子上而不是电脑。

也许会有一些有趣的玩弄文字的反驳，比如，“如果它只改变一个显示的图标，那它算不算打印？”等等。或者“如果它不从键盘读取，那它真的在读取吗？”这些都是无谓的哲学问题。

真正的问题是，有些系统会根据你是从键盘还是从文件读取而有所不同。我不确定这有什么用处，但我想当人们实际在键盘上输入时，你可以提供帮助（例如命令完成等）。

也许有些系统在从文件中读取时不接受多于1个表达式？

“我想知道解释器是否总是存在REPL？”我想这是对“解释器”定义的问题。如果你把它理解为（在实际意义上）“能够按照我要求执行的东西”，那么并不总是。如果它不听，你怎么告诉它呢？

“维基百科是否说编译器也存在REPL？如果是，那是什么样子？”当然有。所有的LISP系统都是这样的。它们感觉就像一个解释器，但随着系统学习如何表达你的想法、了解什么变化和什么不变，并将不变的内容编译为机器代码，速度会神奇地提高。

现在Java也是这样做的，你的VM会话持续的时间越长，它就会发现如何使事情变得更快，如果你停止更改，它最终会运行整个程序的机器代码。

解释器/编译器的整个人工区分只是由于过去的资源限制而意外发生的。