用C语言写解释器（五）

用C语言写解释器（五）——其他一些东西

redraiment, 2009-11-05

写完解释器之后

　　这一篇文章我只想和大家侃侃编程语言的事情，不会被放到书中。因此可以天南地北地扯淡，不用像前几篇一样畏首畏尾的了。

　　经过前面几篇文章的讨论，已经把用纯 C 语言来实现一个解释器的方法介绍完了。但那些是写给我校 C 语言初学者看的，并不只是你，我得也觉得很不过瘾 ^_^。因此准备继续深入学习编译原理等课程，希望有志同道合的朋友和我一起交流！

富饶的语言（工具）

　　在前几篇文章中一直在鼓吹我拍脑袋想出的语言四大要素：“内存管理”、“表达式求值”、“输入/输出”、“按条件跳转”，在这篇文章中您就姑且信一回当它是真的。按照这四条准则去匹配，汇编语言是完全符合的。那为什么又需要 C 语言、Java、C# 等高级语言？这是因为编程除了需要“语言”之外还需要“抽象”！

　　“抽象”是个很有效的工具，相信你在为别人介绍自己房间时不会具体到每个木纤维、油漆分子和铁原子。同样的，我们也不乐意总是写一堆 JNZ、JMP 指令，而仅仅是为了实现 if、for、while 等控制结构。C 语言等高级语言提供的抽象的层次更高、表现力更强，允许用更少的语句描述更多的操作。感谢如此富饶的语言为我们带来不同的视角去审视这个世界。

　　高级语言相较于低级语言属于更高地抽象层次，高级语言之间的差别主要体现在适用范围上。比如一些语言适合写 WEB 程序，另一些适合做数值分析等。术业有专攻，你只需根据自己的问题来选择一门合适的语言。

什么时候需要创造新的语言

　　当我们碰到一类新的问题时，首先考虑的就是定义新的数据结构，并设计多个函数去操作它，最后将它们独立出来打包成一个类库方便在其他地方调用（比如处理图形图像的 OpenGL 库）。上面已经提过，每种语言都有它适合的领域，强行将一门语言用在它不擅长的领域中就出现冗长、繁琐的代码。自然语言也是如此：英语中有种语法叫虚拟语气，描述的是一种假设，并非事实。比如“If I have time, I will go to see you. ”。如果按原意一字不差地翻译相信会很繁琐，我知道台湾作家痞子蔡在使用中文式的虚拟语气很有一套：

如果我还能活一天，

我就要做你的爱侣。

我能活一天吗？可惜。

所以我不是你的爱侣。  ——《第一次亲密接触》

　　上面是一段完整表现虚拟语气精髓的话，相信在生活中我们不会这么罗嗦。同样的，如果你发现用现有语言来描述某个特定领域问题时显得力不从心，就可以考虑为这个领域定制一种特定的语言了（Domain Specific Language）！使用现成的词法分析器和语法分析器（比如 lex 和 yacc）对提高开发效率很有帮助，但你也可以考虑采用像 REBOL 这样的语言设计一个“方言”，这会更简单。如果你对 DSL 或 REBOL 有兴趣，可以加入阿里旺旺 REBOL 群（16626148）和蔡学镛前辈交流，他是这方面的专家。

从语言（工具）中挣脱

　　从写解释器这件事中可以获得一些建议：不要再争论哪个语言更优秀，只有最适合的；用高级语言写代码首先力求可读性好。第一条建议我在以前讨论“工具理论”时提过很多次，就不再重复，主要交流一下可读性的问题。

　　经过了上面冗长的解释和亲自实现解释器以后，大家应该能了解到：一门新语言诞生的动机多数情况下不是为了提高执行效率，而是为了提高开发效率。很多人都沉浸在“++i”比“i++”高效、“10>>1”比“10/2”快等奇技淫巧中，但在你自己实现过解释器后希望能明白，如果真有哪个解释器执行语句“i++;”的效率比“++i;”低，那只能说明这个解释器写得烂！像现代的 C 语言编译器都会有优化的选项，编译时去识别一些常见的热点进行优化，难保那些自以为是的优化反而将代码破坏得连编译器也无法识别。所以要迁就解释器而将代码改得乱七八糟，我宁可换一个更好的解释器！

　　真的想深入研究算法，就势必会和硬件相关。你需要精确地知道代码一共执行了多少个时钟周期，而不是简单地根据嵌套了几层 FOR 循环来判断复杂度是 O(n) 还是 O(n²)。除非你深入了解你的解释器，否则无从知晓执行一条 FOR 语句时解释器会不会背着你扫描了整个内存空间。无怪乎经典巨著《计算机程序设计艺术》三卷本中要使用汇编语言来编写代码。

总结

　　废话了这么多，我只是想表达“我们是主人”，不要被一个蹩脚的工具牵着鼻子走。当你发现打字员平均打字速度忙时，总不会为了迁就她而只说一些她打得快的字吧？以上内容属于个人观点，切莫认真。欢迎大家通过邮件和我交流你们的想法，我的邮箱地址：redraiment@gmail.com。