コンパイル時間の保証に向けてさらに調査しないのはなぜですか？

私はそれがすべてコンパイル時間であり、プログラムをコンパイルするとその実行について多くの保証が行われるという考えが大好きです。一般的に、静的型システム（Has​​kell、C ++など）は、動的型システムよりも強力なコンパイル時保証を提供するようです。

私が理解していることから、Adaはコンパイル時のチェックに関してさらに進んでおり、実行前にさまざまなバグを検出することができます。また、ある時点で、デリケートなフィールド（プログラミングエラーが人命にかかわる可能性がある場合）に選択されたことを考えると、かなり安全だと考えられています。

今、私は疑問に思う：より強力な静的保証が、より文書化され安全なコードにつながるなら、なぜ私たちはその方向でもっと研究しないのか？

欠落しているように見えるものの例はint、基礎となるアーキテクチャのビット数によって決定される範囲を持つジェネリック型を定義する代わりに、範囲を持つことができる言語です（次の例でInt [a..b]は、 aおよびbを含む）：

a : Int [1..24]
b : Int [1..12]
a + b : Int [2..36]
a - b : Int [-11..23]
b - a : Int [-23..11]

または（これをAdaから）：

a : Int [mod 24]
b : Int [mod 24]
a + b : Int [mod 24]

この言語は、範囲に最適な基本型を選択し、式のコンパイル時チェックを実行します。たとえば、次のようになります。

a : Int [-3..24]
b : Int [3..10]

その後：

a / b

定義されることはありません。

これは一例にすぎませんが、コンパイル時に実施できることはもっとたくさんあると感じています。それでは、なぜこれに関する研究がほとんどないように思われますか？このアイデアを説明する技術用語は何ですか（このトピックに関する詳細情報を見つけることができるように）。制限は何ですか？

私はどのくらい言う立場にないですより多くの研究が話題に行われる必要がありますが、私はそこにいることを伝えることができますです例えば、行われている研究は、Verisoft XTのドイツ政府が資金を提供するプログラム。

私があなたが探していると思う概念は、フォーマル検証と契約ベースのプログラミングと呼ばれます。後者はプログラマーに優しい最初の方法です。コントラクトベースのプログラミングでは、最初に通常どおりにコードを記述してから、いわゆるコントラクトをコードに挿入します。このパラダイムに基づいて容易に使用できる言語は、Microsoft ResearchのSpec＃であり、機能的には似ていますが、C＃のコードコントラクト拡張機能はどちらもオンラインで試すことができます（他の言語にも同様のツールがあり、rise4funをチェックしてください）。あなたが言及した「範囲タイプを持つint」は、関数内の2つのコントラクトによって反映されます。

Contract.Requires(-3 <= a && a <= 24);
Contract.Requires( 3 <= b && b <= 10);

その関数を呼び出したい場合は、これらの基準を満たすことが保証されているパラメーターを使用する必要があります。そうしないと、コンパイル時エラーが発生します。上記は非常に単純な契約であり、変数または例外についてのほぼすべての仮定または要件、および考えられるそれらの関係を挿入できます。仮定から。そのため、名前の由来は次のとおりです。呼び出し先は要件を作成し、呼び出し元はビジネス契約のようにこれらが満たされていることを確認します。

$P(x_1,x_2,...,x_n)$$n$$P$使用されている。CS側から見ると、これら2つはプロセスの重要な部分です-検証条件の生成はトリッキーであり、SMTは考慮された理論に応じてNP完全問題または決定不可能な問題です。SMTソルバーをめぐる競争さえあるので、確かにこれに関する研究が行われています。さらに、SMTが現在最も「現代的な」アプローチであるにもかかわらず、状態空間列挙、シンボリックモデルチェック、有界モデルチェックなど、SMTを使用して形式検証を行う代替アプローチもあります。

一般的なアイデアの限界に関して：

• 前述のように、プログラムの正確さを証明することは計算上困難な問題であるため、コントラクト（または別の形式の仕様）を使用したプログラムのコンパイル時チェックは、非常に時間がかかるか、不可能な場合もあります。ほとんどの場合うまく機能するヒューリスティックを適用することは、それに対してできる最善の方法です。
• プログラムについて指定するほど、仕様自体にバグがある可能性が高くなります。これは、プログラムにまだバグがあるにもかかわらず、誤検知（すべてがバグがないにも関わらずコンパイル時チェックが失敗する）または安全であるという誤った印象につながる可能性があります。
• 契約書や仕様書を書くことは本当に退屈な作業であり、ほとんどのプログラマーはそれを行うのが面倒です。コードコントラクトを使用してC＃プログラムをどこでも作成してみてください。しばらくすると、「これが本当に必要ですか？」と思うようになります。そのため、通常、フォーマル検証は、飛行機や自動車を制御するソフトウェアなどのハードウェア設計および安全性が重要なシステムにのみ使用されます。

かなり上記の説明に適合しない最後に一つの価値の言及は、「暗黙の複雑さの理論」と呼ばれる分野、例えばあるこの論文。書くことができる各プログラムが特定の複雑度クラス、たとえばPに分類されるプログラミング言語を特徴付けることを目的としています。そのような言語では、書く各プログラムは自動的に「チェック」できる多項式ランタイムになります。コンパイル時に、単にプログラムをコンパイルします。しかし、私はこの研究で実際に使用できる結果を知りませんが、専門家であることには程遠いです。