这几年我一直从事C语言项目的开发。这些项目的规模都不算小，少则十几万代码，多则几十万行代码，至少也都算得上是中型项目吧。项目构建工具使用的是传统的Make工具，构建脚本都是自行编写的，构建时直接在顶层目录下敲入make即可。

这种传统的构建方式其实是很耗时费力的。比如执行make之前你需要根据项目代码的实际路径重新设定一些环境变量或修改Makefile中的某些标识路径的变量；你还要将项目依赖的各种内部公共库、第三方开源库悉数找到，并安装在指定目录下，修改Makefile中这些第三方库的路径配置。只有做完这些后，你才能顺利地执行Make。以后每当你更换一个环境，你就要将上面的步骤重复执行一遍。有的项目第三方依赖较多，要完整地搭建一个项目构建环境所耗费的时间也是很惊人的，特别是对一些不熟悉项目构建的新人更是如此。另外随着产品被要求具备在多个平台上运行的能力，你的构建脚本还要支持在多个平台上的构建，你要为项目所依赖的第三方库准备多个平台的版本；当某个依赖库版本进行了升级，你还要手工在多个环境下进行更新。

为了使项目构建更加容易，我们曾经对Makefile脚本进行了改进，比如自动判断和设定当前顶层路径、自动判定当前项目代码所在的平台，并根据不同平台设定不同的变量值；甚至将项目依赖的第三方库放入subversion服务器，构建项目时通过Shell脚本自动checkout对应平台的依赖库并链接。这些改进都是有效的，但在修改了多个项目后，我们发现了坏味道，那就是在不同项目的Makefile中充斥着大量重复性的脚本代码，这让后续构建脚本的维护十分困难，在一个项目中修正了构建脚本的bug后，很容易遗忘另外几个项目中存在着同样bug。此外每次构建都重新下载项目依赖的第三方库会导致构建变的十分缓慢。

我们在构建中遇到的问题大致就是这么多了。估计很多人会问：你们为何不用autotools生成的configure来生成项目构建脚本？为何不用scons等更加高级的构建工具呢？我的回答是即使使用了这些工具依旧无法解决现有的所有问题。比如利用configure->make可以屏蔽掉一些平台移植的问题，但依旧无法解决第三方库依赖的问题。scons我也试用过，但了解不甚深入，我的印象中它的主要功用是简化构建脚本的编写，让大家从Makefile那纷繁复杂的源文件依赖关系中解脱出来，至于在区别平台以及解决第三方库依赖方面估计也无能为力；另外还有一个原因那就是让大家从已经十分熟悉的构建模式中转到scons的成本也是不小的。

我们的问题其实并非构建脚本的编写问题，而是构建环境的管理问题。autotools和scons所解决的问题属于前者，即构建脚本的编写问题。而解决C语言项目构建环境管理的工具我了解的不多，在互联网上也没有google到。在这方面Java项目倒是有一个很好的工具 – Maven。利用Maven可以做很多事情，我对其了解不多，这里也不多说，但这里提到Maven是因为它的一个Feature启发了我，这个Feature就是对第三方依赖包的管理。虽说C项目依赖的第三方开源包也越来越多，但与Java项目相比那还是小屋见大屋。实际情况是一个Java项目如果不依赖十几个或几十个第三方开源包都不好意思拿出去说。这样一来如果手工找齐这数目庞大的开源包会让Java程序员头痛不已。Maven的这个Feature恰好帮助Java程序员解决了这个难题。Maven可以根据配置自动从互联网上下载指定版本的依赖包，后续Java项目的构建可直接使用已经下载到本地的包；Maven似乎还会定期自动更新第三方包的版本。

