rhinoのi18nとL10n

文字列リソースはプロパティファイルで外部化されていたりL10nはある程度考慮されている。
しかし、コードがascii以外の文字を考慮してなかったりi18nの方は不完全の模様。

具体例を気づいた範囲で挙げてみる

  • シェルでコード補完を有効にすると化ける
  • デバッガでエディタ部の表示が化ける
  • commonJSで日本語が化ける

シェルが化けるのはJLineがi18n対応していないためこっちを変更する必要がある。
デバッガは内部でストリーム処理してる部分、PrintStreemとかの扱い方の影響。
ソースを読んだ感じこれはデバッガにパッチ当てる形式ではソースの変更・メンテが辛い。
commonJSに関してはまだソース読んでないので解らない。

メッセージを翻訳していて気付いたのだがエラーメッセージ自体は現行のecmascriptやjavascriptにない仕様も存在している。(次期es6の仕様の範囲のエラーメッセージが含まれていた)

ADVエンジンの話


今回は思考メモ的な内容。

ADVエンジンには出力を指示するスクリプトとシステムの設定などを指示する2種類の言語がある。
既存の実装でこのふたつを分けているエンジンは少ないと思う。

二種類の意味領域が異なる言語を、ひとつのソースに混在させるのはいくつかの問題があるので、分けたほうがベターなのは簡単に思いつくことなのだがではどうするかという話。

まずこのふたつの言語パラダイムから考える。

システムの設定などをする言語は宣言型になる。これは簡単。

つぎに出力スクリプトの方、ADVエンジンの出力は文章なのでこれだけなら宣言型と言えるが、実際にはエフェクトの命令が入るので命令型となる。
ここで先と同じ問題にぶち当たる。「二種類の意味領域が異なる言語を、ひとつのソースに混在させるのはいくつかの問題がある」ということ。
文章は宣言的で実際にどう出力されるかはシステムが決める。しかし、エフェクトは人間が決めるので人間が指示する必要がある。
これでは出力スクリプトの中に宣言型パラダイムと手続き型パラダイムが混在してしまう。
マルチパラダイムはプログラミング言語ではメリットだが、スクリプトはプログラマが扱うものではないので単純にしたい。
これは視点を変えると余計なことはさせたくないということ。出来るからと言ってスクリプトで何でもやってしまうと無理が来るのはやる前から分かり切っている。

この、無理をさせないというのと意味領域ごとにソースを分けて管理するというのが今回の複数のパラダイムを混在させないことへの正当化(目的)である。

プログラマから見ればjavascriptのDOMのように言語内DSLで混在させて統一的に扱うほうが楽だが……。

というように、どこまで分離するかという問題で行き詰まった。
少なくともシステムの静的な設定は宣言的でいいが、逐一動的に変化するが静的に決まるデフォルトを持つ場合はどう扱うのがいいだろうか?
たとえば、画面があってそこにフレームとして区切った領域とそこが始点となる座標から文字の出力をはじめる場合。
要するにスクリーンの中にウィンドウを作ってそこに地の文やらを流すという場合。
ウィンドウの形や位置、その中での文字列の描画位置はデフォルトも持つし動的に変更される可能性があるということが問題になる。
デフォルトは宣言的に書いたとして、実行中にそれを動的に変更する記述は演出に由来するので命令的(手続き的)になってしまうが、それだと同じ事をやるのにフェーズが違うだけで違うフォーマットが存在してしまう。

これはおそらく、手続き的なフォーマットの方がいいだろう。宣言的に書くのは全体のごく一部なので多い方に合わせることにする。
そうすると今度は、そのリソースをどこに置いていつ処理するかという問題がある。スクリプトは描画位置を指示するがそれはプラットフォームのGUIに依存するのでそれがいつ初期化されるかに関わってくる。
オーバーラップするウィンドウを持つターゲットならそのウィンドウが初期化される前後だし子ウィンドウが作られる度に個別に処理する必要がある。
アプリケーションがひとつのスクリーンを占領するターゲットならば子ウィンドウというものはないのでタスクが初めて初期化される時と再生成される時に同じ処理を行えばいい。

初期化時に処理するスクリプトが可変か不変かという話なのだけども、仕様としては可変にしたほうが複数のターゲットに対応しやすいのでこんなところで悩んではいられない。

これでひとつ決まった。エフェクト・画面に関わるものは手続き型にする。
つぎに表示するモノの指定は宣言か手続きにするかということ。

スクリプトのソースの中には表示すべき文章が割合を占めるはずなので宣言的に行いたいが途中エフェクトが入るのでそこは手続きである。
ならどうするか、ここはHTMLとjavascriptのように外部スクリプトを指定する方法にしてみる。
そうすると、スクリプトの中心は宣言型で途中に手続きを実行する形になるはずだ。

これで必要なものは内部DSLではなくホスト言語から見た文書処理タスクと外部DSL処理タスクのふたつになった。

ここでHTMLにおけるCSSの役割を果たすのは複雑な見た目の処理もしたいだろうから外部DSLの方。

ここまで来ればだいたい決まってきた。
文章を書くことに注力する宣言的スクリプトとエフェクトに注力する手続き的スクリプトに自然と分かれるので良好な結果ではないだろうか。ここから先は何をどう適用するかの話なのでまた今度に。

結局は過去にHTMLが通った道なのでお手本がすでにあるのだけどそれを持ち込んで再確認するのが今回の趣旨。