『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
以前、リニューアル直後の『日経バイト』に書いたものがWebで掲載された。
一般的な言語論についてまとめて書く機会はなかなかないので面白かった。〆切はきつかったけど。 で、結果としては、歴史的正確さはいまいちだが、読み物としての出来はまあまあではないかと自画自賛。
Citrus Projectの人たちにも聞いてみてはという提案をいただいた。
とりあえず、私の理解ではCitrus Project当面の目標は「正しい」localeシステムの実装にあると思っていたので、 RubyのM17Nはより上位層であって参考にはならないのでは、と考えていた。 それはそれとして、とりあえずもう一度調べてみようと思ったのだが、 このCitrus Projectの現状は私にはさっぱりわからないのだった。
Googleで検索して得られるページは、 かなり古そうだし、メーリングリストアーカイブを見てもSpamばっかりだし。
一応、目標の中に「マルチスクリプトフレームワークの設計/実装」とかあるんで期待したんだけど。
This work is licensed under a Creative Commons License.
<p>Citrusは2001/01に<a href="http://mail-index.netbsd.org/netbsd-announce/2001/01/25/0000.html">NetBSD</a>の一部として取り込まれていますので、NetBSD の <a href="http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/citrus/">CVS tree</a>や <a href="http://news.gw.com/netbsd.tech.userlevel/">ML</a>で情報が得られます。<br><p>最近(2003/11)の成果は<a href="http://bsdcon.jp/2003/docs/t_shiozaki/html/index.html">Citrus iconvの設計と実装</a>にまとめられています。<br><p><a href="http://sigsegv.s25.xrea.com/">Takehiko NOZAKI</a>さんがOpenBSDへの移植をされています。<a href="http://pc.2ch.net/test/read.cgi/unix/985675477/l50">OpenBSDで日本語環境設定@2ch Unix板</a>ともども、進み具合を知るには便利です (日本語で読めますし…)。
Citrus では実装言語がCなので、文字は wchar_t で抽象化してます。<br>Citrus では iso-2022-jp のような stateful encoding もサポート<br>していますが、これも C標準通り mbstate_t の中に状態を持つという<br>方針です。<br><br>glibc の場合、文字集合を Unicode と仮定していますが、Citrus<br>では操作 (API) のレベルでのみ抽象化していて、全ての文字を表せる<br>universal codeset の存在を仮定していません (codeset independent)。<br>ここが最も glibc と方針の異なる点だと思います。<br>glibc と同等な方針は、そういう文字集合を定義することで Citrus の<br>framework でも表現できますが、逆は不可能ですから、抽象化の方法と<br>しては glibc より強力です。しかしその分、iconv の実装は、ちょっと<br>面倒なことになります。<br>glibc のように Unicode を仮定した場合、wchar_t に変換する仮定で<br>文字単位にコード変換が入りますが、Citrus のようにコードセット独立<br>なフレームワークなら wchar_t への変換はごく簡単な処理で済みます。<br>このためリソースの限られた環境で小さなコードセットだけを使う場合、<br>Citrus のような framework の方が軽くなると思います。もっとも、<br>Ruby は、たぶんこういう環境には当てはまらないでしょうけど。<br>iconv に関しては、glibc の iconv の実装がアレなこともあって、<br>glibc の方が速い筈です。<br><br>universal codeset を仮定した方針の場合、universal codeset との<br>間の変換規則を定義しない限り、どんな文字集合も追加できませんが、<br>codeset independent な場合、好き勝手にどんな文字集合でも定義でき<br>るという違いもあります。もちろん iconv を必要とするようなアプリ<br>ケーションを使うためには、他の文字集合との変換規則が必要となる<br>わけですが。<br><br>大きな文字集合を利用する場合、常に問題となるのが文字の包摂基準を<br>どうするかという点です。なぜこれが問題になるかというと、包摂基準<br>に絶対的な正解というものが存在しないからです (意味による包摂、<br>形による包摂などなど)。glibc のように wchar_t に Unicode を利用<br>すると、どうしても Unicode における包摂基準に縛られてしまいます。<br>しかも Unicode の場合、包摂基準の異なる各国の文字集合を単純に<br>足し算し、しかもその際に形による包摂と意味による包摂をごちゃ<br>まぜに行ったため --- 漢字に関しては、一義的には形による包摂を<br>行うが、source code separation の原則に反しない場合には意味に<br>よる包摂も行うという手順でした --- できあがった漢字集合の包摂<br>基準の一貫性が低いので悪名が高いわけです。<br>これに対し universal codeset を仮定しないモデルでは、文字集合<br>ごとに独自の包摂基準を用いることができ、また iconv の際の指定<br>によって、一つの文字集合を、異なる包摂基準で Unicode にマップ<br>することができるわけです。<br><br>もしご質問等ありましたら、Citrus のメーリングリスト <br><bsd-locale-ja@hauN.org> へどうぞ。誰でも投稿できるため spam も<br>多いですが、
「プログラミング言語論」を楽しく読ませていただきました。<br>ところで、Plankalkuel についてですが、Konrad Zuse が作った Z3 というコンピュータ上で動いていたわけではないのでしょうか？<br>http://winnie.kuis.kyoto-u.ac.jp/foldoc/foldoc.cgi?Plankalk%FCl<br>http://www.epemag.com/zuse/