hhkbp2's blog

博客从Octopress迁移到Hugo

Fri, 29 Sep 2023 22:21:22 +0800

自2012年，我开始使用Octopress这个博客框架来写博客，直到2023年的现在。虽然我在这里写文章的频度不高，基于够用就不折腾的想法，很少对Octopress版本做更新，但最近发现继续用它来写博客有几个问题：

项目已停止维护
Octopress项目在2016年已停止维护，它的依赖包和代码都比较老旧，部分甚至有安全漏洞却也不会得到更新。
依赖Ruby开发环境，安装迁移麻烦
Octopress依赖Ruby开发环境和工具链，每当换电脑要迁移的时候都要重新进行安装配置，比较麻烦。

Ruby这门编程语言，虽然我曾经正儿八经地学过，但是因为很少使用渐渐已经忘记七七八八了，因此希望找一个使用我熟悉语言实现的替代品，降低维护成本，不需要达到能改动代码的程度，但至少熟悉如何安装配置环境以及安装它的依赖包，以降低维护成本。经过一番搜索之后，发现目前类似Octopress定位的静态博客/网站生成框架有很多，综合来看Hugo这个项目最接近我的需求，个人觉得Hugo有以下几个优点：

功能丰富，项目活跃
功能足够我个人使用，而且项目处于活跃发展状态，有一个不小的社区，网上文档较丰富。
用Go语言实现，方便部署迁移
Hugo使用Go语言实现，Go语言和它的工具链、依赖包部署安装比较容易，在不同机器之间迁移也相对容易。
速度快
由于Hugo使用Go语言实现，相比使用Ruby语言实现的Octopress在速度上具有天生的优势。

使用Hugo来写博客，与使用Octopress类似，都是先写好Markdown格式的文章，然后编译生成静态网站发布到GitHub Pages。要将我的博客从Octopress迁移到Hugo，只需要将全站框架和博客文章迁移过来。迁移过程主要包括下列步骤：

迁移全站框架
我在Octopress上使用一个叫 whitespace 的主题，它是一个白色背景的简单主题，虽然原来主题已经比较简单，但我还是在其基础上去掉了一些个人不需要的元素，最后得到一个非常简单的只带几个标签的一栏式简化主题。对Hugo的主题做过一番查找，找到一个主题hugo-theme-refined比较符合我的需求和审美，于是在Hugo标准模板的基础上修改为hugo-theme-refined主题，并添加posts, about等几个标签并迁移对应的内容，就搭建好了一个Hugo博客的框架。
迁移博客文章
Hugo在文章头部的写法与Octopress有较大差异，要迁移Octopress的博客文章到Hugo，需要经过转换。我的博客正式发表的文章不多，但过去留下不少草稿，因此不能逐个文章手动修改来迁移。Hugo官方文档网页提供了一个转换工具octohug，经过测试并不能完全识别我的Octopress文章头部的所有标签，因此我参考octohug另外写了一个工具octo2hugo，使用这个工具将Octopress目录中的文章批量转换成适合Hugo的格式，然后复制所有文章中用到的图片到Hugo对应目录，就完成了博客文章的迁移。在这次迁移中把文章URL的日期部分去掉了，并且将每篇文章和图片放到同一个目录。
调整优化
最后对Hugo博客做一些配置调整和优化，主要有配置合适的baseURL, 添加自定义域名CNAME，正文字体调整为更适合中文内容的霞鹜文楷（为了加载速度使用了霞鹜文楷lite版本的在线字体），代码字体调整为Jetbrains Mono等。

迁移后的新博客依旧保留了简洁够用的风格，用Hugo写博客使用体验比Octopress要好，无论是编译全站还是实时预览Hugo都快得多，我博客上的文章并不多，还是能感受到明显的差别。我对这次迁移的效果感到满意，希望Hugo历久长青，支持我的博客走过下一个十年。

Kapok 的设计与实现: Protocol

Mon, 19 Mar 2018 14:56:00 +0800

Kapok是我设计与实现的一个基于Erlang VM的现代Lisp编程语言。《念念不忘，亦有回响》这篇文章叙述了这门编程语言的概况。下面我们来聊一聊其中Protocol的具体设计和实现。

Protocol是什么 #

为了更好地进行程序的编写，编程语言往往需要引入一些抽象，比如一个函数是一系列操作的封装，一个模块是一堆函数的封装，然后出于通用性的需要，又定义了函数签名来区分具有相同参数类型和参数个数的函数，对于具有相同函数签名的模块，在Erlang我们定义了行为(Behavior)。类似地，Protocol也是一种对数据类型和基于数据类型上实现的一些函数的抽象。在面向对象编程语言(OOP)非常流行的今天，这种抽象更多地被称为类与接口。

下面简单举例来说明Protocol是什么。在Erlang里面，如果我们要编写一段代码来处理不同的数据类型，往往需要在一大块集中代码里面针对每一种数据类型进行不同的处理。假设我们正在编写一个Json模块，这个模块要处理list, binary, number三种类型的encode(编码)操作，那么就有代码：

-module(json)

encode(Item) when is_list(Item) ->
  % ...
encode(Item) when is_binary(Item) ->
  % ...
encode(Item) when is_number(Item) ->
  % ...

如果要添加更多的数据类型，那么就在模块内部添加对应那个数据类型的分支。但是如果你没有这个模块的源代码就无法添加，而且经过长时间添加多个类型支持后这个模块变得非常大，难于维护。Elixir引入了Protocol，针对上述的encode操作，可以定义成一个Protocol，代码如下：

defprotocol JSON do
  def encode(item)
end

对于任何实现了JSON Protocol的数据类型对象data，都可以直接调用下述函数：

JSON.encode(data)

这些数据类型的JSON Protocol实现可以分散放在各个文件中，没有要集中维护的问题，当你需要添加一个新的数据类型的支持时，也不需要已有模块的源代码。

defimpl JSON, for: List do
  def encode(item) # ...
end

defimpl JSON, for: BitString do
  def encode(item) # ...
end

defimpl JSON, for: Number do
  def encode(item) # ...
end

通过Protocol这样一个抽象，我们可以在函数式的编程语言中，定义对数据类型绑定一系列的接口，然后针对这些通用的接口来进行编程。针对接口编程一个常常被提到的用法是，在需要快速编写原型的时候，使用简单的数据类型进行接口编程，先快速实现功能，等到程序稳定下来，后期需要进行性能优化的时候，再将接口下面的数据类型更换成更高效的实现，这个过程中所有的接口使用代码都不需要修改。

Elixir中Protocol的实现 #

Protocol，或者说类接口，它的广义的概念可以追溯到20世纪80年代开始流行的面向对象编程语言，比如C++，甚至更早之前60~70年代就已经存在的Lisp，从那个年代流传至今的很多Lisp方言中，都或多或少有着这种抽象，比如Common Lisp中的Sequence的概念。而在Erlang VM上实现了Protocol的Elixir语言，它则是参考了Clojure的Protocol定义和实现。下面简单描述一下Elixir的Protocol实现。

从上面的例子我们可以看到，Protocol的本质是将数据类型和接口分开定义，并在运行时进行动态绑定。上述例子中，对于List类型，定义了对应的encode实现，调用Protocol的接口JSON.encode(data)时，如果data是List类型，就进行动态分发，执行对应的encode实现。那么如何实现这种动态绑定或者说分发呢？由于Erlang是一个函数式编程语言，Erlang VM的基本语义中也只支持模块和函数，因为Protocol的每个实现可以分开，而Erlang VM中基础的编译单元是模块，一个简单的映射方法就是将每个Protocol实现映射为一个模块。而对于接口模块JSON，很自然地也成为一个单独的模块。那么就只剩下一个问题了，即如何实现当调用JSON.encode()时，将执行路径转到defimpl JSON, for: List模块的encode()函数，这里可以实现为在运行时拼接模块名，然后调用具体模块的函数。上述的Elixir代码中的例子，将编译成对应的Erlang代码：

          Elixir                                  Erlang
defprotocol JSON do                     -module(JSON).
  def encode(item)         生成          encode(item) ->
end                                        case item of
                                             data when is_list(data) ->
                                               'JSON.List':encode(data);
                                             data when is_binary(data) ->
                                               'JSON.BitString':encode(data);
                                             data when is_number(data) ->
                                               'JSON.Number':encode(data)
                                             data when is_struct_X(data) ->
                                               'JSON.X': encode(data)
                                           ...

这里的struct_X表示除了几个基本数据类型以外的用户自定义struct类型，其中X为struct的名字，即对应Elixir中的代码

defmodule X do
  defstruct # ...
end

对于各个数据的类型的实现，可以映射为各个Erlang模块：

          Elixir                                         Erlang
defimpl JSON, for: List do            生成      -module('JSON.List').
  def encode(item) # ...                        encode(item) ->
end                                               %% ...

defimpl JSON, for: BitString do                 -module('JSON.BitString').
  def encode(item) # ...                        encode(item) ->
end                                               %% ...

defimpl JSON, for: Number do                    -module('JSON.Number').
  def encode(item) # ...                        encode(item) ->
end                                               %% ...

注意其中的模块名是由Protocol名字，即这个例子中的JSON，和具体的数据类型名，即这个例子中的List, BitString, Number等，两者拼接而成。

Kapok中Protocol的实现 #

既然Elixir已经实现了Protocol，而且Kapok和Elixir都兼容于Erlang VM，那么除了另外捣腾一套Protocol的用法和实现之外，比较好的做法就是兼容Elixir的实现，从而达到重用所有Elixir己经有的库和代码的效果。Elixir中定义了每个Protocol模块都必需具备的接口函数，具体列出如下，它们都是通过defprocotol宏来实现的：

__protocol__/1 当参数是:name，返回Protocol名字当参数是:functions，返回一个元素为Protocol接口函数和参数个数的关键字列表当参数是:impls，返回一个实现的列表
impl_for/1 接收一个struct，返回为此struct实现当前Protocol的模块名，如果不存在这样的实现模块则返回:nil
impl_for!/1 类似于上面的impl_for/1，区别在于当实现模块不存在时不返回:nil而是抛出异常

在Kapok中，也定义类似的Macrodefprotocol来生成这些接口函数。类似地，对于Elixir中的defstruct, defimpl Macro，Kapok也定义了对应的Macro来生成对应的struct结构，和实现函数接口。

以上所述的种种Protocol结构都是通过Macro，这个强大的Lisp编程方式，来实现的。通过Macro处理手写代码，生成新代码，我们可以在Kapok实现一套类似于Elixir Protocol原语，无缝对接到已有的Elixir代码和库中。

Kapok的Protocol使用示例 #

最后附上一个Kapok代码示例，展示一下Protocol在Kapok中的定义和使用，便于理解。

;; 定义一个用于此示例的Protocol
(defprotocol pr
  "A protocol to print something."
  ;; 此Protocol唯一接口用来打印某个数据
  (print [self]))

;; 为Atom数据类型实现pr Protocol
(defimpl pr Atom
  (require io)

  (defn print [atom]
    (io.format "print an atom: #'~p'~n" [atom])))

;; 为List数据类型实现pr Protocol
(defimpl pr List
  ;; 在print的实现代码中，直接使用了Elixir的Enum Protocol
  ;; 所以这里用了一行代码引入Elixir.Enum模块
  (require (Elixir.Enum :as enum)
           io)

  (defn print [list]
    (io.format "print a char list: #\"")
    ;; 直接在List上调用enum.map，直接使用Elixir库代码
    (enum.map list
              (fn [x] (io.format "~c" [x])))
    (io.format "\"~n")))

(ns protocol-examples
  (require pr))

