akr on diff
-----------

akrさんがdiffについて書いている。当然読む。

[diff3] diff3 を読む
https://www.codeblog.org/blog/akr/20060406.html#p01

[...] せっかく diffutil に入ってるんだから diff 自体をライブラリ化すればいいのに、と思わないでもない。

大賛成。こういう基礎的なアルゴリズムは、ライブラリ化されて、いろいろな言語から使えるようになっているとうれしい（主に僕が）。

そういえばdiffの出力（patch）をパーズするライブラリも欲しい。patchはそういう機能を持ってるはずだから、くくり出してライブラリ化できないだろうか。

どちらも誰かやってくれるとすごくうれしい。よく使うデータフォーマットは筋がいいI/Fで読み書きできるライブラリがあるととても助かる。

でも、--diff-program=PROGRAM というオプションで変更できるようだから、外部コマンドを使うコード自体は必要か。

でもでも、そんなオプション誰が使うんだ、という気もする。

呼び出しのインタフェースが決まっていれば、役に立つかもしれない。外部diffプログラムが備えるべきオプションとその振る舞いや、出力であるclassic / context / unified diffのそれぞれのフォーマットなどが明文化されていれば。以前調べた時は見つけられなかった。

# 余談だけどUnix文化で明文化されてないものって多い気がする。EmacsのTAGS（Vi系のtags）ファイルの形式も、仕様を見つけられなかった。その時はirbのコードを眺めてなんとなく分かった気になった。でも、できれば文書があったほうがうれしい。読み書きできるライブラリがあるとさらにうれしい。

[diff3] アルゴリズム
https://www.codeblog.org/blog/akr/20060407.html#p01

diff は SES (Shortest Edit Script) や LCS (Longest Common Subsequence) と深い関わりがあるが、shortest とか longest とか、ともかく長さに関して限界な結果には複数のケースがありうるのである。

一意に定まらないことには僕も気づいた。僕はアプリケーション指向なので、複数ある候補のなかで、人間にとって最も可読性が高いものを選ぶにはどうしたらいいかに興味がある。

[diff] 許し難い diff
https://www.codeblog.org/blog/akr/20060407.html#p02

追加部分の範囲が関数の範囲とずれている。

たしかに、5行追加という意味では変更量は最小なのだが、この結果はわかりにくい。

そう。自然言語を比較するときも、文や段落をまたがる結果が出力されて参ることがある。人間が理解しやすい出力をするには、どうしたらいいんだろう？

おそらく、比較のための単位に分割する際に、内容ごとに人間が考えた基準で何らかの重み付けをすればいいんだと思う。関数や文というまとまりが維持されたままだとペナルティが少ない、とか。自然言語処理関連でそんな仕組みの解説を見た覚えがある。

いずれにせよ、比較対象の意味を何らかの方法でdiffプログラムに伝えてやらないと、読みやすくならない気がする。Unix diffが、改行文字で区切られたバイト列の配列を比較しているだけのはずなのに、Cなどの文法をある程度理解しているように見えるのは、中でいろいろ配慮してるんだろうな。入力時に、比較対象に加えて重み付けのための情報を与える汎用のルールがあるといいかも。