问号提出：“逻辑式编程不是也很特别吗？前面似乎介绍得也不多。”

“那我们就用逻辑式语言Prolog再实现一次quicksort吧。”冒号说着将幻灯片翻页——

/*快速排序法的Prolog实现 */
/* 定义划分法 */
partition(_,[],[],[]).                             /* 划分递归终点 */
partition(Pivot,[X|Rest],[X|Small],Big) :- 
X < Pivot, partition(Pivot,Rest,Small,Big).        /* 比基准小的归入Small */
partition(Pivot,[X|Rest],Small,[X|Big]) :- 
X >= Pivot, partition(Pivot,Rest,Small,Big).       /* 比基准大的归入Big */

/* 定义排序法 */
qsort([],[]).                                      /* 排序递归终点 */
qsort([Pivot|Rest],Sorted) :- 
partition(Pivot,Rest,Small,Big),                   /* 按基准划分子列 */
      qsort(Small,SortedSmall),                    /* 对前面的子列递归 */
      qsort(Big,SortedBig),                        /* 对后面的子列递归 */
      append(SortedSmall,[Pivot|SortedBig],Sorted)./* 子列合并 */ 

逗号挠挠头：“看不太懂哦，好在我记住了您的一句话：容忍无知。我忍了！”

大伙都乐了。

“本节课的焦点不是语言而是范式，因此对Prolog代码不详加解说。我只简单地说三点：首先，Prolog代码是由一系列事实（fact）、规则（rule）和查询（query）语句组成的^[1]。其次，与大多数语言不同的是，大写字母或下划线开头的标识符是变量，其他的是常量或函数。请注意，这不是约定俗成，而是语法规定。最后，符号‘:-’等价于if；逗号‘,’等价于and。比如，我们可以用Prolog来表达一个断言：如果一个人未婚且为男士，那么他就是一光棍。”冒号转身在黑板上写下——

/* X is bachelor if X is unmarried and male*/
bachelor (X) :- unmarried(X) , male(X). 

听见下面一阵嘀咕声，冒号忽地闪过一个念头：这个例子该不会触动了满足条件的某位同学的心事吧？顿了一会，继续说道：“逻辑式实现的排序虽不比函数式更简洁，但比起过程式来还是绰绰有余的。毕竟同属声明式，省去了不少有关变量赋值、迭代和流程控制方面的代码。我们再看一个更加典型的范例。”

黑板上出现了一幅树状图形——

图4-1. 家谱

冒号简作说明：“这是一个三代家谱图。已知每人的性别和父辈，要求判断任意两人之间的关系。我们先用Java来试一试——”

class Person
{
    private Person parent;
    private boolean isMale;

    public Person(Person parent, boolean isMale)
    {
        this.isMale = isMale;
        this.parent = parent;
    }

    private boolean isSibling(Person other)
    {
        return parent == other.parent && parent != null && this != other;
    }

    public String getRelation(Person other)
    {
        if (other == null || this == other) return null;

        if (parent == other) return isMale ? "son" : "daughter";

        if (other.parent == this) return isMale ? "father" : "mother";

        if (parent == null) // this是老祖宗
        {
            if (other.parent == null) return null;

            if (other.parent.parent == this) return isMale ? "grandfather" : "grandmother";

            return null;
        }

        if (other.parent == null) // other是老祖宗
        {
            if (parent.parent == other) return isMale ? "grandson" : "granddaughter";

            return null;
        }

        // 非直系
        if (isSibling(other)) return isMale ? "brother" : "sister";

        if (parent.isSibling(other.parent)) return "cousin";

        if (parent.isSibling(other)) return isMale ? "nephew" : "niece";

        if (isSibling(other.parent)) return isMale ? "uncle" : "aunt";

        return null;
    }

    public static void main(String[] args)
    {
        Person a = new Person(null, true);
        Person b = new Person(a, true);
        Person c = new Person(a, true);
        Person d = new Person(a, false);
        Person e = new Person(b, false);
        Person f = new Person(b, true);
        Person g = new Person(c, false);
        Person h = new Person(d, true);
        Person i = new Person(d, false);
        Person j = new Person(d, true);
        // 以下省略。。。
     }
}