(defn main []
  ;; 下面先后声明了Atom和List两种数据类型的实例，并调用pr.print接口
  (let [data #abc]
    (pr.print data))
  (let [data #"abc"]
    (pr.print data)))
;; 得到输出
print an atom: #'abc'
print a char list: #"abc"

Kapok 的设计与实现: Macro

Mon, 14 Aug 2017 16:20:00 +0800

Kapok是我设计与实现的一个基于Erlang VM的现代Lisp编程语言。《念念不忘，亦有回响》这篇文章叙述了这门编程语言的概况。下面我们来聊一聊其中Macro的具体设计和实现。

Lisp是一系列采用括号包围中缀表达式的列表形式来编写代码的编程语言的统称，借用一位朋友的说法，Lisp就是“裸写AST”。由于这种特别的写法，在Lisp里面将代码作为数据来操作相当容易，而实现这种操作的就是Macro。有很多的书籍和资料都有描述Lisp Macro，这里就不展开了，简单的来说，Lisp Macro是一种在编译时执行的，接受列表输入，输出列表的特殊函数。如果我们构思一下如何在Erlang VM上为一门Lisp语言实现Macro，可以得到这几个要点：

Macro实现为函数，而Erlang和Erlang VM支持函数
Macro对应的实现函数，其输入是代码AST，输出也是AST
Macro在编译时执行，Macro本身的代码需要在被调用前的代码编译前编译完成

下面我们进一步看看Kapok Macro的具体实现。

函数的实现 #

将Lisp Macro实现为函数，首先我们要在Erlang VM上实现Lisp函数。Erlang是一门函数式编程语言，在它的代码编译过程中，生成的Abstract Form(或称为Syntax Tree)和Core Erlang这两种中间代码都直接支持函数。Erlang函数比较特别，参数个数(Arity)也是函数签名的一部分，它支持多个子句但是每个子句只能有固定个数的参数，举例erlang:spawn/1和erlang:spawn/3是一个同名函数的两个子句。目前已经存在的几个Erlang VM上的语言实现，如LFE等，大都沿用了Erlang函数的这个设计，除了Elixir在函数参数的最后面引入Keyword List。如果将Kapok的函数直接编译成Erlang函数，函数参数定义和签名可以照抄过来，是容易做到的。但传统的Lisp，比如Common Lisp, 在函数参数定义这块支持&optional, &rest, &key这几个关键字，其中&optional表示这个关键字后面的参数是可选的，&rest表示将后面的参数构造成一个list，&key表示可以用key value匹配的形式来调用函数。能不能在Erlang VM上实现对这几个关键字的支持呢？不妨尝试一下。

首先思考一下如何实现&optional，我们知道&optional后面的参数在调用时可以不传入而采用默认值。举例来说，如果在Common Lisp里面有这个函数定义

(defun f (a &optional b c)
  ;; 具体实现
  ...
  )

以下面几种方式来调用都是合法的

(f 1 2 3)
(f 1 2)
(f 1)

这种调用的形式可以适配到Erlang的子句上面来。比如上面的函数定义f可以实现成Erlang函数：

f(A) ->
  f(A, nil, nil).
f(A, B) ->
  f(A, B, nil).
f(A, B, C) ->
  %% 具体实现
  ...;

如果参数B, C被省略了，那么就用一个默认值来调用参数多一个的子句，这里假定默认参数统一为Atom nil(Lisp里面optional参数的默认值为symbol nil)。

然后再考虑如何实现&rest, &key。我们看看一个常用的函数参数实现技巧。假设现在需要定义一个函数，这个函数只允许有一个参数(不考虑这个限制是否合理)，然而你需要传入两个参数，你会怎么定义这个函数？

%% An Erlang function which calculates the area of a rectangle
%% with specified length and width.
calc_area({length, width}) ->
   length * width.

你会将这个函数的唯一参数定义成一个能存放两个参数的结构，然后在调用时用实际参数构造一个这样的结构传入。上面是一个以Erlang编写的例子，事实上用其它语言比如Python, C来实现，思路也是一样。

类似地，对于&rest参数，可以将&rest后面的参数构造成一个列表传入。举例说明，若有Lisp的函数定义

(defun f (a &rest b)
  ;; 具体实现
  ...
  )

可以翻译成对应的Erlang函数如下：

f(A) ->
  f(A, []).
f(A, B) ->
  ;; 具体实现，此处B是一个列表
  ...

如果调用Lisp函数f的实际参数超过一个，那么从第二个参数开始及之后的实际参数都会被放入一个List中，赋值给B变量。比如对于调用

(f 1 2 3 4)

那么实际调用的对应代码就变成

f(A = 1, B = [2 3 4])

对于关键字&key，也可以采取类似的思路。比如对于函数定义

(defun f (a &key b c)
  ;; 具体实现 
  ...
  )

会翻译成对应的Erlang函数定义

f(A) ->
  f(A, maps:new()).
f(A, Map) ->
  %% 具体实现
  ...

调用时会变换实际参数为第二个形参构造一个Map。比如这样的调用

(f 1 :c 3)

会翻译成

f(A = 1, Map = #{c => 3})

所描述的都是Lisp函数定义里，固定参数后出现&optional, &rest, &key三个关键字其中之一的简单情况。如果两个关键字都用上，还是否能够工作呢？我们知道&rest, &key都在最后一个参数上做文章，如果&rest, &key同时出现，那最后一个参数是构造成List还是Map？幸好这种情况不会发生，在Common Lisp的编程规范中限制了函数定义中&optional, &rest, &key这几个关键字的用法如下：

固定参数 + &optional/&rest/&key 其中之一的简单情况，上面我们已经过了一遍
&key与&optional, &rest混用会产生奇怪行为，所以&key不能与它们混用
&optional可与&rest混用，但是约定&optional在前，&rest在后

只有第3点是混用的情况，根据的实现方式可知&optional和&rest没有冲突，第3点是可以实现的。

上面花了很长的篇幅来详细描述如何在Erlang VM实现Lisp函数，由开头的讨论可知Macro也是函数，有了函数的实现作为基础，下面我们进一步讨论Macro函数的输入输出。

AST的处理 #

从代码的书写形式来看，在Lisp里面代码是列表，因此Lisp Macro的输入和输出都是列表。在实现层面，Lisp列表形式的代码会经过词法分析语法分析，最后变成编译器内部表示AST。AST主要保存这几类信息：类别，数值，元数据。例如，在Lisp代码里面的100字面量，就需要一个AST数据结构记录下它是一个常量，值为整数100，它在代码文件里面的行号是多少等。Kapok内部将AST定义为Erlang Tuple

{Category, Meta, Value}

其中Category表示这个结点的类别，比如integer常量，list, map等。Meta是一个保存元数据的Property List。Value则是记录了实际的取值，比如对于integer常量，就记录了常量的值是100，对于List类型，就记录了这个List包含的所有元素的子结点AST。

熟悉Elixir元编程的人看到这个定义会觉得很熟悉，因为AST在Elixir中的定义也是如此。

Macro的输入和输出都是AST，在编译过程中，每一个对Macro的调用，都是使用参数的对应的AST来调用Macro的实现函数。举例说明，比如对于Macro定义

(defmacro unless [test &rest body]
  """Evaluates test. If logical false, evaluates body in an implicit do."""
  `(case (core.true? ~test)
     (^true ^ok)
     (^false ~@body)))

有调用代码如下

(unless (f 1)
  (g 2)
  (h 3))

那么在Macro展开的时候会得到调用如下，以对应Erlang代码来描述：

unless(AST{(f 1)}, [AST{(g 2)}, AST{(h 3)}])

其中AST{X}表示Lisp表达式X(也就是在Lisp代码里面看到的形式)对应的AST，每个AST展开都是上面所述的Tuple结构，为方便描述这里使用了简单表示。Macro展开的过程，即是输入的AST流经过unless函数，对应的参数经过变换之后得到输出如下:

AST{(case (core.true? (f 1))
      (^true ^ok)
      (^false (g 2) (h 3)))}

整个输出是一个完整的case表达式的AST，检查case表达式和unless Macro的定义，我们可知AST{(f 1)}插入到了指定的条件判断参数处，而[AST{(g 2)}, AST{(h 3)}]中的元素被取出放入了false分支。

在Kapok编译的最后阶段，这种内部AST会转换成Erlang Abstract Form，最后把它用Erlang Compiler编译并加载到Erlang VM。这部分的转换的逻辑相当于繁琐，篇幅所限就不再一一展开。

Macro编译，展开 #

普通函数一般是在运行时执行的，Macro与之不同，它在编译时执行。要在编译时调用一个Macro，这个Macro的定义必须已知，并且经过编译，才可能被调用。在Erlang里面，模块(Module)即是代码的基本组织单元，也是编译的基本单元，虽然也可以对单个表达式进行编译。已有的几种基于Erlang VM的语言，如Elixir, LFE，都采用了将他们的代码模块翻译到Erlang模块然后按模块编译的方式。按模块编译对于Macro的编译和展开会产生一个编译顺序的问题，举例来说在Elixir里面，你需要先声明一个模块m1，在里面编写宏mac的定义，然后声明另外一个模块m2，在m2里面的代码，假设是函数f，调用mac，编译的时候会先编译m1，使得mac的定义被编译过，然后编译m2，编译m2时在mac被调用的地方执行它。你不能把f和mac都写在同一个模块，否则在这个模块被编译的时候，mac就不能被执行。在Kapok中，我沿用了Joxa的一个技巧，f和mac可以写到同一个模块，但是mac必须放在f之前，在编译时，如果发现f中的代码调用了一个当前模块的Macro，那么就将f之前的代码当成一个完整的模块，以一个随机生成的模块名，送到Erlang Compiler编译，编译后就可以调用其中的mac。

每次调用一个Macro，都会将调用时的参数AST传入，得到结果AST，再插入到原来调用处，这样称之为一次展开。在Lisp中，Macro的展开是递归的，即是说如果展开mac之后，得到的代码若还有其它的Macro，比如unless，还会进一步展开，直至所有Macro都全部展开为止。

一个完整的例子 #

最后，以一个完整的例子来说明整个Kapok编译过程，包括上面提到的函数翻译，Macro的编译和展开等，以帮助理解。用一个简单的Kapok函数定义为例

(defn g [n]
  (io.format "call g(n = ~p)~n", [n]))

这段代码经过词法分析，语法分析阶段后，会生成AST如下：

{list,[{line,4},{column,1}],
      [{identifier,[{line,4},{column,2}],defn},
       {identifier,[{line,4},{column,7}],g},
       {literal_list,[{line,4},{column,9}],
                     [{identifier,[{line,4},{column,10}],n}]},
       {list,[{line,5},{column,3}],
             [{dot,[{line,5},{column,6}],{io,format}},
              {binary_string,[{line,5},{column,14}],<<"call g(n = ~p)~n">>},
              {literal_list,[{line,5},{column,34}],
                            [{identifier,[{line,5},{column,35}],n}]}]}]}

其结构比较简明，从中可以识别出标识符defn, g, n及list等结构。这个AST由于没有任何Macro调用，经过Macro Expand阶段没有任何变化，然后会转换成Erlang Abstract Form如下：

{function,0,g,1,
 [{clause,4,
   [{var,4,n}],
   [],
   [{call,5,
     {remote,5,{atom,0,io},{atom,0,format}},
     [{bin,0,[{bin_element,0,{string,0,"call g(n = ~p)~n"},default,default}]},
      {cons,0,{var,5,n},{nil,0}}]}]}]}

这段中间代码同样比较简单，容易看到函数g只带一个参数n，在它唯一的一个子句里面调用了一个io.format函数。

我们可以加上前面提到的Macro，并且添加一个调用Macro的代码，如下：

(defmacro unless [test &rest body]
  """Evaluates test. If logical false, evaluates body in an implicit do."""
  (io.format "call unless macro~n")
  `(case (core.true? ~test)
     (^true ^ok)
     (^false
      (io.format "before exprs in body!~n")
      ~@body)))

(defn f [n]
  (g n)
  (unless (== n 0)
    (io.format "1. n: ~p~n" [n])
    (io.format "2. hello macro~n")))

f的定义在经过词法与语法分析阶段后得到AST

{list,[{line,16},{column,1}],
      [{identifier,[{line,16},{column,2}],defn},
       {identifier,[{line,16},{column,7}],f},
       {literal_list,[{line,16},{column,9}],
                     [{identifier,[{line,16},{column,10}],n}]},
       {list,[{line,17},{column,3}],
             [{identifier,[{line,17},{column,4}],g},
              {identifier,[{line,17},{column,6}],n}]},
       {list,[{line,18},{column,3}],
             [{identifier,[{line,18},{column,4}],unless},
              {list,[{line,18},{column,11}],
                    [{identifier,[{line,18},{column,12}],'=='},
                     {identifier,[{line,18},{column,15}],n},
                     {number,[{line,18},{column,17}],0}]},
              {list,[{line,19},{column,5}],
                    [{dot,[{line,19},{column,8}],{io,format}},
                     {binary_string,[{line,19},{column,16}],<<"1. n: ~p~n">>},
                     {literal_list,[{line,19},{column,29}],
                                   [{identifier,[{line,19},{column,30}],n}]}]},
              {list,[{line,20},{column,5}],
                    [{dot,[{line,20},{column,8}],{io,format}},
                     {binary_string,[{line,20},{column,16}],
                                    <<"2. hello macro~n">>}]}]}]}

其中可以看到有{list, _, [{identifier, _, unless}, ...]}这样一个宏调用。因为这个宏是在同一个模块的前面定义的，Kapok编译器就将f之前的代码，包括g, unless的定义作为另一个模块编译完后，用f中调用unless的实际参数AST作为参数来调用unless。即unless被调用时得到的参数如下：

{list,[{line,18},{column,11}],
      [{identifier,[{line,18},{column,12}],'=='},
       {identifier,[{line,18},{column,15}],n},
       {number,[{line,18},{column,17}],0}]},
[{list,[{line,19},{column,5}],
       [{dot,[{line,19},{column,8}],{io,format}},
        {binary_string,[{line,19},{column,16}],<<"1. n: ~p~n">>},
        {literal_list,[{line,19},{column,29}],
                      [{identifier,[{line,19},{column,30}],n}]}]},
 {list,[{line,20},{column,5}],
       [{dot,[{line,20},{column,8}],{io,format}},
        {binary_string,[{line,20},{column,16}],<<"2. hello macro~n">>}]}]

其中第一个参数是一个list AST，第二个参数是一个List，它的元素也是两个AST。这一串AST流经unless函数之后，经过转换返回的结果是

{list,
   [{line,10},{column,4}],
   [{identifier,[{line,10},{column,5}],'case'},
    {list,
        [{line,10},{column,10}],
        [{dot,[{line,10},{column,15}],{core,'true?'}},
         {list,
             [{line,18},{column,11}],
             [{identifier,[{line,18},{column,12}],'=='},
              {identifier,[{line,18},{column,15}],n},
              {number,[{line,18},{column,17}],0}]}]},
    {list,
        [{line,11},{column,6}],
        [{atom,[{line,11},{column,7}],true},
         {atom,[{line,11},{column,12}],ok}]},
    {list,
        [{line,12},{column,6}],
        [{atom,[{line,12},{column,7}],false},
         {list,
             [{line,13},{column,7}],
             [{dot,[{line,13},{column,10}],{io,format}},
              {binary_string,
                  [{line,13},{column,18}],
                  <<"before exprs in body!~n">>}]},
         {list,
             [{line,19},{column,5}],
             [{dot,[{line,19},{column,8}],{io,format}},
              {binary_string,[{line,19},{column,16}],<<"1. n: ~p~n">>},
              {literal_list,
                  [{line,19},{column,29}],
                  [{identifier,[{line,19},{column,30}],n}]}]},
         {list,
             [{line,20},{column,5}],
             [{dot,[{line,20},{column,8}],{io,format}},
              {binary_string,
                  [{line,20},{column,16}],
                  <<"2. hello macro~n">>}]}]}]}

从中可以看到输入的AST参数已经被转换插入到指定的地方，这个unless返回的AST也将被插入到f中unless被调用的地方，从而达到修改/变换代码的效果。由于篇幅所限，f以及整个模块最后生成的Erlang Abstract code就不一一展示了。最后贴出整个示例的完整模块Kapok代码如下：

(ns x
  (require io))

(defn g [n]
  (io.format "call g(n = ~p)~n", [n]))

(defmacro unless [test &rest body]
  """Evaluates test. If logical false, evaluates body in an implicit do."""
  (io.format "call unless macro~n")
  `(case (core.true? ~test)
     (^true ^ok)
     (^false
      (io.format "before exprs in body!~n")
      ~@body)))

(defn f [n]
  (g n)
  (unless (== n 0)
    (io.format "1. n: ~p~n" [n])
    (io.format "2. hello macro~n")))

(defn main []
  (f 0)
  (f 1))

假定这份代码在文件x.kpk中，编译安装kapok之后(具体的编译安装过程可以参考Kapok文档，不再详述)使用命令

$ kapok x.kpk

即完成编译x模块，并运行其中的main函数。可得到结果输出

call unless macro
call g(n = 0)
call g(n = 1)
before exprs in body!
1. n: 1
2. hello macro

在代码里，main函数调用了2次f，f又调用了g，于是有2行call g(...的输出。然而由于unless是在编译时被调用的，只在f的定义里被调用了一次，所以只能看到1行"call unless macro"的输出，而且unless展开时输出的这一行在最前面，因为它是在编译阶段执行的，而所有其它io.format都是在运行阶段执行的。最后我们来看一下最后三行输出，“before exprs …“一行是在Macro里面定义的，“1. …”, “2. …“这两行则是在调用unless时的输入参数，它们按指定的顺序被组合到同一个case分支中。

念念不忘，亦有回响

Wed, 08 Jun 2016 00:00:00 +0800

多年以前，当我在Linux下选择Emacs做为编辑器的时候，似乎只是一个比较随机的选择。当时我已经接触并使用VI有一段日子，然而我使用它的体验并不算愉快，也许是我被VI命令模式和编辑模式搞乱了太多次，于是想找个其它编辑器试试，而当时我所知道的Linux终端字符界面编辑器并不多，Emacs是其中一个，然后我就开始使用Emacs，从此一发不可收拾，走上了一条不断修炼的漫漫长路。这段经历后来浓缩成了《Emacs修炼之道》这篇文章。Emacs不仅给我提供了一个舒适高效的编辑器工具与环境，也引领我走入了Lisp语言的世界。

Lisp语言诞生自几十年前，这几十年间世事沧桑，一个又一个浪潮在计算机行业冒升又落下，一门又一门新的编程语言流行而又衰落，Lisp语言早已退出流行的行列，然而却始终吸引着一小群程序员前仆后继地不断进入它的世界。除了传统的几种Lisp方言，2007年出现的Clojure将Lisp在JVM平台重新做了一个现代的实现，也掀起了一波新的潮流，吸引了很多人的关注和使用。几十年前诞生的编程语言，大多早已消失在历史的长河中了，为什么Lisp能够保持长期的生命力呢？正如看待黑客文化时有人主要关注它的政治正确，有人则将它看成是嗡嗡作响的经济引擎，不同的人对Lisp优点的看法也大不相同。有人喜欢Lisp以List作为唯一代码组织方式的简单明了，有人欣赏Lisp由核心几个特殊Form支撑起来的体系，对应着数学领域里面的公理上搭建大厦的体系结构，有人则更实利化只关注可以帮助提高开发效率的那些方面。在我看来，Lisp最吸引我的一点就是强大的元编程能力，非常便于编写DSL。当然这并不是说其它方面不重要，如交互式编程，强调函数式风格但又不强制函数式为唯一风格等特点也是可圈可点。

Lisp的思想和设计是如此优秀，然而传统的几种方言的实现Scheme，Common Lisp还有另外几个方言都没能紧跟这个时代的步伐，Clojure的作者Rich Hickey必定是深知这点，才会创造了Clojure。感谢Rich，我们得以知道在某个语言的成熟VM上实现一个现代Lisp的可行性，也欣赏到了Clojure设计与哲学的种种优雅美丽之处。Clojure设计于运行在JVM之上，固然是它的成功关键，因为如此一来就可以重用成熟的JVM环境以及丰富的代码库，同时Java程序员这个群体也非常庞大，能吸引到的Clojure使用者也多。另一方面也产生了一些缺点，因为底层的JVM原本是为Java设计实现的，而Java的并发模型还停留在操作系统进程/线程和锁这一种方式，因此Clojure除了保留Java的并发原语之外，还在并发上做了多种尝试，像软事务内存，几种不同的原语delay, future, promise，还有几种不同的引用类型。如此多的新概念和原语不可谓不丰富，同时也是繁多复杂。每当我的脑细胞因为折腾可变与不变或者write skew而被烧死一部分的时候，我总是怀念Erlang Actor并发模型的简单。

既然要顺适多核化的趋势，就需要语言本身的并发机制支持用户态进程/协程。那么为什么不直接使用Erlang呢？虽然Erlang并不是Lisp，但Erlang的设计也受到Lisp的影响，很多地方都有Lisp的影子，比如交互shell，热更新等。然而我对Erlang也有觉得不满意的地方，除了经常被, ; .几个符号搞晕之外，最大的不满是来自于在Erlang里做元编程的不便，但是Erlang代码又有很强烈的元编程需求，比如OTP里面的大片模板代码。因此在编写Erlang代码的时候，我又相当怀念Lisp的Macro。

那么，能否把Erlang和Lisp两者的优点结合起来呢，就像在JVM上实现Clojure一样，也许可以在Erlang VM上实现一门Lisp语言？到我的脑海中冒出这个想法的时候，距离我最早接触Erlang已经有三年多时间，距离学习Clojure已经有两年，另外当时在工作上我也写了大半年的Golang，是的，近几年中我学习/使用过的编程语言也不少，基本上每年都会学一到两门新语言，虽然不是每个新学语言都有机会用来写大量的代码，但也算是见识了不少编程语言，也许是对很多好的语言有着更高的期望吧，没有哪种已知的编程语言令我觉得非常满意。带着把Erlang和Lisp结合的想法，我发现原来Erlang VM就像Java VM，VM之上也有中间语言层，可以基于这中间层来实现一门Lisp，而且，早在几年前，就已经有人这样做了。我发现了Robert Virding写的LFE，和Eric Merritt写的Joxa。

作为参与设计Erlang的元老，Robert一直以来也是探索Erlang应用方面的先行者，早在2007年就写了LFE，并且影响了一众后来基于Erlang VM的新语言，如Elixir。LFE是Lisp Flavored Erlang的缩写，顾名思义，LFE就是把Erlang写成Lisp，除了多了一些括号之外(去掉了Erlang原来的分隔符如, ; .等)跟Erlang十分相似，LFE的设计目标在于提供一个可扩展语法的Erlang，它的实现也达到这个目标。然后跟我理想中的Lisp语言相去有一定距离，我并不喜欢它的Lisp-2风格，跟Erlang相似的模块设计如显式的export，只在编译时可用的Macro等方面。

另外一个实现Joxa则是由Eric在2011年开始写的，Eric也是Erlang界的老前辈了，他先是试用过LFE，然后觉得并不如意才重新设计和实现了Joxa，之前我写过的文章《Joxa: 一种基于Erlang VM的现代Lisp编程语言》详细描述了两者的渊源和差别，这里就不再展开了。总的来说，Joxa的Lisp味相对更浓一些，更符合我的个人口味。在过去的一年多时间里，我仔细阅读了Joxa的实现并添加了Erlang R17后引入的Map的语法。Joxa虽好，但有两个主要原因让我不得不考虑重新做一个实现：

Joxa目前的实现是用自举的方式将Lisp代码经过编译转换成Core Erlang，自举是很cool的一种实现编译器的方式，然而用在语法不够稳定的场景下，会提高后续语言开发的复杂度和难度。Core Erlang也是一个规模小巧设计良好的中间层，然而文档方面相当缺乏，很多时候必需花大量时间人手去获取从上层到它的翻译细节。相对来说更上层的Abstract Format虽然规模更大，然而文档较多，一些工具也只工作在这一层，所以更适合用于做为编译器的目标语言。在这一点上我和Eric讨论得出的一致结论是，要将Joxa用Erlang重写并将目标输出定位到Abstract Format，却因为彼此都忙暂时未有足够精力将其重写。
Joxa的设计目标强调它要小而简，希望成为一个小的核心语言，如果其他人有需要就在其上定制扩展。这种设计也是Lisp语言的一种传统特色，由于扩展性强，可以做到核心小扩展大，类似的思想也被人在不同的语言和项目上实现，比如PyPy和Python 3。然而我更希望有一套功能较多较全的编程语言，因此需要在语法和代码规模上都需要添加(或者改动，但主要是添加)很多内容，这就与Joxa的目标有冲突。据我所知Eric对Joxa有明确的定位，应该不会乐意在Joxa里面接受这些添加或改变，因此最好我还是用一个新项目名字来重写一个基于Erlang VM的Lisp实现。

一直以来我有个朦胧的想法，希望在下一个我能够自己决定命名的项目，能够用上一个带有我居住所在地中国华南地区的风物，或者带有东南亚色彩的名字，在给这个新项目取名时，老家旧居楼房前面的两棵高大的木棉树出现在我的脑海，那是一种在南方非常常见非常普通的树，平时不会特别觉察到它们的存在，然而有时觉察到它们的存在却又不禁觉得特别，像鲁迅笔下所说：“在我的后园，可以看见墙外有两株树，一株是枣树，还有一株也是枣树”。于是就将这个新项目的名字取为木棉，英文是Kapok。

我想，Kapok这个新的基于Erlang VM上的Lisp实现会包含如下这些内容：

一套类似Clojure风格的现代Lisp语法(Lisp-1)，当然在语法上并不能无脑照抄Clojure，比如方括号[]在Clojure中表示Vector，在Erlang却是List，那么Kapok里如何选择？若语义跟随前者，是用Erlang的tuple来实现Vector语义还是另外再做一套实现？若语义跟随后者，和普通圆括号()又如何区分，各自的使用场景如何确定？每处细节都需要仔细考量，这些细节也会影响其它方面，如下面将提到的兼容性。另外Clojure语法糖较多，而我不喜欢太甜。
与Erlang VM保持最大的兼容，在Erlang VM上实现的多种语言，都选择了将语法及语义尽量向Erlang靠拢，比如新语言的函数直接编译成Erlang的函数，如此得以保持良好的兼容性，新语言的代码可以直接与Erlang VM基础设施与已有库代码进行相互调用，不像Clojure那样需要通过中间包装。Erlang是一门函数式语言，这意味着新语言最好也保持这种函数式的语义，当然也可以通过上层逻辑修改这种限制，比如另一门基于Erlang VM的语言Elixir通过在编译器做变量名映射的技巧使得在Elixir里同一个变量可以做多次绑定，如此一来Elixir在变量使用上更像命令式语言。基于两个原因我个人更偏向于在Kapok里面完全保留Erlang的函数式语义，一是它利于并发，二是它语义更清晰。
新的语言机制，目前已经在考虑中的有：支持Clojure的Protocol(运行时类型分派，让语言更动态)，探索一套带类型标注的DSL来做强类型编程(强制编译时类型检查，让语言更静态)，Lazy API。其中第Protocal和Lazy API源自Clojure(当然Clojure也借鉴了其它语言)，并且已经在Elixir中得到实现。同时我对其它新想法持开放的态度。
功能丰富接口现代的标准库，包括常用宏，文件，网络等方面，特别一提的是Erlang原生用字符列表来表示字符串并不理想，因此需要有一整套高效易用的unicode字符串标准库，在LFE和Elixir中都重新定义了binary string，这是一个比较好的方案，可以借鉴。
强大且现代的开发工具集，包括：文档及Apropos接口/工具，编辑器集成(如Emacs mode), 项目管理工具(参考Mix)，交互性开发环境(集成Slime和Swank)等

上面的几点综合了Clojure, Erlang, Joxa, LFE, Elixir, Emacs等多种语言或机制，希望可以取多家之长，提供一套强大完整的开发环境。当然也可以说是一个大杂烩，然而不是无脑照搬，库和工具集可以丰富多样，然而基础语法需要保持简约节制，避免出现C++或Scala那样过于烧脑的设计。同时也要了解到上面几点内容只是一个初步的想法，后面可能会根据实际情况有所添加或改变。我一直有个用一门新编程语言编写一个开源数据库的朦胧想法，Kapok完善到一定程度之后，也许可以用Kapok来完成我这个想法。

有了简要设计，就可以开工编写代码了，首先要实现的是1, 2两点，亦即核心编译器部分。要写Kapok的想法早在去年就已经产生，然而一直拖拖拉拉未能动手。去年年中祖母去世，让我明白到时间匆匆人生太短，有些事情想做就抓紧时间去做，迟早人生的终点只是青山上的一把黄土。于是开始动手，由于平时上下班剩余时间不多，生活琐事缠身，进展较为缓慢，拖拉了几个月逐渐完成了编译器前端，大概到今年初开始写后端，也算是慢慢重温了一遍大学时开的编译课程。最近有了一些时间，终于折腾到可以跑起来的程度。我想Kapok这个项目不可谓不大，终究不能短期内完成，要做到非常完善的程度，更是有待时日。就像长跑，并非重在一时之快慢，积跬步恒坚持，方能走得更久更远。我所需要做的，就是调整呼吸，跨开步子。

于是就把Kapok开源了，github地址在这里，虽然暂时还有很多问题和缺点，也有很多想法未能实现，但我想这也算是一个不错的长跑起步。

十年之前，当我第一次安装并启动Emacs的时候，决没有料到会十年之后它带领我在Lisp的世界走了这么远。几年之前在接触Erlang，Clojure的时候，没有想到有一天会用Erlang重写一门Clojure风格的Lisp语言。一年之前开始着手Kapok的时候，我也不知道这个项目要做到何时，做到什么程度。然后事情冥冥中就这样发生了，而我将沿着这条路继续向前走。王家卫电影《一代宗师》里面，宫先生说“念念不忘，必有回响”，行知做人跟练武一样，秉着意念坚持下去，终究能有一点回响。

Joxa: 一种基于 Erlang VM 的现代 Lisp 编程语言

Thu, 20 Aug 2015 20:34:00 +0800

Joxa是一种基于Erlang VM的现代Lisp编程语言，创始人是美国的Eric Merritt[1]。通过在Erlang VM上引入一个精心设计的Lisp语法，它保留了Lisp和Erlang两者的众多优点：简洁而且语义清晰的Lisp语法，强大的Macro，鼓励交互式开发，支持高并发，函数式风格等，并且与现有的Erlang平台保持良好兼容。它是一门功能全面的通用编程语言。

Joxa的官方网站是joxa.org，在这个官方网站上，有它的源代码github地址，以及在线文档。为什么这门编程语言取名为Joxa呢？关于Joxa这个名字的由来，Eric Merritt曾经对我在邮件组的提问做过如下解释：

其实这个名字并无特别的意义。很多年前我想开始一个“基于Java的某个项目”，于是有了它的缩写Joxa这个名字。这个项目从来没有开始做过，但我把域名买下来了并一直持有着。到今天，4个字母的域名已经很少能注册到了，所以我决定用它来做为这门语言的名字。[2]

除了名字开头有个字母"J"，Joxa与Java并没有太大的关系了，Joxa主要受到了Erlang及基于JVM的编程语言Clojure的影响。下面我们先介绍一下Erlang和Clojure，再讨论Joxa受到了它们的哪些影响。

1. Erlang, Clojure以及Joxa #

1.1 Erlang，高并发的函数式容错编程语言 #

Erlang是一门通用的并发程序设计语言，它由瑞典爱立信的Joe Armstrong在上世纪80年代开发，并于1998年对外开源，Erlang这个名字来源自丹麦数学家及统计学家Agner Krarup Erlang。经过近30年的发展，Erlang目前是支持高并发的编程语言翘楚之一，它在语言层面封装了Actor模型，实现了用户空间的轻量级进程，将消息传递作为Actor间通信的唯一方式，避免了由传统的线程和锁在并发方面的限制与缺点。Erlang被设计为电信级系统的编程语言，强调分布式，容错，软实时和公平调度，在语法上它主要受到Prolog及Lisp的影响，保留了函数式，动态，交互式开发等特点。具体来讲，Erlang这个名字可以分成3个方面的要素：

编程语言Erlang本身
总称为OTP的一系列程序设计原则及代码库
称为Erlang VM或BEAM的Erlang虚拟机

Erlang设计于近30年前，因此从现在的角度来看，它在语法，编程环境(包括文档等)及工具链等方面有很多地方都有改进空间。由于Erlang VM是目前工业界支持高并发的最成熟的VM之一，大量技术专家及工程师们在上面投入了无数的工作，通过在Erlang VM上设计一门新语言来重用Erlang VM的优良特性，既能发挥Erlang VM的长处，又能改善Erlang语言本身在语法、工具链等方面的缺点，扬长而避短，是比较完美的方案。业界近几年涌现了众多基于Erlang VM的编程语言，下面介绍其中几种：

LFE
LFE是Lisp Flavored Erlang的缩写，它是由Robert Virding[3]于2007年开始开发的一门函数式的并发的通用编程语言，LFE采用了Lisp-2[4]风格的语法，通过将LFE代码编译为Core Erlang代码运行在BEAM上，保留了Erlang VM分布式，容错，软实时等优点，同时支持Lisp Macro，使得LFE兼有强大的元编程能力，并实现了一个功能丰富的REPL[5]。
Reia
Reia是一门基于Erlang VM上的类似Ruby的脚本编程语言，它由Tony Arcieri[6]于2010年中开始开发，它在Erlang VM的分布式，并发，容错，热更新的基础之上，引入了Ruby的友好语法，灵活的代码块，反射及元编程功能力。遗憾的是，Reia在2011年宣布不再更新。
Elixir
Elixir是一门动态的函数式编程语言，它由José Valim[7]于2012年开发。Elixir同样采用了类Ruby的语法，通过支持强大的Macro功能，它在简洁的语言核心上，建立了一系列的标准库，包括Unicode字符串及相关操作，重写了单元测试框架，丰富的数据类型等，它吸收了Clojure的Protocol，严格和惰性API，还提供了现代的交互命令行，脚本相关的库函数及项目管理工具。通过将Elixir代码编译为Erlang AST，Elixir得以重用Erlang VM的高并发及高效率，克服了Ruby在并发方面的缺陷。由于得到Jose及其它Ruby界牛人的喜爱及宣传[8]，Elixir在近两年开始流行起来。

由于本文主要是讲Joxa，上述这几种编程语言只是简单带过，就不详细展开了。

上面几种编程语言的设计方案虽然有很多不同之处，但从整体思路上几乎是相同的，那就是：通过将代码编译成为Erlang VM上的代码，良好兼容Erlang VM，于是保留了上述3要素中的后两点，同时从头设计语言的语法，并在标准库，工具链等一些方面做补充完善。Joxa的设计也是类似，它选择了Lisp做为Erlang VM上的新语言，不过它走了一条和LFE不同的道路。Eric Merritt后来专门写了一个博客文章《Differences Between Joxa and LFE》来谈Joxa和LFE的不同之处，他说：

最主要和重要的区别在于这两门语言的目标。我认为Robert实现LFE的主要目标在于提供一个可变的语法可扩展的Erlang版本，如此一来人们就可以在需要时改变语言。同时我坚信Robert喜欢实现编程语言，他应该很享受实现LFE的过程。我当然也乐于实现Joxa，然而，当坐下来实现Joxa的时候我怀有一些非常特定的目标：

我需要一个用于开发DSL(Domain Specific Language，领域特定语言)的平台

我想要一个更具交互性和动态的开发环境。类似于Slime和Swank那种[9]

我希望充分利用所有已经存在的相当优秀的Lisp工具

上述每点都可以在Erlang里面解决。例如，我可以用Leex和Yecc[10]实现DSL，但我实现DSL的最好体验总是来自Lisp：使用Lisp函数和Macro来打造这些DSL。不过我使用Erlang有很长时间了，我不愿意放弃Erlang VM上面的优良功能来换成Lisp的种种优点。唯一的解决方法似乎只有使用一门基于Erlang VM之上的Lisp语言。

显而易见的首先选择是LFE，于是我花了几周时间深入研究这门语言和它的内部实现。最后我得到这个结论：它并没有满足我的需求。剩下的唯一退路就是我自己重新创造一门语言(同时也有一点怀疑自己不太明智)。

从整体来看，LFE更像一门披着Lisp外衣的Erlang，相当于给原来Erlang语法添加了括号和Macro，这与Eric Merritt理想中的Erlang VM上的Lisp语言相去甚远，于是他创造了Joxa，而Joxa的语法及风格受到Clojure的影响更大。为什么Clojure能受到Eric的如此青睐呢？它到底有什么出众之处呢？下面我们来了解一下。

1.2 Clojure，JVM上的函数式Lisp编程语言 #

Clojure是一门动态的强类型编程语言，作者是Rich Hickey。它寄居在JVM之上，设计成能够与JVM/Java良好互操作，既利用了JVM所提供的成熟高效的运行环境，也兼容众多流行的Java库与框架，同时它采用了Lisp语法和Macro，非常便于表达DSL，加上一套函数式的持久数据结构，并提供并发机制及惰性语义，使得简洁优雅语言成为函数式编程，并发编程的良好载体，同时重用了成熟流行的JVM平台，使得它便于在现有Java程序员中推广并流行，在这一点上区别于以往所有独立开发的函数式语言。此外它也吸收了Java中的面向对象思想和CLOS[11]，发展出Protocol及多重方法。另外，Clojure自带一系列丰富的标准库，定义了一套项目管理规范，并提供了优秀的项目工具及REPL，使得它在开发环境，交互式开发方面成为佼佼者。

Clojure设计成为Java的一个库包，Clojure代码会编译成JVM byte code，正因为它以一种非侵入性的方式运行在JVM之上，所以在函数式的语言层面，会有一些其它函数式语言不可能出现的“瑕疵”，例如函数没有尾递归优化。兼容JVM平台的已有代码，在重用/连接已有项目方面既是一种优势，但有时混合函数式与命令式代码也会产生实际冲突。在并发方面，语言提供的多种并发原语，delay, future, promise，agent，STM等虽然强大，但从语言整体来看比较复杂。Clojure的很多地方可以体会到作者有意保持简单与功能(复杂)的平衡，在设计上做了务实折衷的克制。与此相反，另外一个基于JVM的语言Scala在设计上就显得博爱放任，看到各个好的特性就收入到语言当中，宛如中国古代的皇帝举国征选妃嫔。

相比各种“主流”编程语言，Clojure至今仍是小众语言，虽然如此，它的推出仍然不可谓不成功，既培养了一个健康壮大的社区，也在市场上占有一定的流行度，产生了一批具有相当影响力的项目，如流式数据处理框架Storm等。Clojure成功地向人们展示了这几个可能性：

在JVM平台实现一个函数式，并发的动态编程语言
通过融合持久数据结构，Protocol等优异特性，复兴Lisp
如何语言设计上在功能、简单与务实之间取得折衷平衡并树立起自身的特色

正因为有些如此之多的优点，Clojure才对程序员们有着如此之大的吸引力。也难怪身为老Lisp爱好者的Eric Merritt在创造Joxa时会受到Clojure的较大的影响。下面我们来谈谈Joxa的设计。

1.3 Joxa, Erlang VM上的新Lisp编程语言 #

对照上述多种语言的实现，Joxa的设计主要有如下几个要点：

上层语言为Lisp，主要目标为用于写DSL(或者作为其它上层Lisp的元语言)，语言的核心部分要简洁
底层将Joxa代码编译成Erlang VM代码，将Joxa代码映射到Erlang上的对应语法结构，比如Joxa里面的函数即为Erlang函数
语言核心之外提供REPL，方便编译/执行脚本的命令行工具等

其中Lisp的语法可以参考简洁，优雅的Clojure，由于Erlang VM与JVM有着非常多的差异，正如Erlang语言与Java语言有着非常多的差异，所以可以预期的是，Joxa在语法上面不能完全保持与Clojure一致，同时这里面有一个目标用户的问题：Joxa更多的是为了Clojure程序员转向Erlang平台而设计，还是为了Erlang程序员转向Lisp而设计。若为前者，就尽量保留可能多的Clojure语法及规范，若为后者则将语法尽可能向Erlang靠拢比较理想。这时Joxa选择了后一种，即认为Joxa主要是解决Erlang现有的问题，所以从语法上来考虑，最后出来的结果很可能是一种Lisp与Erlang的独一无二的新结合。所有的Lisp语言从结构上来看，都具有一种类似数学的体系结构，包括以下几个部分：

一切表达式皆为List，List有两种，原子及函数调用。代码即数据(总结为同像性)
7个基本原语(又称之为特殊Form)加上可以操纵语言本身的Macro，两者作为核心，在此之上演化出整个语言

这就像数学体系，最核心的部分是几条基本原理，然后通过逻辑推导，演化出其它数学分支以构成整个体系，可以不断向外扩展。Joxa将会有同样的结构，核心部分将保持尽可能的简洁，只包括基本原语及Macro，极简的核心既节省开发成本，也给外延留下尽可能大的空间。此处的外延包括针对特定问题领域而言的DSL，也包括其它上层的Lisp语言，从本质上来说这两者本来就没有区别，只不过因为针对的范围有大有小所以说法不同。从语法设计上，Joxa会跟LFE有如下的不同：

Joxa会是Lisp-1，而LFE是Lisp-2
Joxa的语法会向Lisp靠拢，而LFE更像Erlang
Joxa中Macro求值语义与Lisp更为一致，而LFE的Macro求值语义与函数求值语言不同

为了保持与Erlang VM现有的平台等保持无缝兼容，以充分利用现有的Erlang VM的开发规范与代码库等，第2点是必需的。将Joxa建立在Erlang VM平台的生态环境之上，固然是因为作者对Erlang VM的熟悉与喜欢，客观上也可以充分发挥Erlang生态的优势。从上面的叙述也可以看到，众多Erlang VM上的非Erlang编程语言也采用了这种“无缝兼容”设计，虽然它们在实现层面会有一些不同之处。这一点同时确定了Joxa将会保留Erlang的一些语言特性，例如按文件划分的模块化，函数式风格，代码要求先通过编译等。

第3点与开发环境相关，REPL是各种Lisp方言已经是司空见惯了，Erlang在设计的时候也吸收了这个概念，但是实现得不如Lisp的REPL那么好用，比如强制输入为表达式(每行的后面必须输入".“号)，Record不能用等。Joxa的REPL会参考Clojure与Erlang的REPL，结合前者的完整性和后者的功能，在易用性给予特别的关注。同时针对编译、脚本化等开发流程中的各个阶段都提供编辑器、命令行工具等支持。

2. 设计与实现细节 #

下面我们来详细讨论Joxa的设计与实现。根据上述的设计要点，要将Joxa代码要编译成Erlang VM代码，必需先熟悉Erlang代码的编译过程，在此过程中找出合适的切入点。

2.1 Erlang编译过程 #

一个经典的编译过程可以分为如下图所示的多个阶段：

图1 经典编译过程的各阶段[12]

经典的编译过程可以分为词法分析，语法分析，语义分析，中间代码生成，中间代码优化，机器码生成等多个阶段。Erlang的代码编译过程跟经典的编译过程基本一致，也可以分成类似的多个阶段，各个阶段的输入输出如下图所示：

图2 Erlang编译过程各阶段的输入输出

其中Core Erlang为于Erlang代码与VM内部中间代码之间的一层，它是在1999年前后提出的一种BEAM(Erlang VM的最新实现)上的语言，它被设计为：

语法清晰简单，严格的更高阶函数式语言
尽可能规范化，以便相关代码遍历工具的开发
从Erlang代码向Core Erlang代码的翻译应该直白，从Core Erlang向VM内部实现中间代码的翻译也应该简单
有良好定义的文本表示形式，语法简单无歧义，便于人阅读，调试及测试

由于Core Erlang是清晰简单，有良好定义的文本语言，便于作为目标语言，而且Erlang的代码优化和错误检测大多都在Core Erlang层进行，如果我们要在Erlang VM打造新编程语言，那么将新语言的代码编译成Core Erlang(或AST)，将会是一个很好的解决方案。很多Erlang VM上的语言都选择了这种方案，比如LFE，但也有语言选择了编译成Erlang AST，比如Elixir，精通Elixir Macro的人对Erlang AST应该比较熟悉。相对于Core Erlang，Erlang AST更接近于Erlang本身，层次也更高。Core Erlang相关的功能定义在cerl.erl这个模块里面，包括对如模块、函数等各种Erlang语言结构的初始化、操纵等功能的一系列函数。

2.2 一个简单例子 #

下面举一个简单的Hello World程序作为例子[13]，让读者对Erlang AST与Core Erlang有一个感性认识。原始的Erlang代码如下：

-module(test).
-export([hello_world/0]).
hello_world() ->
    io:format("Hello World").

对应的Core Erlang代码如下所示：

module 'test' ['hello_world'/0]
    attributes []
'hello_world'/0 =
    fun () ->
        call 'io':'format'
            (“Hello World”)

对比两份代码，可以看到Core Erlang与Erlang之间的映射还是很直观的。将原始的Erlang代码编译为Erlang AST，可以得到：

[{attribute,1,module,test},
 {attribute,2,export,[{hello_world,0}]},
 {function,2,hello_world,0,
   [{clause,2,[],[],
     [{call,3,
       {remote,3,{atom,3,io},{atom,3,format}},
         [{string,3,"Hello World"}]}]}]}]

编译为Core Erlang AST即得到：

{c_module,[],
  {c_literal,[],test},
    [{c_var,[],{hello_world,0}}],
      [],
     [{ {c_var,[],{hello_world,0}},
       {c_fun,[2,{file,[]}],
         [],
         {c_call,[3,{file,[]}],
           {c_literal,[3,{file,[]}],io},
           {c_literal,[3,{file,[]}],format},
           [{c_literal,[3,{file,[]}],
              "Hello World"}]}}}]}

对比两者，容易看出Erlang AST更高层更抽象，Core Erlang AST更底层更规范。

2.3 编译器 #

下面我们继续来讨论Joxa的编译过程，由于Core Erlang(及AST)可以由Erlang编译器编译成最终的机器码，我们只需将Joxa代码编译成Core Erlang AST便可实现将Joxa编译成机器码整个编译过程，从编译领域的分类来看，目标生成的代码是Core Erlang AST，操纵Core Erlang AST可以直接调用cerl.erl的接口函数，因此编译器后端这一块相对是比较简单的，重点在于前端部分：即将Joxa代码编译成Core Erlang AST。由于Joxa是Lisp语法，Lisp代码以括号划分边界的代码树的方式来表示，本身就已经有良好的结构，所以前端部分也比较简单。区别于LFE或Elixir用Leex或Yecc来生成LALR[14]式Lexer与Parser，Joxa采用了手写PEG[15] Lexer和Parser的方式。PEG编译器的代码量较小，Joxa编译器是在Erlang PEG生成器Neotoma生成代码的基础上写成的。(本节涉及到很多编译领域的术语或技术，由于本文主要是介绍Joxa，篇幅所限故不会详细解释这些术语或技术，有兴趣的读者可以自行寻找相关的资料做进一步了解)

特别值得一提的是，Joxa的编译过程是自举的，即Joxa编译器本身是由Joxa代码编写的，这与LFE或Elixir的编译器用Erlang编写不同。Joxa的自举要求先有一份以Core Erlang AST格式存在的具有正常编译功能的代码，这部分代码在Joxa的Github代码库中，相对根目录的路径是src/ast(后面给出所有的代码路径都相对于根目录)。通过用Erlang编译器将这份AST代码编译成BEAM代码，然后就得到一个能直接在BEAM上执行的Joxa编译器，然后就可以运行此编译器，将编译器的Joxa源代码编译成Core Erlang AST格式。整个流程和依赖如下图所示：

图3 Joxa的自举及编译流程

由上图可以看到整个流程三个步骤是一个循环，要成功实现自举，必然要先实现其中的一个部分，在此基础上才能实现其中其它两个部分。在Joxa的编译器实现中，AST这部分先由作者Eric人手先写出基本的语法解析功能，然后再编写对应功能的编译器的Joxa代码，用AST编译出来可执行的编译器，去验证对应的Joxa代码，然后再按此流程不断添加更多的功能，错误一般出现在编译Joxa代码的时候，此时遇到的错误是由新添加的AST代码还是Joxa代码引起的，有时并不容易定位出来。虽然Core Erlang简单清晰，但手写Core Erlang AST是相当繁琐的，而且由于Joxa语法本身还在不断演变，从头开发一个这样的自举编译器，其难度可以猜想是比较大的。我曾经为Joxa添加过Map语法的支持，对此开发流程的复杂性有较深的体会。编程语言的自举也可以按另外一个思路来做：先用另外一门常见的语言，比如C语言来写编译器，然后当语言的语法发展到比较稳定成熟的时候，再使用这门语言的本身来实现自身的编译器，由于已经有了一个能够工作经过充分检验的C编译器，所以自举的实现就有了一个可靠的保障，大大降低其难度。

编译器这部分的Joxa代码的路径是src/joxa-cmp-*.jxa(其中*符号表示通配)。按照编译器前端和后端的分类法，下面我们讨论一下各主要文件的代码分布。PEG的词法分析部分需要构造一系列对应于词素(lexeme)的正则表达式，首先需要有正则表达式的元操作的函数定义，所谓“元操作”，用各种编程语言里面的正则表达式的术语来说，即是元字符，比如”*“符号用于“匹配0个或多个”。在PEG里面元操作是通过函数来表达的，这部分的代码在src/joxa-cmp-peg.jxa。词素，比如注释或数字，它们的定义放在src/joxa-cmp-lexer.jxa。src/joxa-cmp-parser.jxa则包含Parser的代码。编译器的主要逻辑放在src/joxa-compiler.jxa，它调用Parser来解析读入的字符流，成功解析之后调用make-forms函数递归遍历解析得到的语法树来生成Core Erlang AST，在编译过程中会执行对函数调用的合法性检查，Macro的递归展开等动作。后端的代码按语义的分类分成下述多个文件：

├── joxa-cmp-binary.jxa           # Binary
├── joxa-cmp-call.jxa             # 函数调用
├── joxa-cmp-case.jxa             # case语句
├── joxa-cmp-defs.jxa             # 函数、宏定义
├── joxa-cmp-expr.jxa             # 表达式
├── joxa-cmp-joxa-info.jxa        # 模块info
├── joxa-cmp-literal.jxa          # 常量，常量表达式
├── joxa-cmp-ns.jxa               # namespace
└── joxa-cmp-spec.jxa             # spec

以上即为Joxa编译器实现各部分代码的所在文件。整个编译器实现从代码量上来说并不大。

2.4 数据类型 #

与Elixir在Erlang数据类型的基础上添加了Range、正则表达式、Unicode字符串等新数据类型不同，Joxa支持的数据类型与Erlang保持一致，并没有添加新的数据类型，所有的数据类型包括如下几种[16]：

简单类型：不定长整数，浮点数，原子
系统类型：PID, Port, Reference
集合类型: Tuple, Record，Map, List, Binary

各种数据类型的字面量语法请参考Joxa的在线文档。值得一提的是，围绕Record的各种操作，Joxa在语法上做了包装，便于解耦Record的内部实现与接口，提高了可用性，Elixir在这个方面走得更远，引入了Clojure的Protocol。另外一个常用的集合类型set是通过Erlang库提供的，并没有赋予特别的语法。

2.5 特殊Form及标准库基础原语 #

Joxa里面的特殊Form及标准库中的基础原语包括以下几个:

let*, let
用于绑定变量，不同于Erlang中的绑定操作或Clojure的let操作，let*并不支持Pattern Matching或解构，Pattern Matching或解构需要通过case，标准库中的let是一个用let*和case实现的对应支持Pattern Matching的版本
case
整个Joxa语言中为数很少的一个支持Pattern Matching的原语之一，与Erlang里面在函数签名，变量匹配，case语句等各种语法结构都可以做Pattern Matching不同
receive
接收消息，但没有对应的send原语，这可以通过调用Erlang模块或OTP库接口实现，支持Pattern Matching
do
分组表达式成一块，类似于Lisp里面的progn
apply
以列表函数调用指定函数，类似于Lisp的apply
fn
构造匿名函数，类似于Erlang的fun，或Lisp的lambda
defn, defn+
定义模块内可见，模块外可见函数
defspec
用于定义前置声明
defmacro, defmacro+, quote, quasiquote, ~, ~@, gensym, macroexpand-1
Macro操作，下一节再展开讨论
use, require, as
namespace相关操作，源自于Clojure里面的对应物，要注意的是不同于Clojure默认会在所有namespace自动导入clojure.core，Joxa并不会自动导入joxa-core
try*, try
两者catch用于异常捕取，用法跟Erlang里面的对应物类似，两者的区别在于是否支持Pattern Matching，类似于let*和let

特殊常量，都以函数方式进行调用

  ($filename)       ;; 当前文件的文件名(连后缀)
  ($namespace)      ;; 当前的namespace
  ($line-number)    ;; 当前的行号
  ($function-name)  ;; 当前的函数名

其它如attr，when等原语就不一一列举了。

2.6 Macro #

作为Lisp类语言的杀手级特性，以及表达DSL的终极利器，一直以来Macro在Lisp类语言中都有着重要的地位。Joxa中的Macro原语与Common Lisp或Clojure等之前的Lisp语言保持了一致，详细列出如下：

defmacro     -- 定义模块内部Macro
defmacro+    -- 定义对模块外部可见Macro
quote        -- 抑制求值
quasiquote   -- 对应Common Lisp里面的back quote，或Clojure里面的syntax quote，部分求值
~            -- unquote，对符号后面元素进行求值
~@           -- unquote-splicing，对符号后面的List元素进行求值并展开到当前位置
gensym       -- 动态生成新变量，用于保证Macro健康(或称Macro卫生)

另外为方便调试，标准库中提供了macroexpand-1函数，用于单次展开Macro，这个函数也沿袭于传统的Lisp语言，但是并没有提供macroexpand(macroexpand-all)。

在Joxa里面使用Macro，跟之前的Lisp语言并没有什么不同，以一个标准库joxa-core模块里的代码为例：

(defmacro+ let (args &rest body)
  (let* (process-arg-body
        (fn (arg)
            (case arg
              ([r e]
               `(case ~e
                  (~r ~@body)))
              ((r . (e . rest))
               `(case ~e
                  (~r ~(process-arg-body rest))))
              (detail (erlang/error {:malformed-let-expression detail})))))
    (process-arg-body args)))

Joxa在语法上直接定义为Lisp风格，因此在Macro的定义及使用上面，与传统一脉相承并无修改。在这个Macro定义里面，除了Pattern Matching，以及递归调用process-arg-body之外，与传统Lisp语言并无不同，熟悉传统Lisp的人可以很快就读懂。对比的来看，在Elixir这样的非Lisp语言中引入Macro，由于上层语言的语法与AST并不一致，所以程序员必需记住/区分上层语言与AST两种环境，因此相对较为复杂，比如，在Elixir Macro的签名处Pattern Matching Erlang AST，就在以Elixir的语法编写的Macro定义中，暴露了底层的AST格式。这种复杂性虽然从设计上来说是必需的折衷，但在习惯了Lisp Macro的人看来可能不会太喜欢。Joxa作者Eric在2015年一次接受《This is not a Monad tutorial》的采访中就表示过不喜欢Elixir Macro的复杂性。

2.7 标准库概览 #

Joxa的标准库只包括少数几个基本函数以及对OTP的简单包装。详细列出如下：

joxa-core
基本操作: !=, lte, gte, and, or, +, -, incr, decr, if, when, unless, try, let, define
joxa-eunit
eunit相关函数封装
joxa-lists
list相关的功能函数： dolist, hd, tl, foldl, map, lists-binding, #, all, any
joxa-records
Record相关函数
joxa-shell
REPL函数的简单实现
joxa-otp, joxa-otp-gen-server, joxa-otp-supervisor, joxa-otp-application
Erlang OTP相关接口的封装函数

代码规模很小，跟Elixir的标准库相比差得很远。其功能比较简陋，称之为标准库也许太大，或者称之为帮助函数更加准确。由于Joxa可以直接调用Erlang代码，因此功能缺失之处可由其它Erlang库补充。

2.8 开发环境及工具链 #

目前Joxa只有一个名为joxa的命令行工具，用于编译Joxa源代码，启动REPL，这个工具的功能也比较简陋，跟Clojure的REPL还有很大的距离。源代码中有一个Emacs的Major Mode配置文件emacs/joxa-mode.el，可以在用Emacs开发Joxa时设置缩进，关键字高亮，键绑定等。上面提到的与Slime和Swank集成，则尚未开发。

2.9 项目状态 #

Joxa从2011年底开始开发，一直到2013年初都比较活跃，这之后代码提交量变得相当少，在当前这个时间点(2015年8月)回头看看提交日志，已经有一年多的时间没有任何更新。虽然还未完成原来的设计目标，wiki上面的计划也有很多开发要做，但是由于作者Eric工作上比较忙，而Joxa社区实在太弱小，除作者之外并没有其它的人员贡献过大量代码，因此短期之内似乎项目状态不会重新变得活跃。在Google Group上有Joxa的邮件组，在近一年多时间内也相当少人发言。在应用上，除了作者Eric将Joxa用于编写他的创业项目之外，目前市面上没有看到其它的应用[17]。综合来看，Joxa的项目状态是比较停滞的。

3. 总结 #

Joxa是一种基于Erlang VM的现代Lisp语言，有着简洁清晰的Lisp语法，支持强大的Macro，是在Erlang VM编写DSL的一个很好的载体，它无缝兼容Erlang VM平台，是一门功能全面的通用编程语言。它在语言设计及编译器实现方面质量优良，但目前完成度不高，工具链并不完整，市面上也少见应用。作为一门较新的基于Erlang VM的编程语言，它有待进一步的发展完善。

注：
[1] Eric Merritt是《Erlang and OTP in Action》(中文译本《Erlang/OTP并发编程实战》)一书的作者之一，Erlware项目联合创始人，Afiniate公司的CTO。
[2] 翻译自邮件原文
It doesn’t actually mean anything. Many years ago it was an acronym for some project I wanted to start ‘Java oriented something or other’. I never made that project but I bought the domain and have kept it these years. Four letter domains are pretty uncommon these days, so I just decided to use it as the name for the language. Thats all.
[3] 作为Erlang语言联合创始人以及Joe Armstrong的长期亲密战友，Robert Virding自从当年在爱立信计算机科学实验室开始，长期以来在Erlang的设计，标准库，编译器，发展推广等方方面面都做了杰出的贡献。
[4] Lisp-1和Lisp-2的区别在于函数与变量是否共用同一命名空间，一个详细的解释可以参考文章《What’s Lisp-1, What’s Lisp-2? Bad Jargon or Good Jargon?》
[5] REPL是Read-Eval-Print Loop的缩写，最早被用于指代开发Lisp程序过程中，交互式命令行不断执行读取程序员的输入代码，对其进行求值并打印出求值结果的循环动作。后来这个概念被Python，Ruby及各种交互式命令行工具吸收并推广开来。
[6] Tony Arcieri是一位美国的软件工程师，他的博客见这里。
[7] José Valim是一位波兰的软件工程师，他最被人熟知的两个身份是Ruby On Rails的核心成员以及Elixir编程语言的创始人。
[8] 比如Joe Armstrong于2013年中写了博客文章《A Week with Elixir》盛赞了Elixir“结合了Ruby和Erlang的优良特性”，Dave Thomas于2014年发布了新书《Programming Elixir》向有其它语言经验的程序员提供了一本系统的教程。
[9] 译者注：Slime是Superior Lisp Interaction Mode for Emacs的缩写，它为Emacs提供了一整套交互式开发Common Lisp的功能集，包括编译，调试，文档查找等等，Slime是客户端，Swank是对应的服务器端，它们共同组成了一个强大的程序开发环境。
[10] 译者注：Leex和Yecc是Erlang语言的Lex和Yacc工具集。
[11] CLOS是the Common Lisp Object System的缩写，是指在Common Lisp中实现面向对象机制的一系列代码库。
[12] 此图来自编译领域的经典著作《Compilers: Principles, Techniques, & Tools》第三版，中译本《编译原理》。
[13] 这个例子来自Eric Merritt 2012年8月在Chicago Erlang User Group上的技术分享《Joxa: A Full Featured Lisp on the Erlang VM》，录像视频见这里.
[14] LALR是LookAhead LR的缩写，LR中的L表示对输入进行从左到右的扫描，R表示反向构造出一个最右的推导序列。LALR是流行的自底向上语法分析方法。
[15] PEG是Packrat Expression Parsing的缩写，它是一种相对较新的自顶向下语法分析方法。
[16] 其中Map的语法支持由我添加，写此文时未进入主干分支。
[17] 从推广应用的角度来看，在2011年中开始开发的Elixir在各个基于Erlang VM的新编程语言上是走得最前的。

人体工学机械键盘 Ergodox

Thu, 01 Jan 2015 22:09:00 +0800

作为一个码农，我每天的工作主要就是敲打键盘，因为工作的特殊性，我平均每天面对电脑使用键盘鼠标至少达到10个小时，长期如此，我发现我的手腕时不时会出现无力、僵硬甚至酸痛的现象，这种感觉有时在夜晚睡觉时会特别明显，而右手又比左手要严重。后来经了解这是管腕综合症的症状，是由于长期敲击键盘和使用鼠标造成重复性的神经压迫受损引起的。要缓解这这种症状，除了平时注意多休息之外，我还特别了解过有没有什么工具对此有所帮助，然后发现其实我们最常用的传统键盘，在对手和肩的人体工学上并不是太科学。因为传统键盘是一个长方形的整体，它的键位分布也是各行平行，使用的时候就需要人弯曲手腕和肘弯来形成合适的角度，这种弯曲一旦长时间保持，就会造成手腕肩头等部位的习惯性疲劳甚至病症。如下图左边所示：

一个考虑到人体工学的键盘，设计上应该是左右两边从中间分开，让身体两侧的肘部和手腕，形成更舒适自然的角度，如上图的右边所示。很多的人体工学键盘都带有这样的设计，其中包括微软出品的几款薄膜键盘：停产的Natural Keyboard Elite和后继者Natural Ergonomic Keyboard 4000，较新的Sculpt Ergonomic Keyboard。

带人体工学设计的键盘还有较少见的Truly Ergonomic公司推出的True Ergonomic Keyboard，Kinesis的Advantage和FreeStyle 2等，而像Cherry的MX 5000这种早就停产的绝版产品已经难于在市场上觅到其踪影。

这些键盘左右两边都分叉开，有的可以自由调整分叉角度，有的则角度固定，左右两边都是连成一体的。这些键盘中有的全部键位都采用MX机械轴，有的则为薄膜键盘，薄膜键盘的一大缺点就是手感差，不像MX轴那样寿命长手感好。另外其中有的键盘键位与普通的差异比较大，由于不支持编程，无法自定义键位，用户必然需要一段较长的时间去适应它的独特键位。有没有一个键盘，既有人体工学的设计，也是全键位MX轴，甚至支持全键位编程，可以满足文字工作者对键盘在人体工学、手感和寿命各方面的要求呢？它就是Ergodox。

Ergodox简介 #

Ergodox是一个硬件开源项目，它的项目网站见这里。它主要有如下几个特点：

分体式设计
整个键盘分为左右两个相互独立的部分，左右两边相互对称，中间用线材连接用于通讯。除了常见的字母/数字键区之外，每边还有一个延伸的拇指区，和一些特殊的控制大键位。分体式设计使得用户在使用时可以将左右两边以任何角度或位置摆放，提供了很大的灵活性和舒适度。
直列错行键位
在传统键位中，键位的行是平行的，行与行之间，不同列是错开的，这种设计来源于最早的机械式打字机设计，因为每个键的连杆都要错开一定角度，同一个位置不能有两条连杆重合，否则就会造成冲突。如下图所示：

这种错列的设计从人手的角度来看并不科学，因为对于每一根手指，直上直下才是比较方便的，而且不同的手指长度不同，平行的行键位只是为了方便制造。后来计算机的键盘沿用了打字机这种错位的设计，但现代的键盘都是电信号触发的，连杆早已不复存在，这种平行错列的设计只是简单地追随传统。

Ergodox给出了一个更科学的设计：直列错行。每根手根负责一个直列，不同行即不同手指则按各指长度错开成一定距离。

全键位MX轴
全部键位都使用MX轴，其中每个键位可以自由搭配不同的轴，以供用户的个人定制。常见的MX轴定制方案有：基本键位一种轴，扩展(特殊)键位配另一种轴；或4指控制部分一种轴，拇指部分配另一种轴等。MX轴的使用既改善了手感也提升了寿命。
全键位可编程
全键位可编程，满足了高端用户定制键位映射的需要，虽然键映射可以在不同类型的操作系统中做软件映射来做(如Mac中有karabiner，Windows中有Auto Hotkey)。但是在硬件层面做，可定制的范围更广可玩性更强，同时可以做到换系统即插即用的效果，而且Ergodox支持多达30个layout，足以满足绝大多数的键位定制需求。

获得Ergodox #

由于Ergodox是硬件开源的，有兴趣的用户可以根据官网给出的配件列表自行收集配件组装，如果你和我一样，基于不方便购买配件或没时间等原因，不愿意一点一点的攒配件，也可以通过网络购买。目前主要有两种方式可以买到Ergodox：

1. Massdrop团购 #

Massdrop是美国的一个团购网站，上面主要集中了一批对音响、电子、机械键盘等方面的爱好者，围绕着相关产品用户可以参与团购，社区交流等活动。早在两年之前，Massdrop就开展了Ergodox的团购，在Massdrop的Ergodox主页上，有Ergodox的一个较详细介绍，包括它由哪些配件组成，可以选择不同颜色的MX轴体，半掌全掌两个不同的尺寸，DSA和DCS两种不同的键帽，不同颜色的阳极铝材质上面板，组装完成之后的成品图等等。由于Massdrop出售的只是Ergodox的零配件，并非组装好的键盘，因此它还提供了一个图文并茂的组装教程，另外有一个方便Ergodox用户做定制键位的键位编程配置网页。

有兴趣团购的用户可以点击网页右边的蓝色"Request"按钮，来申请团购。一般每过3个月左右，申请人数到达200个之后，Massdrop就会开放团购，通知之前申请过团购的人去提交订单，当然之前没申请过的人也可以马上下单，下单的时候用户可以定制尺寸，MX轴颜色等选项，最后通过信用卡扣款。在团购结束之后，Massdrop会向上游供应商提出订单生产或购货，越多人组团下单，优惠的尺度越大，一般来说组团的人每批都能达到200个以上，成本会降低到$199，当然这只是键盘本身的价格，如果加订键帽则需要加钱。

在Massdrop团购耗时会比较长，以我参加的2014年9月这一批次团购的经验来看，除了要等待团购开放这段时间，下单付款之后，大概要8~9周后才开始发货，然后快递走UPSMI(UPS Mail Innovations)到国内大概花了3周，以此估算从下单到收到邮件需要12周也就是3个月的时间。因为Massdrop上出售的是零件，Ergodox的亚克力材质外壳、PCB、一堆零件和轴等等装在一起也是比较大件的包裹，包裹通过海关时运气不好的话可能被征关税。UPSMI包裹在国内这段是由EMS负责运送的，EMS的送货服务非常高明：包裹运到本地邮局，EMS的工作人员就打电话给我，叫我在限时之内去领取包裹，所以它也不用考虑邮件地址写得是否准确——因为最准确的投递服务就是让用户自行跑过去领，不用投递。当然EMS的工作人员还是经验丰富的，他们在通知我领包裹的电话里就提醒我包裹已经被税，去领取邮件时记得带上钱付关税。

在2014年9月这一批次我订的配件如下：

配件	价格
Ergodox本身(包括PCB，电容电阻等零件，亚克力壳，轴体)	$199
亚克力壳(全掌)加钱	$10
DCS键帽	$49.99
银色铝质上面板	$39.99
运费	$24.99

全部配件总计298.98美刀，加上运费共323.97美刀，按当时汇率换成人民币是1995块。由于包裹上贴着的配件单写的是这批团购的键盘价格$199，海关收关税是按包裹所标总价的10％征收。我按EMS工作人员的指示交了122块人民币的关税，把包裹带回家对照票据后发现如果按真正的配件价格来收取关税的话，需要多交几十块人民币的关税，由于Massdrop寄件人员没有将全部配件写在包裹外面的工作失误，使得我个人在为国家的光荣税收方面少作了一些贡献，作为人民群众的我表示情绪稳定。

收到配件之后，下一步就是组装了，除了Massdrop上面的组装教程，另外在Youtube上面有一个名为Ergo-Dox keyboard assembly的组装视频，对于新手比较有参考价值。组装过程中需要把电容，MX轴等焊接到PCB上，这需要用到烙铁，由于我很久都没有做过焊接而且手上也没有烙铁，焊锡这些工具，所以花了大概200块人民币通过淘宝购买了一些工具，其中包括入门级的黄花907自动调温烙铁，无铅焊锡，吸锡器，斜口钳，镊子等工具，因为拿不准用哪种型号的烙铁头适合焊接Ergodox的配件，所以多要了几个不同型号的烙铁头，全部焊装完成之后发现其实型号为MT-3927的1.6D平头烙铁头适合用于几乎所有焊点，而型号为900M-T-B的烙铁自带尖头用得不多，只有少数几个焊点适合用上，比如Ergodox对外的USB接头处几个小焊点。其中镊子最好是弯头的，用于夹住每个键位下面的小电容，方便做SMT焊接。

参考上面给出的组装教程网页和视频，一般人都可以完成整个焊接过程，不过特别提醒一下，组装之前要细看每一个步骤所用到的配件和安装说明，注意安装的正反面和位置，如果漏掉一些关键信息可能会造成问题，比如我在焊PCB下面对应每个键位SMT电容时，没有注意看电容上面的极性，当整个键盘都组装完成之后，烧入固件连上电脑才发现有一半的键没有反应，然后出动了万用表检查，才发现有问题的键位SMT电容焊反了(电容上有标记的一端应该对应PCB方块焊头的一头，而不是圆焊点的一头)，只能拆下来重新焊上。

在整个焊接过程中，我个人认为刚才提到的SMT电容和对外的USB接头这两处是比较难焊接的，前者是因为电容很小，而且SMT容易虚焊，如果像Youtube视频那样用熔锡和热风枪来做是比较容易的，但用一般的烙铁操作起来比较繁琐，我用了一个土办法：先为一边点上热锡，用镊子夹住电容粘上去放好位置，再把另一边也点上热锡，最后轻轻按紧电容，两边焊点都用烙铁加热一下，以免虚焊。如此折腾下来，最后到整个键盘组装完成之后，没有发现有虚焊。第二个难点就是USB接头处，首先把Mini USB的接头裁切出来的时候要小心，尽量不要弄断各黑、白、绿、红各颜色接线里面的铜丝，焊接的时候各颜色的线头和PCB的连接处的位置保持好也很关键，Youtube视频中在焊实底面焊点之前，他在PCB上表面先点上一点焊锡以做固定，这办法比较有效。即使如此，由于这几个焊点小，线材小加上位置比较容易移动，而且焊接时间要控制好，一旦烙铁靠得太久线材就会开始熔掉，要焊好还是不太容易的。至于MX轴，由于对应的焊点比较粗，相对来说容易焊得多。像我没有太多焊接经验，组装好一整套Ergodox并确认功能正常(拆掉重装过SMT电容)大概需要花10多小时。

由于我个人不太喜欢灯(我觉得闪亮的键盘灯是一种打扰，Macbook上的键盘灯也从来不用)，而且手头的Ergodox键帽都是不透明的，在键轴上面加灯也看不见，所以我没有像标准安装教程所示的那样装灯。要注意的一点是，由于PCB在MX轴的下面，如果要装灯则需要先把MX轴的上盖拆下来，加上灯，再把MX轴焊到PCB上，上面给出的Youtube教程是先把MX轴焊到PCB，再用一个叫做beast switch tool的工具从上面打开MX的上盖加灯，这个switch tool很难买到[1]，所以一般还是要先拆开上盖再焊MX轴。

焊接完成之后，给teensy芯片烧入固件，就可以正常使用了，为了确认焊接没出问题，烧录完固件之后可以第一时间试试每个键确认功能都正常，再装上亚克力外壳和键帽。一般来说亚克力板是比较容易粘上灰尘和指纹的，上表面指纹容易擦掉但是每层亚克力板之间的灰尘如果长期累积下来，对于有洁癖的人来说可能会觉得影响观感，所以我组装的时候保留了亚克力板表面深棕色的薄纸没有撕掉，上表面装上特别订购的铝质面板，这样一来上表面不会留指纹，也看不见键盘里面的亚克力面板之间的灰尘，不过由于上表面是金属，冬天会冻手，和Macbook键盘前面的手托类似。

2. 淘宝网购 #

由上面我自己的经历可以知道，通过Massdrop团购Ergodox零件再自行组装的成本是相当高昂的，需要花掉团购成本、关税、焊接工具成本共2500块人民币左右的金钱成本，而且要付出很大的人力和时间成本：很长的团购和到货时间，取国际邮件、购买烙铁等工具的时间，还有10多个小时的组装人工和时间。除非自己动手能给你带来很大的乐趣，不然通过这种方法来搞一套Ergodox并非良策。其实Ergodox所用到的电容电阻，MX轴等零件都是市面上比较容易搞到的大路货，PCB和亚克力板也可以在深圳华强北找商家打印或通过淘宝定制，它的成本远远低于Massdrop这一条渠道。话说回来，通过Massdrop买到的零件也有一些国内生产的配件(比如TRRS线)，当你耗费时日不远万里从国外搞到一套Ergodox的配件，打开包裹一看发现很多"Made In China"的时候，我不知道你会有什么反应，反正我是对着关税的收据一轮苦笑。

有个朋友rabinz比较早接触到Ergodox，他原本打算在国内攒零配件来组Ergodox，由于零配件一般是成批卖的，所以后来他攒了很多的零配件，此后更是在原有的Ergodox的基础上做了一些设计方面的改进。他在淘宝上开了一个网店，以一个实惠的价格出售整套组装好的Ergodox，并向用户提供一些定制服务：比如各种轴的搭配，大键区卫星轴、平衡轴的选择等，对Ergodox有兴趣的话可以去那里看看。

我之前在网上多收了一副rabinz做的半掌Ergodox，下面简单的比较一下它和前面所讲的我自己组装的一套，看看两者有何区别。

整体

两套都是Ergodox，硬件键位自然是相同。前者是半掌尺寸带灰色DSA键帽，上表面是透明的亚克力板；后者是全掌尺寸带黑色DCS键帽，上表面是不透明银色的阳极氧化铝板。

接合

半掌Ergodox使用了两条小螺钉在中间通过内嵌螺母连接在一起，在上下两个表面都做了沉孔处理，本来尺寸就较小的螺钉头只比亚克力面板表面高出一点；全掌的一套则使用单条大螺钉和螺母，螺钉头比较粗，上表板也没有做沉孔处理，所以螺钉头明显高出上表面很多，螺母头为半圆球形，尺寸相当于两个螺钉头。全掌的几块亚克力板总厚度比半掌的要薄，但由于上下两面的螺钉头占用了比较多的空间，所以从整体高度上来看，全掌的反而显得略厚。

钢板
从上面几个图明显看到，半掌键盘中间有一块黑色的钢板，全掌的则没有，机械键盘是否带钢板会对手感有所影响，带钢板的话受力时刚性会较好，按键触底会更硬朗一些。
大键区

半掌键盘是青轴，两个大键使用了卫星轴，而全掌的则是白轴，大键区只是普通单轴。在常见的机械键盘产品中，一般大于2X宽度的键轴都会加上卫星轴或者平衡轴，避免键轴受力走偏，以改善大键的手感。要安装卫星轴或平衡轴的话，需要从PCB到中间面板都准备相应的孔位，但Massdrop出售的Ergodox无论是PCB还是中间面板都没有准备对应的孔位，因此只能装上单轴。

经过上面的比较，容易看出rabinz做的Ergodox加入了一些优化，跟Massdrop渠道的自组Ergodox相比占有相当的优势，即使只考虑金钱成本，Massdrop的也高出很多，所以综合来看，通过淘宝向rabinz购买组装好的Ergodox成品，是更好的选择。如果你只是个一般用户，希望拥有一把Ergodox但不愿意自己攒零件动手焊接组装，那么通过淘宝向rabinz订购更是绝佳的选择。

体验与总结 #

有了Ergodox，我在敲打键盘时两手就能以舒服的角度随意放在桌面上，使用了一段时间的Ergodox之后，我手腕的不适症状已经大为减轻，它的人体工学设计起到了很好的效果。在我逐渐上手Ergodox的过程中也遇到一些问题，比如需要一点时间适应它独特(但设计正确)的键位布局：刚刚开始使用Ergodox时，我对Ergodox的键位布局还不是太习惯，由于它的直列错行布局跟一般键盘的直行错列不同，盲打时只要一离开Home Row手指经常会打错列，经过一段时间的练习之后，基本上已经熟悉它的布局，现在无论是普通键盘还是Ergodox，一上手都能操作自如。另外目前市面上并没有适用于全掌Ergodox的包(半掌Ergodox的包倒是有，可以到这里购买)，全掌Ergodox个头大便携性不好，只能放在家里使用。

总体来看，Ergodox设计独特，成本不菲，对于像我一样想改善管腕综合症症状的电脑用户，Ergodox是一个很值得买的机械键盘，对于喜欢DIY喜欢折腾机械键盘的玩家，Ergodox也是一个具有很高可玩性的产品。

注：
[1] 有关beast switch tool在Ergodox组装过程中的使用方法可以参考这里，但它太难买到，你也可以参考这里用常见的文件夹自已DIY一个。

层次状态机

Tue, 04 Nov 2014 19:22:00 +0800

计算机程序是写给人看的，只是顺便能运行。
　　　　　　　　　　　　　　——《计算机程序的构造和解释》[1]

FSM #

在计算机领域，FSM(有限状态机)是一个在自动机理论和程序设计实践中很常见的术语，简单来说，有限状态机表示的是系统根不同输入/不同条件在各个状态之间进行跳转的模型。可以通过图或表来描述有限状态机，这种图或表一般被称为状态图/状态转移图(State Chart)或状态转移表。因为图更加直观，本文统一使用状态图来描述有限状态机。

在状态图里面，一般用圆圈或方框来表示状态，用箭头来表示状态之间的跳转，箭头可以带上跳转需要的输入或条件，也可以带附带其它描述。一个从空白处引出，没有源状态的箭头则表示整个系统的启动，启动后进入的第一个状态可以称为开始状态，可以用双重圆圈特别标出。整个状态图就是一个有圆圈，箭头及描述的有向图形。下面是一个简单例子。

上图表示一个接受二进制输入(输入为0或者1)，计算输入包含奇数还是偶数个0的状态机。其中S1状态表示"偶数个0"，S2表示"奇数个0"。系统启动后，沿着图中最左边的箭头进入S1状态，此时没有读入任何输入（0个0）。S1圆圈上方带1的箭头表示如果输入是1，则跳转到S1，即保持原状态不变。如果输入是0，则跳转到S2。其它箭头也可以类似理解。当全部输入都处理完之后，只需看当前状态是S1还是S2即可得出结论：输入具有奇数个0还是偶数个0。

由于状态机可以将问题整体的分解成各个部分状态及跳转，直观地对系统进行建模，所以它不仅被用于理论研究过程当中，而且被广泛用于程序设计实践，在操作系统，网络协议栈，各种分布式应用中都可以见到它的身影。

程序设计中的FSM #

由上面的表述我们得知，FSM是对系统的建模，是将问题/解决方案以一种条理化系统化的方式表达出来，映射到人的认知层面，而要在程序中表达FSM，也需要一定的建模工具，即用某种代码编写的方式(或称之为FSM模式)，将FSM以一种条理化系统化的方式映射到代码层面。在程序设计领域，到底有哪些常用的FSM实现方式呢？下面我们来做一个简单的回顾。

从简单到复杂，下面我们浏览一下常见的几种FSM实现模式[2]。

a. 嵌套if-else/switch模式 #

自从1960年第一个Lisp实现引入条件表达式以来，if-else/switch语句[3]已经成为每个程序员手头必备的工具，每当需要"根据不同条件进入不同分支"，就搬出它来组织代码，这与FSM里面"状态之间根据不同输入进行跳转"的概念有简单的对应关系，这就使得if-else/switch语句成为人们要表达FSM时最先选择的方式。

仍然以图1例子进行说明，我们用if-else/switch语句编写它的实现代码，用一个变量state表示当前状态，state可以取两个值S1, S2，输入input表示下一个输入的数字是0还是1，那么就有下列代码[4]:

type State int
type Input int

var (
	StateS1 State = 1 + iota
	StateS2 State
)

var (
	Zero Input = 0
	One  Input = 1
)

var state = StateS1

func NumberOfZero(i Input) {
	switch state {
	case StateS1:
		switch i {
		case Zero:
			state = StateS2
		case One:
		}
	case StateS2:
		switch i {
		case Zero:
			state = StateS1
		case One:
		}
	}
}

上面的代码有一个明显的嵌套形式的结构，最外层的switch语句是根据当前状态state变量进入不同的分支，内层switch针对的则是输入，所有代码像挂在衣柜中的衣服一样从上到下一一陈列，结构比较清晰。这种嵌套形式if-else/switch语句的FSM代码组织方式，我们将其称之为嵌套if-else/switch模式。由于这种模式实现起来比较直观简明，所以它最为常见。

嵌套if-else/switch具有形式嵌套，代码集中化的特点，它只适合用来表达状态个数少，或者状态间跳转逻辑比较简单的FSM。嵌套意味着缩进层次的叠加，一个像图1那么简单的实现就需要缩进4层，如果状态间的逻辑变得复杂，所需要的缩进不断叠加，代码在水平方向上会发生膨胀；集中化意味着如果状态个数增多，输入变复杂，代码从垂直方向上会发生指数级别的膨胀。即使通过简化空分支，抽取逻辑到命名函数[5]等方法来"压缩"水平/垂直方向上的代码行数，依然无法从根本上解决膨胀问题，代码膨胀后造成可读性和可写性的急剧下降，例如某个状态里面负责正确设置20个相关变量，而下翻了几屏代码之后，下面的某个状态又用到上面20个变量里面其中的5个，整个代码像一锅粥一样粘糊在一起，变得难于理解和维护。

a. 状态表 #

另一个比较流行的模式是状态表模式。状态表模式是指将所有的状态和跳转逻辑规划成一个表格来表达FSM。仍然以图1为例子，系统中有两个状态S1和S2，不算自跳转，S1和S2之间只有两个跳转，我们用不同行来表示不同的状态，用不同的列来表示不同的输入，那么整个状态图可以组织成一张表格：

State\Input	Zero	One
S1	DoSomething, S2	null
S2	DoSomething, S1	null

对应S1行, Zero列的"DoSomething, S2"表示当处于状态S1时，如果遇到输入为Zero，那么就执行动作DoSomething，然后跳转到状态S2。由于图1的例子状态图非常简单，DoSomething动作为空，这里将它特别的列出来只是为了说明在更一般化的情况下如果有其它逻辑可以放到这里来。根据这个状态表，我们可以写出下列代码：

type State int
type Input into

const (
	StateUndefined State = 0 + iota
	StateS1
	StateS2
)

var (
	Zero Input = 0
	One  Input = 1
)

type Action func(i Input)

func DoSomething1(_ Input) {
	// Do nothing here
}

func DoSomething2(_ Input) {
	// Do nothing here
}

type Item struct {
	Action    Action
	NextState State
}

var StateTable = [][]*Item{
	[]*Item{
		&Item{
			Action:    DoSomething1,
			NextState: StateS2,
		},
		nil,
	},
	[]*Item{
		&Item{
			Action:    DoSomething2,
			NextState: StateS1,
		},
		nil,
	},
}

var state = StateS1

func NumberOfZero(i Input) {
	item := StateTable[int(state)][int(i)]
	if item != nil {
		item.Action(i)
		if item.NextState != StateUndefined {
			state = item.NextState
		}
	}
}

从上述例子我们可以看到，用这种方式实现出来的代码跟画出来的状态表有一个直观的映射关系，它要求程序员将状态的划分和跳转逻辑细分到一定的合适大小的粒度，事件驱动的过程查找是对状态表的直接下标索引，性能也很高。状态表的大小是不同状态数量S和不同输入数量I的一个乘积 S * I，在常见的场景中，这张状态表可能十分大，占用大量的内存空间，然而中间包含的有效状态跳转项却相对少，也就是说状态表是一个稀疏的表。

c. 状态模式 #

在OOP的设计模式[6]中，有一个状态模式可以用于表达状态机。状态模式基于OOP中的代理和多态。父类定义一系列通用的接口来处理输入事件，做为状态机的对外接口形态。每个包含具体逻辑的子类各表示状态机里面的一个状态，实现父类定义好的事件处理接口。然后定义一个指向具体子类对象的变量标记当前的状态，在一个上下文相关的环境中执行此变量对应的事件处理方法，来表达状态机。依然使用上述例子，用状态模式编写出的代码如下：

type Input int

const (
	Zero Input = 0 + iota
	One
)

type State interface {
	OnEventZero(i Input)
	OnEventOne(i Input)
}

var (
	S1 = "S1"
	S2 = "S2"
)

type StateS1 struct {
	c *Context
}

func (self *StateS1) OnEventZero(i Input) {
	self.doSomething1(i)
	self.c.Tran(S2)
}

func (self *StateS1) OnEventOne(_ Input) {
	// do nothing here
}

func (self *StateS1) doSomething1(_ Input) {
	// do nothing here
}

type StateS2 struct {
	c *Context
}

func (self *StateS2) OnEventZero(i Input) {
	self.doSomething2(i)
	self.c.Tran(S1)
}

func (self *StateS2) OnEventOne(_ Input) {
	// do nothing here
}

func (self *StateS2) doSomething2(_ Input) {
	// do nothing here
}

type Context struct {
	allStates    map[string]State
	currentState State
}

func NewContext() *Context {
	object := &Context{}
	states := make(map[string]State)
	states[S1] = &StateS1{c: object}
	states[S2] = &StateS2{c: object}
	object.allStates = states
	object.currentState = states[S1]
	return object
}

func (self *Context) Tran(nextState string) {
	if s, ok := self.allStates[nextState]; ok {
		self.currentState = s
	}
}

func (self *Context) Handle(i Input) {
	switch i {
	case Zero:
		self.currentState.OnEventZero(i)
	case One:
		self.currentState.OnEventOne(i)
	}
}

var context = NewContext()

func NumberOfZero(i Input) {
	context.Handle(i)
}

状态模式将各个状态的逻辑局部化到每个状态类，事件分发和状态跳转的性能也很高，内存使用上也相当高效，没有稀疏表浪费内存的问题。它将状态和事件通过接口继承分隔开，实现的时候不需要列举所有事件，添加状态也只是添加子类实现，但要求有一个context类来管理上下文及所有相关的变量，状态类与context类之间的访问多了一个间接层，在某些语言里面可能会遇到封装问题(比如在C++里面访问private字段要使用friend关键字)。

d. 优化的FSM实现 #

结合上述几种FSM实现模式，我们可以得到一个优化的FSM实现模式，它用对象方法表示状态，将状态表嵌套到每个状态方法中，因此它包含了上述几种模式的优点：事件和状态的分离，高效的状态跳转和内存使用，直接的变量访问，直观而且扩展方便。用它重写上述例子，得到下述的代码：

type Input int

const (
	Zero Input = 0 + iota
	One
)

type EventType uint32

const (
	EventInitialize EventType = 0 + iota
	EventFinalize
	EventStateEntry
	EventStateExit
	EventUser
)

type Event interface {
	Type() EventType
}

type FSMEvent struct {
	T EventType
}

func (self *FSMEvent) Type() EventType {
	return self.T
}

var (
	FSMEvents = []*FSMEvent{
		&FSMEvent{
			T: EventInitialize,
		},
		&FSMEvent{
			T: EventFinalize,
		},
		&FSMEvent{
			T: EventStateEntry,
		},
		&FSMEvent{
			T: EventStateExit,
		},
	}
)

type FSM interface {
	Init()
	Dispatch(i Input)
	Tran(target string)
}

type State func(e Event)

const (
	EventInput EventType = EventUser + 1 + iota
)

type InputEvent struct {
	T EventType
	I Input
}

func NewInputEvent(i Input) *InputEvent {
	return &InputEvent{
		T: EventInput,
		I: i,
	}
}

func (self *InputEvent) Type() EventType {
	return self.T
}

type BaseFSM struct {
	AllStates map[string]State
	S         State
}

func NewBaseFSM() *BaseFSM {
	return &BaseFSM{}
}

func (self *BaseFSM) Register(name string, state State) {
	self.AllStates[name] = state
}

func (self *BaseFSM) InitState(s State) {
	self.S = s
	self.S(FSMEvents[EventInitialize])
}

func (self *BaseFSM) Dispatch(i Input) {
	self.S(NewInputEvent(i))
}

func (self *BaseFSM) Tran(target string) {
	s, ok := self.AllStates[target]
	if !ok {
		panic("invalid target state")
	}
	self.S(FSMEvents[EventStateExit])
	self.S = s
	self.S(FSMEvents[EventStateEntry])
}

type ZeroCounter struct {
	*BaseFSM
	count int
}

func NewZeroCounter() *ZeroCounter {
	return &ZeroCounter{
		BaseFSM: NewBaseFSM(),
		count:   0,
	}
}

func (self *ZeroCounter) Init() {
	self.Register("S1", self.S1)
	self.Register("S2", self.S2)
	self.InitState(self.S1)
}

func (self *ZeroCounter) S1(e Event) {
	switch e.Type() {
	case EventInitialize:
	case EventStateEntry:
	case EventStateExit:
	case EventInput:
		event, _ := e.(*InputEvent)
		if event.I == Zero {
			self.count++
			self.Tran("S2")
		}
	}
}

func (self *ZeroCounter) S2(e Event) {
	switch e.Type() {
	case EventStateEntry:
	case EventStateExit:
	case EventInput:
		event, _ := e.(*InputEvent)
		if event.I == Zero {
			self.count++
			self.Tran("S1")
		}
	}
}

var (
	counter *ZeroCounter
)

func init() {
	counter := NewZeroCounter()
	counter.Init()
}

func NumberOfZero(i Input) {
	counter.Dispatch(i)
}

在这种模式中可以添加整个状态机的初始化动作，每个状态的进入/退出动作。上述代码中ZeroCounter.S1()方法的case EventInitialize分支可以放入状态机的初始化逻辑，每个状态方法的case EventStateEntry和case EventStateExit分支可以放入对应状态的进入/退出动作。这是一个重要的特性，在实际状态机编程中每个状态可以定制进入/退出动作是很有用的。

e. HSM #

上述几种模式中，状态之间都是相互独立的，状态图没有重合的部分，整个状态机都是平坦的。然而实际上很多问题的状态机模型都不会是那么简单，有可能问题域本身就有状态嵌套的概念，有时为了重用大段的处理逻辑或代码，我们也需要支持嵌套的状态。这方面一个经典的例子就是图形应用程序的编写，通过图形应用程序的框架(如MFC, GTK, Qt)编写应用程序，程序员只需要注册少数感兴趣的事件响应，如点击某个按钮，大部分其它的事件响应都由默认框架处理，如程序的关闭。用状态机来建模，框架就是父状态，而应用程序就是子状态，子状态只需要处理它感兴趣的少数事件，大部分事件都由向上传递到框架这个父状态来处理，这两种系统之间有一个直观的类比关系，如下图所示：

这种事件向父层传递，子层继承了父类行为的结构，我们将其称为行为继承，以区别开OOP里面的类继承。并把这种包含嵌套状态的状态机称为HSM(hierarchical state machine)，层次状态机。

加上了对嵌套状态的支持之后，状态机的模型就可以变得任意复杂了，大大的扩大了状态机的适用场景和范围，如此一来用状态机对问题建模就好比用OOP对系统进行编程：识别出系统的状态及子状态，并将逻辑固化到状态及它们的跳转逻辑当中。

那么在状态机实现模式里如何支持嵌套状态呢？从整个状态图来看，状态/子状态所形成的这张大图本质上是一个单根的树结构，每个状态图有一个根结点top，每个状态是一个树结点，可以带任意多的子状态/子结点，每个子状态只有一个父结点，要表达嵌套状态，就是要构造出这样一棵树。

go-hsm #

我用Golang编写了一个HSM框架go-hsm，设计要点如下：

用类来表示状态，局部化状态内部变量及逻辑，整棵状态树由具体应用构造
支持嵌套状态及行为继承，支持进入退出动作，
支持自定义事件，支持静态和动态两种跳转

它的代码在这里，go-hsm的使用例子则放在另一个项目go-hsm-examples。由于Golang本身的语言特点，有一些地方的实现较其它语言多了一些缺点，比如Golang里面的binding是静态的，为了将子类对象的指针传播到父类方法，要显式传递self指针，子类的接口函数也需要由应用重写。但由于HSM本身的灵活强大，go-hsm具有良好的可调整性及扩展性，是一个很好的状态机建模工具，一门灵活有效表达复杂状态机的DSL(Domain Specific Language)。

注：
[1] 《Structure and Interpretation of Computer Programs》一书的中文译本。
[2] 本文内容主要出自Miro Samek博士的经典著作《Practical Statecharts in C/C++: Quantum Programmming for Embedded Systems》，其中文译本书名为《嵌入式系统的微模块化程序设计：实用状态图C/C++实现》，翻译甚差，不推荐阅读。
[3] 各种编程语言里面的条件判断关键字和语句都不尽相同，有的if语句带then关键字，有的不带then，有的支持switch，这里将它们简单统称为if-else/switch语句。
[4] 本文中所有代码都为Go语言代码。
[5] 之所以强调函数是命名的，是因为很多语言支持匿名函数(即lambda函数)，在嵌套if-else/switch模式内部写匿名函数定义对降低代码膨胀起不了作用。
[6] OOP领域设计模式的流行，源于这本书《Design Patterns: Elements of Reusable Object-Oriented Software》的出版，其中文译本见这里。

Curator 介绍

Sat, 08 Mar 2014 16:27:00 +0800

本文翻译自Netflix[1]技术博客文章《Introducing Curator - The Netflix ZooKeeper Library》，原文由Netflix工程师，Curator作者Jordan Zimmerman编写，原文在这里。接触Curator已经快一年时间，期间有过写一篇介绍性文章的念头，但一直没有动手，后来回顾手头的资料，觉得其实这篇文章虽然简洁了一点，但也是一个很好的介绍，于是翻译在这里。仅用于学习，请勿用于其它用途。

Netflix的开源 #

Netflix致力于开源，我们过去写过相关的博客，今天我们公布Netflix开源项目的门户网页。网页托管在Github上，有几个项目在并行推进当中(其中包括我们今天对外发布的Curator)：

Curator - Netflix的ZooKeeper库
Astyanax - Netflix的Cassandra客户端
Priam - Cassandra的跨进程备份/恢复功能，Token管理，配置中心化管理
CassJMeter - 运行Cassandra测试的JMeter插件

ZooKeeper #

ZooKeeper是一个高性能的分布式协调服务框架。它将通用的服务，如命名，配置管理，同步，分组服务等，通过简单的接口展现出来。要全面的了解ZooKeeper，请参考以下网页：

难以用好 #

ZooKeeper本身自带一个Java客户端，但使用这个客户端繁琐[2]而且容易出错。客户端的使用者需要做大量的手动维护性工作。比如：

连接问题

初始化连接：ZooKeeper客户端与服务器进行握手，这需要花一些时间。如果握手未完成，任何要与服务器端同步执行的方法(如，create()，getData()等)都会抛出异常。
Failover：如果ZooKeeper客户端与服务器连接断开，它会failover到集群中另外一台服务器。然后，这个过程会使客户端退回到"初始化连接"的模式。
Session过期：有些边际情况可以导致ZooKeeper session过期。客户端需要监视这个状态，关闭并重建ZooKeeper客户端实例。

恢复问题

当在Server创建顺序节点(sequential ZNode)时，有可能出现这种情况：节点成功创建了，但server在将节点名返回给客户端之前崩溃了。
ZooKeeper客户端可能会抛出几个可恢复的异常，使用者需要捕捉这些异常并做重试操作。

Recipe[3]方面

标准的ZooKeeper recipe(如锁，选leader等)只是得到最低程序的描述，要正确地编写出来比较困难。
有一些重要的边界情况在recipe描述里没有提到。例如，锁recipe的描述中，没有说到如何处理服务器成功创建了顺序(Sequential)/临时(Ephemeral)节点，但在向客户端返回结点名之前就崩溃的情况。如果没有得到正确处理，可能会导致死锁。
某些使用场景下，必须要注意可能出现的连接问题。例如，选leader过程要监视连接的稳定性。如果连接到的服务器崩溃了，leader就不能假定自己继续为leader，除非已经成功failover到另外的服务器。

上述问题(和其它类似的问题)必须由每个ZooKeeper使用者来处理。问题解决方案既不容易编写，也不是显而易见的，需要消耗相当多的时间。而Curator处理了所有的问题。

Curator是什么 #

Curator n ˈkyoor͝ˌātər:，展品或者其它收藏品的看守者，管理员，ZooKeeper的Keeper。它由3个相关的项目组成：

curator-client - ZooKeeper自带客户端的替代者，它负责处理低层次的维护工作，并提供某些有用的小功能
curator-framework - Curator Framework大大地简化ZooKeeper使用的高层次API。它在ZooKeeper客户端之上添加了很多功能，并处理了与ZooKeeper集群连接管理和重试操作的复杂性。
curator-recipes - ZooKeeper某些通用recipe的实现。它是基于Curator Framework之上实现的。

Curator专注于锁，选Leader等这些recipe。大部分对ZooKeeper感兴趣的人不需要关心连接管理等细节。他们想要的只是简单的使用这些recipe。Curator就是以此作为目标。

Curator通过以下方式处理了使用ZooKeeper的复杂度：

重试机制：Curator支持可插拔式的(pluggable)重试机制。所有会产生可恢复异常的ZooKeeper操作都会在配置好的重试策略下得到重试。Curator自带了几个标准的重试策略(如二元指数后退策略)。
连接状态监视：Curator不断监视ZooKeeper连接的状态，Curator用户可以监听连接状态变化并相应的作出回应。
ZooKeeper客户端实例管理：Curator通过标准的ZooKeeper类实例来管理与ZooKeeper集群的实际连接。然而，这些实例是管理在内部(尽管你若需要也可以访问)，在需要的时候被重新创建。因此，Curator提供了对ZooKeeper集群的可靠处理(不像ZooKeeper自带的实现)。
正确，可靠的recipe：Curator实现了大部分重要的ZooKeeper recipe(还有一些附加的recipe)。它们的实现使用了ZooKeeper的最佳实践，处理了所有已知的边界情况(像前面所说的)。
Curator专注于那些让你的代码更强健，因为你完全专心于你感兴趣的ZooKeeper功能，而不用担心怎么正确完成那些的维护性工作。

ZooKeeper在Netflix #

ZooKeeper/Curator在Netflix得到了广泛的使用。使用情景有：

InterProcessMutex在各种顺序ID生成器中被用来保证值的唯一性
Cassandra备份
TrackID服务
我们的Chukwa收集器使用LeaderSelector来做各种维护性的任务
我们用了一些第三方的服务，但它们只允许有限数目的并发用户。InterProcessSemphore被用来处理这个。
各种Cache

获取Curator #

Curator二进制被上传到了Maven Central，这让获取它变得很容易
Curator的源代码放在Github上托管[4]：https://github.com/Netflix/curator
全面的文档放在：https://github.com/Netflix/curator/wiki

注：
[1] Netflix是一个美国的在线DVD租赁公司，后来转型到网络流媒体服务。参考维基百科Netflix词条。
[2] 原文为non-trivial，意思应该是搞反了。
[3] Recipe中文意思为“菜谱，配方”，感觉翻译过来不能很好的表达英文"一系列约定步骤"的意思，故不译。
[4] Curator在去年(2013年)年中已经正式成为Apache Incubator项目，代码改为托管在Github Apache的对应目录下。主页和文档的位置也有所变化。

嵌套反引用有害

Sun, 10 Mar 2013 21:37:00 +0800

本文翻译自《Nested Backquotes considered harmful》，只用于学习，请勿用于其它用途。

好吧，我想嵌套反引用（nested backquote）不是真的有害，因为你的确可以用它来做一些没有它就很难做到的事情；然而，它又的确会导致非常难以理解的代码（它对于混乱代码比赛[1]或许是有用的，但非常难以维护）。实际上，这篇文章的标题应该叫做“嵌套反引用令我头痛”，但我一直想写一篇标题叫做“那谁谁有害”的文章，于是，标题就是这个了。;-)

注：如果你不知道什么是嵌套反引用，它为什么有用，或者感兴趣于了解更多关于写出或理解这种典型地由嵌套反引用生成的，用于生成代码的代码，那么Alan Bawden的杰出论文《Quasiquotation in Lisp》值得一看（这是Jens Axel Søgaard所推荐的）。Alan的论文描述了这项技术的历史和概况，而且读起来很有趣。Paul Graham在他的书《On Lisp》的第16章也谈到了嵌套反引用，他说[2]：
为了定义一个定义宏的宏，我们通常会要用到嵌套的反引用。嵌套反引用的难以理解是出了名的。尽管最终我们会对那些常见的情况了如指掌，但你不能指望随便挑一个反引用表达式，都能看一眼，就能立即说出它可以产生什么。这不能归罪于 Lisp。就像一个复杂的积分，没人能看一眼就得出积分的结果，但是我们不能因为这个就把问题归咎于积分的表示方法。道理是一样的。难点在于问题本身，而非表示问题的方法。

Bruno Haible最近在c.l.l.解释了避免嵌套反引用的两个不同方法。它们主要包含将嵌套反引用转换为简单反引用的做法。这两个方法他概述如下：

1. 在内层使用LIST, APPEND等函数代替反引用
2. 使用包含反引用的辅助函数

Bruno为每个方法提供了例子。

首先，下面给出的这段代码用了嵌套反引用：

(defmacro once-only (variables &rest body)
  (assert (every #'symbolp variables))
  (let ((temps nil))
    (dotimes (i (length variables)) (push (gensym) temps))
    `(if (every #'side-effect-free? (list ,variables))
       (progn ,body)
       `(let
          (,,@(mapcar #'(lambda (tmp var)
                          ``(,',tmp ,,var))
                      temps variables))
          ,(let ,(mapcar #'(lambda (var tmp) `(,var ',tmp))
                         variables temps)
             ,body)))))

原来的代码使用方法1转换后如下：

(defmacro once-only (variables &rest body)
  (assert (every #'symbolp variables))
  (let ((temps nil))
    (dotimes (i (length variables)) (push (gensym) temps))
    `(if (every #'side-effect-free? (list ,variables))
       (progn ,body)
       (list 'let
         (list ,@(mapcar #'(lambda (tmp var)
                             `(list ',tmp ,var))
                         temps variables))
         (let ,(mapcar #'(lambda (var tmp) `(,var ',tmp))
                       variables temps)
           ,body)))))

