理解ECMAScript规范（4）

翻译本文的目的是尝试给出 ECMAScript 规范中核心术语的译法，供同好品评。

原文链接：v8.dev/blog/unders…

环球同此凉热

Mozilla 的Jason Orendorff写了一篇深入分析 JS 诡异语法的文章。虽然实现细节上有差异，但每个 JS 引擎在这些诡异的细节上都会面对同样的问题。

包含文法

这篇文章将深入探讨包含文法（cover grammar）。包含文法是为那些乍一看模棱两可的语法构造规定文法的一种方式。

为简单起见，我们跳过下标[In, Yield, Await]，因为对本文不重要。可以参考第三篇文章，了解它们的含义和用法。

有限前查

通常，解析器在有限前查（finite lookhead，跟进固定个数的标记）基础上决定使用哪个产生式。

有时候，下一个标记可以毫无歧义地决定要使用的产生式。例如：

UpdateExpression :
  LeftHandSideExpression
  LeftHandSideExpression ++
  LeftHandSideExpression --
  ++ UnaryExpression
  -- UnaryExpression

如果我们正在解析UpdateExpression且下一个标记是++或--，那我们马上就知道要使用哪个产生式。如果下一个标记不是它们两个，那也问题不大，可以从所在位置开始解析LeftHandSideExpression，解析完之后再决定下一步干什么。

如果LeftHandSideExpression后面的标记是++，则要使用的产生式是UpdateExpression : LeftHandSideExpression ++。后面是--的情形类似。如果LeftHandSideExpression后面的标记既不是++也不是--，则使用产生式UpdateExpression : LeftHandSideExpression。

箭头函数参数列表，还是带括号的表达式？

区分箭头函数参数列表与带括号的表达式更复杂一些。如：

