Prologでまったり Part4

>>944
このスレw >>933 かな。
Tiebe Index で2月51位からこの二ヶ月で39位まで上昇したのは確か。
ただ、以前の計測が誤りで、修正しただけ、という説も。Prologはプログラム言語の他に歌のグループや
Car racing さらに、アニメやゲームなどにも現れるから、見極めが難しいのかも知れない。

>>946
Tiobe だったか。

処理対象を述語で表すか項で表すか、はどうやって使い分けてますか？

たとえばツリーは
parent(1,2).
parent(1,3).
parent(2,4).
のようにも表せるし
node(1,[node(2,leaf(4),()),leaf(3)]).
のようにも表せますよね。

>>948
項で表すことはしません。全部述語、単位節。
引数としてリスト以外の複合項を渡すこともないですね。

述語はグローバル変数のようなものだから、
引数として項で入力データを渡す方が綺麗だよね。
遅いけど。

>>948
問題解決にノード間の関連が重要な場合は、迷わず命題(単位節)で書く。
そうすることで、grand_parent(X, Y) :- parent(X, Z), parent(Z, Y). のような述語と
その述語を使った演繹(推論)が可能になる。

それは項を使ってもできるでしょ。
ただ述語の引数がひとつ増えるだけで。

>>952
もちろん項表現でもコードは書けます。
ただし「問題解決にノード間の関連が重要な場合」には、
命題として定義するのが望ましいという話です。

項表現が望ましい場合もあります、
たとえば、単純にデータ構造としての直積(C言語の構造体)を表現したいのなら、
項表現を用いるのが望ましいと思います。
この場合には親要素と子要素との間に存在する「親子関係」は無視されますが、
それはそれでかまわないという応用は多々あるでしょう。

述語定義の以前的に構造が決まっている場合がある。例えば行列。それ以前の部分はPrologが関与しない。
句構造文法における辞書とか、あるいは一般的にフレームとか。こういう場合は、構造体を定義する。

変化する部分が少数に特定できる場合は、引数に選択したアトムを指定し持ち回る。
特定できない場合は、フレームが典型ですが、構造体で渡す。そうでないと要素数64のフレームは
64 * 2 = 128 引数以上必要になり煩瑣だ。

つまり、推論のどん詰まり、プリミティブな情報を何に求めるか。構造体であることも有りうる。
しかし、あくまで基本はアトム。集合の外延的記述データ。これを単位節の引数に列記する。

項の場合に親子関係が無視されるというのがわからない。

項表現の利点は
・処理対象データが局所的なこと（物理的にでなく、論理的な意味で）
・prologの持つ一階性の制約を受けないこと（全解計算に集合述語不要）
欠点は
・データを受け渡す記述の手間
・実行効率
だと思う。

基本的に、Haskellのような関数型言語の利点と欠点がそのままあてはまる。

手元の本をみると、技芸は伝統的な述語表現派、Bratkoは項表現派だね。

>>955
解決すべき問題に「ノード間の関連が重要」だとして、以下のように項で表現したとする。(>>948から引用)
　node(1,[node(2,leaf(4),()),leaf(3)]).
この場合、述語 grand_parent/2 を、>>955はどのようにコード化するのだろうか？

% もしも述語表現であれば、>>951のように「論理的に簡潔」なコード化ができる。

>>956
それは面白い指摘だ。

>>955
findall/3, setof/3, bagof/3 のようなメタ述語。述語で指定されたデータからリストへの変換は
Prologそのものであると認識する必要がある。これなくしては、Prologの能力を半分も利用できない。
使用を絶対にためらわないこと。述語定義の作法に悪影響がでる。

>>957の補足。

>>951でも書いたが、項表現を全面的に禁止すべきとまでは考えていないので、誤解しないでほしい。
解決すべき問題が関連(親子/隣接/参照...etc)としてモデル化される場合、それらは命題として表現すべきと考える。
ただし、それらから演繹(推論)導かれた結果を処理するのは、(直積構造としての)項表現が望ましいと思っている。
現実の応用には様々な階層的なデータ構造がある。たとえばCSV/JSON/XMLのように。
演繹の結果をそれら応用に合わせて項として処理(コード化)する事については、何ら反論する気は無い。

Prologの得意とする領域は、>>954で書いてみた以前的な部分ではないか。
それ以後は関数型で書いても差が出ない。現実のデータがどう抽象されるか、
問題の言語的な認識がどう述語として整理できるか、そこら辺にPrologの本領は
あると思う。

関数型言語と比較して、論理型言語であるPrologが優位である点は
関連(relationship)を簡潔に表現できる点にあると思う。

簡単に言うと、与えられた課題が「1対n の単方向写像」として表現(モデル化)できるのなら、
その課題は関数型言語で簡潔に記述できるし、処理効率の面でPROLOGに勝ち目は無い。(...と言い切る)

それに対して、課題が「m対n の双方向写像」であるなら、論路型言語が絶対的に優位となる。
これはデータベースのE-R図やUMLのクラス図を知っていれば、日常的な例であると理解できるはずだ。

ルールを記述する場合においては有利なんじゃないかな。
例えばメールフィルターの設定とかに応用できないかな？
思い付きだけど。

これからソフトウェアはますますインテリジェンスが要求される。
ユーザーは、チェックボックスとかテキストエリアなどに入力した簡単な設定をするだけでなく、
ルールを設定してある程度ソフトウェアに自動化してもらいたいのね。

>>962
なるほどね。
関連を簡潔に表現という部分に補足するなら、返り値が事実上ないと云う点が大きいと思う。
常にデータ構造を平坦に保てる。本体部分のSubgoalも並記されたものとして読めばよい。
だからそれを押し進めて、引数はアトムでありたい、と云うことだと思う。

