理解ECMAScript规范（Part 3）

March 9, 2024

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

本节中，我们将深入了解 ECMAScript 语言及其语法定义。如果你不熟悉上下文无关文法，现在是查阅基础知识的好时机，因为规范使用上下文无关文法来定义语言。
参见《Crafting Interpreters》中有关上下文无关文法的章节以了解通俗易懂的介绍，或参见维基百科页面以了解更数学化的定义。

ECMAScript 语法

ECMAScript 规范定义了四种语法：

词法语法描述了如何将 Unicode 代码点转化为一系列 输入元素（标记、行终止符、注释、空白）。

句法语法定义了语法正确的程序如何由标记组成。

正则表达式语法描述了如何将 Unicode 代码点转换为正则表达式。

数字字符串语法描述了如何将字符串转换为数字值。

每个语法都定义为一个上下文无关文法，由一组产生式组成。

语法使用稍微不同的表示法：句法语法使用 LeftHandSideSymbol : ，而词法语法和正则表达式语法使用 LeftHandSideSymbol :: ，数字字符串语法使用 LeftHandSideSymbol ::: 。

接下来，我们将更详细地研究词法语法和句法语法。

词法语法

规范将 ECMAScript 源文本定义为 Unicode 代码点的序列。例如，变量名不仅限于 ASCII 字符，还可以包括其他 Unicode 字符。
规范并未讨论实际编码（例如 UTF-8 或 UTF-16）。它假定根据源代码所在的编码，源代码已经转换为 Unicode 代码点序列。

无法预先标记 ECMAScript 源代码，这使得词法语法的定义变得稍微复杂一些。

例如，如果不对出现 / 的上下文进行更宏观的观察，我们就无法确定 / 是除法运算符还是正则表达式的开始：

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 的开始。

即使 / 和 }` 的解释取决于它们的“上下文”（它们在代码语法结构中的位置），但我们接下来描述的语法仍然是上下文无关的。

词法语法使用几个目标符号来区分允许使用某些输入元素或不允许使用某些输入元素的上下文。
例如，目标符号 InputElementDiv 用于 / 表示除法和 /= 表示除法赋值的上下文。
InputElementDiv 产生式列出了可以在此上下文中产生的可能的标记：

InputElementDiv ::
  WhiteSpace
  LineTerminator
  Comment
  CommonToken
  DivPunctuator
  RightBracePunctuator

在此上下文中，遇到 / 会产生 DivPunctuator 输入元素。在此处生成 RegularExpressionLiteral 不是一个可选项。

另一方面，InputElementRegExp 是 / 是正则表达式开头的上下文的的目标符号：

InputElementRegExp ::
  WhiteSpace
  LineTerminator
  Comment
  CommonToken
  RightBracePunctuator
  RegularExpressionLiteral

从产生式中可以看出，有可能产生 RegularExpressionLiteral 输入元素，但生成 DivPunctuator 是不可能的。

类似地，还有另一个目标符号 InputElementRegExpOrTemplateTail ，用于允许 TemplateMiddle 和 TemplateTail 的上下文，以及 RegularExpressionLiteral 。
最后，InputElementTemplateTail 是只允许 TemplateMiddle 和 TemplateTail 但不允许 RegularExpressionLiteral 的上下文的目标符号。

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

句法语法

我们研究了词法语法，它定义了如何从 Unicode 代码点构造标记。句法语法基于它：它定义了语法正确的程序如何由标记组成。

示例：允许旧标识符

向语法中引入新关键字是一个有可能会破坏现有代码的更改——如果现有代码已经将关键字用作标识符怎么办？

例如，在 await 成为一个关键字之前，某人可能编写了以下代码：

function old() {
  var await;
}

ECMAScript 语法仔细地添加了 await 关键字，以便此代码继续工作。在异步函数内，await 是一个关键字，所以这是不起作用的：

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

在非生成器中允许 yield 作为标识符，而在生成器中不允许 yield 的工作方式类似。

了解 await 如何作为标识符被允许需要了解 ECMAScript 特定的句法语法符号。让我们直接深入了解一下！

产生式和速记符号

让我们看看 VariableStatement 的产生式是如何定义的。对语法的一瞥可能会让人有点望而生畏：

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

下标（[Yield, Await]）和前缀（+ 在 +In 中以及 ? 在 ?Async 中）是什么意思？

符号在 [语法符号] 部分（https://tc39.es/ecma262/#sec-grammar-notation）中进行了解释。

下标都是一次用于表示一组左侧符号的产生式集的速记符号。左侧符号有两个参数，这两个参数展开成四个“真正的”左侧符号：VariableStatement、VariableStatement_Yield、VariableStatement_Await 和 VariableStatement_Yield_Await。

请注意，这里的普通 VariableStatement 表示“没有 _Await 和 _Yield 的 VariableStatement”。它不应与 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 ;

最终，我们需要找出两件事：

在何处决定我们是使用带有 _Await 还是不带有 _Await 的情况？
在何处产生差异——Something_Await 和 Something（没有 _Await）的产生式在何处出现分歧？

`_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 }

在此产生式中，我们始终得到 FunctionBody 和 FormalParameters（没有 _Yield 和没有 _Await），因为它们在未展开的产生式中使用 [~Yield, ~Await] 进行参数化。