“这段代码很平凡，毋需多言。再来看看逻辑式语言的做法。”冒号不愿过多地纠缠于细节，随即又换成了Prolog代码——

/* 规则 */
/* 上下两代直系关系 */
father(X,Y)        :- parent(X,Y), male(X).
mother(X,Y)        :- parent(X,Y), female(X).
child(X,Y)         :- parent(Y,X).
son(X,Y)           :- parent(Y,X), male(X).
daughter(X,Y)      :- parent(Y,X), female(X).

/* 祖孙关系 */
grandparent(X,Y)   :- parent(X,Z), parent(Z,Y).
grandfather(X,Y)   :- grandparent(X,Y), male(X).
grandmother(X,Y)   :- grandparent(X,Y), female(X).
grandchild(X,Y)    :- grandparent(Y,X).
grandson(X,Y)      :- grandparent(Y,X), male(X).
granddaughter(X,Y) :- grandparent(Y,X), female(X).

/* 平辈关系 */
/* 若X与Y有相同的父辈Z，且X不是Y，则X与Y是同胞*/
sibling(X,Y)       :- parent(Z,X), parent(Z,Y), X\==Y. 
brother(X,Y)       :- sibling(X,Y), male(X).
sister(X,Y)        :- sibling(X,Y), female(X).
cousin(X,Y)        :- parent(Z,X), parent(W,Y), sibling(Z,W).

/* 上下两代旁系关系 */
uncle(X,Y)         :- parent(Z,Y), brother(X,Z).
aunt(X,Y)          :- parent(Z,Y), sister(X,Z).
nephew(X,Y)        :- parent(Z,X), sibling(Z,Y), male(X).
niece(X,Y)         :- parent(Z,X), sibling(Z,Y), female(X).

/* 定义一个普适关系relation，方便查询 */
relation(R, X, Y)       :-  relations(Rs), member(R,Rs), Q =..[R,X,Y], call(Q).

/* 事实 */
/* 关系列表 */
relations([parent,father,mother,son,daughter,grandparent,grandfather,
grandmother,grandchild,grandson,granddaughter,
                sibling,brother,sister,cousin,uncle,aunt,nephew,niece]).

parent(a,b). parent(a,c). parent(a,d).
parent(b,e). parent(b,f).
parent(c,g).
parent(d,h). parent(d,i). parent(d,j).

male(a).
male(b).
male(c).
female (d).
female (e).
male(f).
female (g).
male(h).
female (i).
male(j). 

叹号没有看出名堂：“Prolog代码并不比Java代码简短多少啊。”

“评价代码的复杂度，长短只是一个因素。程序员不是打字员，花在思考上的时间和精力远远超过花在键盘上。”冒号指出，“就拿此例来说，Java代码虽然并不复杂，但有不少的选择分支语句，次序很重要。稍有不慎，就会出现逻辑错误。另外如果我们把关系分得更细致些，比如区分叔伯舅、姑姨婶、堂兄表妹等；再加入姻亲关系，比如姑嫂婆媳、妯娌连襟等。这时你再来改写这段代码试试？”

引号听得头皮有些发麻：“那一定需要不少重重嵌套的if-else语句了。”

问号提出的问题更让人头痛：“如果我们不限于三代，再加上曾孙女、曾叔父之类的关系呢？”

逗号联想到一则笑话：“话说一对父子与一对母女联姻，作父亲的娶了那位女儿，作儿子的娶了那位母亲。本来关系已经够颠倒错乱了，雪上加霜的是这两对夫妇又各自有了子女，那位父亲终于精神崩溃了。”

大家哄笑着：这下彻底乱套啰。

“前面的Java代码之所以没有嵌套，得益于及时退出的一些return语句。如果考虑到超过三代的关系以及多重交叉的关系，许多语句都得改写。可见上述代码是多么地脆弱！” 冒号就棍打腿，“再看Prolog代码，如果要求更细的血亲关系、增加姻亲关系或三代以上的关系，只需引入新的规则和事实即可，不会影响原有代码。下面列出几个示范语句——”

