无废话JavaScript(下)
2008-10-06 15:35 乱世文章 阅读(172) 评论(0) 编辑 收藏 举报无废话JavaScript(下)
上一篇在这里,在这里,在这里……
五、函数式
这个可不是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上的斐波那契数列示例):
八、结语
好象,好象这篇《无废话》有很多废话……哈哈,玩笑啦,真的全无废话,还是活人能看的木?
真的那么想读无废话,你应该去读大学教材了。或者,这里还有一本《JavaScirpt语言精髓与编程实践》。
看见木,语言……精髓哦……,哈哈。