我看到了各种可能性,它取决于您的应用程序的上下文什么是最好的。请注意,一般来说,用于证明自动化的单个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