Lisp と論理

結城浩さんの日記経由で，回りまわって，限りなく論理に近づいていく言語が Lispという言及を見て，違和感を感じました．

というのも，私の中では，λ計算 = Lisp = S 式 = アセンブリ言語 = 機械語までが，自然に無理なくつながるのですよ．

確かに，Lisp は λ 計算という数学的な枠組みを実際に動かせる形にしたものですから，論理 (数学) にも近いです．

しかし，例えば Prolog や Haskell や ML のように，どっからどう見ても機械語とは似ても似つかない，(限りなく論理よりの) 超高級言語とも，単純には言い切れないと思うのですよ．

LISP は高級言語だが，それでも，ビット表現が透けて見えると感じることがある． --- Guy L. Steele, Jr. (ダニエル･ヒリス，思考する機械コンピュータ，pp.102)

今，コンパイラ関係のことをいろいろやっているのですが，結局最終的には，S 式をゴニョゴニョやって，プログラム変換なり，最適化なり，コードジェネレートなりをやることになります．

そして感じるのは，なんて S 式って，扱いが楽 (特に，ET のように，パターンマッチングが使える言語では．ET の D ルールは，ぶっちゃけ，パターンマッチングが使える (Prolog なり，ML なりの，項書き換え系の類．いわゆるルール型言語) Lisp です) なんだろう ！ ということ．

一見 S 式は，機械語とは完全に対照的な見た目で，いかにも距離がありそうです．でも，GCC の中身は，とどのつまり， RTL という S 式の中身を弄繰り回しているだけです．

マクロを駆使して，構文を (S 式の範囲で) 変更して，抽象度を追及することもできますし，その気になれば，プログラム自体が抽象構文木なので，いきなりそこから機械語を生成することもできると．

ここらへんに，Lisp の強力さと奥深さの源があるような気がします．

ただまぁ, 逆に言えば，抽象構文木なんて，人間が読んだり書いたりするもんでもないなとも感じます (笑)

今かなり眠いので，これ以上は書きませんが，これからの時代は，

何らかの仕様記述手法

↓ プログラム合成

ひたすらプログラム変換 (S 式ベース)

↓ シームレス (ブラックボックスではなく，透過的)

できるかぎり最適化された S 式 (ほぼ抽象的な機械語と一対一対応レベル，いわば，アセンブリ言語までなめらかにつなげる)．

↓ コードジェネレート

計算機で実行

という流れに，必然的になっていくと思います (もちろん，こんなに単純ではなく，何十，場合によってはそれ以上の階層 (フェイズ)に分かれると思います)．

# 間を知らなくても良い，というのは理想ですが… プログラム変換の成熟が進み，計算機のパワーが上がれば上がるほど，人間が手で編集する必要性は減ると思います．

ちなみに，私は，「コンパイル」という言葉にも，何か違和感というか，嫌な感じがします．

まるで，あたかも，何らかのブラックマジックで，人間が読む高級言語が，小人さんの魔法であら不思議，機械が読める機械語に ！ というニュアンス (二極化) を感じるもので．

とどのつまり，今までの言語は，高級な部分と，実際の泥臭い部分が分離･乖離しすぎで，無理がありまくりなんですよ．

C++ のコンパイラ作成には，だいたい 10 年かかる，なんていうじゃありませんか．

もちろん，普及させた努力，現実的な制約と真正面から戦い続けた，という功績は，とてつもなく偉大だと思います．

しかし，もし普及してなかったら，ちゃんとしたコンパイラがなかったら，あるいは，互換性を気にする必要性がなかったら，C++ を使う論理的必然性はないな，という気はします．

# むしろその努力，マンパワーを，別の方に向けたほうが… C++ しか現実的には選択肢がない，という現実もあるのでしょうが，もし別な，今は C++ には及ばない，あるいは不十分でも，もっと大局的に見たら芽がありそうなものが他にあるのでは… という気がしてなりません．

Lisp が，継続やマクロなどの，極めて高級な部分から，自分自身のコンパイラ，アセンブラ，さらには自分自身を実行するハードウェアの記述言語までの役割を，完全にシームレスにこなすことができるように．

全ては，意味保存の変換 (等価変換) の繰り返しという枠の中で，各ステップが厳密に検証されて，証明のように進んでいくべきだと思います．仕様の等価変換がプログラム合成で，プログラムの等価変換が最適化 (プログラム合成) なりコード生成で… と．

ただ，Lisp は Lisp で，やはり人間が読み書きするのは多少無理があると思います．

# いやいや，本物の Lisp プログラマに不可能はない，ということは，もちろんわかっているさ．OK OK．でもここでは一般論を語っているんだ，私のメールボックスを抗議や改宗を強要するメールで溢れさせないでくれよ (Joel 調)

※ 何度も言いますが，私は C 言語も，Lisp も，個人的には好きです．C++ は… 「本物のプログラマ」が使う，最もパワフルな言語だと思いますよ．

そこで，何らかの (問題領域にあわせた) 仕様記述手法，仕様からのプログラム合成，プログラム変換 (たとえば，仕様を満たす範囲で，なるべくオブジェクトコードをカリカリにチューンするために，たとえ動的型付けの言語でも，できるだけ型推論して (まぁ，Common Lisp みたいに，クリティカルな部分には型をつけまくるようなイメージ)，動的な型検査のオーバーヘッドを排除して，データ構造を変換して，制御構造を変換して，中間構造を排除して… みたいな感じ．C と同じ程度の情報を与えれば (抽象度を下げる) 同じかそれ以上のコードは普通に生成できるでしょう．C は，文法もセマンティクスもメチャクチャで，ただ普及度と歴史で無理やり長年やってきたから，良いコードが生成される，というだけで，理論的な必然性は何もないと思います ※) あたりが重要になってくるのではないかと．重要なのは，全てを体系的に，なるべく自然に，厳密につなげていくことだと思います．

※ ただし，何度も言いますが，私は C 言語はけっこう好きです．なんだかんだいって，一番馴染んでますし．

ただひたすら快適さを追い求めて，言語のブラックボックス化を進めて，汚いところは全部見てみないふりをするんじゃなくて，ちゃんと全部透過的にやっていきたい，という点では，リンク先の意見と共通しますね．

# おおっと，ここまで書いてきておいて，単なる揚げ足取りだったくさいぞ ｗ すみませんでした ！

これをちゃんとやっていけば，二極化 (仕様とプログラムの乖離) も防げますし，「コード効率」も保てるのではないかと思います．

もちろんすぐにできるようなことではありませんけど，本当にちゃんと腐りきった計算機科学を正そうと思ったら，目新しい開発手法やフレームワーク，小手先の技術ではなく，ちゃんと着実に，あたりまえのことをあたりまえにやって，足元を固めていかないと駄目だと思います．

# まるで小泉政権ですな ｗ うさんくさー ｗ

もう疲れて眠くて眠くて，文章が支離滅裂で，全然整理されていないため穴だらけだと思いますが，そのうちちゃんとここらへんを書いて見ます．

この記事は，メモということで，リリース．普段よりも勢いだけはあるかもしれないので，消すのも惜しいかなと (●'ω'●)

気を悪くされた方がいましたら，本当にすみませんでした (*´-ェ-)

右も左もわかってない，現実を知らない，生意気な若造のたわごとということで （；^ω^）

何卒大人な対応で，よろしくお願いします (弱気)