受到Maven这个特性的启发，我于是就开发了这款C语言项目构建管理辅助工具 – buildc(项目主页http://code.google.com/p/buildc)。buildc工具本身是用Python语言实现的，这主要是考虑到Python较高的开发效率以及自带功能强大的标准库。这也是我第一次用Python写程序，个人认为buildc的代码十分混乱，内部实现耦合较高，扩展性差，也谈不上什么风格，都是命令式语言的思维，代码本身并没什么价值，以后有时间定会重构^_^。

buildc目前主要实现了两个功能：
1、第三方依赖库的远程获取和本地管理
2、根据目标主机环境、目标主机本地缓存的第三方库情况以及项目本身所依赖的第三方库的最新配置，自动生成一份包含了依赖库环境变量信息的Make.rules文件，或重新更新已有Make.rules文件(上一次由buildc生成的)。项目中的Makefile只需包含(include)Make.rules文件并使用该文件中的变量即可。

buildc的使用是有前提条件的，那就是第三方库必须按特定规划集中存储在一个版本控制服务器中，buildc目前仅支持Subversion。我不是很清楚Maven是如何从互联网上获取对应第三方开源包的jar包的，但我们很难直接获得C第三方库的二进制版本。这里面主要有两点原因：
1、C语言的第三方包多以源码包的形式提供；
2、Java号称"一次编写，到处运行"，也就是说Java第三方库仅需提供一份jar包即可运行在多个平台上；但C的二进制库不能，每种平台都会有对应的特定的版本，我们无法将一种二进制库应用到多个平台上。

因此我们首先需要构建组织内部的第三方库集中存储服务器，将各个产品需要的第三方库在各个平台上进行构建，并将得到的静态库或动态库放入版本服务器中。符合buildc要求的二进制库的组织形式如下。比如在svn://127.0.0.1:6666/3rds这个repository下面我们的第三方库按如下组织形式存放：

3rds/
      – libevent/
            – 2.0.10/
                – README
                – source_code_package
                – sparc_32_solaris/
                     – include/
                     – lib/
                – sparc_64_solaris/
                – x86_32_solaris/
                – x86_64_solaris/
                – x86_32_linux/
                – x86_64_linux/
      – netsnmp/
            – 5.2.0/
                …
            – 5.7.0/
                …
      … …

可以看到每个第三方库的组织形式都像下面这样：
package_name/
    – version/
        – CPU_MODE_OS
            – include
            – lib

一旦第三方库都按如此形式存储，buildc就可以获取到该服务器上的二进制库了。前提满足后，我们就来看看buildc在日常构建过程中的使用方法。

一、buildc的安装
buildc目前尚未做成python安装包，只是以源码形式提供的。所以现有情况下只需Checkout或下载buildc源码包到本地即可以使用。

buildc的源码目录结构如下：

buildc*        # 脚本入口
build_utils/   # 源码库
templates/     # Make.rules.in模板
samples/       # 配置样例

为了方便在任意路径下使用buildc，可将存放buildc源码的目录加入到PATH环境变量中去。另外你可能还需执行'chmod u+x buildc'来为buildc加上执行权限。

二、环境初始化
执行buildc init，buildc会在你的HOME目录下建立.buildc.rc文件。该文件用于配置所有可用的第三方库的信息。

$> buildc init
Copy /home/tonybai/proj/build_tools/samples/buildc.rc.sample to /home/tonybai/.buildc.rc OK!
Please config /home/tonybai/.buildc.rc before you use other buildc commands!
Copy /home/tonybai/proj/build_tools/samples/buildc.cfg.sample to ./buildc.cfg OK!
Please config buildc.cfg before you use other buildc commands!

# $HOME/.buildc.rc
foo_repository = ('svn://10.10.0.156:6666/foo',
                       '~/.buildc_libs/foo',
                       [
                        ('snmp', '5.7.0', 'lib/libnetsnmp.a'),
                        ('libexpat', '2.0.1', 'lib/libexpat.a'),
                        ('libiconv', '1.13.1', 'lib/libiconv.a'),
                        ('libevent', '2.0.10', 'lib/libevent.a'),
                        ('lcut', '0.2.0', 'lib/liblcut.a'),
                        ('instantclient', '10.2.0.5.0', 'lib/libnnz10.so')
                       ]
                      )

bar_repository = ('svn://10.10.0.156:6667/bar',
                         '~/.buildc_libs/bar',
                         []
                 )

external_repositories = [
                          foo_repository,
                          bar_repository
                        ]

其中foo_repository和bar_repository分别代表两个可用的集中存储第三方库的服务器，每个repository中的详细配置包括svn repository的url、这个repository的本地缓存路径以及构建所需的该repository中的第三方库信息。

buildc init还会提供一个buildc.cfg配置文件，该配置文件在后面再细说。

三、第三方库的本地缓存管理
有了正确的.build.rc配置，我们就可以初始化第三方库在本地的缓存了，执行buildc cache init。

$> buildc cache init

===>Begin init repository [svn://10.10.0.156:6666/foo]
Create dir: /home/tonybai/.buildc_libs/foo
library [snmp] does not exist!
Checkout [svn://10.10.0.156:6666/foo/snmp/5.7.0/x86_64_linux]…
Checkout [svn://10.10.0.156:6666/foo/snmp/5.7.0/x86_64_linux] OK!
library [libexpat] does not exist!
Checkout [svn://10.10.0.156:6666/foo/libexpat/2.0.1/x86_64_linux]…
Checkout [svn://10.10.0.156:6666/foo/libexpat/2.0.1/x86_64_linux] OK!
… …

buildc cache init命令会根据.buildc.rc中的配置，从各个repository中下载对应该主机平台的第三方库，存放在对应的缓存路径下备用。

如果repository有更新，我们可以执行buildc cache update来更新本地缓存(在实际的日常开发过程中你可以将该命令加入到crontab中来定期自动更新本地缓存)：
$ buildc cache update

===>Begin update repository [svn://10.10.125.156:3560/3rds]
Update [snmp]…
Update [snmp] OK!
Update [libexpat]…
Update [libexpat] OK!
… …

当不需要本地缓存时，我们可以通过buildc cache remove删除之：
$> buildc cache remove

===>Begin remove repository [svn://10.10.0.156:6666/foo]
Remove [/home/tonybai/.buildc_libs/foo] OK!
<=== End remove repository [svn://10.10.0.156:6666/foo]
… …

四、生成项目Make.rules
第三方库的本地缓存建立好后，我们就可以来配置项目了。在前面执行完buildc init时，buildc生成了一个项目配置模板文件buildc.cfg(.buildc.rc和buildc.cfg本身也都是Python源文件)，我们将该文件移到项目的顶层目录下，然后对该文件进行配置，下面是一个例子：

#(proj_name, (major, minor, revision), author)
project = ('foo', (1, 3, 1), 'tonybai')

# [(libname, libversion, [archives*])*]
external_libs = [
 ("snmp"  , "5.7.0", ["libnetsnmpagent.a", "libnetsnmphelpers.a", "libnetsnmpmibs.a", "libnetsnmp.a"]),
 ("libexpat" , "2.0.1", ["libexpat.a"])
]

# [def*]
# e.g. ['-Dprint_msg=printf', '-D_SELF_DEBUG_']
custom_defs = [
                '-Dprint_msg=printf',
                '-Derr_msg=printf'
              ]

# [(var, value)*]
# e.g. [ ('WITHOUT_DB_IMPORT', 'TRUE'), ('SUPPORT_MYSQL', 'TRUE') ]
custom_vars = [
                ('WITHOUT_IMPORT', 'TRUE'),
                ('WITHOUT_NM', 'TRUE')
              ]

# [include_path*]
# e.g. ['./include', '/home/tonybai/.include']
custom_includes = [
                    './include'
                  ]

# [(lib_path, [archives])*]
# e.g. [('/home/tonybai/.lib', ['libfoo.a', 'libbar.so']), (‘.libs’, ['libzoo.a'])]
custom_libs = [
                ('.libs', ['libfoo.a']),
                ('', ['libzoo.so'])
              ]

这里简要说明一下这个配置文件的各个配置项：
* external_libs是项目所使用的第三方库列表，这些第三方库必须存在于该主机的本地缓存中，也就是.buildc.rc中拥有这些库的配置；
* custom_defs是项目需要额外传递给编译器的命令选项集合；
* custom_vars是你想额外在Make.rules定义的变量集合；
* custom_includes是额外需要单独指定的的头文件包含路径集合；
* custom_libs是项目所需额外的(不在本地第三方库中存储的)库路径，比如一些系统库。

完成buildc.cfg的配置，我们就可以通过buildc config-make来生成Make.rules文件：
$ buildc config-make
Can not found Make.rules in current directory!
Generate [/home/tonybai/proj/foo/Make.rules] …
Config [/home/tonybai/proj/foo/Make.rules]…
Config [/home/tonybai/proj/foo/Make.rules] OK!
Generate [/home/tonybai/proj/foo/Make.rules] OK!

生成的Make.rules如下：
#
# Make.rules for foo
#
# tonybai
# 2011-12-08
#
# @Generated by buildc@
#

# Project information
TOPDIR = /home/tonybai/proj/foo#@topdir@

# Platform information
OS = linux#@os@
CPU = x86#@cpu@
CMODE = 64-bit#@cmode@

# Version information, (MAJOR.MINOR.REVISION)
MAJOR = 1#@major@
MINOR = 3#@minor@
REVISION = 1#@revision@
VERSION = $(MAJOR).$(MINOR).$(REVISION)

# Compiler options
DEFS = -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_DEBUG_ -DVERSION=\"${VERSION}\"
… …
CUSTOM_DEFS = -Dprint_msg=printf -Derr_msg=printf #@custom_defs@
CC = gcc -m64#@cc@
CFLAGS = $(FDEBUG) $(FWALL) $(FPIC) $(FOPTIMIZE) $(DEFS) $(CUSTOM_DEFS) $(INCLUDES)

# Library infomation
snmp_ROOT = ~/.buildc_libs/foo/snmp/5.7.0/x86_64_linux#@lib_roots@
libexpat_ROOT = ~/.buildc_libs/foo/libexpat/2.0.1/x86_64_linux#@lib_roots_end@

LIB_INCLUDES = -I $(snmp_ROOT)/include -I $(libexpat_ROOT)/include #@lib_includes@
LIBS_DEPEND =  -L $(snmp_ROOT)/lib -lnetsnmpagent -lnetsnmphelpers -lnetsnmpmibs -lnetsnmp -L $(libexpat_ROOT)/lib -lexpat#@ libs_depend@
CUSTOM_LIBS = -L .libs -lfoo -lzoo#@custom_libs@

# Headers
DEFAULT_INCLUDES = #@default_includes@
CUSTOM_INCLUDES = -I ./include #@custom_includes@
INCLUDES = -I $(TOPDIR)/include $(LIB_INCLUDES) $(CUSTOM_INCLUDES) $(DEFAULT_INCLUDES)

# Libraries
DEFAULT_LIBS = #@default_libs@
LIBS = $(LIBS_DEPEND) $(CUSTOM_LIBS) $(DEFAULT_LIBS)

# Other definitions
WITHOUT_IMPORT = TRUE#@custom_vars@
WITHOUT_NM = TRUE#@custom_vars_end@
… …

你可以对比着项目buildc.cfg的配置来查看Make.rules的构成。如果bulidc.cfg配置发生变化，那么再次执行buildc config-make会更新当前路径下的Make.rules。Make.rules的生成和更新使用了基于模板的标记替换技术。

五、利用Make.rules构建项目
可以看出Make.rules中将平台信息和第三方库的依赖信息都放置在对应的变量中了。项目的Makefile只需要包含Make.rules便可以利用这些信息进行项目的构建。可以利用的Make.rules中的主要变量包括：CFLAGS、LIBS。我们甚至可以为项目再编写一个"一键构建"脚本，该脚本中只需包含两行代码即可：

buildc config-make
make

你无需将Make.rules提交到源码版本库中，但需要将buildc.cfg作为项目的一部分。这样在任一一个通过buildc做项目构建管理的环境中，你的项目就都可以进行"一键式"构建了，再也无需为配置项目路径和寻找构建第三方依赖库而发愁了。另外通过buildc进行构建管理的项目将会很容易地集成到持续集成过程中。

buildc与make的组合模式很类似于maven和ant的组合，但buildc目前的功能还无法与maven相比，不过buildc也不打算做成maven的模样。buildc后续可能会支持从更多种版本管理服务器(比如git)下载第三方库，支持按指定模板生成Make.rules(目前只有一种模板)等特性。从目前实践的情况来看，buildc这个项目构建管理辅助工具十分适合我们内部的C项目构建，也许它也同样适合你的项目，有兴趣的朋友不妨试试。

Common Lisp是函数式编程语言，其基本组成单元自然是函数。对Common Lisp函数的理解也是学习Common Lisp语言的关键。另外与C语言以内存单元修改为主要编程方法不同，Common Lisp的主要编程方法是将函数应用于参数。这里我们分别用两种范式风格实现同一个函数，该函数用于取得第n个fibonacci数（n从0开始）：

;; 命令式风格
(defun imperative-fibonacci (n)
    (let ((first 0)
          (second 1)
          (sum 0))
        (dotimes (i n)
            (progn
                (setf sum (+ first second))
                (setf first second)
                (setf second sum)))
        first))

;; 函数式风格
(defun functional-fibonacci (n)
    (cond 
        ((= 0 n) 0)
        ((= 1 n) 1)
        (t (+ (functional-fibonacci (- n 1)) (functional-fibonacci (- n 2))))))

对比一下我们可以看出函数式风格代码更加简洁，可读性更强，更易于理解。虽然使用Common Lisp也可以写出命令式风格的代码，不过我们强烈建议你使用函数式风格，这才是Common Lisp的首选范式 – 即用自然而然的函数嵌套调用或递归调用，而不是堆砌一些修改变量值的语句。C语言中也有函数，但与Common Lisp语言中函数的区别就在于其内部实现均为对变量的修改操作，就像上面例子中imperative-fibonacci函数定义的那样。

一、定义新函数
Common Lisp使用defun宏来定义一个新函数，其语法形式如下：
(defun function-name (param*)
    "Optional documentation string."
    expr1
    expr2
    expr3
    … )

其实我在之前的几篇文章以及上面的例子中已经多次用到了defun宏，与C语言的函数原型相比，defun定义的函数缺少了一些类型信息，包括返回值类型信息和参数列表中参数的类型信息。

defun定义的函数在全局作用域可见，即使这个定义是嵌套在另外一个函数定义中的(标准C是不允许函数嵌套定义的)：
[1]> (defun foo (x)
        (print x)
        (defun bar (y)
            (print (1+ y))))
FOO
[2]> (foo 1)
1
BAR
[3]> (bar 2)
3

注意：嵌套在其他函数定义中函数定义，如bar，其生命周期起始于外围函数执行后，例如例子中foo函数未执行前，bar是未定义的。

对于C程序员来说，也许Common Lisp函数定义与C函数定义最大的不同在函数参数列表上。C语言的函数只支持两种参数列表形式：定长参数列表和变长参数列表，比如：
int main(int argc, char* argv[]); /* 定长参数列表 */
int printf( const char* format, …);  /* 变长参数列表 */

而Common Lisp函数对参数列表的支持更加灵活，参数的类型更加丰富，功能也更为强大。下面我们逐一来看。

Common Lisp函数参数列表默认都是定长的，参数也是必选的(required)，也就是说参数列表中有几个形式参数，你在调用该函数时就需要传入等量的实际参数，不能多，也不能少，例如：
[1]> (defun foo (x y) (print (+ x y)))
FOO
[2]> (foo 1)
*** – EVAL/APPLY: too few arguments given to FOO
[3]> (foo 1 2 3)
*** – EVAL/APPLY: too many arguments given to FOO
[4]> (foo 1 2)
3

除了参数列表的必选参数外，Common Lisp还支持可选参数(Optional Parameter)。参数列表中的可选参数由&optional指定，例如：
(defun foo (a b &optional c d)
    (print a)
    (print b)
    (print c)
    (print d))

其中位于&optional后面的c，d为可选参数；如果未显式指定默认值，则其值为NIL。
[1]> (foo 1 2)
1
2
NIL
NIL

我们可以为可选参数指定默认值，例如：
(defun foo (a b &optional (c 10) (d 11))
    … …)
[2]> (foo 1 2)
1
2
10
11

可以看出对于指定了默认值的可选参数，如果调用时没有为可选参数传入实际参数，则可选参数将绑定默认值。可选参数的默认值不仅仅可以是常量值，还可以是全局变量或该可选参数左侧的某个必选参数，例如：
(defvar *x* 13)
(defun foo (&optional a b c (d *x*))
    … …)
和
(defun foo (&optional a b c (d a))
    … …)
 
如果有必选参数，那可选参数必须放在必选参数的后面，但我们可以将一个函数的所有参数都定义为可选参数，如：
(defun foo (&optional a b (c 10) (d 11))
    … …)

在带有可选参数的函数体内我们如何知道该函数被调用时外面是否给可选参数传入实际参数了呢？Common Lisp提供了一个指示器，你可以将该指示器放在可选参数默认值的后面，就像这样：
(defun foo (&optional a b (c 10) (d 11 d-supplied-p))
    (print a)
    (print b)
    (print c)
    (print d)
    (print d-supplied-p))

如果函数在执行时可选参数绑定了实际参数而不是默认值，则该指示器的值将为T，否则为NIL。
[1]> (foo 1 2 3 4)
1
2
3
4
T
[2]> (foo 1 2)
1
2
10
11
NIL

Common Lisp语言引入可选参数至少有两个用途，一是为了适应某些场合的需求：一些场合的确不需要显式为所有参数传递实际参数；二是我们通过可选参数可以为某些参数显式地设置默认值。

在Common Lisp中，与C语言变长参数列表对应的是函数列表中的rest参数。rest参数通过在参数前面的&rest关键字修饰。通过rest参数，我们可以定义出类似format这样接受不定个数参数的函数，例如：
[1]> (defun foo (x y &optional z &rest others)
        (print x)
        (print y)
        (print z)
        (mapcar #'print others))
[2]> (foo 1 2 3 4 "hello lisp")
1
2
3
4
"hello lisp"
(4 "hello lisp")

在函数定义内部rest参数是以一个list的形式存在的，例如上面例子中，传入函数体内的参数others的值实际上是(4 "hello lisp")。

我们知道C语言虽然支持变长参数列表，但其参数列表中至少需要有一个必选参数，例如：int printf( const char* format, …)中的format参数是无法省略的；但是Common Lisp就不同，Common Lisp支持完全的变长参数列表，例如：(defun my-add (&rest addends) …)

Common Lisp还提供一种C语言中没有的参数类型 – keyword参数。keyword参数允许你只为参数列表中的某个特定参数传入实际参数，这种能力是rest和optional参数所不具备的。我们可以通过&key来指示keyword参数，如：
[1]> (defun foo (&key x y z)
        (print x)
        (print y)
        (print z))

作为keyword参数，如果在函数调用时没有为其显式赋值，那么该参数的值将为NIL。我们可以通过如下方式为特定的keyword参数赋值：
[2]> (foo :y 2)
NIL
2
NIL

Keyword参数赋值是不用考虑赋值先后的顺序的，例如：
[3]> (foo :z 11 13)
13
NIL
11

对于带有keyword参数的函数，调用该函数时要么不为任何keyword参数传参，要么至少为其中某一个keyword参数传参，不能只为必选参数传参，如：
[1]> (defun foo (&key x y z)
        (print x)
        (print y)
        (print z))
[2]> (foo 1)
*** – FOO: keyword arguments in (1) should occur pairwise

与Optional参数类似，keyword参数也可以指定默认值，也可以通过指示器来标定keyword参数到底是否绑定了外面传入的实际参数，其中默认值既可以是常量也可以是其左侧其他keyword参数组成的表达式，例如：
[1]> (defun foo (&key (x 17) (y 15 y-supplied-p) z)
        (print x)
        (print y)
        (print y-supplied-p)
        (print z))

[2]> (foo :z 23)
17
15
NIL
23

在之前有关keyword参数的例子中我们使用的形式参数多以x，y这样的简单名字命名，这些名字虽便于函数定义内部使用，但是对于这个函数的调用者来说，这些名字却没有什么实际含义。keyword参数支持通过别名方式解决这个问题：
[1]> (defun foo (&key ((:name a)) ((:age b)) ((:gender c) "Unknown"))
        (print a)
        (print b)
        (print c))
[2]> (foo :name "tony" :age 29)
"tony"
29
"Unknown"

Common Lisp中函数的返回值默认为函数体中最后执行的那个表达式的求值结果，上面举的例子也都是这种情况。在C语言中我们通过return语句可以从函数体内的任何位置主动退出该函数，在Common Lisp中我们同样可以用return-from达到这一目的，例如：
[1]> (defun foo (x y)
        (if (< x 0)
            (return-from foo "IIlegal X Value"))
        (if (< y 0)
            (return-from foo))
        (+ x y))
FOO
[2]> (foo 1 2)
3
[3]> (foo -1 2)
"IIlegal X Value"
[4]> (foo 1 -2)
NIL

对于函数而言，return-from的语法形式为：(return-from func-name optional-value)，若不指定返回值，那么默认return-from的返回值为NIL。

二、匿名函数
与C语言不同，Common Lisp支持定义匿名函数，例如：
[1]> (funcall #'(lambda (x) (print (1+ x))) 2)
3

上面例子中这行语句既包含了函数定义，也包含了函数调用。与之前使用defun定义有名函数不同的是，这次我们定义出来的函数没有指定函数名，这种使用lambda关键字定义的函数被称作为匿名函数。

从例子中也可以看出，匿名函数的定义也很简单，其一般形式为：
(lambda (args*) body-form*)

我们也称这种表达式为lambda表达式。lambda表达式定义的匿名函数与有名函数一样，也支持使用optional，rest和keyword参数。

三、高阶函数
函数式编程语言与命令式语言除了在风格方面的不同之外，最大的不同点之一在于函数式语言中函数已经成为了一等公民(first-class citizen)，与整型、字符串等原生类型具有同等的地位。更具体地说，函数成为一等公民意味着我们可以像对待整型数、字符串那样将函数当作数据对待：将函数赋值给变量、将函数作为参数传递给其他函数以及将函数作为返回值返回给函数调用者等等。作为C程序员你也许会说这似乎与C语言中的函数指针很类似啊，但别忘了C语言真正原生支持的是类型是指针，而不是函数。

有了一等公民地位的函数，我们就得到了高阶函数。高阶函数就是那些接受其他函数为函数或将其他函数作为返回值的函数。例如Common Lisp提供的标准函数sort就接受一个比较函数作为参数：
[1]> (defun integer-over-than (x y) (> x y))
INTEGER-OVER-THAN
[2]> (sort '(5 2 98) (function integer-over-than))
(98 5 2)
[3]> (sort '("hello" "world") (function string>=))
("world" "hello")

标准库中的sort函数接受一个自定义的比较函数作为参数，并在内部将传入的函数应用于参数list。例子中我们没有直接将integer-over-than传给sort，而是使用了(function integer-over-than)。function是Common Lisp提供的一个特殊操作符，将其应用于函数名可以得到该函数名对应的函数对象。比如通过(function foo)，我们可以得到名字为foo的内部函数对象。如果没有foo这个函数定义，解释器会提示"undefined function FOO"。可以看出真正被当作一等公民对待的不是foo这个符号，而是foo这个符号名字背后所对应的那个函数对象，也就是函数在Common Lisp中的内部表示形式。我们在将函数绑定到某个变量或将函数传递给某个函数作为实际参数时，我们都需要使用这个内部函数对象，而不是foo这个符号，例如：
[1]> (sort '(5 2 98) integer-over-than)
*** – EVAL: variable MY-OVER-THAN has no value
[2]> (setf *sort-func* integer-over-than)
*** – EVAL: variable MY-OVER-THAN has no value
[3]> (setf *func* (function my-over-than))
# FUNCTION MY-OVER-THAN (X Y) (DECLARE (SYSTEM::IN-DEFUN MY-OVER-THAN)) (BLOCK MY-OVER-THAN (> X Y))>

Common Lisp提供了一个语法糖用于简化function的使用，即我们可以用#'代替function操作符，比如：#'foo就等价于(function foo)。

那么在接受函数作为参数的函数定义内部我们如何使用函数对象呢？Common Lisp提供了两个函数funcall和apply用来执行函数对象对应的函数。我们先以funcall为例，funcall的语法形式如下：
(funcall function-obj args*)

例如：
[1]> (defun foo (x y) (print (+ x y)))
FOO
[2]> (defun my-add (x y f) (funcall f x y))
MY-ADD
[3]> (my-add 1 2 #'foo)
3

apply与funcall的不同之处在于其接受的参数格式有不同，apply的语法形式如下：
(apply function-obj args* other-args-list)

直观地比较：(apply #'+ '(1 2 3))就等价于(funcall #'+ 1 2 3)，不同的是使用apply需要将各个参数打包到一个list中，或至少保证最后一个参数为list。下面几种调用方式与(apply #'+ '(1 2 3))都是等价的：
(apply #'+ 1 '(2 3))
(apply #'+ 1 2 '(3))

lambda表达式用于定义一个匿名函数，我们同样可以通过#'来获得这个匿名函数对应的函数对象，例如：
#'(lambda (x y) (print (+ x y)))

匿名函数对象可以直接作为实际参数传递给函数，我们也可以通过funcall来直接执行匿名函数，例如：
[1]> (my-add 1 2 #'(lambda (x y) (print (+ x y))))
3
[2]> (funcall #'(lambda (x y) (print (+ x y))) 1 2)
3

以上是推荐的标准用法，下面方法（去掉了lambda前面的#'）虽然也可以达到相同效果，但不推荐使用：
[1]> (my-add 1 2 (lambda (x y) (print (+ x y))))
3
[2]> (funcall (lambda (x y) (print (+ x y))) 1 2)
3
[3]> ((lambda (x y) (print (+ x y))) 1 2)
3

在C语言中我们通过函数指针和回调手法也可以模拟一些高阶函数的行为，这里就不赘述了。

四、闭包(Closure)
市面上有很多编程语言都支持闭包，比如JavaScript，Python，Perl，Ruby等。这里所说的闭包不是离散数学里的那个闭包，而是编程语言引入的一种机制，目前对于编程语言中的闭包尚未有一个精确的定义，但一般认为闭包是引用了外部作用域(但不是全局作用域)的变量的函数，这个被引用的变量与这个函数一同存在，即使是脱离了定义它们的上下文环境。

Common Lisp支持闭包，关于Common Lisp闭包的一个最典型例子是这样的：
[1]> (setf *fn* (let ((i 0))
            #'(lambda () (setf i (+ i 1)))))
#FUNCTION :LAMBDA NIL (SETF I (+ I 1))>
[2]> (funcall *fn*)
1
[3]> (funcall *fn*)
2
[4]> (funcall *fn*)
3

按照之前我们对变量的理解，let引入的i只是一个局部变量，在离开定义的环境后，该变量生命周期将终结。理论上我们三次调用*fn*所对应的你们函数得到的结果应该是相同的才对。但就是由于在let构造的局部作用域内的那个匿名函数引用了外部的变量i，导致变量i可以脱离其原生作用域的束缚，让其生命周期等同于了其内部的那个匿名函数，这个内部的匿名函数就被称为闭包，而那个被引用的外部变量被成为自由变量(free variable)。当我们连续调用函数*fn*时，i就像一个全局变量一样，每次值都加一。

引用了自由变量的闭包似乎是终结了自由变量的局部绑定关系，将自由变量从局部作用域环境中取出，并重新放入一个与闭包同生命周期的新作用域。自由变量会常驻内存中，这也是闭包的常用场景之一。闭包的另外一个用途可能就是出于保护自由变量的考虑，让自由变量只有通过闭包函数才能访问到。