今まで何回も取り上げてきた「マイクロフォーマット」ネタですが、Allsopp本の翻訳が
マイクロフォーマット Webページをより便利にする最新マークアップテクニック
というタイトル（仮題）で毎日コミュニケーションズから出版されるようです。情報元は「Web標準Blog」で、監修の木達一仁氏が関わっている会社です。
ちなみにセミナーも Allsopp 氏来日に合わせてあるようですが、これは満員御礼だそうです....
やはり関心ある人多いでしょうね...本は「買うべし」です（ただしエントリ時点で毎日コミュニケーションズの近刊予告には入っていないようです）
前回のエントリ...に限らず、私って平気で「コーラー側」という言い方をしてたのですが、"コーラー側" でググると、あまりコレ引っかからないのですね....
要するに
コーラー(caller) ＝（関数・メソッドの）呼び出し側
コーリー(callee) ＝（関数・メソッドの）呼ばれた側
のことを言います。あれぇ、私はプログラマの日常口語だと思ってたのですが、知らない人が多いみたいなのですね（まあ、「コーラー側」と使うと、「馬から落馬」みたいな冗語っぽいニュアンスがないではないですが）。
とはいえ、caller/callee は（明確な）技術用語で使われている箇所っていうのはあります。皆さんおなじみの JavaScript ですけども（まあ、他のスクリプト言語でも同様な実装があるのでは？）、関数の中で「隠し持っている（実際には関数呼び出し時にセットされる）」arguments というオブジェクトがあります。これは「その関数の呼び出し環境（スタックフレームみたいに考えて良さそうです）」を示し、名前の通り「その関数に渡された引数」を配列として持つのが本来の役割です。しかし、この arguments オブジェクトには、caller と callee という２つの重要なプロパティがあります。
JavaScript の arguments オブジェクトの
callee プロパティ： 現在実行中の関数オブジェクトを示します。
caller プロパティ： この関数を今呼んでいる「呼び元の関数の arguments オブジェクト」を示します。
というように、このargumentsはうまく使うとかなり面白いことができます。arguments オブジェクトはJavaScript 関数の汎用カリー化関数とかで「任意数の引数を再適用する」ところで使ってたおぼえもあります...たとえばですね、JavaScript では「無名の関数」を function() {} などで作ることができますが、この「無名の関数」内で、再帰呼び出しをしたい場合
.....あれ、名前がないから再帰で呼べない...
となりますけども、実はこれ、callee プロパティを呼べばいいのです。
function show(n,m) {
alert( function(x) {
if( x > m ) return x * arguments.callee(x-1);
return 1;
}(n) );
}
n!/m! を再帰的に計算するルーチンならば、こんなところでしょうか。show() の内部で再帰計算をする無名関数を作って、それを引数 n で起動した結果を alert() しています。m の束縛はいわゆるクロージャです。あるいは、caller を使うと、スタックトレースが取れます.....しかし、この caller は JavaScript 1.5 では deprecated の扱いのようですが（がまだIE/FireFox共に動きますね！よかった...）
まあ、この caller/callee というプロパティは「スタックフレームへの参照」ですから、どんなスクリプト言語でも、「言語設計者が実装しようと思えば装備できる」プロパティです（逆に言うとかなり初期からこれを持つ発想のあった JavaScript の設計は評価すべきでしょう。参照方法はともかく、アイデアいいです）。同じようなプロパティが他の言語にもある可能性は高いですね....
そう考えてみたら、プログラマ用語として「コーラー・コーリー」を使う...というのはけして珍しいこと、とまでは言えないのでは？と思います。個人的には時代遅れになってなくって良かった（苦笑）....
書き出した時点で、お昼休憩中です。皆さんお昼ご飯はいかがでしたか？お昼ご飯代はおいくらでしたか....という話では、残念ながらないです（ちなみに私は大概会社の近くの自宅に帰ってお昼ご飯です。今日は昨日の残りモノで、鳥ごぼうご飯と、アスパラのおひたし、大福豆、大根おろし＋金山寺味噌というメニューでした）。
お昼ごはんはタダではいけません！ というのは、有名なＳＦネタのジョークです。「ノーフリーランチ定理」と呼ばれる面白い定理があります。それは、
数学的にありうべき全ての問題の集合について、どの探索アルゴリズムも同じ平均性能を示す
と主張します。結構意外じゃないですか？
プログラマ、というと「このアルゴリズムは性能がいい／悪い」というのを肌で知ってる...というのが望ましいですけども、しかし、それは「日常に現れる一般的な問題」の場合に「性能がいい・悪い」という議論をしているだけなのです。プログラマだったら、「いいアルゴリズム」がデータによって「ウラをかかれ」た経験があるんでは..と思います。たとえば、速いアルゴリズムの代表であるクィックソートは、すでに整列したデータを与えた時に、O(n2 ) にまで性能が劣化します。勿論「ホントにいいアルゴリズム」の場合は「最頻のケース」と同様に、「最悪のケース」に対する備えを心がけるべきなのですが....
このノーフリーランチ定理を言い換えると、
あらゆる問題で性能の良い汎用最適化戦略は理論上不可能であり、ある戦略が他の戦略より性能がよいのは、現に解こうとしている特定の問題に対して特殊化（専門化）されている場合のみである
ということになります。「よくある場合に性能がいい」と「ウラをかかれると性能が悪い」とは同じことの両面に過ぎないことをこの定理は示すのです。汎用的であればあるだけ、「最良の場合の性能」は悪化してしまいます....汎用性と特殊性のせめぎあい、というプログラマがいつも頭を悩ます問題というのは、回避不可能な本質的な問題なのです。
これはもっと広く考えて、問題とその解決法、という視点で考えるのも面白いでしょう。問題を「汎用的に解決する」のは非常に難しいわけです。
人生、宇宙、すべての答え
という極めつけの「汎用的な問い」への答えを要求された銀河最高のコンピュータ「ディープ・ソート」は、
42
という極めて「汎用的な答え」を返します（詳しくは「銀河ヒッチハイクガイド」を...）。「42」は答えに違いないのでしょうが、それは人間にとって「利用可能な答え」ではありえないのです....「汎用的」なのがいつもいつも正しいわけではないのです。