原来的代码使用方法2转换后如下：

(defun construct-binding (variable form)
  `(,variable ,form))

(defun construct-let-wrapper (bindings body-form)
  `(let ,bindings ,body-form))

(defmacro once-only (variables &rest body)
  (assert (every #'symbolp variables))
  (let ((temps nil))
    (dotimes (i (length variables)) (push (gensym) temps))
    `(if (every #'side-effect-free? (list ,variables))
       (progn ,body)
       (construct-let-wrapper
         (list ,@(mapcar #'(lambda (tmp var)
                             `(construct-binding ',tmp ,var))
                         temps variables))
         (let ,(mapcar #'(lambda (var tmp) `(,var ',tmp))
                       variables temps)
           ,body)))))

两个方法中的任一个，产生的代码的可读性都比原来代码好得多。

作为Bruno建议方法的一种替代，也许你会考虑使用Drew McDermott的BQ反引用工具（包含在YTools中）。Drew在YTools手册中对这个反引用问题有一个很好的解释：

反引用是Lisp的一个不可或缺的特性。然而在标准说明中它并非尽善尽美。我主要有两个不满：
当实现一个像反引用这样的机制时，需要3个东西：一个读取器，一个宏展开器，一个写入器。读取器将如 `(foo ,x)的字符序列转换为如(backquote (foo (bq-comma x)))的内部形式（Allegro就是这样读取的）。之后宏展开器将backquote调用转变为像(list 'foo x)构造函数形式。写入器将(backquote (foo (bq-comma x)))输出为 `(foo ,x)。

