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

原文链接:https://v8.dev/blog/understanding-ecmascript-part-3

这一次我们深入ECMAScript语言及其语法的定义。如果你不太熟悉上下文无关文法,应该先补补课,至少先弄懂一些基本概念。因为规范中使用了上下文无关文法定义语言。

ECMAScript文法

ECMAScript规范定义了4种文法。

  1. 词法文法:描述怎么把Unicode码点(code point)翻译为输入元素(标记、行终止符、注释、空白)序列。
  2. 语法文法:定义标记(token)怎么构成语法正确的程序。
  3. 正则文法:描述怎么把Unicode码点翻译为正则表达式。
  4. 数值字符串文法:描述怎么把String翻译成数字值。

每种文法都用上下文无关文法来定义,都包含一组产生式。

不同的文法使用了不同的表示方式。语法文法表示为LeftHandSideSymbol :,词法文法和正则文法表示为LeftHandSideSymbol ::,而数值字符串文法表示为LeftHandSideSymbol :::。(以冒号的多少来区分。——译者注)

接下来我们详细分析一下词法文法和语法文法。

词法文法

规范将ECMAScript源文本定义为一个Unicode码点序列。这意味着变量名并不限于ASCII字符,也可以包含其他Unicode字符。规范并没有谈到实际的编码(如UTF-8或UTF-16),而是假设源代码已经按照自己的编码转换成了Unicode码点序列。

无法提前对ECMAScript源码进行标记化(tokenize),这使得定义词法文法略显复杂。比如,如果不看它所处的更大的上下文,就无法确定/是除法操作符还是正则表达式的开始。

const x = 10 / 5;

这里的/是DivPunctuator

const r = /foo/;

这里/是RegularExpressionLiteral的开头。

模板也引入了类似的歧义:对}`的解释取决于它出现的上下文:

const what1 = 'temp';
const what2 = 'late';
const t = `I am a ${ what1 + what2 }`;

这里I am a ${TemplateHead,而}`是TemplateTail。

if (0 == 1) {
}`not very useful`;

这里}RightBracePunctuator ,而`NoSubstitutionTemplate的开头。

即便对/}`的解释取决于上下文(它们在代码语法结构中的位置),我们下面介绍的文法仍然是上下文无关的。

词汇文法使用一些目标符号(goal symbol)来区分哪些上下文允许哪些输入元素,不允许哪些输入元素。例如,目标符号InputElementDiv(注意,这里的Div是Divide,即除法的意思。——译者注)会用在/是除法和/=是除法赋值的上下文中。InputElementDiv产生式列出了在此上下文中可能产生的标记:

InputElementDiv ::
  WhiteSpace
  LineTerminator
  Comment
  CommonToken
  DivPunctuator
  RightBracePunctuator

在这个上下文中,遇到/产生输入元素DivPunctuator,而不会产生RegularExpressionLiteral

相应地,对于/是正则表达式开头的上下文,目标符号是InputElementRegExp

InputElementRegExp ::
  WhiteSpace
  LineTerminator
  Comment
  CommonToken
  RightBracePunctuator
  RegularExpressionLiteral

这个产生式可以产生RegularExpressionLiteral输入元素,但不可能产生DivPunctuator

类似地,目标符号InputElementRegExpOrTemplateTail对应的上下文除了RegularExpressionLiteral,还允许出现TemplateMiddleTemplateTailt。最后一个InputElementTemplateTail目标符号的上下文只允许TemplateMiddleTemplateTail,不允许出现RegularExpressionLiteral

在实现中,语法文法分析器(“解析器”)可以调用词法文法分析器(“标记器”或“词法器”),将目标符号作为参数传递,并请求适合该目标符号的下一个输入元素。

语法文法

词法文法定义了如何从Unicode码点构建标记。语法文法建立在它的基础上,定义了标记如何组成语法正确的程序。

例子:允许遗留标识符

给文法增加新关键字有可能造成破坏:如果原有代码已经使用该关键字作为标识符了怎么办?

例如,在await还不是关键字的时候,可能出现这样的代码:

function old() {
  var await;
}

ECMAScript文法谨慎地添加了await关键字,以便这段代码可以继续工作。在async函数里面,await是一个关键字,所以不能这样写:

async function modern() {
  var await; // 语法错误
}

在非生成器中允许yield,而在生成器中不允许与此类似。

要理解怎么允许await作为标识符,需要理解ECMAScript特定的语法文法表示。

产生式与简写形式

