Prologの「恐怖」を避ける：純粋な宣言型プログラミングへのガイド

Prologは、現代のプログラミング環境において、しばしば反逆的な選択肢と見なされます。Prologを受け入れる人々にとって、この言語は、どのように計算するか（how）ではなく、解が何であるか（what）に焦点を当てることで問題を解決する方法を提供します。しかし、多くのプログラマー（特に初心者）は、Prologの最大の強みを奪い、強力な論理エンジンを脆弱で命令的なスタイルのスクリプトに変えてしまう罠に陥りがちです。

真に効果的なPrologを書くためには、特定の「恐怖」を避ける必要があります。つまり、欠陥のあるプログラム、暗黙的な依存関係、そして言語固有の汎用性の喪失を招くアンチパターンです。言語の純粋で単調な部分集合に従うことで、開発者は、正しいだけでなく、最も一般的なクエリに対しても柔軟に対応できるプログラムを作成できます。

第1の恐怖：解の喪失

プログラムは主に2つの方法で欠陥が生じます。誤った答えを報告するか、意図した解を報告できないかのどちらかです。誤った答えを報告することは問題ですが、有効な解を報告できないことは、リレーション（関係）としてのプログラムの有用性を制限するため、より深刻な問題となることが多いです。

「解の喪失」の主な原因は、不純で非単調な構成要素です。これには以下が含まれます：

  • カット演算子 (!/0)
  • If-then-else 構成要素 ((->)/2)
  • var/1 述語

これらが使用されると、プログラムは純粋な論理的記述ではなくなります。宣言的な代替案は、クリーンなデータ構造、制約（dif/2 など）、および if_/3 のような特殊なメタ述語を使用して、プログラムの論理的整合性を維持することです。

第2の恐怖：グローバルな状態

初心者は、assertz/1 や retract/1 のような述語を使用してグローバルなデータベースを修正することで、Prologを命令的な言語のように扱う誘惑に駆られがちです。これにより、暗黙的な依存関係が導入されます。プログラムの振る舞いは述語が呼び出される順序に依存しますが、この依存関係は論理の中に明示的にエンコードされていません。

これらの述語が意図しない順序で実行されると、プログラムは予期せず失敗したり、不安定な結果を生み出したりすることがあります。解決策は、グローバルな状態を完全に避けることです。代わりに、述語の引数やセミコンテキスト表記法を使用して状態をプログラム内に「スレッド」し、依存関係を明示的かつ保守可能にすることです。

第3の恐怖：不純な出力

もう一つの一般的な間違いは、Prologのトップレベルに報告させるのではなく、システムターミナルに直接答えをプリントすることです（例：format/2 を使用）。

% The Impure Way
solve :- 
    solution(S), 
    format("the solution is: ~q\n", [S]).

このアプローチは非常に制限的です。なぜなら、出力はターミナル上の文字列としてのみ存在し、Prologの項（term）としては存在しないからです。これにより、出力に対する自動テストケースを書くことがほぼ不可能になり、コードを真のリレーションとして使用することができなくなります。

正しいアプローチは、解を記述し、トップレベルに提示を任せることです：

% The Pure Way
solution(S) :- 
    constraint_1(S), 
    etc.

第4の恐怖：低レベルな言語構成要素

多くのプログラマーは、is/2、=:=/2、>/2 のような低レベルな算術述語に固執します。これらは数十年にわたり業界で役立ってきましたが、プログラマーが宣言的意味論と操作的意味論の両方を同時に管理することを要求するため、認知負荷を増ら大、言語の学習や教授を難しくします。

これらの構成要素は、リレーションを関数として扱います。これはPrologの性質に対する根本的な誤解です。現代的な代替案は、Constraint Logic Programming over Finite Domains (CLP(FD)) を使用することです。これにより、整数算術に対するより宣言的なアプローチが可能になります。

ケーススタディ：恐怖の階乗

これらの点を示すために、典型的な「恐怖」の実装である階乗を考えてみましょう：

horror_factorial(0, 1) :- !.
horror_factorial(N, F) :- 
    N > 0, 
    N1 is N - 1, 
    horror_factorial(N1, F1), 
    F is N*F1.

このバージョンは、いくつかの点で欠陥があります。最も一般的なクエリ (?- horror_factorial(N, F).) を実行すると、カット (!) が N=0, F=1 以外の解をプログラムが探すのを防いでしまいます。もしカットを削除しても、is/2 は引数がインスタンス化されていることを要求するため、プログラムは instantiation_error で失敗します。

CLP(FD) を使用した純粋で宣言的なバージョンに移行することで、プログラムは真に汎用的になります：

n_factorial(0, 1).
n_factorial(N, F) :- 
    N #> 0, 
    N1 #= N - 1, 
    n_factorial(N1, F1), 
    F #= N*F1.

これで、クエリ ?- n_factorial(N, F). は、NとFのすべての可能なペア（0,1; 1,1; 2,2; 3,6; など）を正しく生成します。これにより、コードは狭い関数から、強力な数学的リレーションへと変貌します。

統合と展望

純粋性の追求は論理的に妥当ですが、実務家の間ではしばしば議論を論じます。これらの警告は「大げさ」であると主張する人々もいます。特定の具体的な実交用には、命令的なショートカットが許容されるかもしれない、と示唆しています。他の人々は、Prologの理解には、なぜこれらのアンチパターンが問題となるのかを真に理解するために、four-port model のような操作的モデルの深い把握が必要であると指摘しています。

コミュニティの議論から得られる興味深い教訓は、いくつかの文脈においては、後でフィルタリングできる「誤った」答えを報告することは、正しい答えを完全に逃してしまうことよりも許容される場合がある、という認識です。これは、NP完全問題において、有効な解をどれだけ見らずてもよいかという課題に一致する視点です。

Sources