不幸的是，Common Lisp标准没有详细说明宏（macro）是什么。因此，它依赖于具体实现。对比来看，普通的引用（quote）有一个定义良好的内部形式(quote x)，因此有一个定义良好的来自外部形式'x的转换。没有详细标准的问题就在于，要写一个你自己的工具配合读取器，宏取开器或写入器，是不可能的。例如，无法写一个可移植的代码遍历程序，针对反引用表达式来做一些特别的事情。事实上，一个Lisp实现甚至不要求有一个反引用的内部表示。读取器和宏展开器可以合并，以致于 `(foo ,x)可以读作(list 'foo x)。此外反引用写入器的行为并非良好定义的，因为无法区别一个列表构造形式是不是由反引用转化来的。

为什么要与宏展开器交互呢，这里有个例子。你或许也想和读取器有交互。假设你希望创造一个泛化的反引用读取宏（就叫它!@吧），这个宏建造一些并非列表结构的东西，你可以将(apply #'make-a-foo (list 'baz a) l)简写作!@(make-a-foo (baz ,a) ,@l)。当这个表达式!@(...)被读入时，很多Lisp实现会报一个类似“Comma not inside a backquote”（逗号出现在非反引用表达式中）的错，没有可移植的办法来干预读取过程来使它变成合法的。
用于阐明嵌套反引用的规则是，逗号是与围绕它的最内层的反引用配对的。（同时提取它的参数到上下文中，以便下一个逗号匹配到下一个反引用，如此类推。）

我想这是错误的，或者至少在某些情况下是错误的。我从左到右地读反引用代码，因此先看见最外层的反引用。人们会喜欢这样理解：从反引用的角度来看，所有在它里面的东西，除了用逗号标记的之外都是“不会动的（inert）”（即被引用住）。对于所有可能会出现在其中的表达式，除了反引用外，这是成立的。所以如果你正编辑一个复杂的反引用表达式：
'(foo (bazaroo '(fcn a ,x)))
内层的引用不会“遮蔽”住x使它免于被求值。但如果将内层的引用改成反引用，那么遮蔽就正正要发生。你必须把它改成这样：
'(foo (bazaroo `(,fcn a ,',x)))
这个,',构造只是外观丑陋而已。它的唯一作用是将它的参数提取出最内层的反引用；你不能用,,x，因为这是说“当外层的反引用被展开时对x求值，得到e，然后当最内层反引用展开时求值e”。注意求值是次序是从外到内，然而嵌套反引用的规则是从内到外。非常，非常的令人迷惑。
这些不是巨大缺陷：99.9%的反引用不是嵌套的，而且几乎没人关心一个反引用的内部表示是什么。可是如果你感兴趣，文件bq.lisp提供一个可选的实现。