/* 规则 */
/* 配偶原则 */
father(X,Y)          :- spouse(Z,X), mother(Z,Y).
mother(X,Y)        :- spouse(Z,X), father(Z,Y).
husband(X,Y)      :- spouse(X,Y), male(X).
wife(X,Y)            :- spouse(X,Y), female(X).

/* 父系的堂、姑兄弟姐妹 */
paternal_cousin(X,Y) :- father(Z,X), father(W,Y), sibling(Z,W).
/* 母系的舅、姨兄弟姐妹 */
maternal_cousin(X,Y) :- mother(Z,X), mother(W,Y), sibling(Z,W).

/* 姻亲关系 */
father_in_law(X,Y) :- spouse(Y,Z), father(X,Z).
mother_in_law(X,Y) :- spouse(Y,Z), mother(X,Z).
son_in_law(X,Y)    :- spouse(X,Z), daughter(Z,Y).
daughter_in_law(X,Y) :- spouse(X,Z), son(Z,Y).

/* 曾祖孙关系 */
great_grandparent(X,Y) :- grandparent(Z,Y), parent(X,Z).
great_grandchild(X,Y)  :- grandchild(Z,Y), child(X,Z).

/* 事实 */
/* 新引入的关系 */
relations([husband,wife, paternal_cousin,maternal_cousin,
father_in_law,mother_in_law,son_in_law,daughter_in_law,
great_grandparent,great_grandchild]).

parent(pa,a).
spouse(a,as).
spouse(ds,d).
spouse(cs,c). 

句号方悟其妙：“这样的代码既无层层嵌套，也无次序分别。比起过程式，编写轻松得多，程序的可维护性和可扩展性也更高。”

“此外另有妙处。逻辑式与过程式和函数式的一个不同之处是，它没有明显的输入、输出之分。上面的程序不仅可以用来判断任意二人之间的关系，还能倒过来通过关系来找人。”冒号板书了几行字——

引号义务作翻译：“这告诉我们两件事：a与ds是翁婿关系，pa有曾孙e、f、g、h、i和j。”

“逻辑式语言着眼于关系而非函数，对付这类问题正是它的拿手好戏。”冒号声音逐渐高亢，“大家应该都听说过等式‘算法+数据结构=程序’吧？这是Pascal设计者Niklaus Wirth的一本著作的书名，它刻画了过程式尤其是结构化编程的思想。后来Robert Kowalski进一步提出：算法=逻辑+控制。其中逻辑是算法的核心，控制主要用于改进算法的效率。在逻辑式编程中，程序员只需表达逻辑，而控制交给编程语言的解释器或编译器去管理。”

“所以程序员的负担大大减轻了。”问号接口道，“逻辑式编程听起来真是不错，但不知Prolog程序能否与Java程序对接呢？”

冒号回答：“任何程序之间的对接都是可能的，只是不同的对接方式在复杂度和效率上有所差异而已。除了通过程序之间的通讯（如socket）或可执行文件的直接调用外，Prolog与C、C++、Java、C#、VB、Perl、JavaScript等多种语言之间，还能借助工具进行源代码转换^[2]或通过双向编程接口互嵌代码。具体到Java，一方面可以通过JNI （Java Native Interface）与Prolog引擎相连^[3]，另一方面可以利用Prolog引擎的Java实现来完成JVM上的集成^[4]。”

句号请求：“能否总结一下逻辑式编程的优缺点？”

冒号欣然应允：“由于逻辑式编程模拟人类的逻辑思维，故而在机器证明、专家系统、自然语言处理、博弈等人工智能领域如鱼得水，同时在非学术领域的知识管理、智能决策分析等方面也能大显身手。同为声明式，它与函数式一样比命令式更简洁、更抽象、更少副作用，运用得当能大大提高生产效率，还能用于快速原型（rapid prototyping）开发。但缺点是运行效率偏低，可掌控性较差，与常规的过程式思维差异较大，更适合基于规则（rule-based）而不是基于状态（state-based）的应用^[5] 。此外，相对而言逻辑式语言还不够成熟和完善。”

逗号“抗议”道：“我怎么感觉经过这么一反刍，胃里的负担更重了？”

