五、函数式

这个可不是JavaScript的发明，它的发明人已经死了，而他的这个发明还在困扰着我们……如同爱迪生的灯
泡还在照耀着我们。

其实函数式语言很简单，它就是一种与命令式语言同样“完备”的语言实现方案。由于它的基础思想与命令
式——如果你不想用这个难于理解的名词，那就把它换成C，或者Delphi好了——语言完全不同，所以大多数
情况下，它也与这些传统的、通用的、商业化的语言格格不入。

而事实上，你天天都在用它。

下面这行代码，就充满了函数式语言的思想：

是吗？真的，如果你把那个“+”号看成一个函数，就完全一样了。事实上，所谓函数(function)，就是一个
执行过程、一段运算、一个功能入口……也就是说，代码中的某个东西，要么它是数据，要么它是运算。而如
果它是运算，你就可以把它看成“函数”。上面这行代码——表达式中，a和b显然是数据，而+号则是对之进
行操作的运算，所以它自然可以看成一个“功能、过程或运算”。所以……操作两个数求和的“函数”可以写
成这样：

或者这样：

所有这些，只是文字上的标记法不同而已。就好象我说这个符号是“jia”，而你非得说它是“暗得”，另一个
人却非要读作“a-d-d”。有什么不同吗？没有。

所有程序员天天都在写语句，写表达式，与运算逻辑。大家都知道这些东西都可以写在一个……嗯……无比巨
大的函数里，或者分在无数个小的、看起来很漂亮的函数里。当所有这些函数一个又一个连续起来运算时，它
就成了“函数式语言”。所以称为“函数式语言的祖老爷爷”的LISP就是这样“把函数运算连起来”的语言：

有人认为它是丑陋的意大利面条，也有人认为它是最简洁的语言。Oh，随你，了解了就好了，管它象什么尼。

由于函数式语言只有连续执行的函数——所以它没有了“语句”而又必须实现逻辑上的完整性。简单地说，他
需要在连续执行的过程中实现“顺序、分支与循环”三个基本逻辑。函数式的解决之道，是用三元条件运算来
代替if/then/else，也就下面的代码：

另外，就是用递归（函数调函数）来实现循环。考虑到递归函数调用中会导致栈溢出(Stack overflow at ...)，
所以函数式语言就提出了“尾递归”，也就是在书写代码是“确保”仅只在函数内的最后一个运算中递归调用。
这样一来，这个递归调用就不需要保留栈了——因为再没有后续运算了，因此就能被优化成一行不需要返回的
jmp汇编指令。

世界真美好，所谓函数式不过是一堆运算入口，以及jmp、jmp、jmp。但，但是，难道不是吗——这块CPU？

六、更高级的函数式(1)

其实世界并不美好。

如果一块CPU死躺在那里，它也就只有顺序呀、分支啦、循环之类的指令在里头。但是当它运行起来，就得有一
个时钟在滴嗒…滴嗒…如果是多核的，还会同时有好几个这样的东东在滴嗒着。

这就是问题，世界原本不是单一时序，也不是守序的。所以会有并发，会有中断，也会有异常。函数式语言应
该自己应该像意大利面条一样无限延展开去，那么是不是有多个滴嗒时就该有多根意大利面条呢？但，这种情
况下还叫意大利面条吗？

函数式里的解决方案叫延续(Continuation)和结点。延续是停止当前转到另一处、然后再返回来；而结点则确
保一个位置上的代码是独立完备的，与另一个结点无关。在函数式语言中，多个结点就象平行宇宙，大多数情
况下它们是互相透明的，如果它们要发生联系，得需要极其巨大的能量，以及……一个虫洞。

多个结点的问题我们不需要深究，多个空间下的访问带来的时空问题，是天体学家以及时空多维理论家们研究
的问题，我们只需要知道：如果你希望多个结点之间存在交叉的访问关系，那么世界/宇宙会因此毁灭。这样类
似的说明写在ErLang这类天生支持多个宇宙的语言的白皮书、参考手册以及宇航员日常指南之中。如果你要穷
究其根源，并且认为自己已经能明确了解300个以上的高等数字、物理学和天体学术语，地么下面有一份面向程
序员的入口指引，不妨从这里开始：
http://www.blogjava.net/canonical/archive/2007/12/05/165664.html