因此，正如Common Lisp里大多数的事物一样，如果你不喜欢某些东西，你可以改变它！当你需要写这类嵌套反引用的代码时，你有（至少）4种不同的可以考虑的选择（基于你有多少嵌套反引用工作要做，还有你个人对代码风格／可读性的偏好）：

1. 使用嵌套反引用
2. 在内层使用LIST, APPEND等函数代替反引用
3. 使用包含反引用的辅助函数
4. 使用一个反引用的替代实现

现在，出山吧，去写一些这样的代码：一种形式的代码不断的生成下一种形式，像生物进化的过程那样一代一代衍生。;-)

注：
[1] 即Obfuscation Contest。国际C语言混乱代码大赛（IOCCC, The International Obfuscated C Code Contest）是一项著名的国际编程赛事。
[2] 此段译文引用田春（伞哥）等人翻译的《On Lisp中文版》对应章节。

Emacs 修炼之道

Tue, 08 Jan 2013 16:04:00 +0800

“Don’t panic.”
-- The Hitchhiker’s Guide to the Galaxy

作为一个Emacs控，在办公室我也积极的向别人推荐Emacs，有时候会需要向别人介绍和解释Emacs，比如它能够做什么，与其它编辑器有什么不同，如何使用它等。Emacs是一个很大的话题，而且网上关于Emacs/Vim/其他编辑器的各种圣战中飞扬的口水已经太多了，所以这里我把这篇内容缩小到Emacs的修炼这一点上，因为对于那些真正对Emacs感兴趣并准备起锚出发的Emacs初学者，如果有一个详细的指南，它记录了从入门到进阶等各个阶段，以及前进的道路上有哪些可以借力的资料或资源等，这是很有帮助的。于是我有了写此文的打算，作为一个过来人我就斗胆写一下Emacs的修炼之道。