冒号略带歉意地笑了笑：“在所有编程范式中，函数式与逻辑式与传统思维方式的差别最大，此前的介绍又过于简单，因此今天特意多谈了些。既然有人提意见，那就我就适可而止了。最后请允许我画蛇添足：在代表计算机最高水平的人工智能领域中，这两种范式发挥着举足轻重的作用。单凭这一点，它们也是值得学习和借鉴的。好了，大家先休息十分钟，出去活动活动筋骨吧。”

冒号重新开讲：“你们会不会经常遇到这样的情景：一遍又一遍地写着相似的代码，有心将其归并，却因种种原因无法践行。”

逗号心有戚戚焉道：“是啊，有时明明两个函数的实现几乎是一模一样的，就因为某些参数不匹配，无法合而为一。”

“有一种编程范式可以解决这个问题，它打破了不同数据类型之间的壁垒，让你的代码不再臃肿，这——就是泛型编程。”冒号的语调和说辞不免令人联想到电视上的减肥广告，“Generic Programming，简称GP，其基本思想是：将算法与其作用的数据结构分离，并将后者尽可能泛化，最大限度地实现算法重用。这种泛化是基于模板（template）的参数多态（parametric polymorphism），相比OOP基于继承（inheritance）的子类型多态（subtyping polymorphism），不仅普适性更强，而且效率也更高。这不能不说是一种异数——我们知道，普适性往往是以效率为代价的。如果一定要找出代价的话，那就是其用法稍微复杂一些，可读性稍微差一些。GP最著名的代表是C++中的STL（Standard Template Library），其后亦为Java、C#、D等语言所吸纳^[1]。此外，一些函数式语言如Ocaml、Standard ML、Haskell等也支持GP。”

冒号写下两段代码——

    template <typename T>
    T max(T a, T b)       // 求出两个数中的较大者
    {
            return  (a > b) ? a : b;
    }

    #define max(a,b) ((a) > (b) ? (a) : (b))
    

“求两个数中的较大值是经常遇到的问题。”冒号解说着，“对于静态类型语言^[2]来说，若参数类型不同，即使函数体相同也不能合为一体。如果语言不支持重载（overload），还可能出现maxInt、maxLong、maxFloat、 maxDouble之类的函数名，冗赘而丑陋。尽管在C中可用宏定义（macro definition）来实现，但无法保证类型安全，而C++模板则兼顾类型安全和代码重用，并且由于是在编译期间展开的，效率上也不损失。不止于此，C++支持运算符重载，除数值类型外，一切定义了‘>’ 运算的数据类型均可调用max函数，真是一举N得，N趋向无穷大啊！”

冒号边说边比划，夸张的语气和手势逗得大家都笑了。

引号提出疑问：“Java的一切对象都是Object类型，只要将所有参数都换成Object类型，岂不也是一种泛化？”

冒号答道：“首先，基本类型如int、float等不是Object的子类，虽然Java 新增了自动装拆箱（autoboxing/unboxing）的功能，但要付出性能的代价。更重要的是，这将不可避免地需要类型的显式转换（explicit conversion或cast），无法在编译期间施行严格的类型检查，由此丧失了静态类型语言的优势，为bug大开方便之门。这也是Java最终引入泛型的原因，虽然有些姗姗来迟。类似地，C/C++中的通用指针void *也有类型安全问题。”

句号发表他的看法：“泛型虽好，似乎只是某些局部才用到的技术，不具有前面几种范式的渗透性。”

冒号听罢不语，返身在黑板上写下几道题——

句号暗忖，这有何难？不过是些常规题罢了。不料冒号的问题却出人意表：“请问它们之间有何共同之处？能否共享同一段代码？”

见众人缄默已久，冒号接着投影出一段代码——

template <class Iterator, class Act, class Test>
void process(Iterator begin, Iterator end, Act act, Test test)
// 对容器中在给定范围内（即起于begin止于end）所有满足给定条件的元
//素（即test（元素）==true）进行处理（即act（元素））
{
    for ( ; begin != end; ++begin)    // 从头至尾遍历容器内元素
        if (test(*begin)) act(*begin); // 若当前元素满足条件，则对其采取行动
}

