在解释器中，词法分析器之后（通常）是什么？

发布于 2024-11-07 07:18:20 字数 228 浏览 4 评论 0原文

对于编程语言解释器，我想知道解释器经历的事件顺序。例如，我认为事情是这样的：

解释器获取一些输入词法
分析器/分词器获取输入并划分标记
x 获取标记列表
???
代码被执行

??? 中属于哪些步骤？点，以及替换 x 的位置（即，什么接收词法分析器生成的标记并对其进行操作）？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

邮友 2024-11-14 07:18:20

我首先推荐经典且免费的书籍：计算机的结构与解释计划（视频讲座）

Lisp 是基线解释器，其他一切在某种程度上都是该主题的变体。

一般来说，步骤如下：

词法分析获取字符流并生成标记
解析获取标记（平面列表）并构建称为抽象语法树 (AST) 的数据结构。这一步可以非常简单（Lisp），也可以非常复杂（C++、Ruby）。
评估 AST。细节有点不同，但这几乎是深度优先沿着树走。叶子是数据（数字、字符串、常量、变量），节点可以是原始函数（数学、数据操作、控制结构），也可以是更高级别的复合函数。每个节点都应该简化为可以直接馈送到其上方节点的东西。

最后一步是“代码被执行”。对于编译语言或即时 (JIT) 语言，最后一步是将 AST 翻译回机器指令。注意可能存在的其他两个步骤也很重要。一种是翻译成更简单的语言，如 c--、LLVM、.NET 或 Java bitcode。另一个是解析器和评估器之间可能发生的脱糖和/或优化。例如，Haskell 就因大量脱糖而臭名昭著。

最后，我将鼓励您尝试编写一个Scheme（Lisp 的一种方言）解释器的众多演练中的一个。网上某处可能有适合您最喜欢的语言的语言。

回复收藏 0 原文

々眼睛长脚气 2024-11-14 07:18:20

进行解析，将标记流转换为结构化的、经过验证的语法信息。如果你想计算一个算术表达式：

( x + 4 ) * 3

您不是通过从左到右扫描令牌来完成的。您需要弄清楚操作顺序。您需要将 if 关键字和 { } 大括号之间的标记转换为描述 if 语句的高级结构，以便您无需处理一堆代币即可对其进行评估。并且您需要检查语法，如果不正确解析它，这基本上是不可能的；请阅读上下文无关语法。

上面的表达式将成为一个抽象语法树，如下所示：

    *
  +   3
 x y

评估它非常简单 - 只需遍历树，然后查找 x 和 y > 在环境中。

类似地，给定一系列如下语句：

if ( p && q< /code> ) { foo ; bar ; } 其他 { baz ; }

抽象语法树可能具有以下一般结构：

IfStatement:
  Condition:
    LogicalConjunction:
      LeftOperand: p
      RightOperand: q
  TruePart:
    BasicBlock:
      Statement: foo
      Statement: bar
  FalsePart:
    BasicBlock:
      Statement: baz

希望您能够想象如何遍历这棵树来解释代码。

我强烈推荐的一本关于解释器的教科书是编程语言要点 。

Parsing happens, to turn the stream of tokens into structured, validated, syntactic information. If you want to evaluate, say, an arithmetic expression:

( x + 4 ) * 3

you don’t do it by scanning the tokens from left to right. You need to figure out order of operations. You need to turn the tokens between an if keyword and the { } curly braces into a high-level structure describing the if statement, so you can evaluate it without juggling a pile of tokens. And you need to check the syntax, which is essentially impossible without properly parsing it; please read about context-free grammars.

The expression above would become an abstract syntax tree like the following:

    *
  +   3
 x y

Evaluating this is pretty simple — just traverse the tree, and look up x and y in the environment.

Similarly, given a series of statements like this:

if ( p && q ) { foo ; bar ; } else { baz ; }

the abstract syntax tree might have the following general structure:

IfStatement:
  Condition:
    LogicalConjunction:
      LeftOperand: p
      RightOperand: q
  TruePart:
    BasicBlock:
      Statement: foo
      Statement: bar
  FalsePart:
    BasicBlock:
      Statement: baz

Hopefully you can imagine how you would traverse this tree to interpret the code.

A textbook on interpreters which I highly recommend is Essentials of Programming Languages.

回复收藏 0 原文