一般来说，那些决定不用系统自带的文本编辑器，而专门花时间学习Vim/Emacs的人都需要在文本上做比较多的工作，他们希望在工具这一块上做长期的投资——即使Vim/Emacs的入门需要一些精力和时间，但熟悉之后能提高工作效率并长期发挥作用，当然这些人之中有很多是程序员。如果你像我认识的一些朋友一样，对系统自带的文本编辑器，比如windows下的notepad，保持100%的满意，那么就不用接着往下看了，尽可跳过下文并继续留在那个与世隔绝的默认编辑器的桃花源里，这种说法好像比较鄙视notepad，但其实它主要是说：如果编辑需求复杂多变，那么编辑器相应的也需要变得复杂强大。

接下来这一个Emacs之道会有点长，因为Emacs被设计成能提供各种复杂多变的编辑功能，甚至是文本编辑之外的，例如玩游戏或收邮件等其它功能，所以Emacs才会有“伪装成操作系统的编辑器”这一别称，而且学习曲线会变得非常的，呃，奇怪[1]。尽管下文有点长，但是记得带上你的毛巾[2]，无论遇到什么情况，最重要的是，Don’t panic。

我把Emacs修炼的道路分为几个主要的阶段：

1. 入门小徒 #

初学Emacs，首先要了解Emacs的基本操作，Emacs自带的tutorial文档就是为零起点的新手而写的，它介绍了窗口(window)，文件，缓冲区等概念，并一步一步的指导初学者学习光标移动，插入修改，搜索，保存退出等基础功能，是最好的入门指南。默认的键绑定下在Emacs中使用C-h t可以打开这个tutorial文档，也有对应的中文译版叫《Emacs快速指南》，文档不长，整个看完并按文档指引练习一下，之后就可以用Emacs完成简单的文本编辑。