表現力の話なら述語表現で出来て項表現にできないことはないだろう。
単に述語のリストを作ればいいだけ。

parent(1,2).
parent(2,3).
...

というファクトの集合は
[parent(1,2),parent(2,3)]
という項のリストで表せる。

論点は、効率を取るか、モジュール性や理論的な美しさを取るかの違い。

余談だが、経験的に言うと、項表現の方が述語を双方向的にしやすい。
述語表現ではどうしても副作用に頼る部分がでてくる。

まあリストで持つのは効率悪すぎだから、インデックスがきくような
データ構造を作って、モジュール化してしまうのがいいだろうね。

横からだけど、すごい参考になった。Bratkoって最近四版がでたアレだよな。
Art of Prolog しか持ってないのでちょっと注文してくる。

>>955
> 項表現の利点は (全部略)
> 基本的に、Haskellのような関数型言語の利点と欠点がそのままあてはまる。

全然違うだろ。
文法的には関数型言語はC言語風でも全く問題ない。
ML以降の流れでああなっているというだけで。
Prologはそうじゃない。歴史を無視しても制約がある。

>>968
C言語風とは？

横レスだけど、>>955のカキコ内容が自分にはまるで意味不明 .
しかも、そこからどうやってHaskellうんぬんにつながるのか、まるで分からんw

この流れは >>948 から続いているのかな。そうだとすると、>>948のレスとして、
Prologは述語の節定義を基礎にバックトラックを使ってのプログラミングと、
リストデータを使っての再帰的プログラミングの組合せで書くものだ、という
当たり前のことをはっきり述べるべきではないかな。
巡回問題など木構造を扱うものは、リスト構造を取らず再帰的に書けるが、
これはプログラマが節をまたぐ論理的な連関を仕組んだからで、その努力なしに
書くためのPrologのサービスはリストしかない。
その上で、リストの中に複雑な項(複合項)を書かない理由を述べれば良いのだと思う。

>>971
> これはプログラマが節をまたぐ論理的な連関を仕組んだからで、その努力なしに
> 書くためのPrologのサービスはリストしかない。

トイ・プログラムしか書いたことない人?

Prologはトイ・ランゲージ

>>972
他に何かあったかな？

>>974
functor/3による分解があるということなのでしょう。

DSLを定義して、これの上でアプリ開発、それをPrologで解析して実行というのは
考えらるし、確かに項の読み込みで終始する。でも、そんなことなら最初から
Prologで書きたい。

こんなのあるのね。

Overlay GHC
http://www.media-art-online.org/ghc/

Prologで自然演繹はできますか？

Prologって普通に書いてておもしろい言語だから！！
一番好きな言語がprolog
大学の頃、出会ってよかったと思う。
だからこんなブームが来ると逆に・・・・。

Prologのパズルゲームとかあると面白いかも。
じわじわと迫ってくるインタプリタが来る前に節を追加削除してゴールに誘導するみたいな。

SWI-PrologとGNU Prologってどっちがよく使われてるの？

このすれでSWIとGNUで検索した限りではSWIっぽい。

>>981
SWI-Prolog

日本でPrologがもう一度流行るかどうかは、SWI-PrologとXPCEグラフィックライブラリの
非常によくできた日本語マニュアルが作られるかどうかにかかっている。現在ある、英語版
つまり本家のマニュアルはあまりできがよくないから、これを翻訳したのではだめ。

マニュアル云々より日本語使うと表示が崩れるのはなんとかならんのかね？

開発環境が不満
今どきEmacsでちまちまやってられん
Eclupseみたいに述語一覧とかリファクタリングとか「まともに動く」IDEないのかな

Eclipseみたいな機能、述語一覧とかリファクタリングとかできる、「まともに動く」IDEないのかな

IDEの開発には無茶苦茶労力がかかるし、Eclipse以前以後どんだけ死屍累々だと思ってるんだか。
簡単に言うなって。

>>984
事例がないんだよね。

Eclipseで動作するProlog開発環境を幾つか試してみたけど、あんまり機能が無くて、これじゃEmacsでいいやってレベルだな。

Prolog Plugin
http://eclipse.ime.usp.br/projetos/grad/plugin-prolog/index.html

エジンバラ大学の卒論プロジェクトみたいだけど微妙
ぶっちゃけシンタックスハイライトしか無い。

プログラマがPrologにも手を出す時はIDEをのぞむけれど、
全くのプログラミング初心者の場合は関係ない話だな。
問題は言語が理解しやすいかどうかだろうから。

>>992
実務で利用する人にとっては、開発環境なんてどうでもよく、
サバクラをどう構築するかとか、他の言語インターフェイスは
どんな手段がありうるかといった情報が重要。Prolog単独使用
のケースは少なく、呼ぶか、呼び出されるかという選択になる。
それぞれのケースでどんな問題があるかなどの判断材料が欲しい。
そういうものがしっかりあるかどうかでPrologを採用するか
どうかにも影響がでる。
マニュアルというより、SWI-Prolog詳説といった書き物ね。

それはどうだろう。
理解には試行錯誤が有効。
IDEは試行錯誤を支援してくれる。
例えばプログラミング初心者にJavaを教えるときは、
いきなりIDEをさらわせてHallo Worldを書かせる。
プログラミングという行為において、効率的な意味で開発環境と開発言語は切り離せなくなってきている。

>>993
確かに、内容の過半が主要なメジャー言語とのインタフェイスに取られていて、
Prologと相手言語の間て授受するデータ構造の提案と、その解析の方法が
書かれている大冊の全書本(PDFファイルであっても)があったらすばらしい。