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」值,但不適合我的定義? –