From: URABE Shyouhei <shyouhei ice.uec.ac.jp>
Subject: [langsmith:117] Re: はじめまして
Date: Tue, 7 Sep 2004 19:15:54 +0900

> On 07 Sep 2004, at 18:49, Tsuguo MOGAMI wrote:
> 
> > わたしにとっては（例えばLISPのように）プログラム自体をファースト
> > クラスのデータ型としてプログラムからいじくることが出来る事が「良
> > い言語」の絶対の条件です。
> 
> それができれば便利は便利ですが、たとえばbuffer overrunの典型的な手
> 口を考えれば、やはりプログラムとデータは分かれていた方が安全なのか
> なという気がします。

「プログラムとデータの分離」と言った場合、フォーマットの分離なのか
フェーズの分離なのかを意識しておく必要があると思います。(これらの
用語は俺定義なので、本当は正しい用語があるのかもしれませんが)。

「データとして受け取った『何か』を実行できる」という意味では、
evalのある言語は全て、データがプログラムになり得ます。但し、
「データが化けるプログラム(Y)」と「それを扱うプログラム(X)」の間の
結合強度は色々です。結合の強い順にいくつか並べると：

(1) Yの実行がそのevalを含むXの(静的/動的)ローカル環境を参照、変更できる
(2) Yの実行がXのグローバルな環境を参照、変更できる
(3) Yの実行がXの制限された環境を参照、変更できる
(4) Yの実行はXの環境を参照、変更できない

結合が強いものほど、プログラムの意味が元のプログラム(X)だけでなく
データ(Y)に影響される度合いが増します。プログラムの静的な字面と
実行時の動作とが分離されてない、とも言えます。動的な柔軟性は
増しますが、コンパイル時の最適化はやりにくくなり、邪悪なデータに
よる危険性は増します。結合が弱く、(3)や(4)くらいになると、
プログラムの静的な意味(コンパイルフェーズ)と実行フェーズとが
かなり明確に分かれることになります。もちろん、言語として基本は(1)だが
オプションで(3)などを許す、というようなハイブリッドな構成もありでしょう。

フォーマットの分離とは、プログラムを表現する基本的なデータ
構造と、プログラム自身のデータ構造とが分離されていることを指します。
evalが文字列を取り、その環境で実行されるような言語は、同一フェーズで
データがプログラムになりますが、データの表現(文字列)はプログラムの
データ表現(普通は抽象構文木に類するもの、他の表現があっても構わないが)
とはかけはなれています。これもある程度主観的な判断が入り、昔のTclみたい
に何でも文字列なら両者は同じ、と言えるんじゃないか、なんてことも
考えられますが、実際的な解釈としては、プログラムでどれだけ簡単に
「プログラムとしてのデータ」を扱えるか、ってところが尺度になるんじゃ
ないかと思います。

Lisperがしばしば強調する「プログラムとデータの同一性」は、主として
フォーマットの同一性の方を指すのではないかと言う気がします。
R4RSまでのSchemeはevalが無く、「プログラムとしてのデータ」と
「それを解釈するプログラム」との間には越えられないフェーズの壁が
ありました (loadを使う抜け穴は除いて)。それでもSchemeはLisp一族
とみなされていたわけです。(Lisp族の中では、R5RSの字面の解釈を巡って
「SchemeはLispではない」というのがホットな論争になることがありますが、
外から見たらどれも同じですよね)。

フォーマットが同一である利点は、Lispのマクロに代表されるような、
プログラムを扱うプログラム、すなわちメタプログラムが容易に書けることです。
マクロでなくても、あるプログラムや設定ファイルを読み込んで、何か
複雑な動作をするプログラムを自動生成する、という一種のマクロ
プロセッサは、Lisperなら呼吸するように書いていることでしょう。

それぞれの分離、あるいは同一化のメリットに関しては、プログラミング
スタイルや言語の用途によって意見が分かれるところだと思います。
私自身は、わりとコンパイル時の最適化なんかに興味があるので、
「フォーマットは同一だが、フェーズは適当に分離されている」方が好みです。

--shiro

--
ML: langsmith quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml