data So : Bool → Set where
oh : So true
So
升降机布尔命题到逻辑一。 Oury和Swierstra的介绍性文章The Power of Pi给出了一个由表格列索引的关系代数的例子。以两个表的产品需要,他们有不同的列,为此,他们使用So
:
Schema = List (String × U) -- U is the universe of SQL types
-- false iff the schemas share any column names
disjoint : Schema -> Schema -> Bool
disjoint = ...
data RA : Schema → Set where
-- ...
Product : ∀ {s s'} → {So (disjoint s s')} → RA s → RA s' → RA (append s s')
我已经习惯了建设证据词,因为我要证明我的节目的事情。这似乎更自然构造上Schema
个逻辑关系,以确保脱节:
Disjoint : Rel Schema _
Disjoint s s' = All (λ x -> x ∉ cols s) (cols s')
where cols = map proj₁
So
看起来比一个“正确”的证明长期有严重的缺点:图案oh
匹配不给你任何信息你可以使用另一个术语类型检查(是否?) - 这意味着So
值不能有用地参与交互式证明。将其与Disjoint
的计算有用性进行对比,其表示为s'
中的每列未出现在s
中的证明列表。
我真的不相信规格So (disjoint s s')
简单比Disjoint s s'
写的 - 你必须定义布尔disjoint
功能,无需从类型检查的帮助 - 在任何情况下,当你想操纵Disjoint
收回成本其中包含的证据。
我也怀疑So
在构建Product
时节省了工作量。为了给出So (disjoint s s')
的值,您仍然必须在s
和s'
上进行足够的模式匹配以满足实际上不相交的类型检查器。放弃由此产生的证据似乎是一种浪费。
So
对于部署它的代码的作者和用户来说似乎都很笨拙。 '那么',在什么情况下我想用So
?
此外,每一个证明 “所以b” 为propositionally等于任何其他,对于b编码的任何属性的实际“证据”来说并不一定是这种情况。有时候你想要。 – Saizan
@Saizan,好点。这个属性也在我的答案中的第二个链接中被利用。你有没有好的用例? – user3237465
我觉得这里有更深层次的关于用'data'感应定义的类型与函数中递归定义的类型之间的关系。你能否详细说明为什么Agda很乐意用你的定义推断一个“So”值,但不适合我的定义? –