函数名称的处理不同：如果左侧符号具有 _Await 和 _Yield，则函数名称将获得参数 _Await 和 _Yield。

总结一下：异步函数具有 FunctionBody_Await，非异步函数具有 FunctionBody（没有 _Await）。
由于我们讨论的是非生成器函数，因此我们的异步示例函数和非异步示例都使用不带 _Yield 的参数。

也许很难记住哪一个是 FunctionBody，哪一个是 FunctionBody_Await。
FunctionBody_Await 是用于 await 是标识符的函数，还是用于 await 是关键字的函数？

你可以将 _Await 参数理解为“await 是一个关键字”。这种方法还可以面向未来。想象一下，添加了一个新关键字 blob，但仅在“blob 状”函数内。
非 blob 状的非异步非生成器仍会具有 FunctionBody（没有 _Await、_Yield 或 _Blob），就像它们现在一样。
Blob 状函数将具有 FunctionBody_Blob，异步 blob 状函数将具有 FunctionBody_Await_Blob，依此类推。
我们仍然需要向产生式添加 Blob 下标，但已经存在的函数的 FunctionBody 的展开形式保持不变。

不允许 `await` 作为标识符

接下来，我们需要找出如何在 FunctionBody_Await 内部将 await 不允许作为一个标识符。

我们可以进一步跟踪产生式，以了解 _Await 参数如何从 FunctionBody 原封不动地传递到我们先前看到的 VariableStatement 产生式。

因此，在异步函数内，我们将有一个 VariableStatement_Await，在非异步函数内，我们将有一个 VariableStatement。

我们可以进一步跟踪产生式，并跟踪参数。我们已经看到了 VariableStatement 的产生式：

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

VariableDeclarationList 的所有产生式都会原封不动地传递参数：

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

（这里我们只展示与我们的示例相关的产生式。）

VariableDeclaration[In, Yield, Await] :
  BindingIdentifier[?Yield, ?Await] Initializer[?In, ?Yield, ?Await] opt

速记符号 opt 表示右侧符号是可选的；实际上有两个产生式，一个带有可选符号，一个不带有可选符号。

在与我们的示例相关的简单情况下，VariableStatement 由关键字 var 组成，后面跟着一个没有初始值设定项的 BindingIdentifier，最后以分号结尾。

为了不允许或允许 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_Yield 和 BindingIdentifier_Yield_Await 的产生式。）

这看起来像 await 和 yield 将始终被允许用作标识符。怎么回事？整篇博文都白写了？

静态语义来救援

事实证明，禁止将 await 作为异步函数内的标识符需要 静态语义。

静态语义描述静态规则——也就是说，在程序运行之前检查的规则。

在这种情况下，BindingIdentifier 的静态语义定义了以下语法导向规则：

BindingIdentifier[Yield, Await] : await
如果此产生式具有 [Await] 参数，则这是 Syntax Error。

实际上，这禁止了 BindingIdentifier_Await : await 产生式。

规范解释说，之所以有此产生式但通过静态语义将其定义为 Syntax Error，是因为与自动分号插入（ASI）发生干扰。

记住，当我们无法根据语法产生式解析代码行时，ASI 就会发挥作用。ASI 会尝试添加分号以满足语句和声明必须以分号结尾的要求。（我们将在以后的章节中详细描述 ASI。）

考虑以下代码（规范中的示例）：

async function too_few_semicolons() {
  let
  await 0;
}

如果语法不允许 await 作为标识符，ASI 会发挥作用并将代码转换成以下语法正确的代码，该代码也使用 let 作为标识符：

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

由于这种类型的与 ASI 的干扰被认为过于混乱，因此静态语义被用于禁止将 await 作为标识符。

标识符的不允许 `StringValue`

还有一条相关的规则：

BindingIdentifier : Identifier
如果此产生式具有 [Await] 参数并且 StringValue of Identifier 是 "await"，则这是 Syntax Error。

这起初可能会令人困惑。Identifier 定义如下：

Identifier :
  IdentifierName but not ReservedWord

await 是 ReservedWord，所以 Identifier 怎么会是 await 呢？

事实证明，Identifier 不能是 await，但它可以是 StringValue 为 "await" 的其他东西——字符序列 await 的不同表示形式。

标识符名称的静态语义定义了如何计算标识符名称的 StringValue。
例如，a 的 Unicode 转义序列是 \u0061，所以 \u0061wait 的 StringValue 是 "await"。
\u0061wait 不会被词法语法识别为关键字，而将是一个 Identifier。
静态语义禁止将其用作异步函数内的变量名。

因此，这是可行的：

function old() {
  var \u0061wait;
}

而这不行：

async function modern() {
  var \u0061wait; // Syntax error
}

总结

在本节中，我们熟悉了词法语法、句法语法以及用于定义句法语法的速记符号。
作为一个示例，我们研究了禁止在异步函数内将 await 用作标识符，但在非异步函数内允许将其用作标识符。

句法语法的其他有趣部分，例如自动分号插入和覆盖语法，将在以后的章节中介绍。敬请期待！

←Back to home

This work is licensed under CC BY-NC-SA 4.0

NickName

E-Mail

Website

Comments

Latest
Oldest
Hottest

No comment yet.

YieldRay

理解ECMAScript规范（Part 3）

Preview: