Shiro Kawai
shiro****@lava*****
2004年 3月 28日 (日) 20:32:07 JST
これは長年の懸案事項なんですが、綺麗でかつシンプルな解を 見つけられていません。 From: Kouhei Sutou <kou****@cozmi*****> Subject: [Gauche-devel-jp] generic function Date: Sun, 28 Mar 2004 17:04:50 +0900 (JST) > 須藤です． > > 私は，あまりSchemeに慣れ親しんでいるわけではないので変な事を > いっているかもしれませんが，現在のgeneric functionがいまいち > 使いづらいです． [..] ここのリクエストにはほぼ同意します。但し、(1)に関しては若干解釈が違って、 > (1) 例えば， > > (define-module a > (export x) > (define-method x ((y <list>)) #f)) > > (define-module b > (export x) > (define-method x ((y <string>)) #f)) > > と定義されていたときに， > > (import a) > > としても > > (import b) > > としても > > x ; => #<generic x (2)> > > となって欲しいです． 私は、 (import a) だけのとき -> #<generic x (1)> (x <list>) だけ見える (import b) だけのとき -> #<generic x (1)> (x <string>) だけ見える (import a), (import b)の両方を行ったとき -> #<generic x (2)> となるべきだと思います。 > * gauche.gfはgeneric functionのテーブルを持つ． > define-methodはgauche.gfにあるgeneric functionにメソッド > を追加する． => (1)が解決． > > gauche.gfにgeneric functionの束縛を導入しないので，明示 > 的にimportとかdefine-methodとかしない限りはgeneric > function の実体は見えない． > > * define-methodしたとき，現在のmoduleでgeneric function名 > がgeneric fucntionの実体に束縛されていなければ，現在の > moduleに束縛を導入する． => (2)が解決． 前者はちょっと問題があって、現在のGaucheは名前の可視性をmoduleで 一元管理する方針であり、例えばsandboxのような機構はそれを前提に 組み立てられます。しかし、陽にimportしていないモジュールの メソッドが可視なgeneric functionにくっつくと、そこで module機構で説明できない関係が存在してしまうのです。 それは避けたいと思っています。 根本的には、トップレベルの名前のマッピング機構としてmoduleと generic functionがぶつかっているということなんですが、それなら それで、簡単に説明できるセマンティクスを導入しないと、目先の対応 だけでは長い目で見て不条理な仕様になってしまうおそれがあります。 後者に関してはそういう実害は無さそうです。導入を渋っていたのは、 前者と同時に解決できるような解がないかと夢のようなことを考えて いたせいです。銀の弾丸は無さそうなので、それなら導入してしまっても いいかなと思います。 --shiro
