プルーフアシスタントで「戦術」はどのように機能しますか？

質問：プルーフアシスタントで「戦術」はどのように機能しますか？それらは、用語を等価用語に書き換える方法を指定する方法のようです（「等価」の定義のため）。おそらくこれには正式なルールがありますが、それらが何であり、どのように機能するかをどのように知ることができますか？彼らはベータ削減のための順序の選択以上のものを含みますか？

私の興味に関する背景：数ヶ月前、私は正式な数学を学びたいと決めました。予備調査からは正しい方法（TM）のように見え、魅力的なプログラミングと数学を統一するように思われるため、型理論を採用することにしました。私の最終的な目標は、Coqのような証明アシスタントを使用して理解できるようにすることだと思います（特に、行列のタイプを表すようなものに興味があるので、依存型を使用できると思います）。私は、初歩的な関数型プログラミングでさえほとんど知らずに始めましたが、ゆっくりと進歩しています。型とプログラミング言語（Pierce）の大部分を読んで理解し、HaskellとMLをいくつか学びました。

$A$$B$$A\wedge B$$A\wedge B$$A$$B$同じ仮説で）、補題（〜関数アプリケーション）を適用し、いくつかの帰納的タイプに関する補題を各コンストラクターのケースに分割します。基本的な戦術は、適用されるコンテキストに応じて成功または失敗する場合があります。より高度な戦術は、基本的な戦術を実行する小さな機能プログラムのようなものであり、目標や仮定の用語に対してパターンマッチングを実行し、戦術の成功または失敗に基づいて選択を行います。より高度な戦術では、算術やその他の特定の種類の理論を扱います。Coqの戦術言語に関する重要な論文は次のとおりです。

• D.デラヘイ。システムCoqの戦術言語。Proceedings of Logic for Programming and Automated Reasoning（LPAR）、Reunion Island、volume 1955 of Lecture Notes in Computer Science、85-95ページ。Springer-Verlag、2000年11月。

基本的な戦術の本質を形成する正式なルールは、ここのCoqユーザーガイドまたはpdfの第4章で定義されています。

戦術と戦術（本質的に他の戦術を引数として取る戦術）の実装に関する非常に有益な論文は次のとおりです。

• エイミー・フェルティ。高次プログラミング言語での戦術と戦術の実装 Journal of Automated Reasoning、11（1）：43-81、1993年8月。

Coqの戦術言語には、それを使用して書かれた証明が手作業で行う証明とほとんど似ていないという制限があります。より明確な証明を可能にするために、いくつかの試みが行われました。これらには、Isar（Isabelle / HOL用）およびMizarの証明言語が含まれます。

余談： プログラミング言語MLは、もともとLCF定理証明者のための戦術を実装するために設計されたことをご存知ですか？型推論など、ML用に開発された多くのアイデアは、現代のプログラミング言語に影響を与えています。

実際、LCFはこれらすべてのシステムの祖父です：Coq、Isabelle、HOL、MLプログラミング言語（今日はOCaml、SML、F＃とも呼ばれます）を含みます。はい、Coqをより優れたLCFファミリーのメンバーとして含めています。米国とアメリカの証明アシスタント（特にACL2）、またはまったく関係のないミザールと比較して、Coqは主に戦術の共通の考え方により、イザベルとHOLに文化的に非常に近いです。

それでは、とにかく、書き換え、変換、結合子の導入または削除に関する偶然の観察から取り除かれた戦術とは何ですか？

ここでの主な階層化の原則は、MilnerのLCFから継承されています。

• コア推論（前方推論）。thm元のLCFアプローチの抽象データ型として、またはファミリのタイプ理論ブランチ（Coq、Matita）で証明用語を個別にチェックします。これにより、証明者が定理と見なす結果の特定の論理的基盤が得られます。したがって、primitive Aと⊢Bを取り、⊢A∧Bを与えるプリミティブ推論を使用できます。別のプリミティブ推論は、⊢t = uを与えることができます。ここで、uはtのベータ正規形です。これらのメカニズムはいずれも戦術ではありませんが、標準ロジックのように推論ルールです。

• 目標指向の証明（後方推論）。アイデアは、「ゴール状態」の概念を洗練し、それをより多くのサブゴールに分割し、サブゴールを閉じて、すべて解決されるまで操作するというものです。ゴール状態を終了すると、特定の定理がプロセスからポップされます。LCFは目標に特定の特別な論理的インフラストラクチャを導入しましたが、それはまだHOLにあります。証明の最後に、ジャスティフィケーションが逆の順序で再生され、上記の基本的な推論に従って証明を順方向に生成します。

CoqとMatitaは、まだこのLCF原理にかなり近いです。イザベルはここで異なります。1989年には、ラリーポールソンが目標と戦術の概念を改革し、論理、つまりイザベルの「純粋な」論理フレームワークに近づけました。Isabelle / Pureは、含意==>および量指定子を備えた最小限の高次ロジックを提供します!! 自然な控除規則の構造と目標状態の両方を示します。

たとえば、⊢A ==> B ==> A∧Bは、論理フレームワークの定理としての（オブジェクトロジックの）連結導入ルールです。

ゴール状態も定理であり、最初のクレームCの⊢C ==> Cから始まり、中間状態では⊢X ==> Y ==> Z ==> Cに洗練されます。ここで、X、Y、Zは現在のサブゴールであり、プロセスは⊢C（サブゴールなし）で終了します。

戦術に戻りましょう。これは、これらのすべての証明者により均一です。目標状態の概念（上記のイザベルなど）を考えると、戦術は目標状態を（0、1、またはそれ以上）のフォローアップにマッピングする関数です目標状態。さらに、戦術はそのような戦術的な機能のコンビネーターです。例えば、連続的な構成、選択、繰り返しなどを表現します。実際、戦術と戦術の言語はパーサーコンビネーターの「成功のリスト」アプローチに関連します。

戦術は、目標の絞り込みの特定の戦略を体系的に記述することを可能にします。1970/80年代のLCFでの発明以来、彼らは非常に成功しましたが、悪名高く読めない証明スクリプトを作成しています。

戦術言語のいくつかの側面の最近の概要は、A。Asperti等によるPLMMS 2009の論文に記載されています。22 ページのワークショップの議事録を参照してください。

MizarとIsabelle / Isarは、人間が読める構造化推論の代替アプローチとして言及されており、その意味では戦術に基づいていません。MizarはLCFファミリーとは無関係であるため、その戦術用語はわかりません。Isabelle / Isarはある程度戦術的な伝統を取り入れていますが、証明方法の概念はもう少し構造化されています（明示的なIsar証明コンテキスト、連鎖された事実の明示的な表示、推論の過程での内部目標ハッキングの回避）。

過去数十年間で、戦術言語のさらに多くの改革と再考が行われました。たとえば、Coqコミュニティの最近のブランチは、従来のLtacではなくSSReflect（G. Gonthier作）を好みます。

プルーフアシスタントで「戦術」はどのように機能しますか？

私はこの答えがちょっとしたとりとめになると思います。

第一に、「証明アシスタントでは戦術がどのように機能するか」を尋ねるだけでは十分ではありません。今日使用されている主なアシスタントには、イザベル、HOL、HOLライトなどの元のLCFから派生したものと、CoqやMatitaなどの型理論ベースの証明アシスタントがあります。これら2つの異なるクラスの証明アシスタントでは、戦術はさまざまな方法で機能します。たとえば、イザベルのボンネットの下で行われていることは、たとえばマチタのボンネットの下で行われていることとはまったく異なります。

自問してください：Matitaで命題Pを証明しようとするとどうなりますか？タイプPのメタ変数Xを導入します。次に、いわばゲームをプレイします。完全なラムダ項（メタ変数を含まない）が得られるまで、Xを改良し、不完全な用語に構造を追加します。完全なラムダ項を取得したら、Pに関して型チェックを行い、必要な型に確実に含まれるようにします。CoqとMatitaでは、戦術は不完全な証明用語から不完全な証明用語への単なる機能であり、適用後の用語に少しの構造を追加することを願っています（この観察は、例えばJojgov 、Pientkaなど）。

たとえば、Matitaの戦術「イントロ」は、既存の用語に対するラムダ抽象化を導入し、「cases」は用語内の一致表現を導入し、「apply」は、ある用語を他の用語に適用します。これらの基本的な戦術は、より複雑なものを作成するために、高階関数を使用して一緒に張ることができます。基本的な考え方は常に同じですが、戦術は常に不完全な証明用語に少しの構造を追加することを目指しています。

実装者は、すべての戦術アプリケーションの後に再びタイプチェックする用語を返すことを目指していることに注意してください。厳密に言えば、型理論に基づいた証明アシスタントにとって重要なことは、ユーザーが証明をQedに来たときに、命題Pに属する証明用語を持っているということだけなので、そうする必要はありません。この証明用語に到達したことは、ほとんど無関係です。ただし、CoqとMatitaの両方は、すべての戦術アプリケーションの後に型チェックする（おそらく不完全な）証明用語をユーザーに返すことを目指しています。しかし、この不変式は、特にCICベースの証明アシスタントが実装しなければならない2つの構文チェックに関して、失敗する可能性があります（そしてしばしば失敗します）。

特に、有効な証明と思われるものを実行し、オープンな目標がなくなるまで一連の戦術を適用できます。戦術によって生成された証明用語がこれらの構文チェックの1つを無効にしたため、Matitaの終了チェッカーまたはその厳密な陽性チェッカーが文句を言うことを発見するために、想定された証明をQedします再帰呼び出しは、元の引数より構文的に小さくない用語でインスタンス化されました）。これは、CIC型理論が何らかの意味で「十分に強力」ではなく、その型の陽性またはサイズの構文要件を反映していないことを反映しています（Abelのサイズ型の動機付けと、陽性型に関する最近の研究）。

一方、LCFスタイルの証明アシスタントはまったく異なります。ここで、カーネルは、抽象型「thm」を含むモジュール（通常はMLのバリアントで実装されます）、および証明アシスタントのロジックの推論規則を実装する関数で構成され、「thm」を「thm」にマッピングします。前方へ。型 "thm"の値を構築する唯一の方法がこれらの推論規則（基本的な戦術）を介して行われることを保証するために、MLの型付け規則に依存しています。Isabelleのカーネルはこちらです。

証明は、これらの基本的な戦術の一連のアプリケーションで構成されます（または、より高次の関数を使用してより単純な戦術をつなぎ合わせて作成される、より複雑で大きな戦術--- Isabelleでは、戦術と呼ばれる高次の関数は、ここで見られます）。型理論ベースの証明アシスタントとは異なり、LCFスタイルのアシスタントでは、明示的な証明用語の証人をいじっておく必要はありません。証明の正確性は、構造によって保証され、MLのタイピング規則に対する信頼（ただし、Isabelleなどの多くのアシスタントは、証明のために証明用語を生成します）。