TeX与Lisp：一些知识片段（2022/07/30）

从数据结构谈起

作为一个非计算机专业毕业的学生，读计算机相关的书，曾经是吃了不少苦的。数据结构就是一个比较典型的例子。数据结构就是一定程度上对于元素关系的考察。自我接触TeX以来，从一个用户变成开发者，所接触的数据结构，其实也就是：数组，散列表（关联数组），树。图就基本没碰过，至今我也没接触过典型的需要我使用树的情况。

数据结构的书，读起来虽然还是有一点难度，但是总比数学书好读。一些数学书的作用，完全就是一把钥匙，它很少告诉你为什么这把钥匙要打开的门是什么样的。数据结构的书，由于描述语言的不同，虽然也会带来一些细节上的差异，但是大的图景上，还是一样的。

TeX中的数据结构

TeX中的数据结构，构造页面的，就是list。这个list确实和Lisp中的cons是一样的（cons之后会讲）。

TeX中的这个list的控制和处理，只有在引入新的排版元素的时候才需要做一些改动。把OpenType引入到TeX中，加入了细粒度更细的glyph node或者native word node（相当于一组glyph），基本上只需要写几十行代码控制内存分配和释放，大部分内容会被测量后直接丢给DVI。

TeX中保存宏命令的是散列表，做断词算法的是trie树。由于本文围绕list展开，所以不多作介绍了。

TeX和Lisp

读过TeX源码的，应该会注意到TeX中的list处理和Lisp有一定相似之处。但其实，这更多的应该是巧合。巧合在于：list是一种常见的结构。Lisp本身就是以List处理为核心特点的语言。

不过，由于TeX和Lisp在一些人看起来，都有一些别扭之处。这种古怪的东西，放在一起，似乎有点分类学上的趣味。

Lisp的宏和TeX的有一点像，不过麻烦程度上，还是TeX的宏比较麻烦：有先展开后展开的问题。

Lisp on TeX

在TUG 2013的时候，HAKUTA Shizuya发表了Lisp on TeX。这东西就更古怪了。但是，古怪归古怪，这东西是能用的。

虽然，真没有多少人会用这个东西来搞运算。说它是炫技？倒也不必，这种东西就是个showcase。就好比一个人能吃五碗饭，但是平时只吃两碗一样，它更证明了TeX的完备性。

未完成的m17n-flt接入

我自己的TeX，曾经有一个想法，就是把m17n的flt子组件接进来。但是这个尝试，当时是失败了。这个东西的作用，和今天的harfbuzz一样。

m17n-flt的核心系统，是一个用S表达式写成的一组控制代码。这些S表达式基本上是要处理unicode中一些特定书写系统的模型，比如bidi，indic。那些代码，熟悉基本的Lisp控制结构就能看了。

之所以失败，两个原因：m17n-flt不是单独的库，在分发和部署上会有很大问题；m17n-flt中特定语言的s表达式文件有错误，似乎是没经过测试的。

平心而论，m17n-flt的代码虽然难读一点，但是还是比harfbuzz要好读一点。harfbuzz的代码为什么变成了今天的那个鬼样子，我不太好说。坊间传闻，是用了邪术保证开发者对项目的掌控权。

所以我那个TeX，至今就是没接入太多的OpenType处理的功能。现有的功能是由m17n的子项目libotf实现的。今年还是冲一冲业绩，把这个libotf换成我自己写的mlayout吧。这里还需要说一下为什么没接入harfbuzz。我是发现harfbuzz跨版本，有一些不一致。这会影响到输出的文档，用不同版本跑出来的东西不一致。还有就是harfbuzz的控制细粒度的问题，它们内部优化，导致不能使用16个以上的feature调用（记忆上如此）。

题外。m17n的作者之一Kenichi Handa（半田剣一），应该日本的排版国标JIS X 4051（《日本語文書の行組版方法》）的审定者或定制者之一。家里书都收起来了，要不然还能查证一番。

Wadalab，和田研的尝试

如果谁还在使用CJK包处理汉字，那大概还可能会碰到wadalab的包。不过，从我的直觉出发，似乎日本人也不用这个了。

TeX Live或者CTAN收入这个包，一定意义上只是为了保存人类一定时期的智力遗产。

wadalab这个字体，只是一个计算出来的结果。它是一套使用Lisp构建出来的造字系统（使用的是UtiLisp）。和glyphwiki的kage系统的JavaScript版本的设计方式不太相同。不过，两者输出的东西都有独特的古怪之处。

wadalab在一定意义上是失败的。错不在lisp。错在两点：一是缺乏描述汉字stroke的参数化工具（现在也缺，只不过字体厂商用一定的人力解决了），二十缺乏有力的GUI调试工具（这个工具不只是作为查看工具，还有修改工具）。