ruby-dev

たけ(tk)です。

kenn さん曰く。
》個人的にはTRON のアプローチが好きなんですが、アプリケーションレベルで
》これを実装しようとすると死ぬ程面倒くさそうだよなぁ…

　僕も TRON の方式が好きです。言語切り替えコード 0xFEnn をテキストに埋め
込んでどんな言語でも扱えるようにする。言語コード切り替えで、言語面（４万
文字）を変えるばかりではなく、検索のアルゴリズムなども変えていく。という
ものだとおもいます。

　しかし、まつもとさんが指摘している Unicode の問題、(c) ラウンドトリッ
プが成立しない可能性。(d)変換による実行効率のペナルティ、(e) インタプリ
タサイズの増大、(f) Ｃライブラリとの関係。などは、すべて、内部コードに TRON 
方式を採った場合でも当てはまる。（独自コードでも同じ）。

　さらに思うに、ＤＯＳなどのようにプラットフォーム自体に制限がある場合に
は、Ruby の内部コードを多言語化しても意味がない。表示も入力も出来ない。

  (c) ラウンドトリップが成立しない可能性。というのは文字セットのサイズ・
範囲が異なれば必然的に出てくる問題。ASCII < JIS < Unicode < TRON という
関係にあると思う。小さなサイズのセットから大きなサイズへの変換は可能だが、
逆は出来ない可能性がある。

　TRON にインプリメントされた Ruby で内部コードが Unicode なら TRON コー
ドが使えなくなるという制限を持ち込むことになるし、逆に ASCII マシンや 
SJIS=DOS,WIN や EUC=UNIX の Ruby で内部が Unicode にしても宝の持ち腐れと
変換による効率低下を招くだけ。

　したがって、Ruby 本体としては内部コードを特定することは出来ない。

　とすれば、Ruby 本体としては単なるバイト列としてしか扱わない。としてお
き、具体的処理は「抽象化されたインターフェース」を通じて、関数ポインタを
経由して、モジュール化した関数を切り替えながら処理を行う。まつもとさんの
表現では「文字操作を抽象化した構造体(各操作毎に関数ポインタを持つ)を経由
して操作する」。ということになるんだと思います。

　モジュールは ASCII版（英語版のWIN、UNIX など多言語フォントを持たないマ
シン用）、JIS版（日本語版の UNIX、WIN）、韓国語版、中国語版・・、 
Unicode 版、TRON 版というように各言語毎に作る必要がある。

　各プラットフォーム（DOS、WIN、UNIX、TRON）ごとにインプリメントされた 
Ruby では、そのプラットフォームに適したモジュールをデフォルトで使用する
ようにセットしておく。

　内部コードは、実際には使用するモジュールに適したものになっているが、
Ruby 本体としてはその名前とそれを処理するモジュールくらいしか知らくてよ
い。Ruby 本体としては、「内部コードはない＝単なるバイト列である」という
扱いしかしない。

　モジュール作りの前に、インターフェースの設計が問題になるかも知れない。
すべてのモジュールで必要な機能を持てるように設計すること、・・などが必要
になる。

　−−

　？？。TRON 方式で、テクストに埋め込まれた言語切り替えコード 0xFEnn を
みて、検索のアルゴリズムなども変えていく、ということは、処理モジュールの
動的切り替えが必要になると言うことか？。そうすると、モジュール切り替え時
の対策も必要になるな。

http://www2.tron.org/troncode.html
をみると、Unicode もTRONコードに含まれている。結局、コード切り替えを考慮
すると言うことはTRON方式と言うことになるのか？。

http://www.personal-media.co.jp/btron/developer/document.html 仕様書

たけ(tk)　ggb03124@nifty.ne.jp
http://member.nifty.ne.jp/take_tk

Thread

Prev Next

In This Thread

Prev Next