接下来可以阅读《Learning GNU Emacs》，这本由老牌黑客Eric Raymond参与编写的书是学习Emacs的经典书目，内容很多也很全面，它介绍了从用Emacs做基本的文本编辑，到用Emacs收发邮件阅读网页，到定制编辑宏以及做程序开发等各种功能。初学者可以只读前5章，对Emacs的环境及常用操作做一个比较细致的了解。这本书的原英文第1版讨论的是Emacs的18版本，之后第2版出版，讨论的是Emacs的19.30版，而2004年出版的第3版，则随着Emacs的版本升级把内容更新到21.3版，到2013的今天，Emacs的主版本号已经升到24，虽然这本书在过去一段时间也算是与时俱进，但从版本上来远远落后于Emacs更新的速度，不过，很多内容在Emacs中保持稳定，还是很有价值的，只是阅读的时候要注意一下版本变化。这本书也有中文译本，已经绝版，但对应的只是较旧的英文第2版，译文流畅印刷错误也少，译本质量尚佳，因为是针对初学者而写的入门书，讲解详细，辅以图示截屏帮助理解，读来比较轻松。

进一步学习的话，则根据各人的需求而选择了，需求不同则学习的内容也不同。希望使用Emacs来做大量重复编辑的人可以学习定制编辑宏，用来写笔记的可以学习outline-mode或org-mode，用来收邮件的可以学习mew等邮件客户端的用法。考虑到使用Emacs的人当中有很多的程序员，那么也根据编程语言的不同，学习的编辑模式也不同，Emacs对于多种编程语言都有着很好的支持，如C, C++, Java, Shell, Python, Perl, Erlang, Lisp……还有常见标记语言如Html, XML和排版用的Tex, LaTeX和Troff等。此外你可能会需要一些特别的功能，这些功能在其它的编辑器/IDE也有，比如显示行号，在编写代码时的自动补全，全文格式化，代码折叠与展开，实时显示代码错误等，Emacs还有一些比较独特好玩的功能，如hungry delete。学习这些内容，除了《Learning GNU Emacs》这本书第5章后面的多个章节之外，网上也有很多的资料，不过就比较分散了，要找到Emacs是否有满足你特定需要的扩展，或者这些扩展怎么使用，google是一个很好帮手。

