转载

为自己写本 Guile 书

为什么写这本书？

物理学家 John Archibald Wheeler 曾言：『要想了解一个新的领域，就写一本关于那个领域的书』。

直到我开始写这本可能会半途夭折的书时，Scheme 对我而言依然是一个新『领域』。虽然此前断断续续的看过一些讲述 Scheme 语言的书，例如《The Little Scheme》，《Teach Yourself Scheme in Fixnum Days》以及《计算机程序的构造与解释》（即 SICP，Structure and Interpretation of Computer Programs），但是我却一直都没有掌握它，或者说我一直都没学会如何用它来写现实中的程序。

我反省了一下。耗费了许多时间去了解某种事物，结果却未能达到目的，这只能证明我不是真的需要了解它，因此我对它所作的任何观察与分析都是无意义的。要让对事物的观察与分析变的有意义，必须建构与该事物相关的一些问题。从而将了解该事物的过程转化为解决这些问题的过程。

所以，我开始写这本书。

为什么是 Guile？

Guile 是 Scheme 语言的一种实现，也可以称为一种 Scheme『方言』。虽然 Scheme 是有标准的，但是各家的实现都夹带了一些私货。Scheme 语言本身是 Lisp 语言的一种方言。

Guile 的解释器的执行效率在众多 Scheme 语言的解释器中可能属于末流。不过，我还是选择了它作为本书的主角。因为我喜欢它的设计定位——嵌入应用程序，使应用程序具备脚本扩展能力。

有些语言与 Guile 的设计定位相似，但是它们缺乏 Scheme 语言里那些简洁、优美的特性。例如，大部分编程语言都不会支持像 empty? ， string=? ， i-am-super-man 这样的变量或函数命名，但是 Scheme 支持——它甚至允许使用中文对变量或函数进行命名。大部分编程语言的宏语法的表现力远逊于 Scheme，有的语言干脆不支持宏。对于基于一种通用的编程语言定义一种领域专用语言而言，宏是非常有用的功能。虽然像 Scheme 这样的语言，可能不太适合构建大型程序，但是 Guile 本来也没有将自己定位为可独立担当构建大型程序之重任的编程语言。

Guile 解释器的执行效率虽然不是很理想，但是这些年也不断在进步着——2.0 版本比 1.8 版本提升约 30%，而 2.2 版本又比 2.0 版本提升约 17%。

就这样，我说服了自己，选择了 Guile。

这本书的主题是什么？

之前我曾用 C 语言写了一个文式编程工具，后来又觉得我『设计』的文式编程语法有些问题。现在，我打算将原来的所有设计推倒重来，并且将编程语言由 C 换为 Guile。因此，对于 Guile 的学习，我不仅要解决为它写一本书的问题，还要解决如何用它构建一个可用的文式编程工具的问题。

我比较喜欢文式编程这种来自史前的编程方式。所谓文式编程，是将程序文档与程序源码统一于某种元文档——可从中提取所需的程序代码以进行程序的构建，也可以将其转化为排版语言以获得排版规范的程序文档。文式编程，本质上只一种注解程序的方式——用写篇文章或写本书的方式来注解一个程序，或者在承认非形式化的人类语言与形式化的编程语言存在对立性的前提下，尝试对二者进行统一。

伟大的计算机科学家 Edsger Wybe Dijkstra 曾说过，『对本土语言的异常的精通会是一个计算机程序员的最宝贵的财富』。从这一点来看，文式编程应该是一种很有意义的编程方式。

与 C 语言相比，使用 Guile 来实现这个新的文式编程工具，最大的好处在于 Guile 直接支持 UTF-8 文本的处理。之前用 C 语言实现的那个文式编程工具，在文本处理方面，我不得不依赖 GLib 库提供的一些函数。

面向的读者

这本书的第一个读者肯定是我。但是，这个世界上可能会有一些人的志趣与我相同，那么这本书也是为他们而写。

在众多编程语言中，我对 C 最为熟悉。这本书在讲述 Guile 的一些知识时，为了便于理解，有时我会用 C 代码来诠释 Guile 代码。这意味着，如果你决定阅读这本书，对 C 语言有一些了解可能会更好一些。但是这不是必须的，一方面你也可以为自己写一本不含 C 语言的 Guile 书，另一方面有很多 Scheme 教材可以帮助你理解这本书中的所有 Guile 代码——我在写这本书的过程中也需要从它们那里学会 Guile。

原文 https://segmentfault.com/a/1190000005162858

正文到此结束