来看看VariableStatement的产生式是怎么定义的。乍一看,这个文法有点吓人:

VariableStatement[Yield, Await] :
  var VariableDeclarationList[+In, ?Yield, ?Await] ;

这里的下标([Yield, Await])和前缀(+In里的+?Await里的?)都什么意思呀?

这种表示法在“文法表示法”中有解释。

下标是对一组产生式的简写形式,一次性表达了一组产生式左端(left-hand side)符号。这个产生式左端符号有两个参数,它们可以展开为四个“真正的”产生式左端符号:

  • VariableStatement
  • VariableStatement_Yield
  • VariableStatement_Await
  • VariableStatement_Yield_Await

注意,以上VariableStatement就表示VariableStatement,没有_Await也没有_Yield。不要把它跟VariableStatement[Yield, Await](简写形式)弄混了。

在产生式右端,可以看到简写+In,意思是“使用带_In的版本”,而?Await的意思是“当且仅当左端符号有_Await时使用带_Await的版本”(?Yield也是类似的)。

第三种简写形式~Foo,意思是“使用没有_Foo的版本”(这个产生式中没有出现)。

了解了这些,可以把上面的产生式展开成这样:

VariableStatement :
  var VariableDeclarationList_In ;

VariableStatement_Yield :
  var VariableDeclarationList_In_Yield ;

VariableStatement_Await :
  var VariableDeclarationList_In_Await ;

VariableStatement_Yield_Await :
  var VariableDeclarationList_In_Yield_Await ;

最后,还有要搞清楚两件事。

  1. 在哪里确定我们处在有_Await或没有_Await的情况下?
  2. 有它和没它有什么区别,或者说Something_Await的产生式和Something(没有_Await)的产生式是在哪里分叉的?

_Await还是没有_Await

先解决第一个问题。因为很容易猜到可以根据函数体是否带_Await来区分异步函数和非异步函数。看异步函数声明的产生式,我们发现了这个

AsyncFunctionBody :
  FunctionBody[~Yield, +Await]

注意AsyncFunctionBody没有参数,参数在右端被添加给了FunctionBody。展开这个产生式得到:

AsyncFunctionBody :
  FunctionBody_Await

换句话说,异步函数有FunctionBody_Await(即一个await会被当成关键字的)函数体。

另一方面,如果是在非异步函数中,相关产生式为:

FunctionDeclaration[Yield, Await, Default] :
  function BindingIdentifier[?Yield, ?Await] ( FormalParameters[~Yield, ~Await] ) { FunctionBody[~Yield, ~Await] }

FunctionDeclaration还有一个产生式,但跟我们的代码示例不相关。)

为避免组合展开,我们忽略Default参数,因为这个特别的产生式中没用到。于是,这个产生式的展开形式为:

FunctionDeclaration :
  function BindingIdentifier ( FormalParameters) { FunctionBody }

FunctionDeclaration_Yield :
  function BindingIdentifier_Yield ( FormalParameters) { FunctionBody }

FunctionDeclaration_Await :
  function BindingIdentifier_Await ( FormalParameters) { FunctionBody }

FunctionDeclaration_Yield_Await :
  function BindingIdentifier_Yield_Await ( FormalParameters) { FunctionBody }

在这个产生式中,只有FunctionBodyFormalParameters(不带_Yield,也不带_Await),因为在未展开的产生式中它们都有参数[~Yield, ~Await]

函数名的处理方式就不一样了:如果产生式左端符号中包含_Yield_Await,则右端的函数名也会带上相应参数。

总结:异步函数有FunctionBody_Await,而非异步函数有FunctionBody(不带_Await)。因为我们讨论的是非生成器函数,所以无论异步示例函数还是非异步示例函数,都不会带参数_Yield

可能记住哪个是FunctionBody,哪个是FunctionBody_Await有点难。在有FunctionBody_Await的函数体中,await是标识符,还是关键字?

可以把_Await参数的意思理解为“await是一个关键字。”这样理解在将来也不会有问题。假设将来又添加了一个blob关键字,但只适用于“斑驳”(blobby)函数。非斑驳、非异步、非生成器的函数仍然有FunctionBody(不带_Yield_Await_Blob),跟现在完全一样。斑驳函数则会有FunctionBody_Await_Blob等。虽然仍然要在产生式中添加Blob下标,但已存在函数的FunctionBody的展开形式还跟以前一样。

不允许await用作标识符

接下来,我们要搞清楚在FunctionBody_Await中,是怎么不允许await用作标识符的。