延续是解决状态问题的方法之一。简单说来，有时间就有状态：有过去，现在和将来。对于过去，我们有历史，
也就会因为过去发生了什么而决定现在发生什么，例如因为昨天喝高了小酒，所以今天只能吃稀粥；而现在也
就是明天的昨天，所以要为了明天能做什么而记录下今天的状态，例如今天已经吃了稀粥；至于明天，当然，
将要发生的事情很多，我们得一件一件地做好准备。

Oh，重要的就是这个“做好准备”了。这在计算机系统里叫：事件。或者叫计划，或者叫突发。知道为什么我
们的PC机可以运行吗？En...是因为有一个指令流水线在按照一个足够微小的时间片去执行指令。对于运算系统
来说，这个定时发生的指令访问行为，就是中断。所以有一天一个朋友问我：如果执行逻辑只有顺序、分支与
循环，那么流程系统中的触发器算什么？我想了很久，无解。而现在来回答这个问题，就得把“时间”这个维
度加上，所谓突发、并发以及类似的东西，是时序概念下的逻辑。

好了，当我们“做好准备”，为了将来要触发某个东西做准备的时候——简单的说，就当是个时钟处理程序好
了（在windows中它叫OnTimer，在浏览器中它叫setTimeout/setInterval），为了这个时候我们能够在函数式
语言中做好一顿意大利面条，我们说明：“我们已经做好了准备”，以及“我们做好了怎样的准备”。而按照
函数式的基本原则，一个函数是与状态无关的，它与“将来”这样一个时序无关。这，变成了一个矛盾。

事实上开始我们已经与这个矛盾正面冲突了一次，这就是“循环”。因为循环需要一个状态量来指示循环进度，
这个“进度”就是时序相关的。而函数式使用了“递归”来解决它，也就是通过递归函数的参数来传递这个进
度。在“递归参数”——这个界面的两边，函数式都是时序无关的。由此带来的问题就是栈溢出，解决方法则
是尾递归；又由此带来的问题就是编程复杂性，以及能否证明尾递归能替代所有递归；解决方案是……温伯格
说得没错，所有解决问题的方法都会带来新的问题。Oh...又是温伯格。

现在，我们明确的需要“更多的状态”了，因为我们已经将系统运行一个或是多个的时序里——也就CPU。即使
我们有结点，而且保证“没有虫洞”，那么我们也需要解决一个CPU中的过去、现在与将来的问题。

函数式的仙家们说了两个字：持续。简单啊，就是把为过去、现在的状态，和为将来的准备作为函数的参数传过
去。看起来，“现在”立即就要爆炸了，因为既要包括过去的、现在的状态以及变化，还要包括将来的运算。于
是新的解决方案是：若要现在不爆炸，"持续"的界面上不要发生运算就好了。

运算由“将来”根据“过去”的数据做决策，这就是持续。支持它的函数式特性，就是在惰性求值。简单的说，

由于在传送界面f()上，c本身是不求值的，所以爆炸会发生在/不会发生都是在将来c(x)进行运算的时候。如果
宇宙的熵有极限，那么这个极限也是在末可知的将来。而且，在末可知的将来，也有可能回扭曲回现在。这就是
持续的两个原则：
--------------------
一个成功持续之后，是一个新的持续（或过程）
一个失败持续将回到上一个选择点
--------------------
正是因为有持续的状态，且这个状态及持续本身都是通过函数参数传递的，所以，“回到选择点”只是将来自身
的一个决择，与现在的状态是无关的。

七、更高级的函数式(2)

无论如何，种种函数式的复杂性，确实是在编程范型中保持一种自我的纯粹性而存在的。例如生成器（产生器）
这个问题，由于一批数据的产生之间是有关系的（例如增量），而产生过程是时序相关的（不总是在一次调用中
得到全部的数据），因此函数式语言定义了一个“生成器”这样的函数概念。我们可以在生成器中定义一个yield，
这个返回就是“将来”回到这个“现在”的一个虫洞。通过这个虫洞，我们可以拿到一个时序相关的数据。下面
就是这样的一个例子(mozilla上的斐波那契数列示例)：

八、结语

好象，好象这篇《无废话》有很多废话……哈哈，玩笑啦，真的全无废话，还是活人能看的木？

真的那么想读无废话，你应该去读大学教材了。