fsi.exe是翻译吗？

Question

我读过fsi.exe (F#互动)不是严格意义上的真正的“解释器”，因为它动态编译F#代码并显示其输出。

我的印象是，“解释器”一词适用于“动态”语言(即JavaScript)，因此不适用于F#，因为它是一种编译语言。

这是公平的评估吗？或者编译语言可以被“解释”？或者这仅仅是一个语义问题？

感谢你的帮助。

Answer 1

汇编和解释之间的区别是模糊的。事实上，许多被视为“解释”的语言通常被编译成本机代码(例如，JavaScript和v8)。动态语言最动态特性eval的一些实现只是一个编译的包装器(例如，在SBCL中)。

当然，REPL与编译或解释无关，REPL可以建立在任何执行模型之上。fsi只是一个REPL，它使用的是与fsc相同的F#编译器核心。

Answer 2

我的印象是，“解释器”一词适用于“动态”语言(即JavaScript)，因此不适用于F#，因为它是一种编译语言。

这是公平的评估吗？

不是的。“解释器”一词是指程序的执行方式。如果一个源程序是通过一个名为“解释器”的独立程序执行的，该程序通过解释源程序中每条指令的含义来执行它，那么它将被解释。

“动态编程语言”一词似乎没有正式的定义，只是非正式地使用，通常指动态类型语言(即缺乏静态类型系统的语言，因此推迟运行时的所有类型检查)或实现的编程语言，以便能够在运行时完成宏、反射、REPL等功能。这与程序是被解释还是编译无关。例如，Common被视为一种动态语言，而OCaml则被视为一种静态语言(尽管它同时具有宏和REPL)，但是解释器和编译器都可以用于Common和OCaml。

或者编译语言可以被“解释”吗？

同样，“汇编语言”一词的定义也不明确。任何语言都可以被解释或编译。形式上，任何可执行语言都可以被解释，任何解释器都可以通过对源程序进行部分专门化来转换为编译器。

请注意，一些编程语言实现同时使用编译和解释，以获得两个世界的一些优点。例如，OCaml可以使用用OCaml编写的编译器将程序编译成字节码，然后由用C编写的解释器解释字节码。这有几个优点：

编译阶段的编译阶段可以执行优化(例如，大步骤语义)，而解释器无需interpreter.

• Much就可以使用C语言编写解释器，从而进一步改进了performance.

。

还是仅仅是一个语义问题？

术语。

Answer 3

当您说JavaScript是"dynamic“时，您通常指的是”动态类型“，这与它通常是作为一种解释语言而不是编译的事实无关。与“动态类型化”相反的是“静态类型化”。注意，这是一个与“弱类型”和“强类型”描述的属性不同的属性。这两个属性都与解释器和编译器无关，只是脚本语言(几乎总是被解释)倾向于动态类型。

编译器显然不是一个解释器(实际上，这个问题与充当解释器的编译器有关，但为了参数起见，让我们继续使用它)，所以如果您将一些源代码编译成一个对象文件并执行它，您可能会认为它显然没有被解释。但事实证明，这不是一条非常明确的界线。如果您认为模拟器是解释器，那么您可以解释任何可执行文件，不管它最初是以什么语言开始的。还有二进制翻译和JIT编译器，它们的字节码混淆了一个已经很混乱的问题。但是请注意，这里的混淆是完全语义的，解决方案可能只是更新了一组定义。

相反，您可以“编译”任何解释语言，方法是记录解释器在解释程序时所做的操作，并将其作为编译后的程序播放。这并不是确切的编译，也不会比解释器更高效，但问题是，被解释并不是语言的固有特性。

因此，传统上编译的语言可以，有时作为解释语言实现。那里甚至还有C的口译员。我相信这回答了你的问题。我认为关于F#的要点是，尽管它是交互式的，但根据最严格的定义，它并不是一个实际的解释器。这是因为它编译代码并运行它们。这并不意味着由于语言的某些属性，F#的严格解释器无法编写。