星の贈り物

本物のプログラマはHaskellを使う 第7回掲載

[topic:Haskell]

ITpro に 本物のプログラマはHaskellを使う - 第7回　出力と遅延評価の間を取り持つIOモナド が掲載されました。

IO モナドや unsafePerformIO の定義は確かに実装依存ではあるものの、黒魔術になっている わけでは なく て、一度知ってしまえば当然としか思いようのないような案外簡単な仕組みの上に成り立っています。と、いうことを主張しようとしていたせいか、今回の話は（も？）結構実装寄りのものです。

……というわりには実装を書いていない部分もありますが、本文中にも書いてある通り、そこは 前回の記事 を参照して考えればすぐに分かると思います。逆に言うと前回の記事に依存して書いているので、前回の記事の内容かもしくはそれと同等の知識なしに読むのは難しいと思います。第3回から今回までの記事は一続きのモナド・シリーズになっているので、今回の記事に興味があるけれどそれらをまだ読んでいないという方は、是非この機会に通して読んでみてください。（第5回のMaybe型について説明している記事は番外編といった感じですが。）

さて、今回の記事は実装寄りのものであるため、参照透過性についての深い議論を期待していた人は肩透かしを食らうかもしれません。今回それらについてあっさりとしか書いていないのは、一つには純粋に分量的な問題があるのですが……。GHC のような環境渡し形式上に築かれている IO モナドの参照透過性について興味のある方は、 Cleanで関数プログラミング の 環境渡し技術 や 一意型 の部分を読んでみると良いかもしれません。

ただ、ここで議論されていることをそっくりそのまま（一意型の基である線形論理（linear logic）以外の）他の形式の上に築かれた IO モナドに当てはめて良いのかどうか分かりません。（他の形式に対する知識が不足しているので、まだ確かめられていません。また、ひょっとしたら将来的には全く別の参照透過性を守る仕組みが生まれるかもしれません。そういう仕組みの上であっても、IO モナドになっていればそれは IO モナドです。）念のため。

Unicode 対応表を使った文字コード変換（作りかけ）

[topic:Haskell]

最近 Haskell 界隈 や Windows Vista 関連で文字コードに関する議論が盛んなの で、勉強がてら JIS X 0213 と Unicode の対応表 を使った文字コード変換を実装してみました（ GenMapping.hs ）。UTF-8 の入出力には Takusen の UTF-8 encoder & decoder を使っているので、試す場合には Takusen のものを持ってくるか 、適当な別実装を使えるよう書き換えてください。

まだまだ作りかけなので、色々と問題があります。今のところ ISO-2022-JP-2004 （正確には ISO-2022 全般）へは対応できていません。また、合成文字への対応するためのコードのどこかがバグっているため、Shift_JIS-2004 や EUC-JIS-2004 への書き込みがうまくいきません（何文字か文字化けします）……などなど。

さて、どうしようかしらん。wxHaskell などをビルドする際、Windows 上で自動生成されたコードに日本語文字列（Shift_JIS）が入ることで途中でエラーが出て止まるのをどうにかしたいだけなら、合成文字対応まで頑張らなくても良いんだろうけど。

追記：あっ、ぼかした書き方をしてしまっていましたが、RHG の時に話したように原因は分かっています。対応表から IntMap（パトリシア木）を生成したり IntMap から検索する時、複数のコード番号を合成（連結）して一つの数字にしているんですが、この数字が他の文字のコード番号とも対応してしまうのが原因です。

対応表で示されている合成文字のコード番号は大きいものが多い ために、Int が32ビットだと合成した数字を明らかに Unicode にはありえない数字にはしにくいので、そこが悩みどころ。……あっ、その多くの文字のコード番号の合成結果は Unicode の範囲を超えてますね。なら、 composedChar > ord (maxBound) である程度どうにかなりそうです。

というわけで、（一部の合成文字を除き）書き込みがうまくいくようコードを書き換えました。

文字コードの判別

[topic:Haskell]

先週の 文字コード変換 に続いて、今度は文字コード判別を実装してみました（ Guess.hs ）。

色々と迷った末、Gauche の charconv/guess.scm で使われている 状態遷移を使って統計的に判断する 方法に落ち着きました。charconv/guess.c のルーチンをあえて使わずに単にスコアが最大のものだけを算出するようにしているのは、ISO-2022 及び ISO-2022-JP-? 間での判別を考えているためです（ただし、実際にやるかどうかは不明）。これに伴い、正しく判定できるよう、スコアを少しだけ変えてあります。あと、ISO-2022-JP-2004 もきちんと扱えるように書き換えたり、charconv/guess.scm の表面化していないバグを直しています。

（JIS X 0213:2004（あるいはJIS X 0213:2000）の第二面が正しく3バイトの文字として扱われていません、とか。報告しておくべきかな、これは。）

自動生成されるソースコードをどうにかしようというのがそもそものモチベーションであったため、その後 Latin-1（ISO-8859-1）との判別を行うルーチンも入れてみたのですが、これがちょっと微妙な感じ。Latin-1 自体の判別はうまくいくのですが、半角カナなしの EUC-JP だと、EUC-JP と Latin-1 のスコアが同じになって区別がつかない可能性が……現在、Latin-1 の後 EUC-JP かどうか判定することにして凌いでいるのですが。

こういう場合にはロケール情報を利用して判別するのが常套手段だと思いますが、それだと手元で自動生成されるソースはともかく、他人が自動生成したソースを持ってきて利用する場合にはありがたくないかもしれません。日本語文字列と欧米言語の文字列では明らかにアルファベット（ASCII 文字列）の登場頻度が違うはずなので、これで重み付けするべきでしょうか？

他に ISO-8859-? 同士から判別する場合にはどうしようかという悩みもありますね。例えば Latin-1 と Latin-9（ISO-8859-15）とか。 Haskell' では諦めているみたいですが （作った後でこのページのことを思い出したので、上のプログラムには UTF-? 間での判別を行うコードはまだ入れていません。また、まだ UTF-16 や UTF-32 のソースコードは扱えませんし）。

この他にも論点はありますが、そのあたりの話（もしくはリンク集）の URL はソースコード中にコメントとして載せてあるので、特にここで繰り返すようなことはしません。