两周自制脚本语言pdf

两周自制脚本语言 内容简介

《两周自制脚本语言》是一本优秀的编译原理入门读物。全书穿插了大量轻松风趣的对话，读者可以随书中的人物一起从简单的语言解释器开始，逐步添加新功能，最终完成一个支持函数、数组、对象等高级功能的语言编译器。《两周自制脚本语言》与众不同的实现方式不仅大幅简化了语言处理器的复杂度，还有助于拓展读者的视野。

《两周自制脚本语言》适合对编译原理及语言处理器设计有兴趣的读者以及正在学习相关课程的大中专院校学生。同时，已经学习过相关知识，有一定经验的开发者，也一定能从本书新颖的实现方式中受益良多。

两周自制脚本语言 目录

第1部分　基础篇

第1天　来，我们一起做些什么吧　1

1．1　机器语言与汇编语言　2

1．2　解释器与编译器　3

1．3　开发语言处理器　5

1．4　语言处理器的结构与本书的框架　6

第2天　设计程序设计语言　10

2．1　麻雀虽小、五脏俱全的程序设计语言　11

2．2　句尾的分号　12

2．3　含糊不得的语言　14

第3天　分割单词　17

3．1　Token对象　18

3．2　通过正则表达式定义单词　19

3．3　借助java．util．regex设计词法分析器　22

3．4　词法分析器试运行　27

第4天　用于表示程序的对象　30

4．1　抽象语法树的定义　31

4．2　设计节点类　34

4．3　BNF　38

4．4　语法分析与抽象语法树　42

第5天　设计语法分析器　44

5．1　Stone语言的语法　45

5．2　使用解析器与组合子　46

5．3　由语法分析器生成的抽象语法树　53

5．4　测试语法分析器　59

第6天　通过解释器执行程序　62

6．1　eval方法与环境对象　63

6．2　各种类型的eval方法　65

6．3　关于GluonJ　69

6．4　执行程序　72

第7天　添加函数功能　75

7．1　扩充语法规则　76

7．2　作用域与生存周期　81

7．3　执行函数　83

7．4　计算斐波那契数　89

7．5　为闭包提供支持　90

7．6　实现闭包　92

第8天　关联Java语言　95

8．1　原生函数　96

8．2　编写使用原生函数的程序　98

第9天　设计面向对象语言　101

9．1　设计用于操作类与对象的语法　102

9．2　实现类所需的语法规则　103

9．3　实现eval方法　104

9．4　通过闭包表示对象　110

9．5　运行包含类的程序　114

第10天　无法割舍的数组　115

10．1　扩展语法分析器　116

10．2　仅通过修改器来实现数组　119

第2部分　性能优化篇

第11天　优化变量读写性能　123

11．1　通过简单数组来实现环境　124

11．2　用于记录全局变量的环境　127

11．3　事先确定变量值的存放位置　130

11．4　修正eval方法并最终完成性能优化　134

第12天　优化对象操作性能　137

12．1　减少内存占用　138

12．2　能否通过事先查找变量的保存位置来优化性能　141

12．3　定义lookup方法　144

12．4　整合所有修改并执行　147

12．5　内联缓存　152

第13天　设计中间代码解释器　156

13．1　中间代码与机器语言　157

13．2　Stone虚拟机　158

13．3　通过栈实现环境　167

13．4　寄存器的使用　170

13．5　引用变量的值　173

13．6　if语句与while语句　173

13．7　函数的定义与调用　175

13．8　转换为虚拟机器语言　177

13．9　通过虚拟机执行　184

第14天　为Stone语言添加静态类型支持以优化性能　187

14．1　指定变量类型　188

14．2　通过数据类型检查发现错误　193

14．3　运行程序时执行类型检查　204

14．4　对类型省略的变量进行类型推论　208

14．5　Java二进制代码转换　214

14．6　综合所有修改再次运行程序　226

第3部分　解说篇(自习时间)

第15天　手工设计词法分析器　229

15．1　修改自动机　230

15．2　自动机程序　233

15．3　正则表达式的极限　235

第16天　语法分析方式　236

16．1　正则表达式与BNF　237

16．2　语法分析算法　238

16．3　LL语法分析　239

16．4　算符优先分析法与自底向上语法分析　244

第17天　Parser库的内部结构　251

17．1　组合子分析　252

17．2　解析器组合子的内部　252

第18天　GluonJ的使用方法　263

18．1　设定类路径　264

18．2　启动设定　265

18．3　GluonJ语言　267

18．4　功能总结　268

第19天　抽象语法树与设计模式　271

19．1　理想的设计　272

19．2　Interpreter模式　273

19．3　Visitor模式　276

19．4　使用反射　282

19．5　面向切面语言　284

两周自制脚本语言 精彩文摘

2.3　含糊不得的语言

如果代码中能够随处省略分号，并可以任意换行，似乎可读性就会提升。但要是一种程序设计语言的各种语法元素都能省略，语句中任何地方都能换行，它就可能会变得模棱两可，引起误解。

如果语言的含义不清，程序员就无法判断程序的实际执行方式，这会造成很大的麻烦。事实上，如何为这种语言设计语言处理器也很让人头疼。在设计一种语言时，设计者必须多加注意，确保语言中不出现模棱两可的歧义语法。

A 刚刚讨论的句尾分号的省略问题，不会有什么歧义吧？

H 如果一个分号不能省略，又没有明确的不可省略的理由，会让人感到很困惑呢。

C 我在设计时已经尽力避免出现这种情况了。不过刚才的说明确实不够明了，不太容易理解。

F 我倒是觉得多写几个分号不是什么问题，不过似乎大家都不喜欢写分号嘛。

C 就是呀，如果语句必须由分号结束，就不会有那么多问题了。

S 嗯，不过从使用者的角度来看，能不用的东西肯定是不用比较好。

C 顺便一提，基于类似的理由，Stone 语言也不会支持 Ruby 语言的正则表达式字面量。

A 正则表达式字面量？

C 如果只要把两个 / 内的内容视作正则表达式字面量自然没什么问题，不过 / 本身还是除号不是吗？比如说，x / ruby / 3 该怎样理解呢？

S 嗯，/ 的含义可以通过上下文来判断。

C 话虽如此，不过通过上下文判断并不容易，实现起来也较为复杂，因此 Stone 语言就不支持这种语法了。

例如，Stone 语言中 while 语句体必须由大括号 {} 包围。if 语句也是如此。条件表达式不一定非要用括号括起，但这两个语句体两侧必须使用括号。