为函数式语言设计解释器的主要问题是什么？
假设我想为函数式语言实现一个解释器。我想了解这样做所涉及的问题以及可用的合适文献。这是一种处于早期设计阶段的新语言，这就是为什么这个问题的范围很广泛。
出于本次讨论的目的，我们可以假设该语言的目的并不重要，并且如果它对编写解释器的难易程度产生显着影响，则其功能特征可以改变（甚至是巨大的）。
麻省理工学院网站有一个在线副本计算机程序的结构和解释 以及 MIT 6.001 讲座的视频使用Scheme，于 1986 年在 HP 录制。这些构成了对语言设计的精彩介绍。
Suppose I want to implement an interpreter for a functional language. I would like to understand the issues involved in doing so and suitable literature that is available. This is a new language that is in early design stages, that is why the question is broad in scope.
For the purpose of this discussion we can assume that the purpose of the language is not important and that its functional features can be changed (even drastically) if it makes a significant difference in the ease of writing an interpreter.
The MIT website has an online copy of Structure and Interpretation of Computer Programs as well as videos of the MIT 6.001 lectures using Scheme, recorded at HP in 1986. These form a great introduction to language design.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我推荐《编程语言要点》作为 SICP 的一个很好的补充，特别是如果您对解释器感兴趣的话：EOPL 官方网站。您可能想查看第三版- - 该网站尚未更新。
编辑：垃圾邮件预防让我在链接之间进行选择，因此官方页面现在不热了。不过，它很容易通过谷歌搜索。
I'd recommend Essentials of Programming Languages as a good complement to SICP, particularly if you're interested in interpreters: Official EOPL site. You may want to check out the third edition-- the site hasn't been updated for it yet.
Edit: spam prevention is making me choose between links, so the official page is now unheated. It's easily Google-able, though.
我强烈推荐计算机程序的结构和解释（SICP）作为起点。本书将介绍编写解释器（和编译器）的含义，并且通常是任何设计语言的人的必读书籍。
为函数式语言实现解释器与为任何其他通用语言实现解释器不太可能有太大区别。有词法分析、解析、AST 构造、语义分析，以及执行（对于纯解释器）或代码生成和优化（对于编译器，甚至编译为 Java/Perl/Python 等字节码）。 SICP 将介绍“应用顺序”和“正常顺序”评估之间的区别，这在纯函数上下文中可能对您很重要。
I would highly recommend Structure and Interpretation of Computer Programs (SICP) as a starting point. This book will introduce the idea of what it means to write an interpreter (and a compiler), and is generally a must-read for anybody designing languages.
Implementing an interpreter for a functional language isn't likely to be too much different from implementing an interpreter for any other general purpose language. There's lexical analysis, parsing, AST construction, semantic analysis, plus execution (for a pure interpreter) or code generation and optimisation (for a compiler, even compiling to bytecode like Java/Perl/Python). SICP will introduce the difference between "applicative order" and "normal order" evaluation, which may be important for you in a pure functional context.
我认为，对于任何语言解释器或编译器来说，主要问题都是相同的。
您需要确定语言的某些基本特征（语义，而不是语法），并且事物的大部分设计都由此而来。
例如，您的语言是否有
类型系统？如果是的话，是什么样的
它有什么类型？会不会是
静态类型、动态类型、
鸭子类型？
你是什么表情
计划支持？你需要吗
定义操作顺序？将要
你甚至还有运算符？
您将使用什么作为运行时
程序的代表？将要
您将文本转换为字节码
表示，或 AST，或
源文本的标记化形式？
有一些工具包可以帮助消除实际文本解析中的一些乏味（ANTLR 和 Bison，仅举两个例子），但我不知道有什么可以帮助完成任务的实际解释部分。我确信有人会提出一些建议。
For just about any language interpreter or compiler, the main issues are the same, I think.
You need to decide certain basic characteristics of the language (semantics, not syntax), and the bulk of the design of the thing follows from that.
For example, does your language have
a type system? If so, what sorts of
types does it have? Is it going to be
statically typed, dynamically typed,
duck-typed?
What sort of expressions are you
planning to support? Do you need to
define an order of operations? Will
you even have operators?
What will you use as the run-time
representation of the program? Will
you convert the text to a byte-code
representation, or an AST, or a
tokenized form of the source text?
There are toolkits available to help take some of the tedium out of the actual parsing of text (ANTLR and Bison, to name two), but I don't know of anything that helps with the actual interpretation part of the task. I'm sure somebody will suggest something.
主要问题是为您正在实现的语言提供语义——这样，实现就变得简单了。否则，这个问题就太宽泛了，很难回答。
The main issue is having a semantics for the language you're implementing -- with that, the implementation becomes straightforward. Otherwise, this question is incredibly broad and hard to answer.