为函数式语言设计解释器有哪些主要问题？

Question

假设我想为函数式语言实现解释器。我想了解这样做所涉及的问题以及可用的合适文献。这是一种处于早期设计阶段的新语言，这就是为什么问题范围很广的原因。

为了讨论的目的，我们可以假设语言的目的并不重要，如果它在编写解释器的难易程度方面有显着差异，那么它的功能特征可以改变（甚至是大幅度的）。

麻省理工学院网站有一份Structure and Interpretation of Computer Programs的在线副本，以及videos使用计划的麻省理工学院6.001讲座，于1986年在惠普录制。这些都是语言设计的一个很好的介绍。

Answer 1

我强烈建议Structure and Interpretation of Computer Programs (SICP)作为起点。本书将介绍编写解释器（和编译器）意义的概念，对于任何设计语言的人来说，这通常都是必读的。

为函数式语言实现解释器与为任何其他通用语言实现解释器不太可能有太大的不同。有词法分析，解析，AST构造，语义分析，加上执行（对于纯粹的解释器）或代码生成和优化（对于编译器，甚至编译为像Java / Perl / Python这样的字节码）。 SICP将介绍“应用订单”和“正常订单”评估之间的区别，这对于您在纯粹的功能背景下可能很重要。

Answer 2

对于几乎任何语言翻译或编译器，我认为主要问题是相同的。

你需要决定语言的某些基本特征（语义，而不是语法），并且事物的大部分设计都是从那里开始的。

• 例如，您的语言是否有 一个类型系统？如果是这样，有什么样的 它有哪些类型？会不会是 静态类型，动态类型， 鸭类型的

• 你是什么样的表达方式 计划支持？你需要吗？ 定义一个操作顺序？将 你甚至有经营者？

• 您将使用什么作为运行时 该计划的代表？将 您将文本转换为字节码 表示，或AST，或 源文本的标记化形式？

有一些工具包可以帮助从文本的实际解析中解决一些单调乏味（ANTLR和Bison，更名为两个），但我不知道任何有助于实际解释部分的任务。我相信有人会提出建议。

Answer 3

主要问题是为您正在实现的语言提供语义 - 这样，实现变得简单明了。否则，这个问题非常广泛且难以回答。

Answer 4

我建议编程语言要点作为SICP的一个很好的补充，特别是如果你对口译员感兴趣：官方EOPL网站。您可能需要查看third edition - 该网站尚未更新。

编辑：垃圾邮件预防让我在链接之间进行选择，因此官方页面现在不加热。不过，它很容易使用谷歌。