#subtype? のテストケース、左辺が </> で右辺が <top> でないものがないですね。右辺が <top> の場合はショートカットしちゃいますし。
#右辺が <top> でなくて #t を期待するテスト、だ
#ども。descriptive typeの包含関係については、(subtype? (</> <integer> <char>) (</> <char> <integer>)) が#tにならない問題もあって、これを要素ごとにパスを辿って検査すると指数的に遅くなるので何らかのソートオーダーで線形化しなきゃな、ってとこで止まってました。とりあえず目につくとこから直してこうかな。
#あ、上のは#tになるのか。(</> <int> <char>)みたいな場合だ。
#えっと、(subtype? (</> <int> <char>) (</> <char> <int>)) の場合ですか？
#;; s/FALSE/SCM_FALSE/ の修正入り
gosh$ (subtype? (</> <int> <char>) (</> <char> <int>))
#f
gosh$ (subtype? <int> (</> <char> <int>))
#f
gosh$ (subtype? <char> (</> <char> <int>))
#t
#よく分かってません。
#あ、native typeがclassに置き換えられちゃってるのかな。
#あ、その問題はそれですね。
#なんでここ置き換えたんだったかな。classに置き換えたら拡大しちゃうからまずいよな。
#superがclassでsubがnative typeの場合を分ける必要があるのか
#ですかね
#直和型/ユニオン型については、ソース上でunion typeって書いてるのにドキュメントでsum typeって書いてて混乱してたみたいです。union typeに統一します。
#(or (is-a? super </>) <class>) だと常に真になっちゃってますけどなんとなく動いてますね。分岐自体必要なかった…？
#常に小さくできるからdelegate-to-superする必要はない気がします。
#あれほんとだ。
#そういえば、Cの char に対応するnative typeってFFIとかで必要にならないんですか？ABIとかはよく知らないんですが、Cの型システム上では char は signed char とも unsigned char とも異なる型(中身は処理系定義でどちらかと同じ)みたいなので。
#単純に引数や戻り値での受け渡しの場合、1 byteであることさえ合わせてあれば、Scheme側でsignedと解釈しようがunsignedと解釈しようが自由ではあるんだけど、ヘッダ読み込んで型取り出す場合とかは分けておいた方が気持ちいいかなあ。
#今あるffi (undocumentedだけど) の低レベル呼び出しルーチンではint系はどうせ6汎用レジスタかスタック渡しの時に64bitになるからcharの符号の有無は気にしてないな。ただstructとかを扱い始めたら気にせざるを得ないかな。
#ふーむ、なるほど。
Gauche > Archives > 2025/02/06