読者です 読者をやめる 読者になる 読者になる

プログラム=データをまじめに検討してみる

Twitterで話した/聞いたことのまとめ.

まず,プログラム=データは,次の二つに分けることができる.

  1. プログラム→データ
  2. プログラム←データ

プログラムをデータに変換する方法が用意されていて,データをプログラムに変換する方法が用意されていれば,プログラム=データと言えると思う.

まず,データ→プログラム,というのは,いまどきの言語ならなんでもついているevalのこと.この意味で,LispJavaScriptも,RubyPerlも,リストか文字列かという差以外に,なにも差は無い*1.ちなみにこの性質を満たさない言語は,わりとあって,OCamlとかCとか(いや,アクロバティックなことすれば,けっこうできると思いますが).

しかし,プログラム→データ,というのは,けっこう難しいんじゃないかと思う.これはつまり,プログラム((lambda (x) (+ x 1)))からソースコードが得られるか,という問題.別にソースコードじゃなくて,リストでも良い.例えば,Schemeはムリだし(多分),Rubyもムリ.実は,JavaScriptはけっこうがんばってて,javascript:(function (x) { return x+1; }).toString();とかすると,ソースコードが表示されたりする.当然,evalすれば同じ挙動をする関数が得られる.

残念なのは,javascript:(function(x) { return function() { return x; }; })(3).toString();としたときに,function () { return x; }とか表示されるところで,こいつをevalしても元には戻らない.惜しい.

しかし,完璧にプログラム=データではないとはいえ,JavaScriptはけっこう良い線行ってて,Lispなんか目じゃない,と言える,と思った.Lispは,当時のほかの言語に比べれば,プログラム=データにはるかに近かったのかもしれないが,いまどきの言語と比べたら,大した特徴じゃないよね,と思った.





そして,CommonLispのfunction-lambda-expressionを知って,負けを悟った.CommonLispすげー.

http://www.lisp.org/HyperSpec/Body/fun_function-_a-expression.html

*1:リストになってれば,操作が楽じゃん,という話はありうる.がそれはここでは本質とは認めない