From: Minero Aoki Date: 1999-09-14T16:17:43+09:00 Subject: [ruby-list:16773] Re: maillib? 0.5.0 あおきです。 すみません、出したつもりが出してませんでした。 In mail "[ruby-list:16678] Re: maillib? 0.5.0" wakou@fsinet.or.jp wrote: > 青山です。 > > 以上の理由から、ぼくはリソースの文字列とRDドキュントの処理は、 > > 同種の問題ではないと思います。 > > プログラムの中に書く場合、たとえ RD であっても ruby の解析にかかるので、 > 同じ扱いというか、同じ注意が必要かと思っての事でした。しかし、 (略) > =begin, =end の間にどんなデータが入っても解析を誤らないのであれば、RD > は別として検討しても良いかもしれません。ただし、それが保証出来ないよう > であれば、やはりプログラム中の文字列であるという事を意識して検討しなけ > ればならないでしょう。 整理してみると、問題は2つに分割できます。 1つめは、Rubyがパース(スキャン)するときの問題。(以下[スキャン]) 2つめは、ひとつの場所に多数の言語を対応させるときの問題。(以下[対応]) [スキャン]はキャラクタセットの問題です。 [対応]は言語の問題です。 まず、[スキャン]の問題に関して。 プログラムの文字列の場合は、スキャンを通すのは簡単です。即値の 埋め込みにこだわる必要はありませんから、文字列を加工した形で 保持し、プログラム中で明示的/暗黙的に元の形を復元することが できます。 しかし、RD(埋め込みドキュメント、以下同じ)はそうではありません。 RDは、Rubyに処理された後ではなく、その「前に」lessとかmule (なんでもいいです)で直にソースコードを見た時にそのまま見ることが できなくてはいけませんから、即値埋め込みが必須です。 しかし、青山さんがおっしゃるとおり、この方法で全てのキャラクタ セットの埋め込みに対応することは不可能です。ちょっと調べてみると、 万が一ユニコードあたりを使われると、誤爆する可能性が十分にあります。 一方で、ソース埋め込みのRDはASCIIに限ることにすれば、RDのスキャンには 問題はなくなります。使われる可能性のあるすべてのキャラクタセットに 対応することは不可能ですから、この妥協は現状ではやむを得ないと思います。 そうやって、ASCII以外のキャラクタセットをソースから追いだしたら、 今度は[対応]問題がでてきます。追いだされたASCII以外の部分を どうやって持ってくるかということです。 プログラムの文字列の場合は、「本来の」処理に使われる前に適切な 言語の文字列になればいいので、どんな手段もありえます。プログラム が明示的に解決してもいいですし、インタプリタの協力を得る方法も 考えられます。ここで重要なのは、実装ではなくプログラマに対しての インターフェイスです。 しかしRDはRubyの協力が得られません。Rubyでツールを書くことが できても、やはりそれを動かすにはユーザの協力が必要です。 ここにRDの問題があります。 ようするに、プログラム中の文字列とRDの問題は似てはいるし、根源は 同じところにあると思いますが、対策も方針も環境も違う。 結論としては、このふたつの問題はきっちり分割するべきだと思います。 ------------------------------------------------------------------- あおきみねろう