当然，这种子语言相比于宿主语言，缺乏调试器的帮助，缺乏编译器的优化，缺乏各种ide的支持，可用性程度是大大不如的。
但是，它也有它的好处，那就是，不用额外进行一次编译；写出来的东西和宿主语言无缝集成；可以自动利用宿主语言里面的一切设施。等等。
那么如果把co作为一个语言来考虑，是不是会给我们一些别的启示呢？
oz曾经质疑，所谓的co，怎样决定基本的组合子？怎么样才知道组合子够用了？
那么，设计语言的时候，怎么设计基本的语言设施？怎么样知道这个设施是不足，还是太多呢？
这是个大话题，语言设计非常有争议性和主观性。但是，也仍然是有些共性的。比如，几乎所有的语言都支持顺序，if/else，递归/循环，函数定义等。相当多我们熟悉的语言还支持异常处理，字符串，整数等。
我们难道不能从这里借鉴一些东西？如果我们把基本的nop,顺序，分支作为启动co的基本要求，这算不算是一个可以遵循的guidline呢？
另外，不同的语言，根据它所面向的领域，还有一些不同的内建操作，比如perl，面向文本处理，所以内建了regexp，而c/c++因为直接面对机器硬件模型，所以提供了指针。
那么，根据我们的组合子所要面对的应用类型，我们也可以预先定义一些内建的原始组合子，比如那个WriterLogger。
一般来说，对general purpose的语言，设计的基础设施都是非常”基础“的，基础到几乎不会有什么设施是多余的。同时，也基础到一般人都可以没有什么困难地掌握基本的语法语义。
那么这些语言用这么有限的聊聊几个设施怎么对应它不可能预见的各种现实中的需求呢？
我们平时对可以用简单的if-else，顺序，循环就可以做几乎任何我们能想到的事情感到惊讶了吗？对某个语言能否处理复杂的需求担忧了吗？
为什么没有呢？就在于”组合“的威力。就是那么几个简单的设施，组合起来却可以具有巨大的力量。
同样，在设计组合子的时候，如果我们遵循这些共性，同时在和具体需求磨合的时候积极改进组合子本身，应该就可以达到一个可以满意的组合子系统。
说到这里，可能有人问：你不是说组合子系统是脱离需求自己发展的吗？
这个，怎么说呢？还是说语言。设计一个语言，原则上是设计一些和具体需求没有耦合的基础设施，然后让写具体应用的人组合这些基础设施达到我们语言设计者不可能都预见到的某些具体效果。
但是，在语言设计和逐渐发展过程中，仍然会从用户（就是程序员）那里得到反馈，什么样的需求是他们需要的，什么样的设施不好用，然后设计者再进行改进。
一个语言，一般不会是某个具体需求通过划分责任，自顶向下的设计，最后作为这个需求的附属模块被开发出来。更多的情况，是语言的设计者对可能面对的需求有一个大致了解，并且知道这种可能的需求是变化的，不确定的，于是才会从基本设施开始设计这个语言，最后交付给开发具体应用的人来使用。
组合子系统也遵循一样的规律。组合子的设计需要来自具体需求的灵感和纠正。但是，基本组合子本身却不能耦合于这些具体需求。
组合子的设计者应该对可能面对的需求有大致的了解，但是并不需要完整地预测这种多变的需求。
当然，组合子这种语言中的语言，还有不容易理解的弱点。当组合层次增多，逻辑变得复杂，这个复杂的组合子可不象写在一般的程序设计语言里面的代码那样简明，java繁琐的语法让这种语言中的语言对一些程序员也许就象是神庙里面的神谕一样难以理解，甚至让人望而生畏。
这一半是因为java本身没有提供对这种高阶逻辑的直接支持，组合的语法相对繁琐。如果用haskell，使用语言提供的do-notation，形式上的复杂程度就没了。
另一方面，高阶逻辑都是有这种弱点的。
其实，就算是oo，相比于po，它的多态也是降低可理解性的。
因此，就象我们也不能在oo中到处override虚函数一样，组合子的使用也要有一定的度，过犹不及。
好了，没有实际例子的论述已经太长了。肯定已经有人昏昏欲睡了。
做个调查，我下面的例子有几个选择：
[list]1。简单的predicate。就是一个具有bool is(Object v);方法的接口。
2。ant的FileSelector。一个predicate的变体。
3。swing提到的jdbc的action。负责数据库操作的组合子。
4。yan container的component。负责从任意的构造函数，工厂方法，java bean以及它们的任意组合来产生和注射组件。比pico/spring灵活很多。
5。neptune的command，负责调用任何ant task以及其它的可能返回一个java对象的函数。是一个一般化了的ant task。[/list:u]

这些东西都是基于组合子的。大家觉得对哪一个更有兴趣呢？我有些拿不定主意哪个更合适。

from:http://ajoo.iteye.com/blog/23309