let x = (a,

这是一个箭头函数的开头吗，如：

let x = (a, b) => { return a + b };

还是一个带括号的表达式，如：

let  x = (a, 3);

括号中的内容，不管是什么，但可能是任意长度。因此不能根据有限标记确定它是什么。

想象一下，假设我们有下列直观的产生式：

AssignmentExpression :
  ...
  ArrowFunction
  ParenthesizedExpression

ArrowFunction :
  ArrowParameterList => ConciseBody

那就可以使用有限前查来选择产生式。如果解析到AssignmentExpression之后，下一个标记是(，那怎么确定接下来解析什么？可以解析ArrowParameterList，也可以解析ParenthesizedExpression，但肯定有可能猜错。

非常宽纵的新符号：CPEAAPL

规范通过增加一个符号来解决这个问题：CoverParenthesizedExpressionAndArrowParameterList，简写成CPEAAL。CPEAAL表示既可能是ParenthesizedExpression也可能是ArrowParameterList，但现在不知道选哪个。

CPEAAL的产生式非常宽纵，允许任何可以出现在ParenthesizedExpression和ArrowParameterList中的构造：

 CPEAAPL  :
  ( Expression )
  ( Expression , )
  ( )
  ( ... BindingIdentifier )
  ( ... BindingPattern )
  ( Expression , ... BindingIdentifier )
  ( ArrowFunction , ... BindingPattern )

比如，下列表达式都是有效的CPEAAPL：

// 有效的ParenthesizedExpression和ArrowParameterList：
(a, b)
(a, b = 1)

// 有效的ParenthesizedExpression：
(1, 2, 3)
(function foo() { })

// 有效的ArrowParameterList：
()
(a, b,)
(a, ...b)
(a = 1, ...b)

// 两个都无效，但仍然是CPEAAPL：
(1, ...b)
(1, )

末尾的逗号和...只可能出现在ArrowParameterList中。有的构造（如b = 1）两种情况下都有可能出现，但是含义不同：出现在ParenthesizedExpression中是赋值，出现在ArrowParameterList中是带默认值的参数。数值及其他不是有效参数名的PrimaryExpression（或参数解构模式）只可能出现在ParenthesizedExpression中。但它们都可能出现在CPEAAPL中。

在产生式中使用CPEAAPL

现在我们可以在AssignmentExpression产生式中使用这个非常宽纵的CPEAAPL。（注意：ConditionalExpression通过一个长长的产生式链通往PrimaryExpression，这里没有展示中间经过的产生式。）

AssignmentExpression :
  ConditionalExpression
  ArrowFunction
  ...

ArrowFunction :
  ArrowParameters => ConciseBody

ArrowParameters :
  BindingIdentifier
  CPEAAPL

PrimaryExpression :
  ...
  CPEAAPL

想象一下，我们再次碰到之前的情形：解析到AssignmentExpression之后，下一个标记是(。这一次我们可以解析CPEAAPL，到后面再看要使用哪个产生式。此时是解析ArrowFunction还是解析ConditionalExpression并不重要，无论解析哪一个，下一个要解析的符号都是CPEAAPL！

解析完CPEAAPL之后，就可以决定最开始的（包含这个CPEAAPL的）AssignmentExpression使用哪个产生式了。这是由CPEAAPL后面跟着的标记决定的。

如果这个标记是=>，则使用下面的产生式：

AssignmentExpression :
  ArrowFunction

如果这个标记是其他什么，则使用这个产生式：

AssignmentExpression :
  ConditionalExpression

例如：

let x = (a, b) => { return a + b; };
//      ^^^^^^
//     CPEAAPL
//             ^^
//             跟在CPEAAPL后面的标记

let x = (a, 3);
//      ^^^^^^
//     CPEAAPL
//            ^
//            跟在CPEAAPL后面的标记

此时可以保持CPEAAPL不变，继续解析程序其余部分。比如，如果这个CPEAAPL在ArrowFunction中，那现在还不需要看它是不是有效的箭头函数参数列表，可以在后面再检查。（实际的解析器可以选择此时立即做有效性检查，但从规范角度看这不是必需的。）

限制CPEAAPL

如前所示，CPEAAPL的产生式非常宽纵，允许根本不合法的构造（如(1, ...a)）。在按照文法解析完程序后，需要驳回其中不合法的构造。

规范为此增加了如下限制：

静态语义：前期错误

PrimaryExpression : CPEAAPL

• 如果 CPEAAPL 未包含ParenthesizedExpression就是一个语法错误。

补充语法

在处理以下产生式的实例时

PrimaryExpression : CPEAAPL

对CPEAAPL的解释使用以下文法改进（refine）：

ParenthesizedExpression : ( Expression )

这意味着：如果CPEAAPL在语法树中出现在PrimaryExpression中，那它实际上是ParenthesizedExpression，而这是它唯一有效的产生式。

Expression永远不能为空，因此( )不是有效的ParenthesizedExpression。逗号分隔的列表，如(1, 2, 3)是通过逗号操作符创建的：

Expression :
  AssignmentExpression
  Expression , AssignmentExpression

类似地，如果CPEAAPL出现在ArrowParameters中，则适用如下限制：

静态语义：前期错误

ArrowParameters : CPEAAPL

• 如果 CPEAAPL 未包含ArrowFormalParameters就是一个语法错误。

补充语法

在处理以下产生式的实例时

ArrowParameters : CPEAAPL

对CPEAAPL的解释使用以下文法改进（refine）：

ArrowFormalParameters : ( UniqueFormalParameters )

其他包含文法

除了CPEAAPL，规范还对其他看起来不明确的构造使用了包含文法。

出现在箭头函数参数列表中的ObjectAssignmentPattern把ObjectLiteral用作包含文法。这意味着ObjectLiteral允许在实际的对象字面量中不能出现的构造。

ObjectLiteral :
  ...
  { PropertyDefinitionList }

PropertyDefinition :
  ...
  CoverInitializedName

CoverInitializedName :
  IdentifierReference Initializer

Initializer :
  = AssignmentExpression

比如：

let o = { a = 1 }; // 语法错误

// 箭头函数使用了带默认值的解构参数：
let f = ({ a = 1 }) => { return a; };
f({}); // 返回1
f({a : 6}); // 返回6

异步箭头函数在使用有限前查时同样有歧义：

let x = async(a,

是调用async函数呢，还是一个异步箭头函数？

let x1 = async(a, b);
let x2 = async();
function async() { }

let x3 = async(a, b) => {};
let x4 = async();

为此，文法定义了一个包含文法符号CoverCallExpressionAndAsyncArrowHead，其原理与CPEAAPL类似。

小结

本文介绍了规范怎么定义包含文法，并且在基于有限前查无法识别当前语法构造时使用它们。

特别地，我们探讨了区分箭头函数参数与带括号的表达式，以及规范在碰到看不懂的构造时怎么宽纵地使用包含文法，并且又在后面用静态语义来限制它们。