构建口译员需要学习什么?

Lou*_*Lou 5 interpreter programming-languages interpreted-language

对于我的 AQA A2 级计算项目,我决定创建一种基本的解释性编程语言,输出到控制台。我不知道如何构建一个解释器。我有一本紫龙书,里面都是关于编译器设计的,正如user166390在回答这个问题时所说,构建编译器的初始步骤与构建解释器相同。我的问题是:这是真的吗?

我可以使用龙书中描述的技术来编写解释器吗?如果是的话,我需要使用哪些步骤并学习如何使用?

例如,我是否需要编写词法分析器、语法分析器、语义分析器和中间代码生成器?

我是否可以编写一个基本的解析器来读取源代码的每一行,解析它并立即执行指令,或者这是一个众所周知的坏主意?

com*_*orm 2

是的,你可以使用龙书中描述的技术来编写一个解释器。

无论如何,您都需要一个词法分析器和一个解析器。

正如其他人指出的那样,您确实需要编写代码来执行实际执行 - 但对于简单的解释器来说,这基本上与龙书中描述的语法指导翻译相同。

其他一切都是可选的。


如果您想直接从解析器跳到执行,也可以。这将为您留下一种非常简单的语言,它可能是好的,也可能是坏的——看看Tcl的这种语言的例子。

如果您想在解析每一行时对其进行解释,您也可以这样做;这是大多数命令行解释器(Unix shell 脚本、Microsoft 的 cmd.com 和 PowerShell)所做的事情,也是 Python 和 Ruby 等语言的交互式“REPL”(Read-Eval-Print-Loops)所做的事情。

“语义分析器”对我来说似乎很模糊,但听起来它应该包括大多数类型的加载时一致性检查。这也是可选的,但是解释器有一个优点,它不会接受任何旧的垃圾并尝试将其作为程序执行......

“中间代码”也有点模糊,但它可以说是可选的。如果您不直接从程序字符串执行(如 Tcl 中),则在读入代码后,您需要某种内部表示来存储代码。一种流行的选择是从内部树结构执行,基于更多信息或者不太接近您的解析树,这可以说与生成“中间代码”不同。另一方面,如果您的“中间代码”或多或少可以直接从内部树结构中编写出来,那么您不妨将内部结构算作您的“中间代码”。


有些重要的问题你还没有解决;突出的一个问题是:你想如何处理名字?想必您会希望程序员能够定义和使用他自己的名称(例如变量、函数等),因此您需要为此实现某种机制。

名称的确切处理方式是一个重大的设计决策,对语言的可用性和可实现性具有重大影响。最简单的实现选项是使用单个全局哈希映射来实现单个全局命名空间 - 但请注意,这种选择存在众所周知的可用性问题......