“STL有三要素：算法（algorithm）、容器（container）和迭代器（iterator）。算法是一系列切实有效的步骤；容器是数据的集合，可理解为抽象的数组；迭代器是算法与容器之间的接口，可理解为抽象的指针或者游标。”冒号讲述道，“算法串联数据，如脊贯肉；数据实化算法，如肉附脊。只有抽象出表面的数据，算法的脊梁才能显现。以上几题看似风马牛不相及，若运用泛型思维，便可发现它们的共性：对指定集合中满足指定条件的元素进行指定处理。用模板语言，寥寥数行即勾勒完毕。”

问号诧异道：“相比前面的max模板，这儿连元素的数据类型T都不见了？”

冒号回答：“元素被容器封装了。”

问号追问：“可连容器也看不到啊？”

冒号料有此问：“容器通过它的迭代器参与算法。”

句号豁然开朗：“通过模板，泛化了容器——可以是数组、列表、集合、映射、队列、栈、字符串等等；泛化了元素——可以是任何数据类型；泛化了处理方法和限定条件——可以是任何函数。”

冒号提醒道：“补上两点：这里的处理方法和限定条件不限于函数，还可以是函子（functor）^[3]——自带状态的函数对象；另外迭代器也被泛化了——可以从前往后移动，可以从后往前移动，可以来回移动，可以随机移动，可以按任意预先定义的规律移动。”

叹号由衷感叹：“果然强悍无比啊！”

逗号倒也心细：“最后一题中标准输入也算容器吗？”

“为什么不呢？只要一个对象配备了迭代器，它就可以作为容器来对待。I/O流上就有现成的迭代器，当然你也可以自行定制。索性我们来看看这道题的解法吧。”冒号给出了第六题的实现代码——

#include <iostream>
#include “process.h” // 前述process所在的头文件

using namespace std;

// 判断字符是否为非数字字符
bool notDigit(char c)
{
    return (c < '0') || (c > '9');
}

// 打印非数字字符
void printNondigit(char c)
{
    cout << c << "不是数字字符" << endl;
}

int main()
{
    process(istream_iterator<char>(cin), istream_iterator<char>(),
            printNondigit, notDigit);

    return 0;
}

逗号打量了半天：“这里完全看不到I/O读取的过程，也看不到通常的迭代循环，简洁得难以置信。”

冒号补充道：“不光是代码简洁，它还让人摆脱了底层编码的细节，在更高更抽象的层次上进行编程设计。”

引号发觉：“开始谈起泛型编程时，您特别强调它对数据类型的抽象。现在看起来，它也能对函数进行抽象呢。”

“说得没错，条件是被抽象的函数或者方法具有相同的签名（signature）或接口（interface）。不过别忘了，在C和C++中的函数——准确地说是函数指针——也能作为数据类型。但不管怎样，这都表明泛型编程不仅能泛化概念，还能泛化行为。”冒号目光转向句号，“现在还有人认为泛型编程的渗透性不够强吗？”

句号腆然一笑。

“这些只是泛型编程的冰山一角。重要的是，我们不是在玩弄花哨的技巧，而是在用一种新的视角去审视问题。”冒号总结道，“泛型编程是算法导向的（Algorithm-Oriented），即以算法为起点和中心点，逐渐将其所涉及的概念（如数据结构、类）内涵模糊化、外延扩大化，将其所涉及的运算（函数、方法、接口）抽象化、一般化，从而扩展算法的适用范围。这非常类似数学思维——当数学家证明完一个定理后，总会试图在保持核心思想的前提下，尽可能地放宽题设，增强结论，从而推广定理。外行人常以为数学定理最重要，其实数学思想才是数学的精髓。比如举世皆知的哥德巴赫猜想和费尔马大定理，人们在攻克它们的过程中产生的新思想、新理论、新方法，已远远超过了定理本身的意义。数学家们甚至不愿这些猜想被过早地解决，怕扼杀了会下金蛋的鸡。在他们眼里，思想是鸡，结论是蛋。这也无怪乎STL会出自一位学数学的人之手了^[4]。”

“我怎么觉得更像是出自一位菜场大妈之口呢？” 逗号打趣道，“不信你们听嘛，算法好比脊骨、数据好比猪肉、思想好比母鸡、结论好比鸡蛋。我没说错吧？”。

众人哑然失笑。