F. Schwarzentruber/Electronic Notes in Theoretical Computer Science 278
(
2011
)
187
它 的 工 作 原 理 正 如 [10] 中 所 描 述 的 那 样 。 LoTREC 设 计 用 于 教 育 目 的 [7] 。 与
LoTREC
一样,
LotrecScheme
也提供了模式匹配机制,并允许定义循环检查机制。
然而,
LoTREC
的模式匹配机制存在一些局限性。首先,不可能识别一个不连贯
的模式。例如,不可能编写条件为“如果当前画面包含世界w和世界u ...”的规则 在
LoTREC
中,w和u必须通过 关系
8
.
第二,不可能对世界
9
的名字进行模式匹
配。
LotrecScheme
有一个通用的模式匹配机制来解决这些问题(参见第
3
节中的一
个关于世界名称的模式匹配的例子
LoTREC中的公式 是以前缀风格编 写的,而LotrecScheme可以使用 前缀,in
fix,post fix符号,只要表达式是完全括号化的。例如,命题动态逻辑[a;b](pq)的
公式可以由
; b)(p和q))
作为
LoTREC
,
LotrecScheme
提供了一个图形界面来显示
tableau
和
tableau
方法
的执行。但是LotrecScheme还提供了一个用户图形界面,以便用户查看和设计处理
图形的tableau规则。图形界面的作用基本上是教学。
关于引擎本身,LoTREC不可能动态评估用户编写的表达式,而整数,列表,集
合和其他额外的数据结构通常用于tableau方法(见第4节)。据我所知,动态求值
在Java中很难实现。与LoTREC相反,LotrecScheme允许使用Scheme编写的可执行
代码来丰富tableau规则。从技术上讲,这个特性是通过eval函数完成的。所以
LotrecScheme填补了这个空白,并且是一个通用的证明器,它很容易处理整数,列
表,集合,哈希表等。
LoTREC解决了给定公式的模型构造问题,也就是说,我们想要构造一个包含
满
足
的节点的模型。与LoTREC相反,LotrecScheme还解决了给定图的更一般的模型
构造问题,即构造一个扩展给定图的模型,使得节点w中
的
每个公式都满足w。
不幸的是,与
LoTREC
相反,在当前版本的
LotrecScheme
中还不可能编写任意
策略。LotrecScheme中实现的唯一策略是尽可能长时间地应用给定规则列表中的第
一个适用规则,并在没有适用规则时停止。
但是,这种策略是足够的,当前版本的
LotrecScheme
已经能够为各种模态逻
辑实现许多
Tableau
方法:
K
,
KT
,
KD
,
S 4
,
S 4
。
3
、
S5n
(
[12]
)、
[4]
S5n-PAL
(
[2]
)、
KD
45n
→
Qi+1
→Q
总结
上,
LotrecScheme
结合了
Molle
的图形方面,
OOPS
,
编写Lotrec和LWB
[8]
通过构建普遍关系,总是可以进入
[9]
通过在节点中添加特定类型的公式作为
“name.”
,总是可以模拟世界的名称但这使得画面法成为一种人工方
法。