|
Size: 1373
Comment:
|
Size: 1523
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 31: | Line 31: |
| 教程进行到这里就开始增加对函数的Parse似乎有点太早，因为目前尚未触及到'''参数传递'''之类的问题。而且真实世界的编程语言通常都会有type机制，支持多种type，其中可能会有function type，而type也是目前尚未触及的问题。 | 教程进行到这里就开始增加对函数的Parse似乎有点太早，因为目前尚未触及到'''参数传递'''之类的问题。而且真实世界的编程语言通常都会有'''type'''机制，支持多种type如function type之类，而type也是目前尚未触及的问题。 |
| Line 34: | Line 34: |
| 1. 让编译器在某些事情上与最终版很很近 | 1. 让编译器在某些事情上与最终版很相近 |
| Line 36: | Line 36: |
截至目前完成的Parse可以归类为一种叫“predictive parser”的概念：在关键之处通过精确的Peek下一个字符来决定动作。 |
更多表达式的Parsing
简介
上一章节讲述并验证了Parse和Translate普通数学表达式的技术。最后以一个简单Parser作为成果而结束，该parser可以解析任意复杂的数学表达式，但有两个限制：
- 不支持变量，只支持数字字面量
- 数字字面量只支持单个数字
变量
b * b + 4 * a * c
其中a、b、c皆是变量。
要支持变量，只需要在之前的设计上扩展<factor>即可。 之前是：
<factor> ::= <number> | (<expression>)
现在要扩展为：
<factor> ::= <number> | (<expression>) | <variable>
代码改动非常小，只需要在factor解析那儿增加一种peek操作即可实现。
函数
除了现有的<factor>形式，还剩一种factor是几乎所有编程语言都会支持的：函数调用。
教程进行到这里就开始增加对函数的Parse似乎有点太早，因为目前尚未触及到参数传递之类的问题。而且真实世界的编程语言通常都会有type机制，支持多种type如function type之类，而type也是目前尚未触及的问题。
但是作者还是决定现在就踏足对函数的Parse，原因有：
- 让编译器在某些事情上与最终版很相近
- 引入一个很值得讨论的新问题
截至目前完成的Parse可以归类为一种叫“predictive parser”的概念：在关键之处通过精确的Peek下一个字符来决定动作。