(二)

最后更新于:2022-04-01 06:26:16

## 宏 自定义一个 m4 宏所用的基本格式如下: ~~~ define(宏名, 宏体) ~~~ 上一节,我们定义的一个很简单的 `say_hello_world` 宏: ~~~ define(say_hello_world, Hello World!) ~~~ `say_hello_world` 是宏名,`Hello World` 是宏体。如果在宏定义之后的文本中出现了 `say_hello_world`,例如: ~~~ define(say_hello_world, Hello World!) blab blab ... say_hello_world ~~~ 假设上述文本均处于非负号缓存,那么当 m4 从输入流中读取到 `say_hello_world` 时,它能够检测出该文本片段是一个被定义了的宏,于是它就将这个宏展开为 `Hello World`,并使用这个展开结果替换文本片段 `say_hello_world`,所以,上述文本经过 m4 处理后发送到输出流,就变成: ~~~ blab blab ... Hello World! ~~~ 上述输出结果中的空行,应该没什么玄机可言了,只是需要注意:宏定义语句本身也会被 m4 展开,因为 `define` 本身就是一个宏,只不过它的展开结果是一个空的字符串。 ## 有参数的宏 宏可以有参数。遵循 POSIX 标准的 m4,允许一个宏最多有 9 个参数(似乎 Shell 脚本里的函数也最多支持 9 个参数),在宏体中可使用用 `$1, ..., $9` 来引用它们。GNU 的 m4 不限制宏的参数数量。 对于下面这段 C 语言的宏定义与调用: ~~~ #define DEF_PAIR_OF(dtype) \ typedef struct pair_of_##dtype { \ dtype first; \ dtype second; \ } pair_of_##dtype##_t DEF_PAIR_OF(int); DEF_PAIR_OF(double); DEF_PAIR_OF(MyStruct); ~~~ 用 m4 的有参数的宏可给出等价表示: ~~~ divert(-1) define(DEF_PAIR_OF, `typedef struct pair_of_$1 { $1 first; $1 second; } pair_of_$1') divert(0)dnl DEF_PAIR_OF(int); DEF_PAIR_OF(double); DEF_PAIR_OF(MyStruct); ~~~ 它们能够展开为同样的 C 代码(C 语言宏由 C 预处理器展开,m4 宏由 m4 展开): ~~~ typedef struct pair_of_int { int first; int second; } pair_of_int; typedef struct pair_of_double { double first; double second; } pair_of_double; typedef struct pair_of_MyStruct { MyStruct first; MyStruct second; } pair_of_MyStruct; ~~~ 注意,C 宏与 m4 宏的调用有点区别。在 C 中,调用一个宏,宏名与其后的 `(` 可以有空格,而 m4 宏的调用不允许这样。 m4 版本的 `DEF_PAIR_OF` 宏的宏体为: ~~~ `typedef struct pair_of_$1 { $1 first; $1 second; } pair_of_$1' ~~~ 这个宏体是一个带引号的字符串,形如: ~~~ `... ... ...' ~~~ 注意左引号与右引号对应的符号。在大部分键盘上,左引号与 `~` 符号同键,右引号与 `"` 同键,它们是单引号。不要对引号掉以倾心,它在 m4 中的重要地位仅位列宏之下,如果没有它,宏的世界会异常的混乱。后面,我会在单独给引号的基本用法留出一节专门阐述。在此只需将引号理解为一段文本的封装。 事实上,对于 m4 版本的 `DEF_PAIR_OF` 宏体,不用引号也不会出问题(可以去掉引号试一下)。但是,在复杂一些的宏体内,可能会出现 `,` 符号,如果这样的宏体不用引号囊括起来,那么 `,` 会被 m4 误认为宏参数的分隔符。所以,一定要记住:`,` 会被 m4 捕获为宏参数分隔符,而引号可使之逃逸。 ## 小实践:reStructuredText 插图标记的简化 reStructuredText 是一种轻量级的文本标记语言,与 Markdown 属于同类,一般用于记笔记,然后以网页的形式发布。之所以要用轻量级文本标记,是因为直接手写 HTML 太繁琐了。我在我的机器上搭建的 Nikola 静态网站,默认用的就是 reStructuredText,我用它来整理我的一些笔记。 在使用 reSturcturedText 写文档时,我觉得它的插图标记过于繁琐。我常用的插图标记如下: ~~~ .. figure:: 图片文件路径 :align: center :width: 宽度值 ~~~ 上述标记文本块前后必须要留出空行,否则 reStructuredText 的解析器就会抱怨。`align` 与 `width` 前面的缩进也是必须的,否则 reStructuredText 的解析器就会抱怨…… 为了简化这个标记,我用 m4 定义了一个宏: ~~~ divert(-1) define(place_figure, ` .. figure:: $1 :align: center :width: $2 ') divert(0)dnl ~~~ 然后我就可以愉快的像下面这样在 reStructuredText 文本中插入一幅图片了。 ~~~ place_figure(`/images/amenta-needles/0001.png', 480) ~~~ 用这种办法可以简化许多繁琐的文本标记,甚至可以实现 reStructuredText 不具备的功能,例如参考文献的管理。如果你不打算研究如何改造 reStructuredText 解析器来满足自己的需求,在这种前提下,用 m4 简单的 hack 一下,使得 reStructuredText 的易用性显著增强,这就是宏语言最大的用途。 不妨将宏语言视为生活中的方便袋。 ## 宏的陷阱 m4 允许宏的重定义,结果是新的宏定义会覆盖旧的。例如: ~~~ define(LEFT, [)dnl LEFT define(LEFT, {)dnl LEFT ~~~ 如果你按照我说『新的宏定义会覆盖旧的』来判断,可能会认为上述文本流经 m4 会变为: ~~~ [ { ~~~ 然而,事实上 m4 的处理结果是: ~~~ [ [ ~~~ 与理解这个诡异的结果是如何产生的,就需要认真的回顾一下 m4 的工作过程。 我将 m4 处理第一个 `LEFT` 宏定义的过程大致拆解为: 1. 在输入流中,m4 遇到了 `define`,在它的记忆里,`define` 是一个宏; 2. 接下来它遇到了一个 `(`,它会认为这是 `define` 宏参数列表的左定界符; 3. 接下来,它遇到了 `LEFT,`,它会认为 `,` 之前的文本是 `define` 的第一个参数; 4. 接下来,它遇到了 `[)`,他会认为 `[` 是 `define` 的第二个参数,而 `)` 是 `define` 参数列表的右定界符; 5. 它现在终于明白了,`define(LEFT, [)` 是在调用 `define` 宏; 6. m4 对 `define(LEFT, [)` 进行展开,具体的展开过程,我们不得而知,因为 `define` 是 m4 内建的宏。我们只知道在`define(LEFT, [)` 的展开过程中,m4 会为我们定义 `LEFT` 宏,并且 `define(LEFT, [)` 宏展开完成后,m4 会向输出流发送一个空字串。 当 m4 遇到第二个 `LEFT` 宏定义时,它的过程大致如下: 1. 在输入流中,m4 遇到了 `define`,在它的记忆里,`define` 是一个宏; 2. 接下来它遇到了一个 `(`,它会认为这是 `define` 宏参数列表的左定界符; 3. 接下来,它遇到了 `LEFT,`,它会认为 `,` 之前的文本——`LEFT`是 `define` 的第一个参数。但是 m4 随即发现 `LEFT` 是一个宏,于是它就将这个宏展开,结果为 `[`,它认为 `[` 才是真正的 `define` 的第一个参数; 4. 接下来,它遇到了 `[)`,他会认为 `[` 是 `define` 的第二个参数,而 `)` 是 `define` 参数列表的右定界符; 5. 它现在终于明白了,`define([, [)` 是在调用 `define` 宏; 6. m4 对 `define([, [)` 进行展开,具体的展开过程,我们不得而知,因为 `define` 是 m4 内建的宏。我们只知道在`define([, [)` 的展开过程中,m4 会为我们定义 `[` 宏,并且 `define([, [)` 宏展开完成后,m4 会向输出流发送一个空字串。 m4 处理输入流的过程,非常像人类,急功近利,目光短浅,一叶障目,不见泰山,管中窥豹,略见一斑……现在明白了吧!第二个 `LEFT` 宏定义,表面上看起来是重定义了 `LEFT` 宏,实际上定义的是 `[` 宏。 由于 m4 允许用任何符号作为宏名,所以定义一个 `[` 宏,这种行为是合法的,只不过 m4 不会真正的将它视为宏。我一直没有提 m4 的宏命名规则,现在是谈谈它的最好的时机,但是没什么好说的,在 m4 眼里,只有像 C 函数名的宏名才是真正的宏,也就是说,m4 的宏名名规则是:只允许使用字母、数字以及下划线构造宏名,并且宏名只能以字母或下划线开头。只有符合宏名规则的宏,m4 才会将它视为真正的宏。不过,不符合宏名规则的宏,也是有办法调用的,以后再讲。 如果想真正的实现宏定义,需要借助引号,例如: ~~~ define(`LEFT', [)dnl LEFT define(`LEFT', {)dnl LEFT ~~~ 在 m4 语法中,单重引号具有逃逸的作用:当 m4 读到带单重引号的文本片段 S 时,它会将 S 的引号消除,然后继续处理 S 之后的文本。 现在可以这样来理解引号的作用: * m4 将一切没有引号的文本都视为宏。对于已定义的宏,m4 会将其展开;对于未定义的宏,m4 会按其字面将其输出。 * 加了引号的文本,m4 不再检测它们是不是宏,而是将其作为普通文本按字面输出。 也就是说,加了引号的文本,可以让 m4 不需要判断它是不是宏。 ## 记号 现在,我们继续探究 m4 究竟对于输入流都做了些什么。这件事,已经讨论了 3 次了,虽然每一次都比前一次更深入一些,但是迄今为止,真相依然未能堪破。现在应该到堪破真相的时候了。 m4 对输入流是以记号(Token)为单元进行读取的。一般情况下,m4 会将读取的每个记号直接发送到输出流,但是当 m4 发现某个单词是已定义的宏名时,它会将这个宏展开。在对宏进行展开的过程中,m4 可能会需要读入更多的文本以获取宏的参数。宏展开的结果会被插入到输入流剩余部分的前端,也就是说,宏展开后所得到的文本会被 m4 重新读取,解析为记号,继续处理。 上面这段文字尤为重要。当 m4 不能如你预期的那样展开你定义的宏,都应该重新理解上面这段文字。 什么样的文本对于 m4 而言是一个记号?带引号的字符串、宏名、宏参数列表、空白字符(包括换行符)、数字以及其他符号(包括标点符号),像这些类别的文本,对于 m4 而言都是记号。对于每种记号,m4 都有相应的处理机制。数字与标点符号(西文的),它们本身是记号,同时也是某些记号的边界,除非它们出现于带引号的字符串或者宏的参数列表中。 来看一个例子: ~~~ define(`definenum', `define(`num', `99')') num ~~~ 若这行文本流经 m4,那么 m4 读到的第一个记号是 `define`。因为 `define` 后面尾随的是 `(`。由于 `(` 即是记号,也是某些记号的边界。m4 读取 `define` 文本之后,就遇到了边界,因此 `define` 是 m4 遇到的一个记号。 然后,m4 开始对 `define` 这个记号进行处理,它发现这个记号是一个带参数的宏。所以它暂停对 `define` 的处理,继续读取并分析 `define` 之后的文本,看是否能获得 `define` 宏的参数列表。 接下来, m4 读取的是 `(`,这是个记号,而且是宏参数列表的左定界符。这对 m4 而言,已经开始经进入了一段可能是参数列表的文本。它期望接下来能遇到一个 `,` 或者 `)`,以得到完整的参数列表记号。 但是接下来,m4 读到的是一个左引号。这时,对 m4 而言,已经开始进入了一个可能是带引号的字符串文本,它期望接下来能遇到一些文本或右引号,以得到一个完整的字符串记号。 但是接下来,m4 读到是文本片段 `definenum`,再读下去,就读到了右引号。这时, m4 很高兴,它确定自己已经读取了一个带引号的字符串记号,然后它就将包围这个字符串的引号消除,继续读取后面的文本。m4 之所以不在这时将 `definenum`发送到输出端,因为它没有忘记自己还有一个使命:为 `define` 宏搜寻完整的参数列表。 接下来,m4 读到了 `,`——这是宏参数记号的边界。m4 很高兴,它终于得到了 `define` 宏的第一个参数,即`definenum`。此时,m4 认为刚才读到的 `,` 就没什么用了,于是就将 `,` 消除了,然后它认为后面也许还会有第二个参数,决定继续前进。 接下来,m4 遇到了一个空格。在宏参数列表中,在 `,` 之后的空格是无意义的字符,m4 将这个空格扔掉,继续前进。然后它遇到了左引号……于是就像刚才处理 `definenum` 一样,m4 可以得到一个带引号的字符串: ~~~ `define(`num', `99')` ~~~ m4 将这个字符串的引号消除,然后继续前进,结果碰到了 `)`。此时,m4 吁了口气,它终于为 `define` 宏获得了一个完整的参数列表,尽管这个参数列表只含有两个参数。 接下来,m4 对 `define` 宏进行展开。这个过程,我们无法得知,因为 `define` 是 m4 内建的宏,但是我们知道在 `define`的展开过程中肯定发生了一系列计算,然后 `definenum` 变成了一个宏,最终 ~~~ define(`definenum', `define(`num', `99')') ~~~ 的展开结果是一个空的字符串。由于宏展开的结果会被插入到输入流剩余部分的前端,也就是说,宏展开后所得到的文本会被 m4 重新读取,解析为记号,继续处理,因此 m4 会将 ~~~ define(`definenum', `define(`num', `99')') ~~~ 的展开结果视为它下一步继续要读取并处理的文本。当 m4 继续前进时,它就会读到到一个空的字符串。空的字符串,虽然不具备被 m4 发送到输出流的资格,但是它可以作为其他记号的边界记号使用。 接下来,m4 遇到了一个空格字符。空格字符也是个记号,而且是其他记号的边界。m4 将空格记号直接发送到输出流,继续前进。 接下来,m4 一口气读到了输入流的末尾,得到了 `num` 记号。之所以说 `num` 是一个记号,是因为 `num` 的左侧与右侧都有边界,左侧是空格,右侧是输入流终止符。m4 将 `num` 这个记号视为宏,然后它确定这个宏没有被定义,因此无法对其进行展开,所以只好将它作为字符串发送到输出流。 ## 挑战 对于以下 m4 文本 ~~~ define(`definenum', define(`num', `99')) definenum num ~~~ 推测一下 m4 的处理结果,然后执行 m4 命令检验所做的推测是否正确,然后再回顾一次 m4 的工作过程,最后用: ~~~ $ m4 -dV your-m4-file ~~~ 查看一下输出,根据输出信息再回顾一次 m4 的工作过程。
';