to creation-zy:
我大体看了一下你的思路,按我的感觉,就像是我们要写一个脚本解释器,组件就像是一个个的脚本,通过我们的系统让脚本正常运行。如果这样的话,我们写组件是不是要先
学习一下“脚本解释器”的规则?如果规则太简单的话,恐怕不能解释一些复杂的东西,
如果规则太复杂,学习起来就比较费时间,他的存在就没有价值,因为他同一般的解释语
言没有太大的差别(不能让编程变得更简单)。
对于你说的一些细节,我也有一些疑问:
1、>>至于知识化组件的具体实现,我的想法是,一个较为复杂的组件将包含若干个子组
>>件,如此递归定义,直到每个组件都足够“基础”或者“特殊”。
按我的理解,这个定义的过程应该只能通过两种方法实现:
1)、在设计阶段,由设计人员按照自己的理解将复杂的过程分析、简化为一些简单
的、已知的组件。
2)、由设计人员按照一定的规则写出脚本,由程序自动分解成一些小的、已知的组件。
这两个方法,都有一个致命的问题,就是规则足够复杂,学习起来太费时间。参考我上面
解释语言的例子,我觉得有没有必要值得考虑。
2、关于共性”以及“不共性”的抽取问题:
我觉得,其实这就是模式识别的问题,如果提前不预作假设,我们很难识别出我们想要
的答案。举你的例子:
1个苹果+1个苹果=2个苹果 1个葡萄+1个葡萄=2个葡萄 1个鸡蛋+1个鸡蛋=2个鸡蛋
——共性:1+1=2 不共性:苹果、葡萄、鸡蛋
对于这个例子,如果理解的角度不同,抽出来的共性差别是很大的。如果我们丛数的角度
来看,确实是可以抽象出你的答案来,但是离了这个预设的角度,可能答案就不同了。比如
如果我们的角度是从物品的角度来看,那么抽象出来的结果就成了食物。你认为是共性的
1+1=2,在这里没有了意义,你认为是不公性的苹果、葡萄、鸡蛋,反而成了共性的(都是
可以吃的食物)。这个问题足够简单,所以角度不多,如果问题足够复杂的话,这就成了
一个致命的问题,我觉得没法解决。
我觉得这个项目,反而不如你原来的autotool,我们可以给他加上感知别的程序的
功能,看看他是否可以真的学会写脚本。我觉得是有希望的。
另外,你给我的源代码我已经编译通过了(注释掉了两句:(我从网上找的一个单
元中两个函数与你的参数不同)。但是你的脚本在我这里没法运行,我最近时间不多,
你能否给我发个mail,写明白点。看着代码研究程序的功能,实在是痛苦啊
to 楼主:
不好意思,借你的宝地干点私活儿