理解 ECMAScript 规范(4)

时间:2021-2-20 作者:admin

翻译本文的目的是尝试给出 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,简写成CPEAALCPEAAL表示既可能是ParenthesizedExpression也可能是ArrowParameterList,但现在不知道选哪个。

CPEAAL的产生式非常宽纵,允许任何可以出现在ParenthesizedExpressionArrowParameterList中的构造:

 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不变,继续解析程序其余部分。比如,如果这个CPEAAPLArrowFunction中,那现在还不需要看它是不是有效的箭头函数参数列表,可以在后面再检查。(实际的解析器可以选择此时立即做有效性检查,但从规范角度看这不是必需的。)

限制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,规范还对其他看起来不明确的构造使用了包含文法。

出现在箭头函数参数列表中的ObjectAssignmentPatternObjectLiteral用作包含文法。这意味着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类似。

小结

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

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

声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。