#>natsutanさん、vminsn.cとかを再生成しようとしてるとしたら、タイムスタンプの問題かな? vminsn.scmの方が新しいと再生成しようとするんですが、その時はインストール済みのgoshが必要になります。
#>yamasushiさん、そのへんは型理論で枠組みができてると思うので、とりあえず型の方から学んでみてはどうでしょう。Schemeだとどうしても「値」がまずあってそれはどういう性質を持つか、を考えてしまいますが、そうすると多値のようにひとつのファーストクラスの値で扱えないと考えが止まってしまいます。直和型についても、例えば data Foo = Bar | Baz; という直和型Fooがあったとして、それを値として受け取った時には値の型はBarかBazであってFooは直接は見えないわけです。
#ちょっと不明瞭だったので修正。「多値のように、ひとつのファーストクラスの値で扱えないケースが出てくると考えが止まってしまいます」
#>shiroさん
#ありがとうございました。
#その後、AO_compare_and_swap_full が無いと言われ、ソースを追ったところ、なんとかしてコンパイル通せば動くという状況でも無かったのでいったんあきらめます。
#もう少しARMのクロスコンパイルの経験値上げてから挑戦します。
#>Shiroさん、ありがとうございます。やはり型ですか。多値が型でありえないように、直和に相当する「何か」もやはり型でありえないと思っています。型よりも上位にある抽象的なものかなあ・・・と。
##「for a human eye it is easier to identify topologically identical diagrams than to recognize equivalence between the corresponding tensor expressions.
人間の目では、絵図の位相的な同型性を判断することは、対応するテンソル表現の同値性を認識するよりずっと簡単だ。」
#たしかに、わたしもコードを読むときにはプリントアウトして図をかきながら理解する、ということをします。手間がかかりますが。
#(数学的な内容についてはチンプンカンプンで・・・・)
#「型でありえない」っていうのはちょっとおかしいでしょう。直和型ってあるわけで。例えば「リスト型」は「ペア型」と「空リスト型」の直和ですが(Gaucheでは継承によって表現していますが、直和型で表現することもできます)、手元にある値を見るとそれはペアか空リストに見えるわけです。だから「値よりも上位にある抽象的なもの」の話をする必要があって、それが「型」である、と私は主張しています。
#多値を直積と見るならば、という前提があります。多値を直積として捉えるなら、直積と関係の深い直和は何か？というのが私の問いでした。多値が横方向の広がりでとするなら、縦方向(generic関数の呼び出し？)の広がりをあらわすような。
#それと、「直和型」に対応するのは「タプル」ですよね？ 多値とは違うわけで。多値とは、何かが複数個(もしくはゼロ個)ならんだ状態そのものを表していると、考えています。(map f l1 l2 l3)のl1 l2 l3のように複数のリストを渡すような。
#なので、「型」よりも上位にある抽象的なものがあって、多値の場合には直積が対応している。と、見ています。
#多値のコレクションを実装してみて確信したというか。型よりも上位にある何かの存在について。(すみません。主観的な感想で。)
#タプルに対応するのは直積型です。そんで、Schemeのようにn-in m-outはn個の引数やn個の返り値をまとめてタプル (ファーストクラスではありませんが) と見れば直積型で表現できます。カリー化がなければこのように見て何も問題は出ないでしょう。(これが、まさしく「値」の上位として型があるってことです。) もし、そのような見方を越えて「型よりも上位の概念がある」と主張されるのでしたら、具体的な話を聞いてみたいです。
#念のため補足しておきますが、直積型のインスタンスとしてのタプル、がそのまま「ファーストクラスの値」になる必要性というのはありません。直積型のインスタンスとしてのタプルが、Schemeではn引数やm返り値で表現されている、というだけのことですから。(Schemeにはタプルという値がもともと無いですし---リスト等で代用することはできますが)
#文章がまずかったです。
直積---タプル---多値
| | |
直和---直和型---????
こういう図式を考えたのでした。
#それはなんかレイヤがおかしい感じがします。
型 抽象的な値 実装
直積型 ---- タプル ---- 多値
| | |
直和型 --- X ---- Y
ってな対応になって、XとYに何が入るかですが、素直に考えたら特別なものではない「値」になると思うんですが。直和型についてどういうものをイメージしてますか? 静的型言語での直和型とは違う?
#数学 抽象 ???
直積---タプル---多値
| | |
直和---直和型---????
多値については「実装」というか物の見方のような解釈をしていました。
#抽象的な値、っていうのは変か。真ん中は「表現」とかの方がいいかなあ。直積型で表現されるものを入れるにはタプルが必要ですが、直和型の場合は実際の「もの」はどれかの型の値になるのですよね。
#何でタプルと直和型が対応するのかがわかりません。素直に考えたら直和型と直積型が対応するんじゃないんですか?
#数学 抽象 インスタンス ???
直積---直積型---タプル-------多値
| | | |
直和---直和型---???? -------???
#直和型、で何を意味してますか? Haskellの data Maybe a = Just a | Nothing とかとは違うものですか?
#Maybeも直和型になるんじゃないのですか？
#直和型です。その場合、具体的な値は Just 1 とか Nothing とかですよね。Maybeなんとか、って値が見えるわけじゃない。
#それがまさに、generic関数の呼び出しそのものではないですか？
#今の時点ではメタファーの域をでないのですが・・・・
#んー、generic関数は確かに関数型 (a -> b) の直和になってるんですが、case-lambdaだって異なる数の引数を取る関数型の直和ですし、関数ではないものの直和もあるわけで、generic関数を特別扱いする意味がまだわかりません。
#ええ、case-lambdaも含めています。generic関数は特定化子リストという実体をもっているのでわかりやすい例だなあと。
#<list>は<pair>と<null>の直和型と考えられますが、それも含めるのですか?
#えーと、手続き(それに準ずるもの)に限定して考えていましたが・・・<list>ですか。ちょっとわからないです。
#なんだ、そういう前提があったのですね。最初から言ってくれれば回り道をしないで済んだのに。確かにn引数やm返り値というのは手続きの入力/出力にしか現れないから、直和の方もそういう前提で話しても構わないと思います。それで元の話に戻って来ますが、そういった直和が「型よりも抽象的な概念」だというのはなぜでしょうか。今のところ型で説明できるような気がするのですが。
#なるほど、型で説明できるわけですね。関数のディスパッチに関係している型ということか。メタ的な情報を格納している型ということですね。
#んー、私の理解だと、「メタ的な情報」のことを型というのです。
#なるほど。メタレベルが高くなっても型は型ということですね。たしかに。
#んー、メタレベルの低い型というのはどんなものですか? 確かに「型の型」を考えることはできると思いますが、一階目の「型」で既に関数のディスパッチとかには十分なような。
#メタの使い方がまずかったです。具体的な値を格納する型、実行を制御する情報を格納する型、のような階層のようなものを想定していました。
#そんで最初の話に戻って来ますが、型のレベルで直積と直和を組み合わせてゆくことは当然できて、それをSchemeにマップすることも可能だと思うんですが、いかんせんSchemeは綺麗に型がつけられるように作られてないし、言語処理系が型演算をサポートしてくれないので、いろいろやりづらいだろうなとは思います。
Gauche > Archives > 2013/06/14