我看到了各種可能性,它取決於您的應用程序的上下文什麼是最好的。請注意,一般來說,用於證明自動化的單個ML代碼在過去很常見,但現在比較少見。例如,比較法新社(從2007年開始,一直持續到最近)的非常小的HOL-Bali(1997年開始)與大JinjaThreads的自定義戰術的數量。
嵌套ML反語(如@{tactic}
)原則上可以工作,但您很快會遇到更多問題,比如如果您的定理參數應該是Isar或ML來源,會發生什麼情況。
代替antiquoting在ML戰術積木,一個更基本的做法是報價在伊薩爾你證明precedure通過給予普通方法的語法如下:
ML {*
(*foo_tac -- the payload of what you want to do,
note the dependency on ctxt: Proof.context*)
fun foo_tac ctxt =
let
val my_ctxt =
ctxt |> Simplifier.map_simpset
(fold Splitter.add_split @{thms prod.splits} #>
Simplifier.add_simp @{thm split_def})
in ALLGOALS (clarsimp_tac my_ctxt) end
*}
method_setup foo = {*
(*concrete syntax like "clarsimp", "auto" etc.*)
Method.sections Clasimp.clasimp_modifiers >>
(*Isar method boilerplate*)
(fn _ => fn ctxt => SIMPLE_METHOD (CHANGED (foo_tac ctxt)))
*}
在這裏,我第一次在Isabelle/ML中定義了一個傳統的foo_tac
定義,然後用通常的伊薩爾方式作爲證明方法。後者意味着你有像SIMPLE_METHOD
這樣的包裝將「連鎖事實」推送到你的目標狀態,CHANGED
確保Isar方法取得進展(如simp
或auto
)。
foo_tac
示例假定您通過硬連線拆分規則對上下文(或其simpset)的修改是恆定的。如果你想在那裏有更多的參數,你可以在具體的方法語法中包含它。請注意,Method.sections
在這方面已經相當複雜。在isar-ref手冊的「Defining proof methods」一節中給出了更多基本的參數解析器。您還應該通過搜索method_setup
(位於Isabelle/Isar)或Method.setup
(位於Isabelle/ML)的源代碼查看現有示例。
如果你還想做ML antiquotations,而不是具體的方法的語法,一個可以嘗試的@{context}
一個變種,它允許修飾符是這樣的:
@{context simp add: ...}
這是一個有點投機,發明了當場,和可能會變成糟糕的做法。正如我所說的,近年來,伊莎貝爾細緻的策略編程已經有些失用了,儘管ML是伊莎貝爾框架的一個組成部分。如果你用更多的應用上下文提出更具體的問題,我們可以重新考慮反引用方法。
你可能想看看'try0'的代碼。 AFAIK,它與你提出反引用的建議類似。 – 2013-03-06 07:09:33
@LarsNoschinski:'try0'最初看起來很有前途,但不幸的是使用了校驗狀態('state')對象,但仍不能用於需要「策略」的情況。一種可能的方法是將已部分驗證的'thm'注入新的證明狀態對象,對其應用一個方法,然後提取結果;不幸的是,似乎沒有明顯的機制來做到這一點。 – davidg 2013-03-07 02:55:24
隨着一些問題和答案和評論蔓延在他們身上,它變得有點難以遵循。更好地在'isabelle-users'開始一個簡單的郵件列表討論。 – Makarius 2013-03-07 11:10:09