chise-core / chise-base 0.23 released.

守岡知彦 / MORIOKA Tomohiko tomo @ m17n.org
2006年 5月 21日 (日) 08:15:32 JST


>>>>> In [chise-ja : No.00509] 
>>>>>	KAMICHI Koichi <kamichi @ fonts.jp> wrote:

> ここからは守岡さんへの質問ですが、xemacs/chise抜きでchise-dbが構築で
> きるようになることを期待するのですが、それができない理由はなんでしょ
> うか。s式を処理することがxemacsの必要性だと私は認識していますがそれ
> 以外に何かありますか?

できない理由はないですが、XEmacs CHISE を使うと楽な点は

(a) メモリ(オブジェクト)管理
    (i) GC が使える
    (ii) 構造を持ったデータ(オブジェクト;S 式が指すもの)が使える
(b) S 式が読める

があります。

また、define-char 形式から chise-db を作るには、

(c) 文字同一性に関するポリシー、文字 ID の割り当てポリシー
(d) chise-db/character/index 作成ポリシー
(e) 関係素性を文字オブジェクトのネットワークにどう展開するか?(逆リン
    クの作成)

という『評価・解釈』が必要だといえ、これは今のところ XEmacs CHISE のプ
ログラムとしてハードコーディングされているといえます。これらのポリシー
は宣言的なプログラムないしはデータの形にしたいと思いますし、順次、
libchise ないしは libconcord に移して行きたいと思ってはいるのですが。
とはいえ、(e) は (a) がないと難しいです。

;; あと、

;; (f) chise-db/feature/feature の作成

;; が XEmacs CHISE の coding-system の定義情報から作っているという問題
;; があり、これも何とかしたいです。

逆にいえば、(a) さえあればそんなに難しい話ではない訳で、例えば、Gauche
なり Perl なり Ruby なりを使うとか、あるいは自前のオブジェクト管理モジュー
ルを作って、構造を持ったオブジェクトが使えるようにすれば良い訳です。

ただ、自前のオブジェクト管理モジュールを用意すると、言語処理系との関係
がどうかなと思うので、ちょっとためらっています。自前のが必要だとしても、
Scheme とかの小さな言語処理系を使うのが良いかなと思っています。


また、libconcord では試験的にアプリケーション側のオブジェクト・リーダ
とのインターフェース用 API を作ってたりします。

これは、アプリケーション側のオブジェクトが void* 型のポインターに収ま
るという仮定が成立する場合(私の記憶では、Tru64 の XEmacs では成り立っ
ていなかったような気がするのですが、まあ、大概の場合 OK ですよね?)、

・型 CONCORD_Object	アプリケーション側のオブジェクトを表す

・関数 concord_ds_set_object_failure
			アプリケーション側での処理失敗を表す値
			(Lisp での nil のようなもの)
			を設定する

・関数 concord_ds_set_read_object_function
			Concord/CHISE の S 式表現の reader を設定する

・関数 concord_obj_get_feature_value
			オブジェクトの素性値をアプリケーション側の
			オブジェクトとして返す

が使えるというものです。同様に、printer を設定する関数と、アプリケーショ
ン側のオブジェクトを素性値として設定する関数があれば、(a), (b) が満た
され、(c), (d), (e) も実現しやすくなります。


ところで、XEmacs CHISE じゃない文字データベース管理ユーティリティ用の
言語処理系として、Scheme (Gauche?) を使うのはどうかと思っています。

これに際し、Concord/CHISE での素性名・素性値の表現形式も、現状の Emacs
Lisp の S 式から、Scheme の S 式に変更してはどうかと思っています。

現状の chise-db に含まれているデータの場合、文字の表現 ?FOO が変わって
しまうのが大きな変更になります。あとはほとんど変わらないと思います。

Concord の場合、同様に Concord object の表現 #s(concord-object genre
FOO =id VAR) が変わってしまいます。ベクター等、S 式が異なる部分を使え
ば非互換性が生じます。

ただ、Scheme の方が処理系が多く、S 式の定義がしっかりしている(標準化
されている)し、XEmacs CHISE に対し、Scheme の S 式の reader/printer 
を用意するのも難しくないと思います。

皆様、どう思われます?

;; ちなみに、理論的には XML とかでも良いけど、メモリ効率が悪くなるので
;; 却下です。

-- 
===『幾千億の分子に分かれても ========================================
     決して忘れない。    
     この宇宙が終るまで』              守岡 知彦 (MORIOKA Tomohiko)
====================== Email: <tomo @ kanji.zinbun.kyoto-u.ac.jp> ======




More information about the CHISE-ja mailing list