这个时候你已经很熟悉Emacs日常使用，以及为自己的编辑需要加了一些扩展和定制，在配置文件不断变大的同时，你可能也知道一点简单的Emacs Lisp写法，但对Emacs Lisp还没有深入的了解。

由于各人的编辑需求不一样，这个寻找某种特定功能并定制使用的过程可长可短，了解Emacs在各种编辑模式下的功能有助于进一步学习Emacs Lisp及Emacs的内部实现，但这不是必需的。即使你很快的进入下一阶段开始系统学习Emacs Lisp，但如果时不时会遇到新的编辑需要，还是会重复上述的扩展定制过程。以像我自己为例，因为需要编辑的代码种类越来越多，如后来的Markdown, Erlang，所以也对应的添加了markdown-mode, erlang-mode的定制代码。

2. 登堂入室 #

在接触Emacs的过程中，很多新手都会注意到一个事实：Emacs是用一种叫做Emacs Lisp的Lisp方言写的，如果不懂Emacs Lisp是无法进一步走入Emacs的殿堂的。所以在这里我把“开始系统的学习Emacs Lisp”做为进入到第2阶段的标志。

在Emacs自带的Info文档中，对Emacs的描述是：

Emacs is the extensible, customizable, self-documenting real-time display editor.

可以看到，可扩展性，可定制性和自文档化是Emacs三个特别强调的特点，前两个特点或者其它编辑器也有，比如Vim，但自我文档化这一点，可算是Emacs的一个独门绝技，是的，在visual studio中也有帮助系统，不过与Emacs的自文档化比起来，还是差得太远了，这方面可以比肩Lisp的编程语言不多，Python是其中一个，自文档化与交互式编程结合起来，整个编程环境会让写代码的人相当舒服。

要开始Emacs Lisp之旅，最好的学习资料也是Emacs自带的文档，在Info中有一个Emacs Lisp的入门教程《An Introduction to Programming in Emacs Lisp》，这个文档由另一位老牌黑客Robert Chassell所写，由浅入深地详细介绍了Emacs Lisp中的列表操作，函数，缓冲区操作，窄化，剪切粘贴，正则表达式，代码调试等内容，由于把读者定位为没学过编程的人，所以行文比较啰嗦，程序员读起来可能会有点不耐烦。它也有中文翻译版，书名叫做《GNU Emacs Lisp编程入门》，不过也比较旧了，是2001年由FSF中国组织翻译并出版的，年代久远，对应的Emacs版本是19，这本中译版也已经绝版，不过网上可以找到电子版。虽然后来大师洪峰在他某次答问中说这本中译版质量很高[3]，我个人看过纸版全书之后觉得其实翻译和出版的错误也不少，像他读过那么多书的人肯定清楚一个译本的质量怎么才算是“很高”，不过此书的中文翻译是他组织的，有点敝帚自珍也是人之常情。

特别值得一提的是，在这本书的前言里，作者Robert说“希望读者养成阅读源代码的习惯”，并把Emacs当成一个代码的宝藏，学习其工作机制。书中的内容多是具体的代码细节，看过之后是会忘记的，但“深入代码”这个习惯一旦养成，受用无穷。我个人认为也可以依据同样的标准来定义玩Emacs的程度，真正Emacs玩得好，不是说要用过多少个扩展，用得有多么的熟悉，而是深入到源代码去了解其内部实现。

在读完《GNU Emacs Lisp编程入门》的基础上，可以找一些其它的Emacs Lisp入门级资料来看看，比如wiki上的Emacs Lisp Cookbook，上面就有常用的各种数据结构，文件目录操作等的代码示例。经过学习之后，到网上一些站点，比如Emacs中文网或李杀网，看一些文章通读其中简单的Lisp代码已经没有困难。

同时，可以阅读一些Emacs中常用小功能的源代码，比如自动高亮括号的paren.el，高亮当前行的highlight-current-light.el，显示行号的linum.el，自动插入括号对的skeleton.el等，在读源代码的过程中有时会遇到未知的库函数和新的概念，通过查询Emacs的自带文档一般可以解决问题。

通过前面的学习，在前一阶段的基础上你已经掌握大量的Emacs Lisp，在阅读源代码上有了不少的积累，但由于没有全面系统的学习Emacs Lisp，有时候读起源代码来不懂的地方太多，会有种力不从心之感，这时候就可以开始进入第3阶段。

3. 武林高手 #

对于学习Emacs Lisp，最权威的两个文档当然是Emacs自带的Info文档《The Emacs Editor》和《The Emacs Lisp Reference Manual》，前者主要介绍作为编辑器的Emacs概念和机制，比如kill-ring，display, key-binding, 各种mode等，重点在使用，后者则全面系统的介绍了Emacs Lisp这门编程语言，比如各种数据结构及操作，宏，文加载等，重点在于编程，Emacs Lisp作为Emacs的实现语言，当然两个文档会有标题或内容看起来很类似的章节，但由于两个文档重点不一样，两者互为呼应补充而非重复。这两个都是大部头，要读完的话甚费时日，但其内容并不艰深，读起来还算轻松，耐心读完的话，会功力剧增，对Emacs的理解有很大的提高。虽然我在这里把两个文档一起列出，但其实阅读顺序和阅读习惯可以按各人的习惯自由安排：可以先读前一本，读完再读后一本；也可以先读后一本，在遇到新概念的时候再回头看看前一本的对应章节。这两种都是比较有效的读法。就像电影《黑客帝国》第一部所讲的，在Neo知道Matrix不是看起来那样的真实之后，进入Matrix中能看到一些不真实的事物，读完这两本书之后，你再进入Emacs的时候，看着界面的buffer，高亮的代码块，mode-line等，不再只是看到它们显示出来的样子，而且透过表面看到了里面运行的模块和流动的代码。

作为读书的补充，可以适当的找一些源代码来看，一些常用的扩展如auto-complete, yasnippet等代码目录结构不算复杂的都合适。我个人建议以兴趣和熟悉程度为出发点，以你熟悉的mode，或最感兴趣的扩展来作为开始，因为对外部功能了解越多，越有助于理解其内部代码，就像熟悉Linux的库和系统接口，有助于阅读内核源代码一样。

到此，你已经全面系统的学习过Emacs和Emacs Lisp，在阅读源代码上也有了大量的积累。在正式变为高手之前，还有需要做一件事情：写至少一个扩展，并奉献出来。在开源文化或黑客伦理中，一个人成为高手或黑客，不仅因为他技术高超，而且因为他有很好的奉献精神。写一个扩展需要很多的劳动，写一个规模大而且质量好的扩展更是辛苦。虽然在前面的学习过程中，你已经读过一些扩展的源代码了，但在开始正式自己写扩展之前，或者你有兴趣阅读一下《Writing GNU Emacs Extensions》这本书，了解一下如何从头到尾写一个扩展。这本由Bob Glickstein写的书于1997年由O’Reilly出版，虽然内容很好，但是真的远远落后于时代了，对应的Emacs版本是18，目前能找到的电子版印刷错误也较多。

4. 飞升成仙 #

到了这个阶段，进一步提升自己的方向有两个，一曰深度，一曰广度。

深度方面，可以全面阅读Emacs的源代码，学习其底层的C核心，Emacs Lisp解释器的原理，学习Emacs的启动/运行过程，事件机制，与外部进程的接口，等等。还可以找一些较复杂较庞大的扩展代码来看，例如广为人知的巨兽CEDET等，除了熟悉如何用Emacs Lisp来实际编写大项目之外，还需要懂得很多与具体应用紧密相关的内容，例如对于CEDET，就需要知道编程语言的词法文法解析过程。这种复杂项目对基础知识的要求较高，读起来较为艰深，需要做好“深挖洞，广积粮”的准备。

广度方面，可以广泛涉猎其它Lisp方言，学习Lisp的实现，历史及著名项目等，甚至可以弄一个Lisp Machine来玩玩，或者学习其它的函数式编程语言。这个话题太大，但我还是尽力尝试提供一点帮助信息。最大的两个Lisp方言当然是Common Lisp和Scheme，如果详细叙述如何学习Common Lisp或Scheme，那么可以需要写的篇幅比本文长得多，或者将来在我的博客上会出现《Common Lisp修炼之道》或《Scheme修炼之道》，但至少暂时是既无能力也无计划。这里只是简单列一下可供参考的书目：

《Structure and Interpretation of Computer Programs》，中译本《计算机程序的构造和解释》
《Ansi Common Lisp》，目前网上有在线中文翻译版本，前几章翻译得还不错
《Practical Common Lisp》，伞哥(田春)翻译了中文版，2011年出版，有的地方读起来比较生涩
《On Lisp》，伞哥和其他人合作翻译，网上有电子版，翻译质量很高，就像前文所说，“很高”这两个字不是随便用的
《Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp》，由AI大牛Peter Norvig所写的，书名看起来只是AI方面的书，但其实也是一本很好的Common Lisp教程
《Common LISP The Language, 2nd》，描述Common Lisp的语言标准

还有很多Lisp好书都没有一一列出，此外函数式编程语言也不少，虽然有时学习曲线陡得像是悬崖峭壁，但如果你真的到了这一步，相信会有足够的兴趣和技能支撑你继续走下去，总之可以选择的方向太多，这篇小文只谈Emacs修炼，适可而止。

到了这个层次，当然你也要注重发光发热，提挈后辈，可以在社区或邮件组多活动活动，奉献代码，解答疑问。不过这个也是大话题了，网上组织众多各人习惯不同，非三言几语能够说得清楚，按下不表。

如果以上提到的这些内容你都已经深入钻研，深到地球核心，又广到天际之远，那么恭喜恭喜，你可以正式宣称“神丹炼成，择日飞升”，到这个时候，你所需要的只剩下《颈椎病和鼠标手康复指南》。两千年前庄子就说了，“吾生也有涯，而知也无涯。以有涯随无涯，殆已；已而为知者，殆而已矣。”喜欢折腾Emacs的朋友们，人生短暂，还是悠着点吧。

注：
[1] 《主流文本编辑器学习曲线》这里有各种编辑器的学习曲线图示，Emacs的曲线比较奇怪。
[2] 《银河系漫游指南》中毛巾这个词条有一些特别的解释。
[3] 这个问答后来被整理成为《你是如何成为 Lisp 程序员的》一文，在网上可以找到。