仔细看一看产生式,可以发现从FunctionBody到之前的VariableStatement产生式都带_Await参数。因此,在异步函数中,就有VariableStatement_Await,而在非异步函数中,则有VariableStatement

再看仔细一点,注意一下参数。我们已经看到了这个VariableStatement的产生式:

VariableStatement[Yield, Await] :
  var VariableDeclarationList[+In, ?Yield, ?Await] ;

所有VariableDeclarationList的产生式也都照样带这些参数:

VariableDeclarationList[In, Yield, Await] :
  VariableDeclaration[?In, ?Yield, ?Await]

(这里只展示与我们例子相关的产生式。)

VariableDeclarationList[In, Yield, Await] :
  BindingIdentifier[?Yield, ?Await] Initializer[?In, ?Yield, ?Await]opt ;

这里的opt简写代表产生式右端符号是可选的,也就是实际上有两个产生式:一个带可选的符号(Initializer),另一个不带。

对我们简单的例子来说,VariableStatement包含关键字var,紧跟一个BindingIdentifier(没有初始化器Initializer),以分号结束。

为了允许或不允许await用作BindingIdentifier,我们希望最终看到这些:

BindingIdentifier_Await :
  Identifier
  yield

BindingIdentifier :
  Identifier
  yield
  await

这表示在异步函数中不允许await作为标识符,在非异步函数允许它作为标识符。

实际上规范中并没有给出这样的定义,而我们找到的是这个产生式:

BindingIdentifier[Yield, Await] :
  Identifier
  yield
  await

展开后得到:

BindingIdentifier_Await :
  Identifier
  yield
  await

BindingIdentifier :
  Identifier
  yield
  await

(这里省略了BindingIdentifier_YieldBindingIdentifier_Yield_Await的产生式,因为我们的例子不需要。)

这么看awaityield任何时候都可以作为标识符。这是怎么回事啊?这篇文章难道白写了吗?

静态语义出马

原来为了在异步函数中禁止将await用作标识符,还需要用到静态语义

静态语义描述静态规则,也就是在程序运行前要校验的规则。

对我们的例子而言,BindingIdentifier的静态语义定义了以下语法导向的规则:

BindingIdentifier[Yield, Await] : await
  • 如果这个产生式有[Await]参数就是一个语法错误(Syntax Error)。

实际上,这就是禁止BindingIdentifier_Await : await产生式。

规范解释说,之所以存在这个产生式但又通过静态语义将它定义为语法错误,是因为与ASI(Automatic Semicolon Insertion,自动插入分号)冲突。

我们知道,在无法根据语法产生式解析一行代码时,ASI就会介入。ASI尝试添加分号以满足语句和声明必须以分号结束的要求。(关于ASI的详细介绍,可以看下一篇文章。)

来看下面的代码(规范中的例子):

async function too_few_semicolons() {
  let
  await 0;
}

如果文法不允许await作用标识符,ASI就会介入并将上面的代码转换为下面这样文法正确的代码,这样let也会被当成标识符:

async function too_few_semicolons() {
  let;
  await 0;
}

与ASI的这种冲突被认为太令人困惑,因此才用静态语义禁止await作为标识符。

不允许标识符的StringValues

还有另一条相关规则:

BindingIdentifier : Identifier
  • 如果这个产生式有[Await]参数,且IdentifierStringValue"await",就是一个语法错误(Syntax Error)。

乍一看不好理解。Identifier的定义如下:

 Identifier  : 
  IdentifierName but not ReservedWord

await是个ReservedWord,因此Identifier怎么可能是await呢?

的确,Identifier不可能是await,但可以是StringValue"await"(字符序列await的一种不同的表示方式)的其他值。

标识符名的静态语义定义了如何计算标识符的StringValue。比如,a的Unicode转义序列是\u0061,因此\u0061waitStringValue"await"\u0061wait不会被词法语法识别为关键字,而会被识别为Identifier。静态语义禁止在异步函数中使用它作为变量名。

因此,这样可以:

function old() {
  var \u0061wait;
}

但这样不行:

async function modern() {
  var \u0061wait; // 语法错误
}

小结

通过学习这篇文章,我们了解了词法文法、语法文法,以及用于定义语法文法的简写形式。作为例子,我们研究了await在异步函数中被禁止用作标识符,但在非异步函数中则允许。

下一篇文章将介绍词法文法其他有意思的部分,比如自动插入分号(ASI)和包含文法(cover grammar)。

标签: none

添加新评论