へびにっき

先日に引き続き、Erlang/OTP R13A の Unicode サポートについて調査していく。

リストとバイナリの混成

iodata() と同様のコンセプトの Unicode 対応版として、*chardata() というデータ型が導入される。

chardata()

UTF-8 でエンコードされたバイナリと、妥当な Unicode コードポイントからなるリストの混成

latin1_chardata()

latin1(iso-8859-1) でエンコードされたバイナリと、latin1 文字コードからなるリストの混成。iodata() と直接の互換性がある

external_chardata()

UTF-8 以外の Unicode 系エンコーディング（UTF-16/UTF-32）でエンコードされたバイナリと、妥当な Unicode コードポイントからなるリストの混成

このうち標準となるのが chardata() であり、Erlang/OTP 内部ではこの表現で統一するよう推奨されている。latin1_chardata() と external_chardata() は（少なくとも現時点では）後方互換性と外部システムとの連携のために用意されたものだと言える。実際 latin1_chardata() の定義におけるリストの制限は露骨に後方互換性を意識したものであることを示しているし、external_chardata() の定義はかなりテキトーだ（バイナリのエンコーディングに制限がないので、複数のエンコーディングが混在しても定義に適う。もちろんそれでは使い物にならないはずだが）。

unicode モジュール

*chardata() をフラットなリスト/バイナリに変換するための関数が unicode モジュールに用意される。詳細はマニュアルを参照。基本となるのは次の2つの関数である。

characters_to_list(Data, InEncoding)

Data を InEncoding でデコードして、Unicode コードポイントのリストに変換する

characters_to_binary(Data, InEncoding, OutEncoding)

Data を InEncoding でデコードして、OutEncoding でエンコードしたバイナリを返す

InEncoding に latin1 を指定した場合、Data は latin1_chardata() でなければならない。すなわちリスト内に含まれる整数は 255 以下に制限される。

例1：リストで表現された”日本語”という文字列を UTF-8 バイナリに変換

unicode:characters_to_binary([26085,26412,35486], utf8, utf8).
%% -> <<230,151,165,230,156,172,232,170,158>>

例2：UTF-8 でエンコードされた”日本語”という文字列を UTF-16LE に変換

unicode:characters_to_binary(
	<<230,151,165,230,156,172,232,170,158>>,
	utf8,
	{utf16,little}).
%% -> <<229,101,44,103,158,138>>

例3：”日本語”という文字列のリスト表現と UTF-16LE バイナリ表現を連結してフラットなリストに変換

unicode:characters_to_list(
	[[26085,26412,35486],<<229,101,44,103,158,138>>],
	{utf16,little}).
%% -> [26085,26412,35486,26085,26412,35486]

続く。

最新の Erlang/OTP R13A を Ubuntu 8.10 にインストール。せっかくだから wxErlang も動くようにしよう！と欲を出したせいでひどく苦労した。普通にインストールするだけなら

./configure --prefix=/usr/local/otp_r13a
make
sudo make install

で良いはず（既存のバージョンとは別のディレクトリにインストールしている）。

wxErlang を有効にするには……正確な方法はよく分からない。いろいろ試行錯誤した揚げ句、何が最低限必要だったのか分からなくなってしまった。最初は apt に標準で用意されている wxWidgets 関連パッケージをインストールしまくったのだが、configure で「wxWidgets don’t have gl support」とか「wxWidgets don’t have wxStyledTextControl (stc.h)」とかのエラーが出てしまい、最終的にはwxErlang のページに従ってまず wxWidgets をソースからインストールして、それから以下のようにコンパイル＆インストールした。

./configure --enable-wx=/usr/local \
	    --enable-smp-support \
	    --prefix=/usr/local/otp_r13a
make
sudo make install

これでも configure の最後で先述のエラーは出るのだが（wxWidgets のコンパイル時に OpenGL サポートは追加しているし、stc.h も存在するのに）、そのまま make && make install したらうまくインストールできた。もしかしたら apt の標準パッケージでもできていたのかも知れない。

あと SMT を有効にしておかないと「WX ERROR: SMT emulator required」となるので、–enable-smp-support は必須（デフォルトで有効になる？）。あと erl の起動時にも -smp オプションが必要。

/usr/loca/otp_r13a/bin/erl -smp

1章 「wxErlang」 – INAの日記を参考に最小限のサンプルを動かして、とりあえずウィンドウが表示されるところまでは確認した。長い道のりだった……。

3月17日に Erlang/OTP の次期バージョン R13A がリリースされた。これはβリリースであり、正式版となる R13B は4月29日にリリースされるとのこと。

このリリースのハイライトとして、トップページでは以下の内容が紹介されている：

• SMP/マルチコア環境における大幅なパフォーマンス改善
• Unicode サポートの追加
• WxErlang（GUIライブラリ WxWidgets に対するバインディング）の追加
• リリース管理ツール RelTools の追加

マルチバイト圏の人間としては、何と言っても Unicode サポートの追加が嬉しい。仕様は EEP10 に基づいているとのことなので、一通り目を通してみた。

Erlang/OTP R13A の Unicode サポート

