Prolog初学者 - 这是一个坏主意吗？

Question

我正在处理的应用程序是各种各样的"配置器".它是用C#编写的,我甚至编写了一个规则引擎来配合它.这个想法是有一堆命题逻辑语句,用户可以进行选择.根据他们选择的内容,其他一些项目变得必需或完全不可用.

命题逻辑语句通常采用以下形式:

A => ~X 
ABC => ~(X+Y) 
A+B => Q 
A(~(B+C)) => ~Q A <=> B

符号:

=>  -- Implication
<=> -- Material Equivalence
~   -- Not
+   -- Or
Two letters side-by-side -- And

我对Prolog很新,但似乎它可以为我处理所有"规则处理",允许我摆脱目前的规则引擎(它可以工作,但它不是那么快或容易按照我的意愿保持).

此外,所有可用选项都属于层次结构.例如:

Outside
   Color
      Red
      Blue
      Green
   Material
      Wood
      Metal

如果暗示了第二级(特征,如颜色)的项目,则必须选择第三级的项目(选项,例如红色).同样,如果我们知道某个功能是假的,那么它下面的所有选项也都是假的.

问题在于每个产品都有自己的一套规则.设置包含这些运算符作为谓词的知识库是一种合理的方法,然后在运行时开始构建产品的所有规则吗？

我想象它可能会起作用的方式是建立组件,功能和选项的想法.然后设置then之间的关系(例如,如果该功能为false,则其所有选项均为false).在运行时,添加产品的特定规则.然后将所有用户的选择传递给一个函数,检索哪些项为真,哪些项为假.

我不知道我所要求的所有含义,因为我刚刚进入Prolog,但我正试图避免走上一条糟糕的道路,并在此过程中浪费大量时间.

一些问题可能有助于针对我想要找到的内容:

1. 这听起来有效吗？
2. 我吠叫错了树吗？
3. 尝试在运行时创建所有这些规则有任何缺点或顾虑吗？
4. 有没有一个更好的系统来支持这种事情,我可能会挤进一个C#应用程序(Silverlight,确切地说)？
5. 我还应该检查其他竞争系统吗？
6. 你对这类事有什么一般的建议吗？

提前感谢您的建议!

Answer 1

1. 当然,但Prolog有一个学习曲线.
2. 基于规则的推理是Prolog的游戏,尽管您可能需要将许多规则重写为Horn子句.A+B => Q是可行的(它成为q :- a. q :- b.或q :- (a;b).)但你的其他例子必须重写,包括A => ~X.
3. 取决于您的Prolog编译器,特别是它是否支持动态谓词的索引.
4. 搜索"前向检查","推理引擎"和"业务规则"等术语.各种社区不断为这个问题发明不同的术语.
5. 约束处理规则(CHR)是一种逻辑编程语言,实现为Prolog扩展,更接近基于规则的推理/转发链/业务规则引擎.如果你想使用它,你仍然需要学习基本的Prolog.
6. 请记住,Prolog是一种编程语言,而不是逻辑推理的银弹.它削减了一阶逻辑的某些角落,以保持事物的高效可计算性.这就是它只处理Horn子句的原因:它们可以与程序/子程序一对一映射.