【发布时间】:2016-01-21 02:51:07
【问题描述】:
So 类型的预期用途是什么?音译成Agda:
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')
我习惯于为我想证明的关于我的程序的事情构建证据术语。在Schemas 上构建逻辑关系以确保脱节似乎更自然:
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?
【问题讨论】:
标签: functional-programming agda dependent-type idris