├── .gitignore
├── part2.md
├── part1
├── 1.10-liu-cheng-kong-zhi.md
├── README.md
├── 1-1-intro.md
├── 1-6-ast-interpreter.md
├── 1-2-source.md
├── 1-9-ast-calculator.md
├── 1-4-lexer.md
├── 1-3-hi.md
├── 1-5-parser.md
├── 1-8-arith-precedence-assoc.md
└── 1-7-arith-left-recursion.md
├── images
├── prog.png
├── STRING.png
├── say_hi.png
├── source.svg
└── expr123.svg
├── .gitbook
└── assets
│ ├── prog.png
│ ├── prog (1).png
│ ├── say_hi.png
│ ├── string.png
│ ├── say_hi (1).png
│ ├── string (1).png
│ ├── source.svg
│ └── expr123.svg
├── .vscode
└── settings.json
├── code
└── hi
│ ├── package.json
│ ├── test.js
│ ├── visitor.js
│ ├── interpret-visitor.js
│ ├── yaml-visitor.js
│ ├── package-lock.json
│ ├── source.js
│ ├── lexer.js
│ └── parser.js
├── README.md
└── SUMMARY.md
/.gitignore:
--------------------------------------------------------------------------------
1 | .DS_Store
2 | node_modules/
--------------------------------------------------------------------------------
/part2.md:
--------------------------------------------------------------------------------
1 | # 编译器篇
2 |
3 | TBD
4 |
5 |
--------------------------------------------------------------------------------
/part1/1.10-liu-cheng-kong-zhi.md:
--------------------------------------------------------------------------------
1 | # 1.10 流程控制
2 |
3 |
--------------------------------------------------------------------------------
/images/prog.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/hsiaosiyuan0/icj/HEAD/images/prog.png
--------------------------------------------------------------------------------
/images/STRING.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/hsiaosiyuan0/icj/HEAD/images/STRING.png
--------------------------------------------------------------------------------
/images/say_hi.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/hsiaosiyuan0/icj/HEAD/images/say_hi.png
--------------------------------------------------------------------------------
/.gitbook/assets/prog.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/hsiaosiyuan0/icj/HEAD/.gitbook/assets/prog.png
--------------------------------------------------------------------------------
/.gitbook/assets/prog (1).png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/hsiaosiyuan0/icj/HEAD/.gitbook/assets/prog (1).png
--------------------------------------------------------------------------------
/.gitbook/assets/say_hi.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/hsiaosiyuan0/icj/HEAD/.gitbook/assets/say_hi.png
--------------------------------------------------------------------------------
/.gitbook/assets/string.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/hsiaosiyuan0/icj/HEAD/.gitbook/assets/string.png
--------------------------------------------------------------------------------
/.gitbook/assets/say_hi (1).png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/hsiaosiyuan0/icj/HEAD/.gitbook/assets/say_hi (1).png
--------------------------------------------------------------------------------
/.gitbook/assets/string (1).png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/hsiaosiyuan0/icj/HEAD/.gitbook/assets/string (1).png
--------------------------------------------------------------------------------
/.vscode/settings.json:
--------------------------------------------------------------------------------
1 | {
2 | "cSpell.words": [
3 | "EBNF",
4 | "ofst",
5 | "sayhi"
6 | ]
7 | }
--------------------------------------------------------------------------------
/code/hi/package.json:
--------------------------------------------------------------------------------
1 | {
2 | "name": "hi",
3 | "version": "1.0.0",
4 | "description": "",
5 | "main": "interpret-visitor.js",
6 | "scripts": {
7 | "test": "echo \"Error: no test specified\" && exit 1"
8 | },
9 | "keywords": [],
10 | "author": "",
11 | "license": "ISC",
12 | "dependencies": {
13 | "js-yaml": "^3.13.1"
14 | }
15 | }
16 |
--------------------------------------------------------------------------------
/part1/README.md:
--------------------------------------------------------------------------------
1 | # 解释器篇
2 |
3 | 在这一整篇章节中，我们将从零开始，不断完善我们的第一个编程语言「hi 语言」。在本篇完成时，我们将得到一个可以解释执行的「hi 语言」版本。
4 |
5 | * [1.1 简述](1-1-intro.md)
6 | * [1.2 预备工作 - Source](1-2-source.md)
7 | * [1.3 我们的第一个语言 - hi](1-3-hi.md)
8 | * [1.4 词法解析器](1-4-lexer.md)
9 | * [1.5 语法解析器](1-5-parser.md)
10 | * [1.6 使用 AST - 第一个解释器](1-6-ast-interpreter.md)
11 | * [1.7 解析算术表达式 - 左递归和其消除法](1-7-arith-left-recursion.md)
12 | * [1.8 解析算术表达式 - 优先级与结合性](1-8-arith-precedence-assoc.md)
13 | * [1.9 使用 AST - 计算器](1-9-ast-calculator.md)
14 | * 1.10 流程控制
15 |
16 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # 使用 JavaScript 来实现解释器和编译器系列教程
2 |
3 | 该系列「icj, Writing Interpreters and Compilers in JavaScript」中，我们将一起使用 JavaScript 徒手实现编程语言解释器和编译器。因此整个系列分为「解释器篇」和「编译器篇」，[在线阅读](https://hsiaosiyuan0.gitbook.io/icj/)。
4 |
5 | * [解释器篇](part1/)
6 |
7 | 我们将逐步实现我们的第一个编程语言「hi 语言」。我们会一起从零开始构建它，然后以解释器的形式来实验它的功能。
8 |
9 | * [编译器篇](part2.md)
10 |
11 | 我们将继续完善我们的「hi 语言」，使之可以直接编译为 JavaScript，并在浏览器和 node 环境中运行我们的编译结果。
12 |
13 | 本系列所有代码，都归纳在 [code](https://github.com/hsiaosiyuan0/icj/tree/master/code) 目录下。
14 |
15 | 200 个 stars 继续更新怎么样
16 |
17 | **该系列文章属于原创，不可用于任何收费环节或者项目中。转载请注明出处。**
18 |
19 |
--------------------------------------------------------------------------------
/SUMMARY.md:
--------------------------------------------------------------------------------
1 | # Table of contents
2 |
3 | * [使用 JavaScript 来实现解释器和编译器系列教程](README.md)
4 | * [解释器篇](part1/README.md)
5 | * [1.1 简述](part1/1-1-intro.md)
6 | * [1.2 预备工作 - Source](part1/1-2-source.md)
7 | * [1.3 我们的第一个语言 - hi](part1/1-3-hi.md)
8 | * [1.4 词法解析器](part1/1-4-lexer.md)
9 | * [1.5 语法解析器](part1/1-5-parser.md)
10 | * [1.6 使用 AST - 第一个解释器](part1/1-6-ast-interpreter.md)
11 | * [1.7 解析算术表达式 - 左递归和其消除法](part1/1-7-arith-left-recursion.md)
12 | * [1.8 解析算术表达式 - 优先级与结合性](part1/1-8-arith-precedence-assoc.md)
13 | * [1.9 使用 AST - 计算器](part1/1-9-ast-calculator.md)
14 | * [1.10 流程控制](part1/1.10-liu-cheng-kong-zhi.md)
15 | * [编译器篇](part2.md)
16 |
17 |
--------------------------------------------------------------------------------
/code/hi/test.js:
--------------------------------------------------------------------------------
1 | const { Source } = require("./source");
2 | const { Lexer, TokenType } = require("./lexer");
3 | const { Parser } = require("./parser");
4 | const { InterpretVisitor } = require("./interpret-visitor");
5 | const { YamlVisitor } = require("./yaml-visitor");
6 | const util = require("util");
7 |
8 | const code = `print 1 + 2 ** 3 * 5`;
9 | const src = new Source(code);
10 | const lexer = new Lexer(src);
11 | const parser = new Parser(lexer);
12 |
13 | const ast = parser.parseProg();
14 | // const visitor = new YamlVisitor();
15 | // console.log(visitor.visitProg(ast));
16 | const visitor = new InterpretVisitor();
17 | visitor.visitProg(ast);
18 |
--------------------------------------------------------------------------------
/code/hi/visitor.js:
--------------------------------------------------------------------------------
1 | const { NodeType } = require("./parser");
2 |
3 | class Visitor {
4 | visitProg(node) {}
5 |
6 | visitSayHi(node) {}
7 |
8 | visitExprStmt(node) {}
9 |
10 | visitPrintStmt(node) {}
11 |
12 | visitStmt(node) {
13 | switch (node.type) {
14 | case NodeType.EXPR_STMT:
15 | return this.visitExprStmt(node);
16 | case NodeType.SAY_HI:
17 | return this.visitSayHi(node);
18 | case NodeType.PRINT_STMT:
19 | return this.visitPrintStmt(node);
20 | }
21 | }
22 |
23 | visitStmtList(list) {}
24 |
25 | visitNumLiteral(node) {}
26 |
27 | visitBinaryExpr(node) {}
28 |
29 | visitExpr(node) {
30 | switch (node.type) {
31 | case NodeType.NUMBER:
32 | return this.visitNumLiteral(node);
33 | case NodeType.BINARY_EXPR:
34 | return this.visitBinaryExpr(node);
35 | }
36 | }
37 | }
38 |
39 | module.exports = {
40 | Visitor
41 | };
42 |
--------------------------------------------------------------------------------
/code/hi/interpret-visitor.js:
--------------------------------------------------------------------------------
1 | const { Visitor } = require("./visitor");
2 |
3 | class InterpretVisitor extends Visitor {
4 | visitProg(node) {
5 | node.body.forEach(stmt => this.visitStmt(stmt));
6 | }
7 |
8 | visitSayHi(node) {
9 | console.log(`hi ${node.value}`);
10 | }
11 |
12 | visitBinaryExpr(node) {
13 | const left = this.visitExpr(node.left);
14 | const op = node.op.type;
15 | const right = this.visitExpr(node.right);
16 | switch (op) {
17 | case "+":
18 | return left + right;
19 | case "-":
20 | return left - right;
21 | case "*":
22 | return left * right;
23 | case "/":
24 | return left / right;
25 | case "**":
26 | return left ** right;
27 | }
28 | }
29 |
30 | visitPrintStmt(node) {
31 | console.log(this.visitExpr(node.value));
32 | }
33 |
34 | visitNumLiteral(node) {
35 | return parseInt(node.value);
36 | }
37 | }
38 |
39 | module.exports = {
40 | InterpretVisitor
41 | };
42 |
--------------------------------------------------------------------------------
/code/hi/yaml-visitor.js:
--------------------------------------------------------------------------------
1 | const { Visitor } = require("./visitor");
2 | const yaml = require("js-yaml");
3 |
4 | class YamlVisitor extends Visitor {
5 | visitProg(node) {
6 | return yaml.dump({
7 | type: node.type,
8 | body: this.visitStmtList(node.body)
9 | });
10 | }
11 |
12 | visitStmtList(list) {
13 | return list.map(stmt => this.visitStmt(stmt));
14 | }
15 |
16 | visitExprStmt(node) {
17 | return {
18 | type: node.type,
19 | value: this.visitExpr(node.value)
20 | };
21 | }
22 |
23 | visitPrintStmt(node) {
24 | return {
25 | type: node.type,
26 | value: this.visitExpr(node.value)
27 | };
28 | }
29 |
30 | visitBinaryExpr(node) {
31 | return {
32 | type: node.type,
33 | op: node.op.type,
34 | left: this.visitExpr(node.left),
35 | right: this.visitExpr(node.right)
36 | };
37 | }
38 |
39 | visitNumLiteral(node) {
40 | return node.value;
41 | }
42 | }
43 |
44 | module.exports = {
45 | YamlVisitor
46 | };
47 |
--------------------------------------------------------------------------------
/part1/1-1-intro.md:
--------------------------------------------------------------------------------
1 | # 1.1 简述
2 |
3 | 我们平时所书写的源码，是无法被计算机直接执行的，因此需要一个过程，来将源码转化成机器可以执行的代码，这个转化的过程，就是编译。
4 |
5 | 综合现在所有的编程语言实现来看，并不是只有编译为机器码的语言，比如 C语言，才能称为编译型的语言。这是因为原本看上去是解释执行的语言，在其内部也大都引入的编译的环节，比如 PHP 和 Lua，它们都会将源程序编译为中间代码，称之为 Opcode，然后交由引擎或者虚拟机来执行 Opcode。因此，编译主要是强调的源码转化的过程，笼统地将语言一分为二为编译型和解释型、在当下显得有些不严谨了。
6 |
7 | 编译的步骤可以被大致简单地划分为:
8 |
9 | 1. 词法分析
10 | 2. 语法分析
11 | 3. 语义分析
12 | 4. 生成中间代码
13 | 5. 生成目标代码
14 |
15 | 词法分析「Lexical Analysis」通过词法分析器「Lexer」来完成。词法分析器的作用就是扫描字符串，并输出作为语法单元的词素「Token」，因此它也被称为扫描器「Scanner」。
16 |
17 | 语法分析「Syntax Analysis」通过语法分析器「Parser」来完成。语法分析器的作用就是根据给定的语法「Grammar」来对词素进行分析，生成抽象语法树「AST, Abstract Syntax Tree」，抽象语法树用来描述程序的结构。
18 |
19 | 语义分析「Semantic Analysis」用来保证代码中的语义规则的完整性。比如类型检查「Type Checking」。语义分析过程中还会生成符号表「Symbol Table」并生成中间代码「Intermediate Code」。中间代码的作用就是进一步将词法分析的结果进行完善，方便接下来在生成目标代码时的工作。
20 |
21 | 之所以将编译的步骤进行这样的划分，是希望简化编译器的结构，加快编译的过程。并不是对所有语言而且，上述的环节都是必须的，比如语义分析，可以移到程序运行期间来完成。在 JavaScript 中，当我们引用一个未定义的变量时，会在运行阶段进行报错「ReferenceError」，这也是由于 JavaScript 的动态性，无法在编译环节发现这个错误。
22 |
23 | 我们在接下来的章节中，都会尽量地将一些特定中文词汇所对应的英文列出来，方便大家使用搜索引擎来进一步深入了解它们。
24 |
25 |
--------------------------------------------------------------------------------
/code/hi/package-lock.json:
--------------------------------------------------------------------------------
1 | {
2 | "name": "hi",
3 | "version": "1.0.0",
4 | "lockfileVersion": 1,
5 | "requires": true,
6 | "dependencies": {
7 | "argparse": {
8 | "version": "1.0.10",
9 | "resolved": "https://registry.npmjs.org/argparse/-/argparse-1.0.10.tgz",
10 | "integrity": "sha512-o5Roy6tNG4SL/FOkCAN6RzjiakZS25RLYFrcMttJqbdd8BWrnA+fGz57iN5Pb06pvBGvl5gQ0B48dJlslXvoTg==",
11 | "requires": {
12 | "sprintf-js": "~1.0.2"
13 | }
14 | },
15 | "esprima": {
16 | "version": "4.0.1",
17 | "resolved": "https://registry.npmjs.org/esprima/-/esprima-4.0.1.tgz",
18 | "integrity": "sha512-eGuFFw7Upda+g4p+QHvnW0RyTX/SVeJBDM/gCtMARO0cLuT2HcEKnTPvhjV6aGeqrCB/sbNop0Kszm0jsaWU4A=="
19 | },
20 | "js-yaml": {
21 | "version": "3.13.1",
22 | "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-3.13.1.tgz",
23 | "integrity": "sha512-YfbcO7jXDdyj0DGxYVSlSeQNHbD7XPWvrVWeVUujrQEoZzWJIRrCPoyk6kL6IAjAG2IolMK4T0hNUe0HOUs5Jw==",
24 | "requires": {
25 | "argparse": "^1.0.7",
26 | "esprima": "^4.0.0"
27 | }
28 | },
29 | "sprintf-js": {
30 | "version": "1.0.3",
31 | "resolved": "https://registry.npmjs.org/sprintf-js/-/sprintf-js-1.0.3.tgz",
32 | "integrity": "sha1-BOaSb2YolTVPPdAVIDYzuFcpfiw="
33 | }
34 | }
35 | }
36 |
--------------------------------------------------------------------------------
/code/hi/source.js:
--------------------------------------------------------------------------------
1 | const NL = "\n";
2 | const CR = "\r";
3 | const EOL = "\n";
4 | const EOF = "\x03";
5 |
6 | class Position {
7 | constructor(ofst, line, col) {
8 | this.ofst = ofst;
9 | this.line = line;
10 | this.col = col;
11 | }
12 | }
13 |
14 | class Source {
15 | constructor(code = "", file = "stdin") {
16 | this.code = code;
17 | this.file = file;
18 | this.ch = "";
19 | this.ofst = -1;
20 | this.line = 1;
21 | this.col = 0;
22 | this.isPeek = false;
23 | this.posStack = [];
24 | }
25 |
26 | read(cnt = 1) {
27 | const ret = [];
28 | let ofst = this.ofst;
29 | let c;
30 | while (cnt) {
31 | const next = ofst + 1;
32 | c = this.code[next];
33 | if (c === undefined) {
34 | c = EOF;
35 | ret.push(c);
36 | break;
37 | }
38 | ofst = next;
39 | if (c === CR || c === NL) {
40 | if (c === CR && this.code[next + 1] === NL) ofst++;
41 | if (!this.isPeek) {
42 | this.line++;
43 | this.col = 0;
44 | }
45 | c = EOL;
46 | } else if (!this.isPeek) this.col++;
47 | ret.push(c);
48 | cnt--;
49 | }
50 | if (!this.isPeek) {
51 | this.ch = c;
52 | this.ofst = ofst;
53 | }
54 | return ret.join("");
55 | }
56 |
57 | peek(cnt = 1) {
58 | this.isPeek = true;
59 | const ret = this.read(cnt);
60 | this.isPeek = false;
61 | return ret;
62 | }
63 |
64 | getPos() {
65 | return new Position(this.ofst, this.line, this.col);
66 | }
67 |
68 | pushPos() {
69 | this.posStack.push(this.getPos());
70 | }
71 |
72 | restorePos() {
73 | const pos = this.posStack.pop();
74 | if (pos === undefined)
75 | throw new LexerError("Unbalanced popping of position stack");
76 | this.ofst = pos.ofst;
77 | this.line = pos.line;
78 | this.col = pos.col;
79 | }
80 | }
81 |
82 | module.exports = {
83 | NL,
84 | CR,
85 | EOL,
86 | EOF,
87 | Position,
88 | Source
89 | };
90 |
--------------------------------------------------------------------------------
/part1/1-6-ast-interpreter.md:
--------------------------------------------------------------------------------
1 | # 1.6 使用 AST - 第一个解释器
2 |
3 | 但我们得到了程序的 AST 结构之后，我们可以围绕它做很多事情，接下来我们将通过编写一个解释器，来了解如何使用 AST。
4 |
5 | 因为 AST 是一个树形结构，那么很明显，我们需要通过遍历这个树形结构来使用它。
6 |
7 | 由于 AST 中有很多不同类型的节点\(尽管目前我们的 hi 语言只有寥寥无几的几个类型\)，而针对这些节点，我们大概率也会采取不同的操作，因此我们将对这些节点的操作都抽离出来，放到一个名为 Visitor 的类中。这也是利用了[设计模式](https://zh.wikipedia.org/wiki/设计模式_%28计算机%29)中的访问者模式「Visitor Pattern」。
8 |
9 | 下面我们来看一下 Visitor 的结构：
10 |
11 | ```javascript
12 | class Visitor {
13 | visitProg(node) {}
14 | visitSayHi(node) {}
15 | }
16 | ```
17 |
18 | 由于我们的 hi 语言太简单了，它只有两个节点类型，一个是 `PROG` 和 `SAY_HI`，所以我们的 Visitor 中的操作也只有两个。
19 |
20 | 现在我们开始实现我们的解释器，我们的解释器需要继承于 Visitor 类，我们给它取名「InterpretVisitor」：
21 |
22 | ```javascript
23 | class InterpretVisitor extends Visitor {
24 | visitProg(node) {
25 | node.body.forEach(stmt => this.visitSayHi(stmt));
26 | }
27 | visitSayHi(node) {
28 | console.log(`hi ${node.value}`);
29 | }
30 | }
31 | ```
32 |
33 | 因为 InterpretVisitor 的实现也非常的简单，我们就直接给出实现了。
34 |
35 | 可以看到，我们在 `visitProg` 内部，就是迭代节点的 `body` 属性，使用其中的元素为参数调用 `visitSayHi` 方法。回顾我们的 `Prog` 节点的定义：
36 |
37 | ```javascript
38 | class Prog extends Node {
39 | constructor(loc, body = []) {
40 | super(NodeType.Prog, loc);
41 | this.body = body;
42 | }
43 | }
44 | ```
45 |
46 | 我们将它其中的语句都存入了 `body` 属性数组中。
47 |
48 | 而对于 `visitSayHi` 方法的实现，我们则是简单地拼接一个 `hi ${something}` 字符串，然后打印该字符串。
49 |
50 | 我们将所有这些组合到一起，来运行一下我们的解释器：
51 |
52 | ```javascript
53 | const { Source } = require("./source");
54 | const { Lexer, TokenType } = require("./lexer");
55 | const { Parser } = require("./parser");
56 | const { InterpretVisitor } = require("./interpret-visitor");
57 | const util = require("util");
58 |
59 | const code = `hi "lexer"
60 | hi "parser"
61 | `;
62 | const src = new Source(code);
63 | const lexer = new Lexer(src);
64 | const parser = new Parser(lexer);
65 |
66 | const ast = parser.parseProg();
67 | const visitor = new InterpretVisitor();
68 | visitor.visitProg(ast);
69 | ```
70 |
71 | 幸运的话，我们会在控制台看到如下的输出：
72 |
73 | ```text
74 | hi lexer
75 | hi parser
76 | ```
77 |
78 | 到此为止，我们已经完成了一个解释型的语言。千万不要感到惊讶，尽管它目前非常的简单，但是它真的是一个编程语言。
79 |
80 |
--------------------------------------------------------------------------------
/part1/1-2-source.md:
--------------------------------------------------------------------------------
1 | # 1.2 预备工作 - Source
2 |
3 | 按照前文的介绍，我们本应该探索如何实现词法解析了。在进行词法分析器的讲解之前，我们最好还是先介绍辅助类 Source。
4 |
5 | 在读取字符串的过程中，我们需要统一换行符以及支持先行预测「Lookahead」，需要这些功能的原因后面会介绍。
6 |
7 | Source 类的结构如下：
8 |
9 | 
10 |
11 | 为了简化源文件的处理过程，我们将需要处理的源文件一次性整个地读取到属性 `code` 中，其余属性的含义分别为：
12 |
13 | | 属性 | 作用 |
14 | | :--- | :--- |
15 | | file | 源文件名 |
16 | | ch | 当前偏移量指代的字符 |
17 | | ofst | 当前的偏移量 |
18 | | line | 当前所在行号 |
19 | | col | 当前所在列号 |
20 | | isPeek | 用来标识当前是否处于 peek 模式 |
21 |
22 | 在 JS 中，可以通过下标来检索字符串中的字符。所以我们可以通过属性 `ofst` 作为下标来检索 `code` 中的字符，即 `this.code[this.ofst]` 的方式。
23 |
24 | `ch` 表示我们当前读取到的字符。
25 |
26 | `ofst` 被设定为指向当前字符 `ch` 在 `code` 中的索引位置。
27 |
28 | 比如，对于字符串 `abcd` 而言，当 `ch` 为 `a` 时，`ofst` 的值为 `0`。为了读取下一个字符 `b`，我们需要先将 `ofst` 加 1，以加 1 后的值作为索引来检索字符，即：
29 |
30 | ```javascript
31 | this.ofst += 1;
32 | this.ch = this.code[this.ofst];
33 | ```
34 |
35 | 因此，`ofst` 的初始值被我们设定为 `-1`。
36 |
37 | 在不断的读入字符的过程中，我们还需要维护行列号，行列号主要用作生成调试信息。
38 |
39 | Source 类目前只包含两个方法，分别是 `read` 和 `peak`。它们的作用都是读取给定数量的字符，组成字符串后返回给调用者。区别在于，`read` 方法会改变位置信息，包括 `ch`、`ofst`、`line`、`col`，而 `peek` 方法则不然。
40 |
41 | 我们使用 `peek` 方法来做先行预测，在出现可能分叉的地方进行使用。比如 Lua 中注释以 `--` 开头，我们可以直接向前 peek 两个字符，看看它们是否符合条件。
42 |
43 | _为了使读者能够快速地运行文中的代码，所有代码都可以在_ `node v11.5.0` _下直接运行而不需要借助_ [_Babel_](https://babeljs.io/) _之类的编译器。当然读者还是需要在运行前注意一下代码中的_ `require` _路径是否和自己的环境相匹配。_
44 |
45 | 下面给出 Source 的代码和注释：
46 |
47 | ```javascript
48 | // 不同的操作系统可能使用不同的字符作为换行字符，常见的情况有
49 | // \n, \r, \r\n 三种。
50 | // \n 叫做「LF，Linefeed」存在于「*nix，Unix-like」系统中
51 | // \r 叫做「Carriage Return」存在于老式的 MacOS 中
52 | // \r\n 存在于 Windows 中
53 | // 这里我们使用「NL，newline」作为换成的变量名，因为下面会将三种情况都统一成它。
54 | const NL = "\n";
55 | const CR = "\r";
56 | const EOL = "\n";
57 | // 0x03 在 ascii 表中的含义即为 end of text
58 | const EOF = "\x03";
59 |
60 | class Position {
61 | constructor(ofst, line, col) {
62 | this.ofst;
63 | this.line = line;
64 | this.col = col;
65 | }
66 | }
67 |
68 | class Source {
69 | // 我们的构造函数接收源文件代码，和源文件名
70 | // 源文件名用于生产调试信息
71 | constructor(code = "", file = "stdin") {
72 | this.code = code;
73 | this.file = file;
74 | this.ch = "";
75 | this.ofst = -1;
76 | this.line = 1;
77 | this.col = 0;
78 | this.isPeek = false;
79 | }
80 |
81 | read(cnt = 1) {
82 | const ret = [];
83 | let ofst = this.ofst;
84 | let c;
85 | while (cnt) {
86 | const next = ofst + 1;
87 | c = this.code[next];
88 | if (c === undefined) {
89 | c = EOF;
90 | ret.push(c);
91 | break;
92 | }
93 | ofst = next;
94 | // 这里我们将可能的三种换行都统一为 *nix 换行符 '\n'
95 | if (c === CR || c === NL) {
96 | if (c === CR && this.code[next + 1] === NL) ofst++;
97 | // 识别为换行之后，如果处于 read 模式，则需要更新行列号
98 | // 将行号加 1，表示进入了下一行
99 | // 将列号重置，表示此时处于新行的行首
100 | if (!this.isPeek) {
101 | this.line++;
102 | this.col = 0;
103 | }
104 | c = EOL;
105 | } else if (!this.isPeek) this.col++;
106 | ret.push(c);
107 | cnt--;
108 | }
109 | if (!this.isPeek) {
110 | this.ch = c;
111 | this.ofst = ofst;
112 | }
113 | return ret.join("");
114 | }
115 |
116 | // 由于 peek 逻辑除了不需要更新位置信息外、和 read 逻辑一致，因此我们通过
117 | // 设定 `isPeek` 属性使得在 read 内部得以区分当前状态
118 | peek(cnt = 1) {
119 | this.isPeek = true;
120 | const ret = this.read(cnt);
121 | this.isPeek = false;
122 | return ret;
123 | }
124 |
125 | getPos() {
126 | return new Position(this.ofst, this.line, this.col);
127 | }
128 | }
129 |
130 | module.exports = {
131 | NL,
132 | CR,
133 | EOL,
134 | EOF,
135 | Position,
136 | Source
137 | };
138 | ```
139 |
140 | 对于类「Position」和方法 `Source::getPos()`，很明显它们是分别用于存放和获取 Source 的位置信息的。
141 |
142 | 目前为止，我们 Source 类的功能有这几点：
143 |
144 | 1. 所有对源码的读取操作将通过 Source 类的实例来完成
145 | 2. 我们可以在读取的过程中维护当前的读取位置
146 | 3. 我们将不同的换行符都进行了统一，返回 EOL
147 | 4. 我们还提供了预读功能，就是在不改变当前位置信息的情况下，往前读取几个字符。
148 |
149 |
--------------------------------------------------------------------------------
/images/source.svg:
--------------------------------------------------------------------------------
1 |
--------------------------------------------------------------------------------
/.gitbook/assets/source.svg:
--------------------------------------------------------------------------------
1 |
--------------------------------------------------------------------------------
/code/hi/lexer.js:
--------------------------------------------------------------------------------
1 | const { EOF, EOL } = require("./source");
2 | const assert = require("assert");
3 |
4 | class SourceLoc {
5 | constructor(start, end) {
6 | this.start = start;
7 | this.end = end;
8 | }
9 | }
10 |
11 | class Token {
12 | constructor(type, value, loc) {
13 | this.type = type;
14 | this.value = value;
15 | this.loc = loc || new SourceLoc();
16 | }
17 | }
18 |
19 | class TokenType {}
20 | TokenType.EOF = "eof";
21 | TokenType.HI = "hi";
22 | TokenType.STRING = "string";
23 | TokenType.NUMBER = "number";
24 | TokenType.MUL = "*";
25 | TokenType.DIV = "/";
26 | TokenType.ADD = "+";
27 | TokenType.SUB = "-";
28 | TokenType.EXPO = "**";
29 | TokenType.PRINT = "print";
30 |
31 | class Lexer {
32 | constructor(src) {
33 | this.src = src;
34 | }
35 |
36 | static isDigit(n) {
37 | return n >= "0" && n <= "9";
38 | }
39 |
40 | static isOp(ch) {
41 | return ["*", "/", "+", "-", "*"].indexOf(ch) !== -1;
42 | }
43 |
44 | next() {
45 | this.skipWhitespace();
46 | const ch = this.src.peek();
47 | if (ch === '"') return this.readString();
48 | if (ch === "h") return this.readHi();
49 | if (ch === "p") return this.readPrint();
50 | if (Lexer.isDigit(ch)) return this.readNumber();
51 | if (Lexer.isOp(ch)) return this.readOp();
52 | if (ch === EOF) return new Token(TokenType.EOF);
53 | throw new Error(this.makeErrMsg());
54 | }
55 |
56 | makeErrMsg() {
57 | return `Unexpected char at line: ${this.src.line} column: ${this.src.col}`;
58 | }
59 |
60 | readPrint() {
61 | const tok = new Token(TokenType.PRINT);
62 | tok.loc.start = this.getPos();
63 | const print = this.src.read(5);
64 | assert.ok(print === "print", this.makeErrMsg());
65 | tok.loc.end = this.getPos();
66 | tok.value = "print";
67 | return tok;
68 | }
69 |
70 | readHi() {
71 | const tok = new Token(TokenType.HI);
72 | tok.loc.start = this.getPos();
73 | const hi = this.src.read(2);
74 | assert.ok(hi === "hi", this.makeErrMsg());
75 | tok.loc.end = this.getPos();
76 | tok.value = "hi";
77 | return tok;
78 | }
79 |
80 | readString() {
81 | const tok = new Token(TokenType.STRING);
82 | tok.loc.start = this.getPos();
83 | this.src.read();
84 | const v = [];
85 | while (true) {
86 | let ch = this.src.read();
87 | if (ch === '"') break;
88 | else if (ch === EOF) throw new Error(this.makeErrMsg());
89 | v.push(ch);
90 | }
91 | tok.loc.end = this.getPos();
92 | tok.value = v.join("");
93 | return tok;
94 | }
95 |
96 | readNumber() {
97 | const tok = new Token(TokenType.NUMBER);
98 | tok.loc.start = this.getPos();
99 | const v = [this.src.read()];
100 | while (true) {
101 | let ch = this.src.peek();
102 | if (Lexer.isDigit(ch)) {
103 | v.push(this.src.read());
104 | continue;
105 | }
106 | break;
107 | }
108 | tok.loc.end = this.getPos();
109 | tok.value = v.join("");
110 | return tok;
111 | }
112 |
113 | readOp() {
114 | const tok = new Token();
115 | tok.loc.start = this.getPos();
116 | tok.type = this.src.read();
117 | if (tok.type === "*") {
118 | if (this.src.peek() === "*") {
119 | this.src.read();
120 | tok.type = "**";
121 | }
122 | }
123 | tok.loc.end = this.getPos();
124 | return tok;
125 | }
126 |
127 | skipWhitespace() {
128 | while (true) {
129 | let ch = this.src.peek();
130 | if (ch === " " || ch === "\t" || ch === EOL) {
131 | this.src.read();
132 | continue;
133 | }
134 | break;
135 | }
136 | }
137 |
138 | peek() {
139 | this.src.pushPos();
140 | const tok = this.next();
141 | this.src.restorePos();
142 | return tok;
143 | }
144 |
145 | getPos() {
146 | return this.src.getPos();
147 | }
148 | }
149 |
150 | module.exports = {
151 | SourceLoc,
152 | Token,
153 | TokenType,
154 | Lexer
155 | };
156 |
--------------------------------------------------------------------------------
/part1/1-9-ast-calculator.md:
--------------------------------------------------------------------------------
1 | # 1.9 使用 AST - 计算器
2 |
3 | 我们已经可以解析算术表达式了，基于此我们可以进一步来实现一个计算器。
4 |
5 | 为了可以将打印我们的表达式的执行结果，在实现函数调用的语法之前，我们先实现一个支持打印执行结果的语法：
6 |
7 | ```text
8 | print ::= "print" expr
9 | ```
10 |
11 | 这样对于语句 `print 1 + 2 + 3` 来说，它会先执行 `1 + 2 + 3` 然后打印执行的结果。
12 |
13 | 语法添加完毕后，第一步还是先完善词法解析器：
14 |
15 | ```javascript
16 | TokenType.PRINT = "print";
17 |
18 | class Lexer {
19 | next() {
20 | this.skipWhitespace();
21 | const ch = this.src.peek();
22 | // ...
23 | if (ch === "h") return this.readHi();
24 | if (ch === "p") return this.readPrint();
25 | // ...
26 | throw new Error(this.makeErrMsg());
27 | }
28 |
29 | readPrint() {
30 | const tok = new Token(TokenType.HI);
31 | tok.loc.start = this.getPos();
32 | const print = this.src.read(5);
33 | assert.ok(print === "print", this.makeErrMsg());
34 | tok.loc.end = this.getPos();
35 | tok.value = "print";
36 | return tok;
37 | }
38 | }
39 | ```
40 |
41 | 添加一个新的 Token 类型 `TokenType.PRINT`，在 `Lexer::next` 中增加对该关键字的预测分支，以及解析该关键字的 `Lexer::readPrint` 方法。
42 |
43 | 接着我们来完善语法解析器：
44 |
45 | ```javascript
46 | class PrintStmt extends Node {
47 | constructor(loc, value) {
48 | super(NodeType.PRINT_STMT, loc);
49 | this.value = value;
50 | }
51 | }
52 |
53 | NodeType.PRINT_STMT = "printStmt";
54 |
55 | class Parser {
56 | parseProg() {
57 | // ...
58 | while (true) {
59 | // ...
60 | if (tok.type === TokenType.NUMBER) stmt = this.parseExprStmt();
61 | if (tok.type === TokenType.PRINT) stmt = this.parsePrintStmt();
62 | node.body.push(stmt);
63 | }
64 | // ...
65 | }
66 |
67 | parsePrintStmt() {
68 | const node = new PrintStmt();
69 | let tok = this.lexer.next();
70 | node.loc.start = tok.loc.start;
71 | node.value = this.parseExpr();
72 | node.loc.end = this.lexer.getPos();
73 | return node;
74 | }
75 | }
76 | ```
77 |
78 | 我们新增了一个节点类型 `NodeType.PRINT_STMT` 已经它的定义 `PrintStmt`。在 `Parser::parseProg` 中，我们增加了预测 `print` 语句的分支，`Parser::parsePrintStmt` 负责解析 `print` 语句。
79 |
80 | 接着完善 Visitor：
81 |
82 | ```javascript
83 | class Visitor {
84 | visitPrintStmt(node) {}
85 |
86 | visitStmt(node) {
87 | switch (node.type) {
88 | case NodeType.EXPR_STMT:
89 | return this.visitExprStmt(node);
90 | case NodeType.SAY_HI:
91 | return this.visitSayHi(node);
92 | case NodeType.PRINT_STMT:
93 | return this.visitPrintStmt(node);
94 | }
95 | }
96 | }
97 | ```
98 |
99 | 我们增加了 `visitPrintStmt` 方法，留给子类去实现。在 `visitStmt` 中，增加了对 `NodeType.PRINT_STMT` 类型的识别和处理。
100 |
101 | 最后，我们来完善 InterpretVisitor：
102 |
103 | ```javascript
104 | class InterpretVisitor extends Visitor {
105 | visitProg(node) {
106 | node.body.forEach(stmt => this.visitStmt(stmt));
107 | }
108 |
109 | visitBinaryExpr(node) {
110 | const left = this.visitExpr(node.left);
111 | const op = node.op.type;
112 | const right = this.visitExpr(node.right);
113 | switch (op) {
114 | case "+":
115 | return left + right;
116 | case "-":
117 | return left - right;
118 | case "*":
119 | return left * right;
120 | case "/":
121 | return left / right;
122 | case "**":
123 | return left ** right;
124 | }
125 | }
126 |
127 | visitPrintStmt(node) {
128 | console.log(this.visitExpr(node.value));
129 | }
130 |
131 | visitNumLiteral(node) {
132 | return parseInt(node.value);
133 | }
134 | }
135 | ```
136 |
137 | 在 `visitNumLiteral` 中，我们将字符串通过 `parseInt` 转换成了整型，注意我们在定义数字的语法规则时，具有可选的前导零，当时做这样的选择，也是顺带利用了 JS 中 `parseInt` 方法的功能。`visitBinaryExpr` 中，我们对于两个操作数，我们分别调用 `visitExpr` 来取它们的值，然后根据不同的操作符执行了相应的运算，并返回运行结果，这样使得操作数取值的 `visitExpr` 调用总是可以拿到值：来自 parseInt 或者子节点的运算结果。`visitPrintStmt` 的操作就是打印运算的结果，对于求值则是委托给了 `visitExpr` 来完成。
138 |
139 | 我们可以来试一试运行语句 `print 1 + 2 ** 3 * 5`：
140 |
141 | ```javascript
142 | const code = `print 1 + 2 ** 3 * 5`;
143 | const src = new Source(code);
144 | const lexer = new Lexer(src);
145 | const parser = new Parser(lexer);
146 |
147 | const ast = parser.parseProg();
148 | const visitor = new InterpretVisitor();
149 | visitor.visitProg(ast);
150 | ```
151 |
152 | 我们将会得到输出 `41`。因为我们的 hi 语言使用了和 JS 相同的运算符优先级和结合性，所以大家也可以将表达式 `1 + 2 ** 3 * 5` 直接粘贴到浏览器的控制台，来验证执行的结果是否和 hi 语言相同。
153 |
154 |
--------------------------------------------------------------------------------
/code/hi/parser.js:
--------------------------------------------------------------------------------
1 | const { SourceLoc, TokenType, Lexer } = require("./lexer");
2 | const assert = require("assert");
3 |
4 | class Node {
5 | constructor(type, loc) {
6 | this.type = type;
7 | this.loc = loc || new SourceLoc();
8 | }
9 | }
10 |
11 | class Prog extends Node {
12 | constructor(loc, body = []) {
13 | super(NodeType.PROG, loc);
14 | this.body = body;
15 | }
16 | }
17 |
18 | class SayHi extends Node {
19 | constructor(loc, value) {
20 | super(NodeType.SAY_HI, loc);
21 | this.value = value;
22 | }
23 | }
24 |
25 | class PrintStmt extends Node {
26 | constructor(loc, value) {
27 | super(NodeType.PRINT_STMT, loc);
28 | this.value = value;
29 | }
30 | }
31 |
32 | class ExprStmt extends Node {
33 | constructor(loc, value) {
34 | super(NodeType.EXPR_STMT, loc);
35 | this.value = value;
36 | }
37 | }
38 |
39 | class BinaryExpr extends Node {
40 | constructor(loc, op, left, right) {
41 | super(NodeType.BINARY_EXPR, loc);
42 | this.op = op;
43 | this.left = left;
44 | this.right = right;
45 | }
46 | }
47 |
48 | class NumLiteral extends Node {
49 | constructor(loc, value) {
50 | super(NodeType.NUMBER, loc);
51 | this.value = value;
52 | }
53 | }
54 |
55 | class NodeType {}
56 | NodeType.PROG = "prog";
57 | NodeType.SAY_HI = "sayhi";
58 | NodeType.EXPR_STMT = "exprStmt";
59 | NodeType.BINARY_EXPR = "binaryExpr";
60 | NodeType.NUMBER = "number";
61 | NodeType.PRINT_STMT = "printStmt";
62 |
63 | class Parser {
64 | constructor(lexer) {
65 | this.lexer = lexer;
66 | }
67 |
68 | parseProg() {
69 | const node = new Prog();
70 | node.loc.start = this.lexer.getPos();
71 | while (true) {
72 | const tok = this.lexer.peek();
73 | let stmt;
74 | if (tok.type === TokenType.EOF) break;
75 | if (tok.type === TokenType.HI) stmt = this.parseSayHi();
76 | if (tok.type === TokenType.NUMBER) stmt = this.parseExprStmt();
77 | if (tok.type === TokenType.PRINT) stmt = this.parsePrintStmt();
78 | node.body.push(stmt);
79 | }
80 | node.loc.end = this.lexer.getPos();
81 | return node;
82 | }
83 |
84 | parsePrintStmt() {
85 | const node = new PrintStmt();
86 | let tok = this.lexer.next();
87 | node.loc.start = tok.loc.start;
88 | node.value = this.parseExpr();
89 | node.loc.end = this.lexer.getPos();
90 | return node;
91 | }
92 |
93 | parseSayHi() {
94 | const node = new SayHi();
95 | let tok = this.lexer.next();
96 | assert.ok(tok.type === TokenType.HI, this.makeErrMsg(tok));
97 | node.loc.start = tok.loc.start;
98 | tok = this.lexer.next();
99 | assert.ok(tok.type === TokenType.STRING, this.makeErrMsg(tok));
100 | node.value = tok.value;
101 | node.loc.end = tok.loc.end;
102 | return node;
103 | }
104 |
105 | parseExprStmt() {
106 | const node = new ExprStmt();
107 | const expr = this.parseExpr();
108 | node.loc = expr.loc;
109 | node.value = expr;
110 | return node;
111 | }
112 |
113 | parseExpr() {
114 | let left = this.parseTerm();
115 | while (true) {
116 | const op = this.lexer.peek();
117 | if (op.type !== "+" && op.type !== "-") break;
118 | this.lexer.next();
119 | const node = new BinaryExpr();
120 | node.left = left;
121 | node.op = op;
122 | node.right = this.parseTerm();
123 | left = node;
124 | }
125 | return left;
126 | }
127 |
128 | parseTerm() {
129 | let left = this.parseExpo();
130 | while (true) {
131 | const op = this.lexer.peek();
132 | if (op.type !== "*" && op.type !== "/") break;
133 | this.lexer.next();
134 | const node = new BinaryExpr();
135 | node.left = left;
136 | node.op = op;
137 | node.right = this.parseExpo();
138 | left = node;
139 | }
140 | return left;
141 | }
142 |
143 | parseExpo() {
144 | let left = this.parseFactor();
145 | while (true) {
146 | const op = this.lexer.peek();
147 | if (op.type !== "**") break;
148 | this.lexer.next();
149 | const node = new BinaryExpr();
150 | node.left = left;
151 | node.op = op;
152 | node.right = this.parseExpo();
153 | left = node;
154 | }
155 | return left;
156 | }
157 |
158 | parseFactor() {
159 | return this.parseNum();
160 | }
161 |
162 | parseNum() {
163 | const node = new NumLiteral();
164 | let tok = this.lexer.next();
165 | assert.ok(tok.type === TokenType.NUMBER, this.makeErrMsg(tok));
166 | node.loc = tok.loc;
167 | node.value = tok.value;
168 | return node;
169 | }
170 |
171 | makeErrMsg(tok) {
172 | const loc = tok.loc;
173 | return `Unexpected token at line: ${loc.start.line} column: ${
174 | loc.start.col
175 | }`;
176 | }
177 | }
178 |
179 | module.exports = {
180 | Node,
181 | NodeType,
182 | Prog,
183 | SayHi,
184 | Parser
185 | };
186 |
--------------------------------------------------------------------------------
/part1/1-4-lexer.md:
--------------------------------------------------------------------------------
1 | # 1.4 词法解析器
2 |
3 | 有了前面的介绍，我们编写词法解析的工作将变得很简单。接下来我们开始着手编写我们的词法解析器「Lexer」。
4 |
5 | 我们的 hi 语言只有两个词法元素，它们的类型分别是 `HI` 和 `STRING`。
6 |
7 | 词法分析器的作用就是，接收 Source 的输入，并将其转化为 Tokens 输出，根据这个需求，我们可以这样来写词法解析器：
8 |
9 | ```javascript
10 | class Lexer {
11 | constructor(src) {
12 | this.src = src;
13 | }
14 |
15 | next() {
16 | this.skipWhitespace();
17 | const ch = this.src.peek();
18 | switch (ch) {
19 | case '"':
20 | return this.readString();
21 | case "h":
22 | return this.readHi();
23 | case EOF:
24 | return new Token(TokenType.EOF);
25 | default:
26 | throw new Error(this.makeErrMsg());
27 | }
28 | }
29 |
30 | makeErrMsg() {}
31 |
32 | readHi() {}
33 |
34 | readString() {}
35 |
36 | skipWhitespace() {}
37 | }
38 | ```
39 |
40 | 可以看到 Lexer 的构造函数只有一个参数，就是 Source 的实例。未来在使用 Lexer 的时候，通过不断调用 `next` 方法，来读取 Tokens。
41 |
42 | 在 `next` 方法中，我们使用了先行预测「Lookahead」，即向前预读一个字符，来判断接下来是读取 HI 关键字，还是读取字符串。如果两者都不是，就判断是否已经读到源文件的结尾处。最后如果都匹配不到，我们就直接抛出一个异常，表示读入了无法识别的字符，也就是源文件中包含了不符合词法规则的字符。
43 |
44 | 因为词法元素在源文件中是被空白分割的，所以我们在 `next` 运行之初，调用了 `skipWhitespace` 方法，就和它的名字一样，这是用来跳过文件中的空白字符的。`skipWhitespace` 方法如下：
45 |
46 | ```javascript
47 | skipWhitespace() {
48 | while (true) {
49 | let ch = this.src.peek();
50 | if (ch === " " || ch === "\t" || ch === EOL) {
51 | this.src.read();
52 | continue;
53 | }
54 | break;
55 | }
56 | }
57 | ```
58 |
59 | 我们这里简单地跳过空格、制表符、和换行。
60 |
61 | 为什么是「简单地」？因为我们没有考虑 Unicode 的情况，在 Unicode 中，还有其他的一些字符表示空白。
62 |
63 | 并且上面使用了 `EOL` ，因为各个平台不同的换行符已经被我们在 Source 中处理过了。
64 |
65 | `makeErrMsg` 方法非常简单，就是制作报错信息，因为我们在词法解析的过程中，将会多次使用报错信息，所以我们将该功能做成一个方法：
66 |
67 | ```javascript
68 | makeErrMsg() {
69 | return `Unexpected char at line: ${this.src.line} column: ${this.src.col}`;
70 | }
71 | ```
72 |
73 | 对于报错信息，我们也只是简单地打印行列号。
74 |
75 | 在开始读取 Token 之前，我们还需要另外几个辅助类，分别是「SourceLoc」，「Token」，「TokenType\]：
76 |
77 | ```javascript
78 | class SourceLoc {
79 | constructor(start, end) {
80 | this.start = start;
81 | this.end = end;
82 | }
83 | }
84 |
85 | class Token {
86 | constructor(type, value, loc) {
87 | this.type = type;
88 | this.value = value;
89 | this.loc = loc || new SourceLoc();
90 | }
91 | }
92 |
93 | class TokenType {}
94 | TokenType.EOF = "eof";
95 | TokenType.HI = "hi";
96 | TokenType.STRING = "string";
97 | ```
98 |
99 | Token 表示的就是我们解析后的词法元素，包含了该词法元素的类型，内容，以及它在源文件中的位置信息。由于 Token 的内容是源文件的片段，所以位置需要包含 `start` 和 `end` 信息。
100 |
101 | 接着我们开始看一下 `readHi` 方法的实现：
102 |
103 | ```javascript
104 | readHi() {
105 | const tok = new Token(TokenType.HI);
106 | tok.loc.start = this.src.getPos();
107 | const hi = this.src.read(2);
108 | assert.ok(hi === "hi", this.makeErrMsg());
109 | tok.loc.end = this.src.getPos();
110 | tok.value = "hi";
111 | return tok;
112 | }
113 | ```
114 |
115 | 首先，一旦进入了该方法，则表示接下来的字符一定是 `h`，因为我们是在 `next` 方法中通过预读一个字符、并匹配到 `h` 进来的。于是我们这里直接读取接下来的两个字符，判断它们是否是 `hi`。如果不是 `hi`，我们则直接报错。
116 |
117 | 注意这里 Token 的位置信息收集分为两部分，在读取之前，我们收集了 `start` 信息，在读取内容之后，我们收集了 `end` 的信息。
118 |
119 | 最后我们看一下 `readString` 方法：
120 |
121 | ```javascript
122 | readString() {
123 | const tok = new Token(TokenType.STRING);
124 | tok.loc.start = this.src.getPos();
125 | this.src.read();
126 | const v = [];
127 | while (true) {
128 | let ch = this.src.read();
129 | if (ch === '"') break;
130 | else if(ch === EOF) throw new Error(this.makeErrMsg());
131 | v.push(ch);
132 | }
133 | tok.loc.end = this.src.getPos();
134 | tok.value = v.join("");
135 | return tok;
136 | }
137 | ```
138 |
139 | 注意第一个 `read` 操作，因为我们是通过预读满足了 `"` 才调用的该方法，所以我们这里直接跳过 `"`，因为我们只想收集双引号之间的字符串内容。然后在循环内部，我们就不断读取字符，如果遇到了作为关闭标签的 `"` 我们就跳出循环。
140 |
141 | 我们将读取的字符都先存入 `v` 数组中，在循环跳出之后，再将它们合并为字符串，存入 Token。
142 |
143 | 注意在写循环的时候，一定到注意跳出条件，所以如果在读到文件末尾仍未遇到关闭的 `"`，我们就抛出一个异常来终止程序。对于 `read` 方法的实现，我们也可以结合之前根据 EBNF 生成的铁路图来看。
144 |
145 | 现在我们来试一试我们的 Lexer 的工作效果：
146 |
147 | ```javascript
148 | const { Source } = require("./source");
149 | const { Lexer, TokenType } = require("./lexer");
150 |
151 | const code = `hi "lexer"`;
152 | const src = new Source(code);
153 | const lexer = new Lexer(src);
154 |
155 | while (true) {
156 | const tok = lexer.next();
157 | if (tok.type === TokenType.EOF) break;
158 | console.log(tok);
159 | }
160 | ```
161 |
162 | 运气好的话，我们应该会在控制台看到输出了两个 Tokens，它们的类型分别是 `HI` 和 `STRING`。
163 |
164 | 最后，我们再为 Lexer 添加一个方法 「Peek」，这样我们的词法分析器也有了预读的功能
165 |
166 | ```javascript
167 | peek() {
168 | this.src.pushPos();
169 | const tok = this.next();
170 | this.src.restorePos();
171 | return tok;
172 | }
173 | ```
174 |
175 | 可以看到我们的预读功能主要是借助了 Source 类中的 `pushPos` 和 `restorePos` 方法。所以我们继续在 Source 类中补全这两个方法：
176 |
177 | ```javascript
178 | constructor(code = "", file = "stdin") {
179 | // ...
180 | this.posStack = [];
181 | }
182 |
183 | pushPos() {
184 | this.posStack.push(this.getPos());
185 | }
186 |
187 | restorePos() {
188 | const pos = this.posStack.pop();
189 | if (pos === undefined)
190 | throw new LexerError("Unbalanced popping of position stack");
191 | this.ofst = pos.ofst;
192 | this.line = pos.line;
193 | this.col = pos.col;
194 | }
195 | ```
196 |
197 | 首先我们给 Source 类增加一个属性 `posStack`，用来保存位置信息。随后，通过对这个数组进行 `push` 和 `pop` 来存入和取回位置信息。
198 |
199 | 因为 `push` 和 `pop` 在代码中肯定是成对出现的，所以我们在 `restorePos` 的时候，进行了一个简单的检查。
200 |
201 | 为了使我们未来在 Parser 中获取源文件位置时，不需要使用 `this.lexer.src.getPos()` 这么长的调用链，我们在 Lexer 中增加了 `getPos` 方法。
202 |
203 | ```js
204 | getPos() {
205 | return this.src.getPos();
206 | }
207 | ```
208 |
209 | 这样我们在 Parser 中只需要通过 `this.lexer.getPos()` 就可以了，是短了一点吧看起来。
210 |
211 |
--------------------------------------------------------------------------------
/part1/1-3-hi.md:
--------------------------------------------------------------------------------
1 | # 1.3 我们的第一个语言 - hi
2 |
3 | 我们已经介绍了编译的基本概念，还实现了 Source 类。接下来我们将逐步实现自己的第一个编程语言。按照之前介绍的编译器结构，似乎我们应该开始介绍词法解析了，但是词法解析是需要根据语言的语法来进行的，所以还是让我们先了解一下，如何来对编程语言进行描述。
4 |
5 | ## 扩展巴科斯范式「EBNF, Extended Backus–Naur Form」
6 |
7 | 我们通过语法「Grammar」来定义我们的编程语言。语法的是由一组规则「Production Rules」组成的，通过这些规则来构成语法。
8 |
9 | 这些规则由两部分所构成：1\). 规则名称 2\). 规则内容。比如我们将要实现的语言「称之为 hi」：
10 |
11 | ```text
12 | 「say_hi」需要满足: hi 字符串
13 | 「字符串」需要满足: " 除了「"」的任意字符 "
14 | ```
15 |
16 | 如果上面的描述看不懂的话，我们来看一下使用我们的 hi 语言书写的程序：
17 |
18 | ```text
19 | hi "lexer"
20 | hi "parser"
21 | hi "compiling"
22 | ```
23 |
24 | 看到了吧，我们的 hi 语言就只有一种类型的语句，通过它你可以 「say hi to everyone」。
25 |
26 | 在上面的语法中，我们定义了两个规则，分别是「字符串」和「say\_hi」。
27 |
28 | 对于规则「字符串」而言，它的规则内容为，以「"」开头，接收任意除了「"」的任意字符，直到接收到「"」后结束该规则，在该规则内接收的字符串，都被打包到了我们的「字符串」规则中。
29 |
30 | 对于规则「say\_hi\」而言，它的规则内容为，以关键字「hi」开头，接下来的内容将必须符合「字符串」规则。
31 |
32 | 为了更加严谨的描述我们的语法，我们需要使用各种标记语言，而扩展巴科斯范式「EBNF」就是这些标记语言中的其中一种。
33 |
34 | 通过 EBNF 可以将我们的语法表示为：
35 |
36 | ```text
37 | say_hi = "hi", string ;
38 | string = '"' , { all characters - '"' }, '"' ;
39 | ```
40 |
41 | 可以看出，EBNF 描述规则的表达式为:
42 |
43 | ```text
44 | 规则名称 = 终结符和非终结符的组合
45 | ```
46 |
47 | 终结符「Terminal Symbol」就是词法中不能被分解的最小单元，反之为非终结符「Nonterminal Symbol」。比如规则「say\_hi」的右边，`"hi"` 为终结符；而 `string` 则为非终结符，因为它还有与之对应的规则。
48 |
49 | EBNF 中使用了如下的符号:
50 |
51 | | 符号 | 含义 |
52 | | :--- | :--- |
53 | | = | 定义规则，左边为规则名称，右边为\(非\)终结符的组合 |
54 | | , | 表示连接位于其左右两边的\(非\)终结符 |
55 | | \| | 表示位于其左右两边的\(非\)终结符为二选一的关系 |
56 | | \[ ... \] | 表示方括号中的\(非\)终结符为可选项，在该位置出现次数为 0 或 1 |
57 | | { ...} | 表示大括号中的\(非\)终结符为重复出现的，在该位置出现次数 >= 0 |
58 | | \( ...\) | 表示小括号中的\(非\)终结符在该位置以组合的形式出现 |
59 | | " ... " | 表示终结符 |
60 | | ' ... ' | 表示终结符，主要用于需要表示 '"' 的情况 |
61 | | \( _..._\) | 表示注释 |
62 | | ?...? | 表示其中的内容具有特殊含义，对该含义的定义不在 EBNF 标准之内，有使用者来决定 |
63 | | - | 表示将右边的内容从左边进行排除 |
64 |
65 | 我们使用 EBNF 来总结一下 hi 的语法：
66 |
67 | ```text
68 | prog = { say_hi } ;
69 | say_hi = "hi", string ;
70 | string = '"' , { all characters - '"' }, '"' ;
71 | ```
72 |
73 | 我们增加了一条新的规则「prog」作为我们未来进行解析的起始规则。我们的 hi 语言将只包含一条语句「Statement」类型，就是「say\_hi」。
74 |
75 | ## W3C's EBNF
76 |
77 | 如果大家通过搜索引擎来检索关键字「EBNF」，那么会发现很多链接中都介绍了上一节的 EBNF 语法。它是由 ISO 制定的。ISO 是一个全球化的组织，制定了很多的标准，其中也就包括了 [ISO/IEC 14977](http://standards.iso.org/ittf/PubliclyAvailableStandards/s026153_ISO_IEC_14977_1996%28E%29.zip)，也就是上一小节介绍的 EBNF 标记法。
78 |
79 | ISO 制定 EBNF 标准的目的就是为了扩展和统一 [BNF](https://en.wikipedia.org/wiki/Backus–Naur_form) 的使用方法，因为在此之前大家在描述语法的时候，都或多或少的加入了自己的喜好，使之成了 BNF 的方言「Dialect」。
80 |
81 | 我们好像忘记介绍 BNF 了，没关系，一句话来概括它：就是没有扩展前的 EBNF、功能和 BNF 一样，都是用来描述语法的，缺点就是灵活性不如它的后辈 EBNF。
82 |
83 | 只是大家对 ISO 制定的 EBNF 标准并不满意，因为它使用起来还是很麻烦，甚至在 ISO 后来的标准制定中涉及语法描述的部分，都没有使用自家制定的「ISO/IEC 14977」。
84 |
85 | 所以这里我们要介绍由另一个组织 W3C 制定的 EBNF 标记法。W3C 是主要负责万维网标准制定的组织。它定义的 EBNF 标记法被自身和外界广泛使用。它的特点主要是参考了正则表达式「Regular Expression」的语法。接下来我们来一起看一下它的语法。
86 |
87 | 首先，语法中的每个规则定义一个符号「Symbol」，形式为：
88 |
89 | ```text
90 | symbol ::= expression
91 | ```
92 |
93 | 如果 Symbol 定义词法元素「Token」的话，那么首字母大写；如果是定义语法元素，比如「Statement」或「Expression」的话，那么首字母小写。
94 |
95 | 我们怎么来确定语法中哪些元素应该视为词法元素还是语法元素呢？简单地说，不能再进行划分的，我可以视为词法元素，比如关键字，字符串，数值，它们在编程语言语法组成中的地位都好比我们自然语言中的单词。而编程语言中类比到人类语言中句型定义的部分，规则名称需要小写，比如定义疑问句的规则，定义陈述句的规则之类。
96 |
97 | 规则右边的内容，也就是 expression 用来匹配一个或者多个连续的字符。可以出现在右边的表达式的内容具有以下几种形式：
98 |
99 | **\#xN**
100 |
101 | 单个字符。N 是一个十六进制数，整个表达式用来表示一个字符，前导的 0 可以省略，也就是说 `\x03` 可以直接写成 `\x3`。具体的数值源于该字符在 Unicode 中的 [code-point](https://github.com/hsiaosiyuan0/icj/tree/8cd8591f0fb2468225c66c0c9c2b2af413f99ec8/part1/code-point.md)。比如，`a` 的 code-point 为 `0x61`，那么可以使用 `#x61` 来表示字符 `a`
102 |
103 | **\[a-zA-Z\], \[\#xN-\#xN\]**
104 |
105 | 字符区间。表示匹配位于该区间内的任意字符，包含区间的其实和结束字符在内。比如 `[a-z]` 表示匹配所有位于 `a` 之间的字符 `z`，包括 `a` 和 `z`。如果直接写成 `[\x0-\xff]` 的话，那么数值形式的区间很好理解；如果是字符形式的区间，则可以理解成先将起始和结束的字符转换成它们对应的 code-point，然后取 code-point 对应的数值区间。
106 |
107 | **\[abc\], \[\#xN\#xN\#xN\]**
108 |
109 | 字符枚举。表示接下来出现的字符列举在方括号内，可以和「字符区间」写在同一个方括号内。
110 |
111 | **\[^a-z\], \[^\#xN-\#xN\]**
112 |
113 | 字符区间排除。表示接下来的字符不处于区间之内。
114 |
115 | **\[^abc\], \[^\#xN\#xN\#xN\]**
116 |
117 | 字符枚举排除。表示接下来的字符不处于枚举之列，也可以和「字符区间排除」写在同一个方括号内。
118 |
119 | **"string"**
120 |
121 | 匹配双引号中的字符。
122 |
123 | **'string'**
124 |
125 | 匹配单引号中的字符。
126 |
127 | **\(expression\)**
128 |
129 | 括号中的表达式被划定为一个分组。
130 |
131 | **A?**
132 |
133 | 表示 A 出现的次数为 0 或者 1。
134 |
135 | **A B**
136 |
137 | 表示 A 后面紧接着 B。这个操作的优先级高于符号为 `|` 的交替操作，比如 `A B | C D` 等同于 `(A B) | (C D)`
138 |
139 | **A \| B**
140 |
141 | 表示 A 或者 B 交替出现于该位置，即该位置出现的内容需要满足非 A 即 B
142 |
143 | **A+**
144 |
145 | 表示一个或者多个连续出现的 A。该操作具有比符号为 `|` 的交替操作更高的优先级，比如 `A+ | B+` 等同于 `(A+) | (B+)`
146 |
147 | **A\***
148 |
149 | 表示零个或者多个连续出现的 A。该操作具有比交替操作更高的优先级。
150 |
151 | **/\*... \*/**
152 |
153 | 表示注释。
154 |
155 | 所以我们可以将 sayHi 的语法写成 W3C'S EBNF 的形式：
156 |
157 | ```text
158 | prog ::= say_hi*
159 | say_hi ::= HI STRING
160 | HI ::= "hi"
161 | STRING ::= '"' [^"]* '"'
162 | ```
163 |
164 | 注意我们将词法元素的规则进行了大写区分。
165 |
166 | 我们可以将 W3C'S EBNF 转换成对应的语法图「Syntax Diagram 或 Railroad Diagram」:
167 |
168 | **prog:**
169 |
170 | 
171 |
172 | **say\_hi:**
173 |
174 | 
175 |
176 | **STRING:**
177 |
178 | 
179 |
180 | _我们可以使用_ [_Railroad Diagram Generator_](https://bottlecaps.de/rr/ui) _来生成这些图。_
181 |
182 | 我们在看这些图的时候，使用从左往右的方向，以左边的箭头为起点，遇到分支就可以自由的选择不同的分路、除了不能回头，直到到达最右边。
183 |
184 | 比如第一个图，有两个分支，如果我们在第一个分支处，采取向右直行的分支，那么到达最右端之前，将不会遇到任何的位置匹配，这就表示了我们语法中的零条 `say_hi` 语句的情况。
185 |
186 | 在比如，如果在第一个分支处，我们选取了经过 `say_hi` 的分支，那么在到达第二个分支处时，表示我们已经匹配了一条 `say_hi` 语句，此时如果我们选择直接向右的路线，那么由于到达了终点，此条轨迹表示我们匹配一条语句的情况。而如果我们选择回到第一条分支的路线，那么则会继续匹配 `say_hi` 语句。
187 |
188 | 这几种情况的合集，就表示了我们的第一条规则：匹配零条或多条 `say_hi` 语句。
189 |
190 |
--------------------------------------------------------------------------------
/part1/1-5-parser.md:
--------------------------------------------------------------------------------
1 | # 1.5 语法解析器
2 |
3 | 通常的语法解析算法有「LL，Left-to-right, Leftmost Derivation」和「LR, Left-to-right, Rightmost derivation」两种，第一个 L 表示 Left-to-right，第二个 L 和 R 分别表示最左推导和最右推导。
4 |
5 | 「推导」，表示的是如何运用语法规则来匹配输入的字符串。和数学中的推导相似，我们通过不断地将非终结符替换为它的某个生产式来得出输入字符串是否匹配语法的结论。
6 |
7 | 比如我们的 hi 语言：
8 |
9 | ```text
10 | prog ::= say_hi*
11 | say_hi ::= HI STRING
12 | HI ::= "hi"
13 | STRING ::= '"' [^"]* '"'
14 | ```
15 |
16 | 假设我们的源文件内容为 `hi "parser"`。为了解析这个字符串，我们从 `prog` 开始，遇到非终结符，就使用其规则内容代替，直到字符串结尾。
17 |
18 | 匹配的过程为：
19 |
20 | 1. 以 `prog` 为起始点
21 | 2. `prog` 右边为非终结符 `say_hi`，因此使用 `say_hi` 的规则内容
22 | 3. 发现非终结符 `HI`，于是使用其规则内容
23 | 4. 发现输入中的字符串 `hi` 匹配了该规则，于是开始尝试匹配 `say_hi` 规则中的 `STRING`
24 | 5. 发现 `STRING` 也是非终结符，于是转而使用其规则内容
25 | 6. 发现余下的输入字符匹配了 `STRING` 规则的内容，于是回到 `say_hi` 规则
26 | 7. 回到 `say_hi` 之后，发现它已经处理完毕，因此，回到了 `prog`
27 | 8. 回到 `prog` 之后，我们发现此时已经处理完全部的输入，符合了我们 `prog` 的规则，因此 `prog` 规则也匹配完成
28 |
29 | 最终，我们发现输入的字符串匹配了我们的语法。通过具体的步骤，我们可以体会到不断带入和推导的过程。
30 |
31 | 上述的推导过程，就是最左推导 - 我们总是从语法规则的最左边非终结符进行推导。与之类似，最右推导的定义为 - 总是选择最右边的非终结符进行推导。虽然最右推导的定义如此，但是我们并不能简单地将它套用进上述演示步骤。
32 |
33 | 最右推导可以描述的语法集合大于最左推导，但是缺点就是非常复杂且难于徒手完成它，因此出现了很多工具，用于生成 LR Parser，比如 [Yacc](http://dinosaur.compilertools.net/yacc/)。本系列的主要目的就是教大家如何手写编译器，因此余下的章节中，我们将只讨论最左推导。
34 |
35 | 最左推导还会有一个 N 的代数形式 - 「LL\(N\)」。N 表示的是在遇到分支的时候，最多向前预读 N 个 Token。比如有这样的语法：
36 |
37 | ```text
38 | stmt ::= ifStmt | whileStmt | blockStmt
39 | stmtList ::= stmt*
40 | ifStmt ::= "if" "(" expr ")" stmt "else" stmt
41 | whileStmt ::= "while" "(" expr ")" stmt
42 | blockStmt ::= "{" stmtList "}"
43 | ```
44 |
45 | 我们在处理 `stmt` 规则的时候，至少需要预读 1 个 Token，根据该预读的 Token 是 `if` 还是 `while` 还是 `{` 来是选择接下来处理 `ifStmt` 还是 `whileStmt` 还是 `blockStmt` 。因此这样的语法又被称为 LL\(1\) 语法。
46 |
47 | 以 C 语言入门的同学，不知道是否记得当初学习 if 语句的口诀「if 只能跟单条语句，如果需要使用多条语句则需要将多条语句放在大括号中」。如果了解了上面语法的含义，我就会知道原来 if 语句实际上只能跟单条语句，只不过有一个 `blockStmt` 语句，在它内部可以包含多条语句。
48 |
49 | 如果我们仔细观察上面的演示推导过程，会发现两点：
50 |
51 | 1. 将对每个非终结符处理都设想成一个函数，那么会发现整个推导过程，实际就是函数的互相调用
52 | 2. 并且，是由父级的规则函数调用了子级的规则函数，比如 `Prog` 调用了 `say_hi`；整个过程是由根「Root」规则开始，以深度优先的原则逐步进入到叶子规则的处理
53 |
54 | 因此基于最左推导完成的解析器通常又被称为自上而下「Top-Down」的解析器。
55 |
56 | 现在可以看看作为我们 hi 语言的语法解析器的框架代码：
57 |
58 | ```javascript
59 | class Parser {
60 | constructor(lexer) {
61 | this.lexer = lexer;
62 | }
63 |
64 | parseProg() {
65 | while (true) {
66 | const tok = this.lexer.peek();
67 | if (tok.type === TokenType.EOF) break;
68 | this.parseSayHi();
69 | }
70 | }
71 |
72 | parseSayHi() {}
73 | }
74 | ```
75 |
76 | `parseProg` 中的内容，就对应了 `prog` 规则的内容。我们先预读一个 Token，看其是否已经到达输入的结尾，如果是就停止处理，否则就调用 `parseSayHi` 进行解析。
77 |
78 | 注意这里的框架代码不要完全的对照上面的演示推导过程，否则你会发现没有 `parseHi` 和 `parseString`。前文已经提到过，为了将整个编译过程结构化，词法元素的解析已经被我们移到了 Lexer 中。
79 |
80 | 在开始完善解析器之前，还需要介绍另外两个类：「Node」和「NodeType」
81 |
82 | ```javascript
83 | class Node {
84 | constructor(type, loc) {
85 | this.type = type;
86 | this.loc = loc || new SourceLoc();
87 | }
88 | }
89 |
90 | class Prog extends Node {
91 | constructor(loc, body = []) {
92 | super(NodeType.Prog, loc);
93 | this.body = body;
94 | }
95 | }
96 |
97 | class SayHi extends Node {
98 | constructor(loc, value) {
99 | super(NodeType.SAY_HI, loc);
100 | this.value = value;
101 | }
102 | }
103 |
104 | class NodeType {}
105 | NodeType.Prog = "prog";
106 | NodeType.SAY_HI = "sayhi";
107 | ```
108 |
109 | 我们通过类「Node」和其派生类来存放我们解析的结果，通过「NodeType」来区分 Node 类型。
110 |
111 | 现在我们可以开始看看补全后的解析方法：
112 |
113 | ```javascript
114 | parseProg() {
115 | const node = new Prog();
116 | node.loc.start = this.lexer.getPos();
117 |
118 | while (true) {
119 | const tok = this.lexer.peek();
120 | if (tok.type === TokenType.EOF) break;
121 |
122 | node.body.push(this.parseSayHi());
123 | }
124 |
125 | node.loc.end = this.lexer.getPos();
126 | return node;
127 | }
128 |
129 | parseSayHi() {
130 | const node = new SayHi();
131 | let tok = this.lexer.next();
132 | assert.ok(tok.type === TokenType.HI, this.makeErrMsg(tok));
133 | node.loc.start = tok.loc.start;
134 |
135 | tok = this.lexer.next();
136 | assert.ok(tok.type === TokenType.STRING, this.makeErrMsg(tok));
137 |
138 | node.value = tok.value;
139 | node.loc.end = tok.loc.end;
140 | return node;
141 | }
142 |
143 | makeErrMsg(tok) {
144 | const loc = tok.loc;
145 | return `Unexpected token at line: ${loc.start.line} column: ${
146 | loc.start.col
147 | }`;
148 | }
149 | ```
150 |
151 | 我们在开始处理节点数据前，首先保存它的其实位置信息，在节点处理完成后，保存它的结束位置信息。并且我们使用 `assert.ok` 来在发生读入 Token 和语法不匹配时，直接报错并结束程序。
152 |
153 | 虽然通常情况下，一个好的错误恢复「Error Recovery」机制是一个好的解析器的必要条件，因为这样可以在一次解析过程中收集并报告尽量多的错误信息。然而要真正地完成一个良好的错误恢复子程序，其难度并不亚于编写一个解析器。况且在现有硬件条件、配合大部分情况下源码体积都很小时，解析一次也耗费不了多少时间，所以我们的一次仅报告一个错误的实现看起来似乎也是可行的。
154 |
155 | 最后我们来看一看，如何来将 Parser 和 Lexer 放到一起，来解析程序，并打印结果：
156 |
157 | ```javascript
158 | const { Source } = require("./source");
159 | const { Lexer, TokenType } = require("./lexer");
160 | const { Parser } = require("./parser");
161 | const util = require("util");
162 |
163 | const code = `hi "lexer"`;
164 | const src = new Source(code);
165 | const lexer = new Lexer(src);
166 | const parser = new Parser(lexer);
167 |
168 | const ast = parser.parseProg();
169 | console.log(util.inspect(ast, true, null));
170 | ```
171 |
172 | 运气好的情况下，我们大概会得到以下的输出：
173 |
174 | ```text
175 | Prog {
176 | type: 'prog',
177 | loc:
178 | SourceLoc {
179 | start: Position { ofst: -1, line: 1, col: 0 },
180 | end: Position { ofst: 9, line: 1, col: 10 } },
181 | body:
182 | [ SayHi {
183 | type: 'sayhi',
184 | loc:
185 | SourceLoc {
186 | start: Position { ofst: -1, line: 1, col: 0 },
187 | end: Position { ofst: 9, line: 1, col: 10 } },
188 | value: 'lexer' },
189 | [length]: 1 ] }
190 | ```
191 |
192 | 这个输出的内容，就是我们常说的抽象语法树「AST，Abstract Syntax Tree」了。这个树形结构，就是用来描述源码中的词法元素根据语法规则组成的层程序结构。有了这个结构之后，我们可以做更多的事情，比如我们接下来将进一步实现一个解释器，来解释运行我们的代码。
193 |
194 |
--------------------------------------------------------------------------------
/part1/1-8-arith-precedence-assoc.md:
--------------------------------------------------------------------------------
1 | # 1.8 解析算术表达式 - 优先级与结合性
2 |
3 | ## 优先级「Precedence」
4 |
5 | 上一节我们已经得到了消除左递归后的算术表达式语法，并根据语法完善了我们的解析程序。现在让我们来试着用我们上一节完成的内容，来解析算术表达式 `2 * 3 + 4`，我们会得到类似下面的输出：
6 |
7 | ```text
8 | type: prog
9 | body:
10 | - type: exprStmt
11 | value:
12 | type: binaryExpr
13 | op: '*'
14 | left: '2'
15 | right:
16 | type: binaryExpr
17 | op: +
18 | left: '3'
19 | right: '4'
20 | ```
21 |
22 | 我们解析的结果，从现实的数学表达式的角度来看，是存在问题的，因为我们将表达式解析成了：
23 |
24 | ```text
25 | node
26 | / | \
27 | 2 * node
28 | / | \
29 | 3 + 4
30 | ```
31 |
32 | 上面的结构表示的是 `2 * (3 + 4)`，而表达式 `2 * 3 + 4` 的结构应为：
33 |
34 | ```text
35 | node
36 | / | \
37 | node + 4
38 | / | \
39 | 2 * 3
40 | ```
41 |
42 | 为了解决这个问题，我们引入和数学上解决该问题类似的概念 - 优先级「Precedence」。优先级表示的是，在一个表达式中，如果同时出现多个运算符，那么具有较高优先级的运算符将先进行预算。
43 |
44 | 我们通过观察上面 `2 * 3 + 4` 对应的结构图发现，具有较高优先级的表达式\(`*`\)，将作为较低优先级的表达式\(`+`\)的操作数，即子节点。而是什么造就了图中的层次结构呢？就是我们的语法，语法规则和其待展开项，经过我们的 Top-Down 解析器的解析，就会体现为父子节点的关系。
45 |
46 | 依照这个思路，我们可以将具有较高优先级的表达式独立出来、作为新的语法规则，然后将其作为具有较低优先级的语法规则的待展开项。对于四则运算而言，其中的操作符优先级由高到低为：`num > "*/" > "+-"`，因此我们可以得到：
47 |
48 | ```text
49 | /* rule1 */
50 | expr ::= expr "+" term
51 | | expr "-" term
52 | | term
53 |
54 | /* rule2 */
55 | term ::= term "*" factor
56 | | term "/" factor
57 | | factor
58 |
59 | /* rule3 */
60 | factor ::= num
61 | ```
62 |
63 | 我们通过三个规则来区分运算符的优先级。rule1 和 rule2 为我们之前所提到的左递归规则。我们拿 rule1 来再次实践如何消除左递归。
64 |
65 | 回顾我们的左递归消除公式：
66 |
67 | ```text
68 | A ::= Aα | β
69 | // 消除左递归后
70 | A ::= βA'
71 | A' ::= αA' | ε
72 | // 将消除后的内容利用 EBNF 语法进一步合并为
73 | A ::= βα*
74 | ```
75 |
76 | 根据上面的式子，我们令：
77 |
78 | * `A = expr`
79 | * `α = "+" term`
80 | * `β = term`
81 |
82 | 将得到消除后的结果：
83 |
84 | ```text
85 | expr ::= term ( ("+" | "-") term )*
86 | ```
87 |
88 | rule2 的消除就留给大家来尝试了。上面的算术表达式语法最终为：
89 |
90 | ```text
91 | expr ::= term ( ( "+" | "-" ) term )*
92 | term ::= factor ( ( "*" | "/" ) factor )*
93 | factor ::= num
94 | ```
95 |
96 | 根据最终的语法，我们来完善我们的解析器。得益于我们之前的完善工作，现在我们这里只需要向语法解析器中增加3个方法，来对应上面的规则：
97 |
98 | ```javascript
99 | parseExpr() {
100 | let left = this.parseTerm();
101 | while (true) {
102 | const op = this.lexer.peek();
103 | if (op.type !== "+" && op.type !== "-") break;
104 | this.lexer.next();
105 | const node = new BinaryExpr();
106 | node.left = left;
107 | node.op = op;
108 | node.right = this.parseTerm();
109 | left = node;
110 | }
111 | return left;
112 | }
113 |
114 | parseTerm() {
115 | let left = this.parseFactor();
116 | while (true) {
117 | const op = this.lexer.peek();
118 | if (op.type !== "*" && op.type !== "/") break;
119 | this.lexer.next();
120 | const node = new BinaryExpr();
121 | node.left = left;
122 | node.op = op;
123 | node.right = this.parseFactor();
124 | left = node;
125 | }
126 | return left;
127 | }
128 |
129 | parseFactor() {
130 | return this.parseNum();
131 | }
132 | ```
133 |
134 | `parseExpr` 和 `parseTerm` 的内容差不多，所以我们理解一下 `parseExpr` 的实现内容：
135 |
136 | 1. 首先 `let left = this.parseTerm()` 对应 `expr` 规则的最左边第一个非终结符的解析
137 | 2. 随后我们进入了 while 循环
138 | 3. 在循环中，我们预读下一个 Token 是否为 `+` 或 `-`
139 | 4. 如果不是，我们就跳出循环，返回 left
140 | 5. 如果是 `+` 或 `-`，我们就调用 `parseTerm` 来解析运算符右边的子节点
141 | 6. 这样我们就已经得到了一个 BinaryExpr 节点，此时我们将它替换之前的 left 值
142 | 7. 跳到第3步继续执行
143 |
144 | 在循环中，我们将中间每一步得到的节点，都作为下一个即将处理的 BinaryExpr 节点的左边子节点。因此对于表达式 `1 + 2 - 3`，解析后的结构为：
145 |
146 | ```text
147 | node
148 | / | \
149 | node - 3
150 | / | \
151 | 1 + 2
152 | ```
153 |
154 | 也就是说，对于优先级相同的情况，我们采用了和数学中类似的从左往右处理的方式。
155 |
156 | 我们可以试再着解析问题表达式 `2 * 3 + 4`，我们会得到下面的输出：
157 |
158 | ```text
159 | type: prog
160 | body:
161 | - type: exprStmt
162 | value:
163 | type: binaryExpr
164 | op: +
165 | left:
166 | type: binaryExpr
167 | op: '*'
168 | left: '2'
169 | right: '3'
170 | right: '4'
171 | ```
172 |
173 | 上面的结果对应下图：
174 |
175 | ```text
176 | node
177 | / | \
178 | node + 4
179 | / | \
180 | 2 * 3
181 | ```
182 |
183 | 可见我们的工作已经达到目的了。
184 |
185 | ## 结合性「Associativity」
186 |
187 | 接下来我们来解析一个新的运算符 `**`，这个运算符就是 JS 中的指数运算符。该运算符含有两个字符，而我们目前的运算符还只是单个字符，除了这点不同之外，它还具有比 `*/` 运算符更高的优先级。
188 |
189 | 我们可以打开这个页面 [Operator precedence ](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence)，这个页面中列出了 JS 中所有的运算符，以及它们的优先级。
190 |
191 | 在这上述页面中，我们可以发现 `**` 运算符的优先级为 `15`，而 `*/` 的优先级为 `14`。因此为了在语法中包含这个运算规则，我们需要将现有的规则修改成如下的形式：
192 |
193 | ```text
194 | expr ::= term ( ( "+" | "-" ) term )*
195 | term ::= expo ( ( "*" | "/" ) expo )*
196 | expo ::= factor ( "**" factor )*
197 | factor ::= num
198 | ```
199 |
200 | 只要将现有的实现，修改下面几处，就可以实现对该运算规则的解析。
201 |
202 | 首先在 Lexer 中修改：
203 |
204 | ```javascript
205 | // 增加 Token 类型
206 | TokenType.EXPO = "**";
207 |
208 | // 修改 Lexer::isOp 方法，增加 `*`
209 | static isOp(ch) {
210 | return ["*", "/", "+", "-", "*"].indexOf(ch) !== -1;
211 | }
212 |
213 | // 修改 Lexer::readOp 方法，使之可以读取 `**`
214 | readOp() {
215 | const tok = new Token();
216 | tok.loc.start = this.getPos();
217 | tok.type = this.src.read();
218 | if (tok.type === "*") {
219 | // 如果当前的字符为 `*`，我们就预读下一个，如果也是 `*` 就读取它
220 | if (this.src.peek() === "*") {
221 | this.src.read();
222 | tok.type = "**";
223 | }
224 | }
225 | tok.loc.end = this.getPos();
226 | return tok;
227 | }
228 | ```
229 |
230 | 接着修改 Parser：
231 |
232 | ```javascript
233 | parseTerm() {
234 | let left = this.parseExpo();
235 | while (true) {
236 | const op = this.lexer.peek();
237 | if (op.type !== "*" && op.type !== "/") break;
238 | this.lexer.next();
239 | const node = new BinaryExpr();
240 | node.left = left;
241 | node.op = op;
242 | node.right = this.parseExpo();
243 | left = node;
244 | }
245 | return left;
246 | }
247 |
248 | parseExpo() {
249 | let left = this.parseFactor();
250 | while (true) {
251 | const op = this.lexer.peek();
252 | if (op.type !== "**") break;
253 | this.lexer.next();
254 | const node = new BinaryExpr();
255 | node.left = left;
256 | node.op = op;
257 | node.right = this.parseFactor();
258 | left = node;
259 | }
260 | return left;
261 | }
262 | ```
263 |
264 | 我们增加了 `parseExpo` 方法，并将 `parseTerm` 中原本调用 `parseFactor` 的地方替换为 `parseExpo`，而在 `parseExpo` 中，我们调用 `parseFactor`。这些修改都是一一对应了我们的语法规则的变动。
265 |
266 | 修改完成后，我们试着解析表达式 `2 ** 3 ** 4`，我们会得到下面的输出：
267 |
268 | ```text
269 | type: prog
270 | body:
271 | - type: exprStmt
272 | value:
273 | type: binaryExpr
274 | op: '**'
275 | left:
276 | type: binaryExpr
277 | op: '**'
278 | left: '2'
279 | right: '3'
280 | right: '4'
281 | ```
282 |
283 | 该输出的结构即为：
284 |
285 | ```text
286 | node
287 | / | \
288 | node ** 4
289 | / | \
290 | 2 ** 3
291 | ```
292 |
293 | 该结构表示的计算等于表达式 `(2 ** 3) ** 4`。但是我们知道，在 JS 中，表达式 `2 ** 3 ** 4` 实际上等于 `2 ** (3 ** 4)`，大家动手试一试。
294 |
295 | 造成这个结果的原因，就是我们没有正确处理运算符的结合性。当表达式中的运算符具有相同的优先级时，就需要通过结合性来指定计算的先后顺序。
296 |
297 | 更为具体地来说，对于表达式 `a OP b OP c` 而言：
298 |
299 | * 因为两个 `OP` 相同，即具有相同的优先级，此时我们需要考虑 `OP` 的结合性
300 | * 如果 `OP` 为左结合的，那么 `b` 将先和左边的 `a` 一起，执行 `OP` 运算，运算的结果再和 `c` 一起，做右边的 `OP` 运算。
301 | * 如果 `OP` 为右结合的，那么 `b` 将先和右边的 `c` 一起，执行 `OP` 运算，运算的结果再和 `a` 一起，做左边的 `OP` 运算。
302 |
303 | 比如 `a ** b ** c ** d`，对应的结构应为：
304 |
305 | ```text
306 | node
307 | / | \
308 | a ** node
309 | / | \
310 | b ** node
311 | / | \
312 | c ** d
313 | ```
314 |
315 | 在了解了结合性之后，我们来看如何将 `parseExpo` 进行修改，以解析具有右结合性的操作符 `**`。
316 |
317 | 我们来回顾一下在 [1.7 解析算术表达式 - 左递归和其消除法](1-7-arith-left-recursion.md) 末尾的测试用例，对于表达式 `1 + 2 + 3`，我们输出的结果为
318 |
319 | ```yaml
320 | type: prog
321 | body:
322 | - type: exprStmt
323 | value:
324 | type: binaryExpr
325 | op: +
326 | left: '1'
327 | right:
328 | type: binaryExpr
329 | op: '+'
330 | left: '2'
331 | right: '3'
332 | ```
333 |
334 | 对应的结构就是：
335 |
336 | ```text
337 | node
338 | / | \
339 | 1 + node
340 | / | \
341 | 2 + 3
342 | ```
343 |
344 | 这个结果其实可以看成是将 `+` 当做右结合性来解析的结果。为什么能有这样的效果，我们来看当时的语法：
345 |
346 | ```text
347 | expr ::= num expr'
348 | expr' ::= ( ( "*" | "/" | "+" | "-" ) expr )*
349 | | ε
350 | ```
351 |
352 | 为了解析这样的语法，我们的代码为：
353 |
354 | ```javascript
355 | parseExpr() {
356 | const num = this.parseNum();
357 | return this.parseExpr1(num);
358 | }
359 |
360 | parseNum() {
361 | const node = new NumLiteral();
362 | let tok = this.lexer.next();
363 | assert.ok(tok.type === TokenType.NUMBER, this.makeErrMsg(tok));
364 | node.loc = tok.loc;
365 | node.value = tok.value;
366 | return node;
367 | }
368 |
369 | parseExpr1(left) {
370 | const node = new BinaryExpr();
371 | node.left = left;
372 | node.op = this.lexer.peek();
373 | if (!Lexer.isOp(node.op.type)) return left;
374 | this.lexer.next();
375 | assert.ok(Lexer.isOp(node.op.type), this.makeErrMsg(node.op));
376 | node.right = this.parseExpr();
377 | return node;
378 | }
379 | ```
380 |
381 | 我们还一起看了这段代码执行的流程示意图，大家可以结合起来看。这段代码将操作符都处理成右结合性的原因就在于，`parseExpr1` 方法中，对于右边节点的处理，总是调用 `parseExpr`：
382 |
383 | ```javascript
384 | parseExpr1(left) {
385 | // ...
386 | node.right = this.parseExpr();
387 | return node;
388 | }
389 | ```
390 |
391 | 而在 `parseExpr` 内部，它先读取一个操作数，然后将其作为参数继续调用 `parseExpr1`，在未来某一时刻 `parseExpr1` 返回时，此前被传入的操作数，成为了返回的节点的左边子节点；这样的间接递归形式，使得所有的操作数都和它右边的操作符结合到了一起，刚好符合了我们需要对右结合性的处理需求。
392 |
393 | 所以我们可以将我们的 `**` 处理方法修改成：
394 |
395 | ```javascript
396 | parseExpo() {
397 | let left = this.parseFactor();
398 | while (true) {
399 | const op = this.lexer.peek();
400 | if (op.type !== "**") break;
401 | this.lexer.next();
402 | const node = new BinaryExpr();
403 | node.left = left;
404 | node.op = op;
405 | node.right = this.parseExpo();
406 | left = node;
407 | }
408 | return left;
409 | }
410 | ```
411 |
412 | 非常简单的修改，只有一行 `node.right = this.parseExpo();`，我们将原本 `parseFactor` 换成了 `parseExpo`。虽然我们这里使用的是直接递归，但是不必担心，我们在 `parseExpo` 中总是会先读取 factor，从而消耗掉一部分输入，因此不会陷入无限循环。
413 |
414 | 我们通过一个测试来试一试我们修改后的内容，解析表达式 `2 ** 3 ** 4 ** 5`。我们可以得到下面的输出：
415 |
416 | ```yaml
417 | type: prog
418 | body:
419 | - type: exprStmt
420 | value:
421 | type: binaryExpr
422 | op: '**'
423 | left: '2'
424 | right:
425 | type: binaryExpr
426 | op: '**'
427 | left: '3'
428 | right:
429 | type: binaryExpr
430 | op: '**'
431 | left: '4'
432 | right: '5'
433 | ```
434 |
435 | 再来一个综合型的测试，解析表达式 `1 + 2 ** 3 * 5`。我们可以得到下面的输出：
436 |
437 | ```yaml
438 | type: prog
439 | body:
440 | - type: exprStmt
441 | value:
442 | type: binaryExpr
443 | op: +
444 | left: '1'
445 | right:
446 | type: binaryExpr
447 | op: '*'
448 | left:
449 | type: binaryExpr
450 | op: '**'
451 | left: '2'
452 | right: '3'
453 | right: '5'
454 | ```
455 |
456 |
--------------------------------------------------------------------------------
/part1/1-7-arith-left-recursion.md:
--------------------------------------------------------------------------------
1 | # 1.7 解析算术表达式 - 左递归和其消除法
2 |
3 | ## 算术表达式语法
4 |
5 | 到目前为止，我们的 hi 语言还是显得有些单薄了。接下来我们将给它添加计算数学表达式的功能。
6 |
7 | 未来我们在像 hi 语言中增加新的语法功能的时候，都将按照这样的步骤：
8 |
9 | 1. 增加相应的语法规则，也就是在我们的 EBNF 中增加需要新增的语法规则
10 | 2. 根据新增的语法规则，向词法解析器中增加适应新规则的内容
11 | 3. 根据新增的语法规则，向语法解析器中增加适应新规则的内容
12 |
13 | 按照上面的步骤来看，首先我们需要在向语法中增加数学表达式的新规则。我们来看看数学表达式的语法来如何书写：
14 |
15 | ```text
16 | expr ::= expr "*" expr
17 | | expr "/" expr
18 | | expr "+" expr
19 | | expr "-" expr
20 | | num
21 | ```
22 |
23 | ## 左递归「Left Recursion」
24 |
25 | 我们先来回顾下，我们对已有的 hi 语言规则是如何进行解析的：
26 |
27 | ```text
28 | prog ::= say_hi*
29 | say_hi ::= HI STRING
30 | HI ::= "hi"
31 | STRING ::= '"' [^"]* '"'
32 | ```
33 |
34 | 我们分别在 Parser 中写了 `parseProg` 和 `parseSayHi` 两个方法，它们分别对应语法中的 `prog` 和 `say_hi` 这两个规则。然后我们根据 `prog` 的语法规则，在 `parseProg` 内部调用了 `parseSayHi`，方法之间的协作方式，完全的参照了语法规则的定义。
35 |
36 | 再来看一看我们目前得到的数学表达式语法规则，我们立刻按部就班地往 Parser 中添加一个新的 `parseExpr` 方法。
37 |
38 | 但是问题很快就出现了，我们先看第一个分支：
39 |
40 | ```text
41 | expr ::= expr "*" expr
42 | ```
43 |
44 | 按照规则的定义，我们在 `parseExpr` 内部，需要首先调用 `parseExpr` 方法。很显然，由于这个方法直接调用了自身的同时、内部并没有对需要处理的字符串进行任何步进操作，因此会导致程序陷入无限循环。
45 |
46 | 对于一个规则而言，如果它右边的规则内容部分、最左边出现的又是自身的规则，我们就称该规则是左递归「Left Recursion」的；并且该规则所属的语法，又被称为是左递归的语法。相似的，如果它右边的规则内容部分、最右边出现的又是自身的规则，我们就称之为右递归的规则。
47 |
48 | ## 消除左递归「Elimination of Left Recursion」
49 |
50 | 我们目前手写的语法解析器，是属于自上而下「Top-Down」的类型，我们还发现，自上而下的语法解析器，是无法处理左递归语法的。
51 |
52 | 所以我们要考虑，如何消除左递归「Elimination of Left Recursion」。
53 |
54 | 为了将问题简化，我们来看一个简单的左递归的语法规则：
55 |
56 | ```text
57 | A ::= Aα | β
58 | ```
59 |
60 | 这个语法规则中包含这样几个内容：
61 |
62 | 1. 非终结符 A
63 | 2. 不以 A 开头的\(非\)终结符 α
64 | 3. 不以 A 开头的\(非\)终结符 β
65 |
66 | 有一点需要注意的是，上面的语法规则属于直接左递归，因为它的右边的规则内容立刻出现了自身。为了做为对比，我们看一下间接左递归：
67 |
68 | ```text
69 | A ::= Sα | β
70 | S ::= Aβ
71 | ```
72 |
73 | 我们来看一下这个规则的匹配过程：
74 |
75 | 1. 选取 `A ::= Sα` 这个分支
76 | 2. 因为 `S ::= Aβ`，所以将其右边带入到上一步、替换其中的 `S`，得到：`A ::= Aβα`
77 |
78 | 这又符合了我们之前对左递归的定义。我们的自上而下的解析器同样无法处理间接左递归的语法。
79 |
80 | 我们先看一下对于直接左递归 `A ::= Aα | β` 而言，它如何匹配输入的字符串：
81 |
82 | 1. `A ::= Aα`
83 | 2. `A ::= Aαα`
84 | 3. `A ::= Aααα`
85 | 4. 以此类推...
86 | 5. 直到某一时刻，输入的内容匹配到了 `β`，最终我们匹配的结果为
87 | 6. `A ::= βααα...`
88 |
89 | 当然，我们也可能在第一步的时候就直接匹配到了 `β`。因此，上面的语法匹配的字符为：以 `β` 开头的，后面紧接着任意数量的 `α`。
90 |
91 | 现在我们知道对于上面的规则来说，形如 `βααα...` 的输入，将会符合规则。并且上面的语法规则实际上是从右往左来匹配输入的。
92 |
93 | 为了使得我们的自上而下的解析器得以工作，我们重写后的规则需要满足：
94 |
95 | 1. 规则 A 需要从左往右来匹配输入
96 | 2. 规则 A 最左边的第一个\(非\)终结符不能为 A 自身
97 |
98 | 根据这两个原则，我们首先将 A 写成：
99 |
100 | ```text
101 | A ::= βA'
102 | ```
103 |
104 | 这样的目的就是先匹配 `βααα...` 中的第一个 `β`，这就满足了我们上面的两点重写需求。但是还没结束，我们接着 `A'` 要做的就是能够匹配重复出现的 `α`，因此我们可以将 `A'` 写成：
105 |
106 | ```text
107 | A' ::= αA' | ε
108 | ```
109 |
110 | `ε` 表示匹配输入的结尾，作为匹配的终止条件。
111 |
112 | 我们将它们放到一起：
113 |
114 | ```text
115 | A ::= βA'
116 | A' ::= αA' | ε
117 | ```
118 |
119 | 我们来试着使用重写后的规则，看看它将如何匹配输入：
120 |
121 | 1. `A ::= βA'` 匹配开头第一个 `βA'`
122 | 2. 因为 `A' ::= αA'`，将其右边带入上一步的右边、替换 `A'`，可以匹配到 `βαA'`
123 | 3. 继续上一步，可以继续匹配到 `βααA'`
124 | 4. 继续上一步，可以继续匹配到 `βαααA'`
125 | 5. 以此类推...
126 | 6. 直到匹配到输入的结尾部分，满足 `A' ::= ε`
127 | 7. 最终得以匹配的结果为 `βααα...αααε`
128 |
129 | 现在我们得出结论，对于直接左递归：
130 |
131 | ```text
132 | A ::= Aα | β
133 | ```
134 |
135 | 我们可以通过左递归消除，将其变换为：
136 |
137 | ```text
138 | A ::= βA'
139 | A' ::= αA' | ε
140 | ```
141 |
142 | 现在我们着手看一下我们的算术表达式语法，针对它如何进行左递归消除：
143 |
144 | ```text
145 | expr ::= expr "*" expr
146 | | num
147 | ```
148 |
149 | 我们直接套用公式，令:
150 |
151 | * `A = expr`，因为 `A` 的定义为需要进行消除的项
152 | * `α = "*" expr`，因为 `α` 的定义为，以不是待消除项开头的\(非\)终结符
153 | * `β = num`，因为 `β` 的定义为，以不是待消除项开头的\(非\)终结符
154 |
155 | 经过变换得到：
156 |
157 | ```text
158 | expr ::= num expr'
159 | expr' ::= "*" expr expr' | ε
160 | ```
161 |
162 | 我们已经可以将乘法表达式进行左递归消除了，接下来我们看看如何处理整个算术表达式：
163 |
164 | ```text
165 | expr ::= expr "*" expr
166 | | expr "/" expr
167 | | expr "+" expr
168 | | expr "-" expr
169 | | num
170 | ```
171 |
172 | 面对一下变得这么复杂的表达式，大家估计会感到无从下手。我们可以利用已经掌握的知识，将每个分支先拆开来进行消除：
173 |
174 | ```text
175 | expr ::= num expr'
176 | expr' ::= "*" expr expr' | ε
177 |
178 | expr ::= num expr'
179 | expr' ::= "/" expr expr' | ε
180 |
181 | expr ::= num expr'
182 | expr' ::= "+" expr expr' | ε
183 |
184 | expr ::= num expr'
185 | expr' ::= "-" expr expr' | ε
186 | ```
187 |
188 | 我们将上面的结果两行一组、相互对照起来观察，不难发现，第一行都是相同的，第二行也只是操作符不同，将所有第二行综合起来看，它们其实都是表示 `expr'` 的不同分支。我们可以将上面的结果进行合并：
189 |
190 | ```text
191 | expr ::= num expr'
192 | expr' ::= "*" expr expr'
193 | | "/" expr expr'
194 | | "+" expr expr'
195 | | "-" expr expr'
196 | | ε
197 | ```
198 |
199 | 于是我们发现一个新的结论，对于形如：
200 |
201 | ```text
202 | A ::= Aα | Aβ | γ
203 | ```
204 |
205 | 的规则，我们可以将其转换成：
206 |
207 | ```text
208 | A ::= γA'
209 | A' ::= αA' | βA' | ε
210 |
211 | /* A' 根据 EBNF 语法功能，上面的 A' 又可进一步简化为 */
212 | A' ::= α*
213 | | β*
214 | | ε
215 |
216 | /* 将 A' 进一步简化 */
217 | A' ::= ( α | β )*
218 | | ε
219 | ```
220 |
221 | 来消除左递归。
222 |
223 | 我们最终处理完成后的表达式语法为：
224 |
225 | ```text
226 | expr ::= num expr'
227 |
228 | /* 对照上面简化 A' 中间形式 */
229 | expr' ::= ( "*" expr )*
230 | | ( "/" expr )*
231 | | ( "+" expr )*
232 | | ( "-" expr )*
233 | | ε
234 |
235 | /* 对照 A’ 的最终形式 */
236 | expr' ::= ( "*" expr )*
237 | | ( "/" expr )*
238 | | ( "+" expr )*
239 | | ( "-" expr )*
240 | | ε
241 |
242 | /* 根据我们的表达式内容进一步简化 */
243 | expr' ::= ( ( "*" | "/" | "+" | "-" ) expr )*
244 | | ε
245 |
246 | /* 最终我们得到 */
247 | expr ::= num expr'
248 | expr' ::= ( ( "*" | "/" | "+" | "-" ) expr )*
249 | | ε
250 | ```
251 |
252 | ## 完善解析器
253 |
254 | 现在我们来补全我们的解析器，以解析算术表达式。
255 |
256 | ### 完善词法解析器
257 |
258 | 我们先来完善词法解析器，首先我们先增加几个 Token 类型：
259 |
260 | ```javascript
261 | TokenType.NUMBER = "number";
262 | TokenType.MUL = "*";
263 | TokenType.DIV = "/";
264 | TokenType.ADD = "+";
265 | TokenType.SUB = "-";
266 | ```
267 |
268 | 这些新增的类型即为我们接下来将要解析的 Token 类型，我们来修改一下 `Lexer::next` 方法：
269 |
270 | ```javascript
271 | next() {
272 | this.skipWhitespace();
273 | const ch = this.src.peek();
274 | if (ch === '"') return this.readString();
275 | if (ch === "h") return this.readHi();
276 | // 解析数字
277 | if (Lexer.isDigit(ch)) return this.readNumber();
278 | // 解析运算符
279 | if (Lexer.isOp(ch)) return this.readOp();
280 | if (ch === EOF) return new Token(TokenType.EOF);
281 | throw new Error(this.makeErrMsg());
282 | }
283 | ```
284 |
285 | 没有什么特别新的东西，只是增加了两个预测分支，分别预测接下来选择解析数字还是解析运算符。接着我们看一下 `readNumber` 和 `readOp` 的实现：
286 |
287 | ```javascript
288 | readNumber() {
289 | const tok = new Token(TokenType.NUMBER);
290 | tok.loc.start = this.getPos();
291 | const v = [this.src.read()];
292 | while (true) {
293 | let ch = this.src.peek();
294 | if (Lexer.isDigit(ch)) {
295 | v.push(this.src.read());
296 | continue;
297 | }
298 | break;
299 | }
300 | tok.loc.end = this.getPos();
301 | tok.value = v.join("");
302 | return tok;
303 | }
304 |
305 | readOp() {
306 | const tok = new Token();
307 | tok.loc.start = this.getPos();
308 | tok.type = this.src.read();
309 | tok.loc.end = this.getPos();
310 | return tok;
311 | }
312 | ```
313 |
314 | 如果输入的是数字的话，我们就不断的尝试读取接下来的数字，直到接下来的字符不是数字为止，这里我们只处理了整型数，并且没有特别考虑前导零和正负整数的情况。所以符合我们条件的数字面量的类型为：以可选前导零开头的任意整数。
315 |
316 | 处理操作符\(运算符\)的过程就很简单了，由于我们目前的操作符都是单个字符的，直接读取它们就行了。
317 |
318 | ### 完善语法解析器
319 |
320 | 我们继续看一下如何完善语法解析器。
321 |
322 | 首先，我们添加几个新的节点类型的定义：
323 |
324 | ```javascript
325 | class ExprStmt extends Node {
326 | constructor(loc, value) {
327 | super(NodeType.EXPR_STMT, loc);
328 | this.value = value;
329 | }
330 | }
331 |
332 | class BinaryExpr extends Node {
333 | constructor(loc, op, left, right) {
334 | super(NodeType.BINARY_EXPR, loc);
335 | this.op = op;
336 | this.left = left;
337 | this.right = right;
338 | }
339 | }
340 |
341 | class NumLiteral extends Node {
342 | constructor(loc, value) {
343 | super(NodeType.NUMBER, loc);
344 | this.value = value;
345 | }
346 | }
347 | ```
348 |
349 | 这里我们开始区分表达式「Expression」和语句「Statement」这两种不同的节点类型了。
350 |
351 | 运算符 `* / + -` 被称为双目运算符，所谓「目」就是操作数的意思。因为这些运算符都需要两个操作数，所以称之为双目运算符，它们所表示的运算就称为双目运算。
352 |
353 | 我们通过类「BinaryExpr」来表示这样的程序结构。
354 |
355 | 对于数值字面量而言，我们使用类「NumLiteral」来表示它。字面量也是表达式，表达式「Expression」是语句「Statement」的组成部分。
356 |
357 | 为了表示程序中出现的表达式语句，我们还定义了类「ExprStmt」，该类的属性 `value` 表示的就是作为其唯一子节点的表达式节点。
358 |
359 | 为了对应新增的节点定义，我们也需要添加几个新的节点类型：
360 |
361 | ```javascript
362 | NodeType.EXPR_STMT = "exprStmt";
363 | NodeType.BINARY_EXPR = "binaryExpr";
364 | NodeType.NUMBER = "number";
365 | ```
366 |
367 | 和完善词法解析器的步骤相似，我们也从语法解析的入口方法开始完善：
368 |
369 | ```javascript
370 | parseProg() {
371 | const node = new Prog();
372 | node.loc.start = this.lexer.getPos();
373 | while (true) {
374 | const tok = this.lexer.peek();
375 | let stmt;
376 | if (tok.type === TokenType.EOF) break;
377 | if (tok.type === TokenType.HI) stmt = this.parseSayHi();
378 | // 预测解下来是否需要进行表达式的解析
379 | if (tok.type === TokenType.NUMBER) stmt = this.parseExprStmt();
380 | node.body.push(stmt);
381 | }
382 | node.loc.end = this.lexer.getPos();
383 | return node;
384 | }
385 | ```
386 |
387 | 上一节我们已经将算术表达式的左递归进行了消除，通过消除后的表达式我们发现，算术表达式总是以数值字面量作为开头的，因此我们可以使用上面代码中的预测条件。
388 |
389 | 由于 ExprStmt 只有唯一的表达式节点，所以对它的解析也很接单：
390 |
391 | ```javascript
392 | parseExprStmt() {
393 | const node = new ExprStmt();
394 | const expr = this.parseExpr();
395 | node.loc = expr.loc;
396 | node.value = expr;
397 | return node;
398 | }
399 | ```
400 |
401 | `parseExprStmt` 只是简单地调用 `parseExpr` 方法，那么 `parseExpr` 实现为：
402 |
403 | ```javascript
404 | parseExpr() {
405 | const num = this.parseNum();
406 | return this.parseExpr1(num);
407 | }
408 |
409 | parseNum() {
410 | const node = new NumLiteral();
411 | let tok = this.lexer.next();
412 | assert.ok(tok.type === TokenType.NUMBER, this.makeErrMsg(tok));
413 | node.loc = tok.loc;
414 | node.value = tok.value;
415 | return node;
416 | }
417 |
418 | parseExpr1(left) {
419 | const node = new BinaryExpr();
420 | node.left = left;
421 | node.op = this.lexer.peek();
422 | if (!Lexer.isOp(node.op.type)) return left;
423 | this.lexer.next();
424 | assert.ok(Lexer.isOp(node.op.type), this.makeErrMsg(node.op));
425 | node.right = this.parseExpr();
426 | return node;
427 | }
428 | ```
429 |
430 | 上面的代码对照消除左递归后的表达式语法：
431 |
432 | ```text
433 | expr ::= num expr'
434 | expr' ::= ( ( "*" | "/" | "+" | "-" ) expr )*
435 | | ε
436 | ```
437 |
438 | 我们只是使用方法来替代语法规则中的展开操作。`parseNum` 就是解析数值字面量，就不过多解释了。
439 |
440 | `parseExpr1` 方法就对应了消除后的 `expr'` 的内容。`parseExpr1` 中我们先预读接下来的 Token 是否为操作符，如果不是，就表示处理已经完成了，直接返回传入的 `left`。如果接下来为操作符，我们就先将已经处理的操作符跳过，然后接续调用 `parseExpr`。我们没有陷入无限循环的原因就是，我们在方法内部总是可以消化掉一部分输入。
441 |
442 | 对于表达式 `1 + 2 * 3` 来说，调用的过程如下：
443 |
444 | 
445 |
446 | 我们可以以一个 U 型的方式来看这个图，从左边开始往下，到了最底部时，转到右边往上。左边和中间左半边部分，表示我们的递归调用链、期间发生的参数传递、以及表达式字符串被不断读取的消减过程。右边和中间的右半部分表示了递归调用结束，不断返回并构造节点的过程。
447 |
448 | 上图中我们不仅分析了整个表达式解析的过程；还根据这个过程，演示了我们消除左递归后的右递归的执行过程。
449 |
450 | 在我们着手试一试完善的成果之前，我们先添加一个新的 Visitor - 「YamlVisitor」，它可以将我们的 AST 输出为 [YAML](https://yaml.org/) 的格式，这个格式的好处就是既能体现我们树形结构的层级关系，格式上也显得更加清晰。
451 |
452 | 我们先往类「Visitor」中增加一些内容：
453 |
454 | ```javascript
455 | visitExprStmt(node) {}
456 |
457 | visitStmt(node) {
458 | switch (node.type) {
459 | case NodeType.EXPR_STMT:
460 | return this.visitExprStmt(node);
461 | case NodeType.SAY_HI:
462 | return this.visitSayHi(node);
463 | }
464 | }
465 |
466 | visitStmtList(list) {}
467 |
468 | visitNumLiteral(node) {}
469 |
470 | visitBinaryExpr(node) {}
471 |
472 | visitExpr(node) {
473 | switch (node.type) {
474 | case NodeType.NUMBER:
475 | return this.visitNumLiteral(node);
476 | case NodeType.BINARY_EXPR:
477 | return this.visitBinaryExpr(node);
478 | }
479 | }
480 | ```
481 |
482 | 空着的方法留给子类去实现。`visitStmt` 和 `visitExpr` 做一个简单的任务派发，根据不同节点的类型，将它们派发到各自的处理方法中。
483 |
484 | 下面是「YamlVisitor」的实现：
485 |
486 | ```javascript
487 | const { Visitor } = require("./visitor");
488 | const yaml = require("js-yaml");
489 |
490 | class YamlVisitor extends Visitor {
491 | visitProg(node) {
492 | return yaml.dump({
493 | type: node.type,
494 | body: this.visitStmtList(node.body)
495 | });
496 | }
497 |
498 | visitStmtList(list) {
499 | return list.map(stmt => this.visitStmt(stmt));
500 | }
501 |
502 | visitExprStmt(node) {
503 | return {
504 | type: node.type,
505 | value: this.visitExpr(node.value)
506 | };
507 | }
508 |
509 | visitBinaryExpr(node) {
510 | return {
511 | type: node.type,
512 | op: node.op.type,
513 | left: this.visitExpr(node.left),
514 | right: this.visitExpr(node.right)
515 | };
516 | }
517 |
518 | visitNumLiteral(node) {
519 | return node.value;
520 | }
521 | }
522 | ```
523 |
524 | 在对不同节点的处理中，我仅输出扼要的内容，比如跳过了行列号。在起始点的处理方法 `visitProg` 中，我们将返回根据 YAML 语法序列化后的字符串。
525 |
526 | 我们尚未考虑如何消除间接左递归，因为消除直接左递归已经可以应对大部分情况了，我们不妨等遇到间接左递归的时候再考虑如何消除它。
527 |
528 | 最后通过一小段程序来检验这次的完成结果：
529 |
530 | ```javascript
531 | const { Source } = require("./source");
532 | const { Lexer, TokenType } = require("./lexer");
533 | const { Parser } = require("./parser");
534 | const { InterpretVisitor } = require("./interpret-visitor");
535 | const { YamlVisitor } = require("./yaml-visitor");
536 | const util = require("util");
537 |
538 | const code = `1 + 2 + 3
539 | 4 + 5 * 6
540 | `;
541 | const src = new Source(code);
542 | const lexer = new Lexer(src);
543 | const parser = new Parser(lexer);
544 |
545 | const ast = parser.parseProg();
546 | const visitor = new YamlVisitor();
547 | console.log(visitor.visitProg(ast));
548 | ```
549 |
550 | 幸运的话，将看到类似下面的输出：
551 |
552 | ```yaml
553 | type: prog
554 | body:
555 | - type: exprStmt
556 | value:
557 | type: binaryExpr
558 | op: +
559 | left: '1'
560 | right:
561 | type: binaryExpr
562 | op: '+'
563 | left: '2'
564 | right: '3'
565 | - type: exprStmt
566 | value:
567 | type: binaryExpr
568 | op: +
569 | left: '4'
570 | right:
571 | type: binaryExpr
572 | op: '*'
573 | left: '5'
574 | right: '6'
575 | ```
576 |
577 |
--------------------------------------------------------------------------------
/images/expr123.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/.gitbook/assets/expr123.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------