松尾です。

# 精度に関心がある方が多いのかな?
# 僕は見た目が数学らしいモデルに興味がある、感じ。


GOTO Kentaro wrote:

> なんとなく分かりました。つまり、定義域を外から決めている数学
> 関数と同じ仕組みを導入しようという路線ですね。気持ちは分かる
> ので、いくつか思い付く点を書きます。

ありがとうございます。気持ちが通じた事で、かなり満足しています。


> 定義域を拡大する場合は定義域という大域的な情報を操作する必要
> がありますが、そもそも定義域はどの名前空間に属するのが妥当だ
> と思いますか?? トップレベル??

今のところトップレベルだと思います。何故かといわれると困るのですが…。

# 名前空間の処理は、僕は下手糞です。何時も、今も悩んでます。


> クラスの継承関係は一般に包含関係かどうかは決まっていません。
> これをどうしますか??

別に定義すべきだと思います。その為に、クラスと定義域を別に考える(等の)
必要があります。集合としてのクラスと定義域が一致する場合も多いと思いま
すが、独立させるべきです。

(前回は定義域の定義で継承と書きましたが、あれは包含と読み替えてください)


> lub (least upper bound) が一意に存在しない場合はどうしますか??
> たとえば下の図は左が右を包含するとして、 AxA で定義された関
> 数 f に、f(d,e) が与えられたとき何に格上げします?? それ以前
> にこういう状況は考慮しますか??
> 
>     +- B -+  +- D
>     |     |  |
>  A--+     +--+
>     |     |  |
>     +- C -+  +- E

この場合 AxA の責任で処理します。って、問題の意図を正確に捉えられてな
いような気がします_o_ が、包含関係の系列はツリーでなければならない、等
というルールは必要だと考えていました。

# しかしこのルールは「ソフトウェア的に拡張がエレガントに行える」とい
# うニーズに反しそうな予感があります。


> それから、たとえば、print が to_s を呼ぶようなのも型変換とい
> う文脈でみることが出来ますが、それらもこの路線で整理してみよ
> うという気はありますか?? to_s と inspect や == と === などの
> デフォルトの関係がすっきりするのではないかという希望がちょっ
> とあります。

# '==' と '===' には時々苦労させられます。

正直なところ、言語の研究としてこの辺は既に進んでいるんじゃないかなぁと
思っていて、僕の出る幕ではない、或いは専門家に任せたい感じです。