翻译本文的目的是尝试给出 ECMAScript 规范中核心术语的译法,供同好品评。
原文链接:https://v8.dev/blog/understanding-ecmascript-part-4
Mozilla 的Jason Orendorff[1]写了一篇深入分析 JS 诡异语法的文章。虽然实现细节上有差异,但每个 JS 引擎在这些诡异的细节上都会面对同样的问题。
这篇文章将深入探讨包含文法(cover grammar)。包含文法是为那些乍一看模棱两可的语法构造规定文法的一种方式。
为简单起见,我们跳过下标[In, Yield, Await]
,因为对本文不重要。可以参考第三篇文章[2],了解它们的含义和用法。
通常,解析器在有限前查(finite lookhead,跟进固定个数的标记)基础上决定使用哪个产生式。
有时候,下一个标记可以毫无歧义地决定要使用的产生式。例如[3]:
<pre>
<i>UpdateExpression</i> :
<i>LeftHandSideExpression</i>
<i>LeftHandSideExpression</i> ++
<i>LeftHandSideExpression</i> --
++ <i>UnaryExpression</i>
-- <i>UnaryExpression</i>
</pre>
<!--more-->
如果我们正在解析UpdateExpression
且下一个标记是++
或--
,那我们马上就知道要使用哪个产生式。如果下一个标记不是它们两个,那也问题不大,可以从所在位置开始解析LeftHandSideExpression
,解析完之后再决定下一步干什么。
如果LeftHandSideExpression
后面的标记是++
,则要使用的产生式是UpdateExpression : LeftHandSideExpression ++
。后面是--
的情形类似。如果LeftHandSideExpression
后面的标记既不是++
也不是--
,则使用产生式UpdateExpression : LeftHandSideExpression
。
区分箭头函数参数列表与带括号的表达式更复杂一些。如:
let x = (a,
这是一个箭头函数的开头吗,如:
let x = (a, b) => { return a + b };
还是一个带括号的表达式,如:
let x = (a, 3);
括号中的内容,不管是什么,但可能是任意长度。因此不能根据有限标记确定它是什么。
想象一下,假设我们有下列直观的产生式:
<pre>
<i>AssignmentExpression</i> :
...
<i>ArrowFunction</i>
<i>ParenthesizedExpression</i>
<i>ArrowFunction</i> :
<i>ArrowParameterList</i> => <i>ConciseBody</i>
</pre>
那就可以使用有限前查来选择产生式。如果解析到AssignmentExpression
之后,下一个标记是(
,那怎么确定接下来解析什么?可以解析ArrowParameterList
,也可以解析ParenthesizedExpression
,但肯定有可能猜错。
CPEAAPL
规范通过增加一个符号来解决这个问题:CoverParenthesizedExpressionAndArrowParameterList
,简写成CPEAAL
。CPEAAL
表示既可能是ParenthesizedExpression
也可能是ArrowParameterList
,但现在不知道选哪个。
CPEAAL的产生式[4]非常宽纵,允许任何可以出现在ParenthesizedExpression
和ArrowParameterList
中的构造:
<pre>
<i> CPEAAPL </i> :
( <i>Expression</i> )
( <i>Expression ,</i> )
( )
( <i>... BindingIdentifier</i> )
( <i>... BindingPattern</i> )
( <i>Expression</i> , <i>... BindingIdentifier</i> )
( <i>ArrowFunction</i> , <i>... BindingPattern</i> )
</pre>
比如,下列表达式都是有效的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
,这里没有展示中间经过的产生式。)
<pre>
<i>AssignmentExpression</i> :
<i>ConditionalExpression</i>
<i>ArrowFunction</i>
...
<i>ArrowFunction</i> :
<i>ArrowParameters</i> => <i>ConciseBody</i>
<i>ArrowParameters</i> :
<i>BindingIdentifier</i>
<i>CPEAAPL</i>
<i>PrimaryExpression</i> :
...
<i>CPEAAPL</i>
</pre>
想象一下,我们再次碰到之前的情形:解析到AssignmentExpression
之后,下一个标记是(
。这一次我们可以解析CPEAAPL
,到后面再看要使用哪个产生式。此时是解析ArrowFunction
还是解析ConditionalExpression
并不重要,无论解析哪一个,下一个要解析的符号都是CPEAAPL
!
解析完CPEAAPL
之后,就可以决定最开始的(包含这个CPEAAPL
的)AssignmentExpression
使用哪个产生式了。这是由CPEAAPL
后面跟着的标记决定的。
如果这个标记是=>
,则使用下面的产生式:
<pre>
<i>AssignmentExpression</i> :
<i>ArrowFunction</i>
</pre>
如果这个标记是其他什么,则使用这个产生式:
<pre>
<i>AssignmentExpression</i> :
<i>ConditionalExpression</i>
</pre>
例如:
let x = (a, b) => { return a + b; };
// ^^^^^^
// CPEAAPL
// ^^
// 跟在CPEAAPL后面的标记
let x = (a, 3);
// ^^^^^^
// CPEAAPL
// ^
// 跟在CPEAAPL后面的标记
此时可以保持CPEAAPL
不变,继续解析程序其余部分。比如,如果这个CPEAAPL
在ArrowFunction
中,那现在还不需要看它是不是有效的箭头函数参数列表,可以在后面再检查。(实际的解析器可以选择此时立即做有效性检查,但从规范角度看这不是必需的。)
CPEAAPL
如前所示,CPEAAPL
的产生式非常宽纵,允许根本不合法的构造(如(1, ...a)
)。在按照文法解析完程序后,需要驳回其中不合法的构造。
规范为此增加了如下限制:
静态语义:前期错误[5]
PrimaryExpression : CPEAAPL
- 如果 CPEAAPL 未包含
ParenthesizedExpression
就是一个语法错误。
补充语法[6]
在处理以下产生式的实例时
PrimaryExpression : CPEAAPL
对
CPEAAPL
的解释使用以下文法改进(refine):
ParenthesizedExpression : ( Expression )
这意味着:如果CPEAAPL
在语法树中出现在PrimaryExpression
中,那它实际上是ParenthesizedExpression
,而这是它唯一有效的产生式。
Expression
永远不能为空,因此( )
不是有效的ParenthesizedExpression
。逗号分隔的列表,如(1, 2, 3)
是通过逗号操作符[7]创建的:
<pre>
<i>Expression</i> :
<i>AssignmentExpression</i>
<i>Expression</i> , <i>AssignmentExpression</i>
</pre>
类似地,如果CPEAAPL
出现在ArrowParameters
中,则适用如下限制:
静态语义:前期错误[8]
ArrowParameters : CPEAAPL
- 如果 CPEAAPL 未包含
ArrowFormalParameters
就是一个语法错误。
补充语法[9]
在处理以下产生式的实例时
ArrowParameters : CPEAAPL
对
CPEAAPL
的解释使用以下文法改进(refine):
ArrowFormalParameters : ( UniqueFormalParameters )
除了CPEAAPL
,规范还对其他看起来不明确的构造使用了包含文法。
出现在箭头函数参数列表中的ObjectAssignmentPattern
把ObjectLiteral
用作包含文法。这意味着ObjectLiteral
允许在实际的对象字面量中不能出现的构造。
<pre>
<i>ObjectLiteral</i> :
...
{ <i>PropertyDefinitionList</i> }
<i>PropertyDefinition</i> :
...
<i>CoverInitializedName</i>
<i>CoverInitializedName</i> :
<i>IdentifierReference Initializer</i>
<i>Initializer</i> :
= <i>AssignmentExpression</i>
</pre>
比如:
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
类似。
本文介绍了规范怎么定义包含文法,并且在基于有限前查无法识别当前语法构造时使用它们。
特别地,我们探讨了区分箭头函数参数与带括号的表达式,以及规范在碰到看不懂的构造时怎么宽纵地使用包含文法,并且又在后面用静态语义来限制它们。
[1] Jason Orendorff: https://github.com/jorendorff
[2] 第三篇文章: https://lisongfeng.cn/2020/09/16/understanding-ecmascript-part-3.html
[3] 例如: https://tc39.es/ecma262/#prod-UpdateExpression
[4] CPEAAL
的产生式: https://tc39.es/ecma262/#prod-CoverParenthesizedExpressionAndArrowParameterList
[5] 静态语义:前期错误: https://tc39.es/ecma262/#sec-grouping-operator-static-semantics-early-errors
[6] 补充语法: https://tc39.es/ecma262/#sec-expression
[7] 逗号操作符: https://tc39.es/ecma262/#sec-comma-operator
[8] 静态语义:前期错误: https://tc39.es/ecma262/#sec-arrow-function-definitions-static-semantics-early-errors
[9] 补充语法: https://tc39.es/ecma262/#sec-arrow-function-definitions
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8