Common Lisp キモイ
ここいらでちょっとマクロをちゃんと理解しておくかとちょっと思ったのと、関数がネイティブコンパイルできてさらに逆アセンブルして生成されたバイナリを確認する、なんてのがインタプリタ*1上で全て行える、という変態的なところに憧れて、On Lispを読みながらSBCLというCommon Lispに手をだしてみたが、うーん。
schemeに慣れてると、関数と変数の名前空間が別*2なせいで、いろいろと気持ちわるい。特にシャープクォートとfuncallがキモイ。なぜにシンボルにバインドされたものが関数なのか値なのかを意識してコードを書かないといけないのか。表面的には、文法がいっさい存在せず一様に（）でくくればOKなLispだけに、そこの差異が非常に気にかかる。一発シンボル評価すれば、関数でも値でも同じように結果が返ってくるschemeのシンプルさのほうが好きだなあ。
マクロを使うときには、関数と名前空間が別なのが便利らしいけどそこまではまだ読めてないのでなにがどう便利なのか謎。で、そこに到達する前に、変数のキャプチャとかいろいろマクロの暗黒面が押し寄せてきて、どうにもすっきりしないんだなあ。アドホックなバッドノウハウの香りがぷんぷんする。強力なのはすごく良くわかるけど、もう少しなんとかならないものか。schemeのマクロのほうがすっきりしてる？
インタプリタ上から関数がネイティブコンパイルできて、さらにdisassembleまでかませられるscheme処理系があったらそっち使いたいんだけど、あるかな。gaucheはネイティブコンパイルまではしないしなあ。
あと気になるのが、構文木を操作するマクロと、文字列を操作するPHPやらerubyやらamritaやらのテンプレートエンジンとの関係。これ、操る対象は全然違うけど、概念的にはかなり近いところにある気がする。バッククォート+カンマでマクロ展開するとこなんてテンプレートそのまんまなわけだし。テンプレートエンジンはいろんなやり方があちこちで試されてる気がするから、そういう知見がマクロの構成法にもいかせないんだろうか。テンプレートはモナドである！なんて話もあるし。そのへん加味しつつ、もうちょっとひねるとマクロへの一貫性ある上手い適用法が見えてきたり、、しないかなあ。しないか。On Lisp全部読んでからまた考えよう。
