javascript - 语法产生规则与ECMAScript中的解析如何相关

Question

如Wikipedia关于Parsing的文章所述，该过程分为三个阶段：


Lexical analysis（令牌化）：将Unicode代码点转换为令牌
语法分析：验证令牌流形成有效的脚本/模块，并创建分析树
语义分析：令牌的其他验证（在创建“分析树”之后发生？


除了上面阶段（3）中的小混乱之外，我还想验证我对该过程的理解对ECMAScript是正确的。

因此，以下流程正确吗？



词法分析阶段（ECMAScript Clause 11）


输入：Unicode代码点流<-词汇语法中的终端符号
输出：有效记号<-词汇语法中的非终结符
语法应用


分析每个Unicode代码点（字符），一次
通过应用适当的生产规则，将尽可能长的终端符号序列替换为非终端符号
然后，再次应用生产规则，替换尽可能长的非终结符序列
以相同的方式，一次又一次地应用生产规则，一直到产生“目标符号”为止

目标符号是语法分析阶段（下一个阶段）的输入元素（也称为标记）
ECMAScript的词汇语法（spec states which to pick）存在多个“目标符号”




句法分析阶段（ECMAScript第12-15条）


输入：令牌流<-语法中的终端符号
输出：解析树，以脚本|模块作为根解析节点<-语法上的非终结符
语法应用


首先从输入元素流开始。代币
这些标记是语法中的终端符号
通过将最大符号流与合适的生产规则的RHS匹配来应用生产规则，然后用该规则的LHS非终端符号替换流
这一直持续到只剩下“目标符号”为止

ECMAScript：如果我们可以替换所有终端符号（标记）并以单个“目标符号”结尾（脚本|模块），则该程序有效

Answer 1

语法分析不遵循“最大修改”规则（选择最长匹配前缀）。实际上，据我所知，ECMA-262并未指定解析算法，但确实提供了明确的上下文无关文法，例如，除了某些语法外，还可以使用自底向上（LR（k））解析器进行解析自动分号插入的问题以及跨换行符（不是语法标记）的产品的一些限制。

但是，如§5.1.4中所述，语法实际上可以识别该语言的超集。其他限制以补充语法的形式提供。

一个澄清：与具有多个上下文相关的词汇目标符号相关的复杂性使得很难先将输入划分为词素，然后仅将词素组合为解析树。没有至少部分解析就不可能在每个点上都知道正确的词汇目标符号，因此可以方便地将句法和词汇解析交织在一起。实用的解析算法从左到右运行，基本上按输入顺序处理词素，因此可以按需进行词法分析，只有在解析器需要更多输入才能继续时才找到词素。

但是除此之外，您概述的总体结构是正确的。在词法分析中，将终端（字符）的尽可能长的前缀聚合到一个非终端中，以创建词素（根据关于哪个词法目标需要的稍微复杂的规则）；在语法分析中，将终端（词汇）聚合为非终端，以生成与两个语法目标符号之一相对应的单个分析树。

就像现实世界中的语言经常出现的那样，现实并非如此干净。除了需要解析器指出需要哪个词汇目标外，还存在换行规则和自动分号插入，这两者都跨越了词汇和句法分析之间的边界。



注意：

单词“终端”和“非终端”的使用可能会有些混乱，但是我（和ECMA标准）在上下文无关的语法中将它们与标准含义一起使用。

上下文无关的语法由产生形式组成，每个产生形式具有：

N ⇒ S …

其中，N是非终结符，而S是终结符或非终结符的可能为空的序列。终端符号是要识别的字符串表示形式中的原子。

标准的解析模型将解析分为两个级别：词法和句法。原始输入是一个字符序列；词法分析将其转换为一系列词素，这些词素是语法分析的输入。

标准的上下文无关文法只有一个目标符号，它是文法定义的非终结符之一。如果可以将整个输入减少到此非终端，则解析成功。

词法扫描可以看作是无上下文语法，带有目标符号的有序列表。它依次尝试每个输入目标的较长前缀的每个目标符号，并接受与最长前缀匹配的第一个目标符号。 （实际上，所有操作都是并行完成的；我在这里是从概念上讲的。）当ECMA-262讨论不同的词汇目标时，实际上意味着可能的目标非终结符的不同列表。

用语义属性扩展符号也很有用；这些属性不会影响解析，但是一旦解析完成，它们就很有用。特别是，解析树是通过将树节点作为属性附加到在解析过程中由生产创建的每个非终端而构建的，因此解析的最终结果不是非终端符号本身（之前知道解析开始），而是附加到非终结符的特定实例的语义属性，而每个点的词法扫描结果是非终结符及其相关的语义属性；通常，语义属性将是关联的输入序列或这些字符的某些功能。

无论如何，两级解析涉及将词法级的输出非终端作为句法级的终端。