CHISE specs (Re: UTF-2000 char-db)

[Kouichirou Eto]

江渡です。

> 江渡さん> 文芸的プログラミングではなく、文学的プログラミングを提唱して
> 江渡さん> いる今日この頃です。
> 
> それってどんなのですか？

文芸的プログラミングというのは文芸的と言いつつも、実際のところは
文章的プログラミングとか説明的プログラミングというのが実体であり、
いわゆる文学という意味での文芸ではない。
では本当の意味での文芸的プログラミング=文学的プログラミングがあるとしたら、
どのようなものになるだろうか。例えばジェイムス・ジョイスが
プログラムを書いたとしたら、どのようなプログラムを書くだろうか。

という着想を元にプレゼンしたのが以下の資料です。
http://eto.com/2002/programming-literature/
もちろん冗談なのであんまり真面目にとらないでね。:-)

> 今は key として文字（例：“?a”）しか使ってません（文字属性の場合； 
> decoding-table (CCS → 文字 の場合、整数を使ってます）。
> 
> そこで、key として symbol（例：“type”）を用いた場合、クラスとしての
> 文字属性の属性として解釈することにするという方法を考えています。

なるほど。これはデータベースの実装の問題になりますが、
メタ情報に相当する情報なので、混ぜないほうがいいのでは?

> 江渡さん> define-char形式ならぬ、define-attribute形式というのはどうで
> 江渡さん> しょうか。これなら私でもわかります。
> 
> attribute というのは一般的すぎなので、関数 define-char-attribute（ある
> いは、define-chattr とか）でしょうか。私もこういうのを導入することを考
> えています。CCS 属性に関しては、既に、make-charset（や define-charset）
> がありますが、この新関数はこれを一般化したものと位置付けられます。また、
> 既存の charset-property は char-attribute の property の一種と見倣され
> るべきでしょう。

とすると、他の情報と一緒にelispの中に同居する形になるわけですよね。
char-atr.ja.txtは、ファイルとしては消滅することになるのだろうか。
なんだか前進しているのか後退しているのかよくわからないですね…。
とはいえなんらかの形式を決めて、それに対応したいです。

江渡 浩一郎.new! 2003 ＠ eto.com