Erlang において「文字列」を表現するには、リストによる方法とバイナリによる方法の二通りがあるが、R13A 以降はそれぞれ次のように変化する。

リスト

R12B までは 0 ~ 255 の整数が iso-8859-1 の1文字を表すと見なされ、0 ~ 255 の範囲の整数のみを含むリストが「文字列」として扱われていた。R13A 以降はこれが 0 ~ 16#10fff の範囲に拡張され、整数1つは Unicode のコードポイントと見なされるようになる。

Unicode のコードポイントにおける 0 ~ 255 の範囲は iso-8859-1 の文字コードと互換性があるので、
R13A 以降の「文字列」は、R12B 以前の「文字列」の上位互換だと言うことができる。

バイナリ

R12B までは8ビットが1区切りとされ、それぞれが iso-8859-1 の1文字を表すと見なされていた。しかしR13A 以降、バイナリで文字列を表現する場合は UTF-8 でエンコードするのが標準となる。ただし iso-8859-1 他のエンコーディングで扱う方法もある。

要するに、抽象的な概念としての「文字」と、具体的な表現としての「バイナリ」が厳密に区別されるようになった、ということになる。今までの Erlang ではこの区別が曖昧なところがあった。iso-8859-1 の範囲で考える限り、バイト列＝文字列と見なして問題なかったからだ。しかし今後は、文字を文字として扱いたいときはリストを用いて操作を行い、外部システムやファイルとのやり取りで具体的なビット表現が必要なときはバイナリとして扱う、という区別が必要になる。

抽象概念としての文字は一意な存在なので、リストを用いた文字列の表現はただ一通りに定まる。”日本語”という文字列を表すリストは
[26085,26412,35486] しかあり得ない。しかしこれをバイナリとして表現する方法は幾通りもあり得る。UTF-8 で表現すれば <<230,151,165,230,156,172,232,170,158>> となり、UTF-16ビッグエンディアンで表現すれば <<101,229,103,44,138,158>> となる。

これから実際にインストールして、動作を確かめてみたい。

「Erlang dict」で検索すると最初に引っかかるページ「Erlang クエックブック」。このページにおいてdictの使い方は次のように説明されている：

D1 = dict:new().                            % 作成
D2 = D1:store(key1, value1).                % キーと値のペアを入れる

新しく作った辞書を「モジュール名として」指定して、dict モジュールの関数を呼び出している。まるでオブジェクト指向におけるメソッド呼び出しのような奇妙な記法だが、確かにこれで動作する。

なぜだろう？

いろいろと調べた結果、これは dict に特有の話ではなく、モジュール名としてタプルを指定した場合の特殊な動作だということが分かった（dict モジュールは個々の辞書をタプルとして表現している）。Mod:Fun(Arg1,..ArgN) の評価を疑似コードで書くと次のようになる：

{Mod,Fun,Args} when is_tuple(Mod), is_atom(element(1, Mod)) ->
	erlang:apply(element(1, Mod), Fun, Args ++ [Mod])

次のように動作を確かめることができる。

erl> M1 = {erlang, 1, 2, 3}.
{erlang,1,2,3}
erl> M1:tuple_to_list().
[erlang,1,2,3]

問題は、この動作が公式なドキュメントのどこにも書いていないということだ。少なくとも私は見つけられなかった。

これとよく似た例として、{Module, FunctionName} という形式のタプルが Module:FunctionName として評価されることはいくつかのドキュメントで触れられており、「非推奨」だとされている。よってこれも既に使われなくなった、古い形式の呼び出し方だということだろうか……？

erl -man file より引用：

IoDevice is really the pid of the process which handles the file. This process is linked to the process which originally opened the file. If any process to which the IoDevice is linked terminates, the file will be closed and the process itself will be terminated. An IoDevice returned from this call can be used as an argument to the IO functions (see io(3)).

IoDevice の実体はファイルを操作するプロセスの Pid であり、ファイルを open したプロセスとリンクされている。そしてそのプロセスが終了したとき、ファイルが自動的に close されるようになっている。サーバを書く上では実に頼もしい仕様だ。

ところで file:open/2 で指定できるオプションには raw というものがある。同じく erl -man file によれば、このオプションを指定するとアクセスが高速化される反面、次のような制限が加わる：

• io モジュールの関数を使えなくなる
• ファイルを open したプロセスからしかアクセスできなくなる
• リモートErlangファイルサーバ（これが何なのかよく分からないが）を使用することができなくなる

「ファイルを open したプロセスが終了しても、自動的にファイルが閉じられなくなる」とは書いていないから、冒頭に引用した部分の説明は raw オプションを指定した場合でも基本的に有効、と判断して良いのだろうか。

erlシェルで見る限り、raw を指定した場合の IoDevice の実体はポート+αらしい。ポートもまた Erlang が提供する抽象のひとつだから、やはりプロセス終了時には自動的に後片づけしてくれる、と思いたくなる。

erl> {ok, Io2} = file:open("m1.erl", [read, raw]).
{ok,{file_descriptor,prim_file,{#Port<0.420>,9}}}

実際もし自動的にファイルが close されないとなると、この IoDevice にアクセスできるのは open した当のプロセスだけなのだから、実質的に close する手段が無くなってしまう。