関数型言語Part2
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGhttp://pc.2ch.net/test/read.cgi/tech/987954395/
0175デフォルトの名無しさん
NGNGまあそうなんだけど、int型だって
「int型は細かく型チェックするタイプの言語にあってこそ有効だ。VBみたいなバリアント型
がある言語ではその力を十分に生かしきれない。」
とも言えると思うぞ。
俺も高階関数は関数型の中心的な要素だと思う。でももうちょっと考えてみるとそれ
は高階関数と言う概念よりも他の概念のほうがしっくり来るような気がしたのでつい
反論したくなっただけだ。
0176デフォルトの名無しさん
NGNGスタートしたもんだと思ってたんだけど、それは違うの？
高階関数が関数型プログラミングで重要な概念だってことは認め
るけど（高階関数なしに関数型プログラミングするのは効率悪い
からな）、
１）高階関数をサポートしないが、代入を排除しているプログラミング
２）高階関数をサポートしているが、代入を排除しないプログラミング
を比較すると、１の方が関数型プログラミングになっている気
がするんだけど。
0177デフォルトの名無しさん
NGNG0178176
NGNGたとえばJavaあたりで代入を使わずにプログラミングしたら、
それは関数型プログラミングになってるって感触があるし、
Lisp系でグローバルオブジェクトをあちこちから操作しまく
ると高階関数を上手に使っていても関数型プログラミングに
なってない（バグがとりにくい）って思うから。
0179デフォルトの名無しさん
NGNG>>純粋なオブジェクト指向言語で対称的(訂正)だから。
>これは理由にならない。
>何度も言うが、言語の完成度なり純粋性は俺の話の反論にはならない。
反論ではありません。ＯＯの議論になぜ欠かせないか答えただけです。
>またプロパティはここでは関係がない。
>と言うより、どう関わってくるのかが
>俺には今一つ分からんので説明してください
属性のアクセスを抽象化できる。
関数型とＯＯがある意味逆というのは
関数型はデータ抽象化しないってこと？
0180デフォルトの名無しさん
NGNG>関数型とＯＯがある意味逆というのは
>関数型はデータ抽象化しないってこと？
↑
前スレコピペ
>OO言語では、その機能を十全たるものにするためには
>しっかりしたクラス設計が欠かせないとされている。
>そして、その際には、属性と方法を適切に弁別する作業が欠かせない。
>つまり、「良い」OOからしてみると、
>属性と方法が渾然一体となってしまうような状態は好ましいとはいえない。
>一方で、関数型は、OO的に言うところの方法が
>同時に属性でもあり得ることを奨励し、
>そのことによってより抽象的なアルゴリズムを構築でき、
>表現力が高まるとしている。
>その意味においては、
>両者は理想とする方向が逆なのではないかと思った。
0181デフォルトの名無しさん
NGNG本当に？
まあ、不必要に属性を公開すべきでないってことなら賛成だけど。
メッセージパッシングとネームスペースを同じドット記法で
書くから混乱しているだけってことかも知れないけれど。
でも、値を利用する立場からすれば、それが式であることには
代わりはないんで、別にどうでも良い気がするんだけどな。
0183デフォルトの名無しさん
NGNG私は割りと好きな手法だ
というのは私はアセンブリ思考の高級言語プログラマーなので
人間側はプログラミング言語よりも仕様書メインで
プログラムは最終的にCPUからみて考えるので
当然goto文相当のものも多く使う、がある程度分離させている。
クラス化(OOP)なものも使うができるだけポインタ渡しの関数を使うようにしている。
その最大の理由は改良や互換性において相互依存度が大きくならないことと
プログラム内に不必要なインスタンスが多数出現するのがいやなため。
これの例で具体的にはOpenGL V.S. DirectXがあると思う
OpenGLはWin95時からずっと同じOpenGL32．dllであり関数型
おんなじかんすうだが実はデバドラのほうへの橋渡しなので
デバドラが新しい関数を提供してくれたら
従来のルーチンに上乗せする形でそれが使える。
一方のDirectXはOOPである。
OOPだから基本クラスを改良すると一から全部やり直し
それでも一応下位互換ルーチンを残しているからいいけれど
新しいインターフェースで作ったプログラムは選択の余地なく
新しいDirectXを入れていないパソコンでは初期化すらできない。
資源の再利用とかはあまり興味ないけれど、環境の変化に対してOOPは弱いのでは？
0185デフォルトの名無しさん
NGNG全然違う
逝け
0186デフォルトの名無しさん
NGNG関数型は名前の通り関数(写像)で記述(モデル化)するって事だな。
0187デフォルトの名無しさん
NGNG副作用のある不純関数型言語だと、高階関数(実装的にはclosure)
ってJavaのインスタンスとほとんど等価だよね(既出だが)。
で、属性の読み出しは引数のないメソッドとみなせるし、属性の
更新も1引数のメソッドと見なせる。
逆に、SmalltalkやJavaのインスタンスは高階関数のようにも使える。
高階関数とか属性はFPLとOOPLとを弁別するキーには全くならんと
思うが。
0188デフォルトの名無しさん
NGNGそんなこと言ったらCで関数ポインタを含む構造体のインスタンスは
javaのクラスインスタンスと等価とか言えるんじゃないの？
キリないよ。
結局字面の問題でしょ。
0189デフォルトの名無しさん
NGNGそれを言いだすと、
ほとんどの言語は関数型言語をエミュレートすることで
高階関数を扱える、とか言っちゃったりするわけで...
字面の問題とまでは言わないけど、
言語自体が「高階関数」という概念を提供しているかどうかは
大きな違いがあると思う。
0190デフォルトの名無しさん
NGNG0191デフォルトの名無しさん
NGNG>副作用のある不純関数型言語だと、高階関数(実装的にはclosure)
>ってJavaのインスタンスとほとんど等価だよね(既出だが)。
>で、属性の読み出しは引数のないメソッドとみなせるし、属性の
>更新も1引数のメソッドと見なせる。
>逆に、SmalltalkやJavaのインスタンスは高階関数のようにも使える。
>高階関数とか属性はFPLとOOPLとを弁別するキーには全くならんと
>思うが。
↑
>>174
>しかし、高階関数は関数型の中にあってこそ、
>始めてその表現力の飛躍的増大を図ることができる。
>つまり、imperativeとは異なり、
>プログラムがコマンドの羅列ではなく関数の集合になっている
>関数型であってこそ、
>高階関数は表現力増大の為に生きてくると思うが。
0192デフォルトの名無しさん
NGNG何故、高階関数(実装的にはclosure)なのか、教えて下さい。
0193デフォルトの名無しさん
NGNG0194実装から曲解
NGNGclosureが返るから、高階関数＝closure と解釈した
のかな？
0195デフォルトの名無しさん
NGNGクロージャに関数スロットと属性スロットをカプセル化する。
それを見て、高階関数＝クロージャと解釈したのかも知れないけど、
高階関数の典型的な使い方からは外れているよね。
0196179
NGNG>クラス設計をする際には、
>インターフェースと(属性とメソッドの)実装に分ける。
は正確ではないので
クラス設計をする際には、
インターフェースと実装に分ける。
に訂正します。
>>126
「属性とメソッドを弁別して抽象化する」というのに反論したんです。
この表現はクラス設計のとき属性とメソッドを区別して設計するみたいです。
これはＣ言語はグローバル変数とグローバル関数を区別して
設計すると言ってるみたいなものです。
こんな表現は奇妙です。
言ってることは分かったので主張そのもに反論はありません。
0197デフォルトの名無しさん
NGNG>「属性とメソッドを弁別して抽象化する」というのに反論したんです。
どこで言っていた？
ちゃんと摘示しろ。
それから、ObjectとClosureとについて
変な文を見つけたのでコピペする。
まあ、どうでもｲｲかもしれないが。
An object is a piece of data with procedures attached to it...
A closure is a procedure with a piece of data attached to it.
0198デフォルトの名無しさん
NGNGついでに"Lambda: the Ultimate Declarative"モナー
Actors ≡ Closures (mod Syntax)
という章に、ObjectとClosureがなぜ等価であるのかちゃんと書いてある。
0199デフォルトの名無しさん
NGNGOOPは「メッセージパッシング」のメタファで抽象データ型をサポートするけど、
FPはクロージャでそれを実現するし、本質的にそれらは等価だってことか。
[aReciver Message] = (aClosure Proc)
みたいな理解でいい？
0200124 128 179 196
NGNG関数型とＯＯが逆というのは高階関数とクラスは違うということらしい。
高階関数とクラスが違うというのは同意。
しっかりしたクラス設計とは
インターフェースと実装を適切に弁別することであって
属性とメソッドを弁別することではない。
>>197 >>180です。
0201デフォルトの名無しさん
NGNGOOPにおけるクラス設計も、より抽象的で本質的なクラスを、
より具象的なクラスから抽出してスーパークラスにまとめて
いく分析・設計プロセスがあるよね。デザインパターンにも
よく出てくる。具象的なクラスばかり作っていてもコードの
共有が進まないからだな。
関数型プログラミングも、共有コードを増やしたいと願って
いることには違いがないから、結局、より抽象的でより本質
的な関数を抽出しようとする。やっていることは同じじゃな
いかと思う。
# というより、デザインパターンの研究は、関数型プログラ
# ミングの研究成果からのフィードバックが大きいと思われ。
0202デフォルトの名無しさん
NGNG真面目な質問なんだが、
（本質的に）等価であるとは一体全体どのような意味だ？
そして、それは、
そのビヘイビアにおいて同形であるということと
どのように関わって来るんだ？
0203デフォルトの名無しさん
NGNG>デザインパターンの研究は、関数型プログラ
>ミングの研究成果からのフィードバックが大きいと思われ。
それはどうかな。
なんともいえないと思いますが。
0204デフォルトの名無しさん
NGNG>しっかりしたクラス設計とは
>インターフェースと実装を適切に弁別することであって
>属性とメソッドを弁別することではない。
しっかりしたクラス設計 ＝ インターフェースと実装を適切に弁別すること。
≠ 属性とメソッドを弁別すること。
>>180
>しっかりしたクラス設計が欠かせないとされている。
>そして、その際には、属性と方法を適切に弁別する作業が欠かせない。
この文は、
しっかりしたクラス設計 = 属性と方法を適切に弁別すること
なのか？
それよりもさ、君>>200の場合、
属性と方法を区別するOOPLが欠陥があるといえるならば、
Class diagramでの属性とオペレーションの区別が
どのような意味を持つかについて答えてよ。
やはりシンタックスシュガー或は便宜的区別なのか？
今更だがsageる。
0205デフォルトの名無しさん
NGNG>OOPにおけるクラス設計も、より抽象的で本質的なクラスを、
>より具象的なクラスから抽出してスーパークラスにまとめて
>いく分析・設計プロセスがあるよね。デザインパターンにも
>よく出てくる。具象的なクラスばかり作っていてもコードの
>共有が進まないからだな。
>関数型プログラミングも、共有コードを増やしたいと願って
>いることには違いがないから、結局、より抽象的でより本質
>的な関数を抽出しようとする。やっていることは同じじゃな
>いかと思う。
質問です。
考えてみると、この発言の趣旨が分かりません。
結局何がいいたいんでしょう？
共有を進めるためのおよそ全てのより本質的な抽象化への努力は
皆お友達だと言いたいのでしょうか？
0206201
NGNGリストのような単純なデータ構造を基盤とする言語の場合はともかく。
強く型付けされた関数型言語の場合、
ある関数の適用範囲は厳密に、揺るぎなく、決定されている（シグニチャ
等を利用してポリモーフィズムを実現したとしても、適用範囲が静的に
決定できることには変わりがない）。
それは、OOPにおいて、クラスの中にメソッドがカプセル化されている
状態と本質的には同じことだと思う。
0207145
NGNG145 です。このスレの行き先が心配になってきたもので...
1. 「属性とメソッドの区別はシンタックスシュガー」というのは、
オブジェクト指向言語を「関数モデル」から見た場合の話です。(>>145,前レス109のFP)
2.オブジェクト指向言語を、DOA や OOA の観点から見る場合は、
・属性とメソッドの区別 (>>149)や、
・インターフェース(分析モデル) と 実装 を分ける事(>>128)は、
重要だと思います。
上記二つの解釈の違いは、議論のベースとなる「計算モデル」の違いです。
オブジェクト指向と、ラムダ計算のクロージャ(?) との類似性は、
比較的古い ('80s) 議論だと思いますが、何か新しい要素はあるのでしょうか？
私としては、「オブジェクト指向言語意味論を、関数モデルでいかに解釈するか？」
といったあたり (>>148-149 のCardelli) に関心を持っているのですが。
0208デフォルトの名無しさん
NGNG0209145
NGNG疑問点：オブジェクト指向言語意味論を、関数モデルで記述しようとする試みの
メリット／デメリットは何か？
0210デフォルトの名無しさん
NGNGここでの論点は、俺的には、
高階関数は関数型の特徴と言えるか？ これは概ね話がついた。
属性と方法の区別のあるOOPLは不完全或は欠陥があるのか？ 未決
もし不完全でないとするならば、
高階関数を特徴とする関数型は属性と方法を区別するOOPとは
理想とする方向性がある意味逆と言えるか？ 未決
ObjectとClosureが等価であるとは一体どのような意味か？
それは、そのビヘイビアにおいて同形であるということとは
どのような関係にあるのか？ 不明
こんな感じだろ。
その209の論点は、とりあえずのところは今のトピックではない。
論点自体は至ってまともだが。
0211デフォルトの名無しさん
NGNG0212200
NGNG>しっかりしたクラス設計 ＝ インターフェースと実装を適切に弁別すること。
> ≠ 属性とメソッドを弁別すること。
わかりやすい！
>属性と方法を区別するOOPLが欠陥があるといえるならば、
>Class diagramでの属性とオペレーションの区別が
>どのような意味を持つかについて答えてよ。
>やはりシンタックスシュガー或は便宜的区別なのか？
>>149から
>オブジェクト指向分析(OOA)では、DOA由来のデータ抽出に加えて、
>メソッド抽出も重要なので、アドホックに operation が加わった、という気がする。
属性とメソッドを区別しない ≠ 属性とメソッドは同じ概念
属性とメソッドは異なる概念です。(念のため)
区別しないというのは同じように扱うという意味です。
>>210
>属性と方法の区別のあるOOPLは不完全或は欠陥があるのか？
この問題は 関数型オブジェクト指向言語 と 手続き型オブジェクト指向言語 を
比較する方がいいと思います。
関数型オブジェクト指向言語 は
メソッドを高階関数で定義できる点で、手続き型オブジェクト指向言語 と異なります。
また、メソッドを引数として渡すと高階関数が Closure になります。
その他の点はほぼ同じです。(CLOSの多重ディスパッチのような反論はやめてください)
議論の混乱は 関数型言語 と 手続き型オブジェクト指向言語 を
比較したことが原因です。
関数型とＯＯの比較は
関数型言語 と 関数型オブジェクト指向言語 を比較する方がいいと思います。
0213デフォルトの名無しさん
NGNGクロージャと高階関数がまざってないかい？
「メソッドを引数として渡すと高階関数がClosureになります。」
がなんだか意味不明。
「Closureを引数または返値とするメソッドは
高階関数の実装として扱うこともできる」
とは言えると思うが、どうよ？
0214デフォルトの名無しさん
NGNGオブジェクト指向言語の型システムを形式化することで
異なる静的型オブジェクト指向言語間でオブジェクトを共有する際の
型検査/型推論のための参照基準ができる。
例えば永続オブジェクトの動的型を表現する時などには
Cardelliの型システムが役立つと思われ。
0215デフォルトの名無しさん
NGNGActors ≡ Closures (mod syntax)
というのは、そのまま読むと、
ActorsとClosuresはSyntaxを法として合同であるということになる。
そして、そのような場合においては、知られているように、
ActorsとClosuresは「同値」関係にある。
つまり、Actors is equivalent to Closuresということになる。
これは残念だが、等価であるとはいわない。
等価であるというと意味が変わってしまう。
0216215
NGNG間違えた。
0217212
NGNG>>210
>属性と方法の区別のあるOOPLは不完全或は欠陥があるのか？
>もし不完全でないとするならば、
>高階関数を特徴とする関数型は属性と方法を区別するOOPとは
>理想とする方向性がある意味逆と言えるか？
この問題は 関数型オブジェクト指向 と 手続き型オブジェクト指向 を
比較する方がいいと思います。
関数型オブジェクト指向 は
メソッドを高階関数で定義できる点で、手続き型オブジェクト指向 と異なります。
また、高階関数の Closure を使える点でも異なります。
その他はほぼ同じです。
議論の混乱は 関数型 と 手続き型オブジェクト指向 を比較したことが原因です。
関数型とＯＯの比較は
関数型 と 関数型オブジェクト指向 を比較する方がいいと思います。
>>213
>「Closureを引数または返値とするメソッドは
>高階関数の実装として扱うこともできる」
>とは言えると思うが、どうよ？
いえない。
0218デフォルトの名無しさん
NGNG関数オブジェクト
クロージャ
高階関数
オブジェクト指向
関数型オブジェクト指向
関数型言語
オブジェクト指向言語
だれか説明して！
0219デフォルトの名無しさん
NGNG0220デフォルトの名無しさん
NGNG0221デフォルトの名無しさん
NGNG>メソッドを高階関数で定義
定義した時点でクロージャになると思うがどうよ？
0222デフォルトの名無しさん
NGNG関数に属性を持たせる概念がクロージャ。
関数（高階関数含む）自体も属性の１つ。
0223デフォルトの名無しさん
NGNG0224デフォルトの名無しさん
NGNG環境っつーのは、ものすご乱暴に言うと、関数が呼び出されようとしている
瞬間の引数や関数から参照される関数の外にある変数の一覧。
スナップショットみたいなもん。
っていうふうに、俺は理解してるんだが。
どーでしょか？＞議論中の方
だから、インスタンスのように振舞うこともあるって感じですかね。
0225デフォルトの名無しさん
NGNGあっちこっちもって歩けるようにしたもの。
高階関数は、関数オブジェクトを引数にとる関数。
あ、関数オブジェクトを返すのもそーですっけ？
0226デフォルトの名無しさん
NGNG関数型言語とevalはまったく関係ないよ。
(C言語でeval実装〜とか言っていた人がいるので念のため。)
'eval'つーのはLISPで動的にリスト（データ）を評価する手段ってだけ。
不要なevalはなるべく使わないで書くのが良いスタイル。
Schemeの規格でも最近までevalは含まれなかったし。
0227デフォルトの名無しさん
NGNG0228デフォルトの名無しさん
NGNGを読んだが、関数言語と妙にシンクロする。
第３章「もの」と｢働き」より
「…群論が現れるまで数学者の考える対象は数か図形に限ら
れていた。…
現代の数学でとくにいちじるしい対立をなしているのは
「もの」の概念と「働き」の概念である。もちろん、一つの
文章はすでに「何かのものが何かの働きをする」という形を
とっているのと同じく、数学のなかにもこの二つが対立して
いることは当然であろう。ガロアの輝かしい功績は、この
｢働き」をきわめて明瞭な姿で数学のなかに持ちこみ…」
オブジェクトとか高階関数の話と似てるような気しない？
0229デフォルトの名無しさん
NGNG0230デフォルトの名無しさん
NGNG0231デフォルトの名無しさん
NGNG数学的記述を目指して開発されたのが
関数型であることを考えるならば、
それはごく当然だろう。
指摘するまでもないことのように思うが。
0232デフォルトの名無しさん
NGNGカリー化された関数（'a -> 'b -> 'c)なんかも高階関数と呼ばれるよね。
>>217
ハア？じゃあ、メソッドは関数の実装といえると思うが、どうよ？
0233231
NGNG計算機科学は「いかにして」の概念を精密に扱う枠組を
提供しようとするものだとされており、
それに対して、数学は「なんである」の概念を
精密に扱う枠組を提供するものとされている。
というか、SICPにはそうある。
しかし、群論などでわかることは、
その「いかにして」を扱うことが
現代数学の主要な特徴になっているということだ。
その意味である種の重なりのようなものを見るのは
いたって自然なことなのかもしれない。
0234デフォルトの名無しさん
NGNGActors ≡ Closures (mod syntax)
Guy Steeleが著者の一人にもなっているHackers' Dictionaryの
moduloの項目を見ろ。(今ならJargon Fileとしてwebで読める。)
Lisp Hacker用語ではmoduloはexceptと読むのだ。
つまり、上は、
「Actorsは(見かけの違いを除けば)Closureとおんなじ」
という意味なのだよ。
0235デフォルトの名無しさん
NGNGおれの感覚おかしい？
0236デフォルトの名無しさん
NGNG板違いだけど、群論入門の良書って何。教えて。
HaskellのMonadなんかも半群うんぬんの話がでてきた。
群論って少しは知ってた方がよさそう。
0237仕様書無しさん
NGNG『数学小事典』 ブルーバックス P.148より
【群】
一般に、集合Gにおいて、Gの任意の元a,bに対し、
Gのある元a・bが対応して、次の1〜3の公理をみたすときに、
集合Gは群と呼ばれる。
公理1 （結合法則）
Gの任意の三つの元a,b,cに対して
([a]・[b])・[c] = [a]・([b]・[c])
が成り立つ。
公理2 （単位元の存在）
Gの任意の元aに対して
[e]・[a] = [a] = [a]・[e]
となるようなGの元eが存在する。
公理3 （逆元の存在）
Gの任意の元aに対して
[a]^{-1}・[a] = [e] = [a]・[a]^{-1}
となるGの元a^{-1}が存在する。
誰か簡単な説明と表記の間違い指摘を頼む（ｗ
0238三歳児
NGNG1*a = a = a*1
(1/x)*x = 1 = x*(1/x)
(a+b)+c = a+(b+c)
0+a = a = a+0
(-x)+x = 0 = x+(-x)
0239デフォルトの名無しさん
NGNGそうなのか、なんか笑っちゃうね。
最初からそんな風に書かなければいいと思うが、
その定義はあとづけだな。要するに。
それを天才というべきなのかは議論の余地があるな。
個人的には、"isomorphic in their behavior"に
説得的なものを感じていただけに、少し残念だ。
0240デフォルトの名無しさん
NGNGまあ、群論というか、代数学は基本的には、
計算機に大きく関係する方だと思うよ。
数を扱っているからね。
0242デフォルトの名無しさん
NGNGなんか果てしない泥沼にはまりそうで怖くなるね。
短い人生をああいうものに賭けるのは漢だ！ｗ
0243デフォルトの名無しさん
NGNG俺にはActors≡Closures(mod Syntax)が
言葉遊びには見えないんだがな。
ActorsとClosuresは、Syntax、
つまり、言葉なり記号なりの配置の仕方
と言う観点からみると、同様の役割・機能・振る舞いのようなものを
持っていると、そういうことを言いたいのではないかと思った。
それを別の言い方で言うと、振る舞いにおいて同形であると、
そういうことなのではないだろうか。
そう考えた方が整合的だと思うが。
それをJargon等を読むような連中には同形の意味がわからんので、
modはexceptなんだといっているのではないだろうか。
言葉遊びと言うにはいささかお粗末だしな。
まあ、俺がいったようなこともある意味言葉遊びだが、
それでもそちらの方が整合的だ。
0244デフォルトの名無しさん
NGNGどう公理系を構築すれば大体の場合において支障をきたさずに済むか、だからね。
どんな論もある前提において成り立つにすぎない。
ユークリッド幾何学しか知らない中学生がヒルベルト空間をどう思うか。
0245デフォルトの名無しさん
NGNG0246217
NGNG手続き型ＯＯのClosureを引数または返値とするメソッドは
高階関数とは少し違うような気がします。
正確に知ってる人がいたら教えてください。
>>232
>ハア？じゃあ、メソッドは関数の実装といえると思うが、どうよ？
メソッドの定義は関数の実装といえるという意味なら同意。
0247デフォルトの名無しさん
NGNG>高階関数とは少し違うような気がします。
そうだね。
戻値として返される関数は、そのメソッドが所持してる変数などを
「知っている」場合があるし。
関数の振る舞いはメソッドの中身と密接に関わっている。
0248デフォルトの名無しさん
NGNGとりあえず、「群（グループ）」についてそれでは意味がわからんので、
計算機科学的に引き直して言っておくと、
なんかしらのassociation（メソッド、関数、演算等）が定義されている
メンバ（属性、変数、数値、文字等々）の集まりだ。
それで、そのassociationがその規則を満たすというものだ。
あくまでも計算機科学的引きなおしだから、
参考程度にとどめて置くように。
0249248
NGNGその結合は、勿論メンバの中に含まれている。
つまり、結合もメンバだ。
0250デフォルトの名無しさん
NGNG428には「結合」という単語は使われていないようだけど、
「その結合」って何のこと？
0251デフォルトの名無しさん
NGNGん？
associationだけど、なんか変か？
まあ、というか、ある種の働きと言うか
関係と言うかそういうもんなんだが。
>誤解のないように言っておくが、
>その結合は、勿論メンバの中に含まれている。
>つまり、結合もメンバだ。
なんか意味不明な表現になってしまっていて
申し訳ないが、
結合（働き、関係）もメンバ（要素、元）になり得ると言うことだ。
どうでもいいかもしれんが、
一応これから出かけるんで、
質問などにはしばらくは答えられない。
0252デフォルトの名無しさん
NGNGもう結合は終わりましたか？
0253デフォルトの名無しさん
NGNGJargon Fileを読んで面白く感じないなら
LispもSchemeも面白いと思わないだろうな...
それはどうでも良いが、Steeleの文章はこの手の言葉遊びばっかりだよ。
RMSらとともにLisp hackerdomの中心にいた人だしね。
moduloをexecpt (for)と読むのが後付けなわけがない。
Imperative論文はjargon-1より後だもの。
自分の勝手な解釈を後付けで補強しようとしてないか?
0254デフォルトの名無しさん
NGNGｵﾏｴﾓﾅｰ
0255GLS
NGNGmoduloは「except for」と読みますが何か？
0256デフォルトの名無しさん
NGNGちょっと聞きたいんだが、
もしexceptならば、
その除外されるSyntaxとは何だ？
また、≡とはJargon的にはどのような意味だ？
0257デフォルトの名無しさん
NGNGというか、moduloがexcept forだなんて、
言葉遊びでもなんでもないぞ。
どうしてこれが言葉遊びになるのか…
ただの間違いだ。それも初歩的な。
それを「言葉遊びだ」なんて言われて、
「はいそうですか」とか真に受けるなんて、
お前は「馬鹿」ではないのか？
しっかし、どうしてもそんな数学的に
粗雑な話をするとは思えないな。
お前はそれで幸せなのかもしれんが。
それは具体的にJargon Fileのどこに書いてあるんだ？
本当に「その部分」の作成に関わったのか？
0258デフォルトの名無しさん
NGNG俺はimperativeは読んでないが…
＞それは具体的にJargon Fileのどこに書いてあるんだ？
http://www.tuxedo.org/~esr/jargon/html/entry/modulo.html
ミラーも山のようにあるからすぐ見つかるはずだが。
別に粗雑とは思えん。（なんか意地になってる？）
＞本当に「その部分」の作成に関わったのか？
http://www.tuxedo.org/~esr/jargon/html/Revision-History.html
を見るとほとんどの版の出版に関与してるね。俺もSteele-1983版は読んだ。
その項目を最初に書いたかどうかはしらんが関わったのは確かだろう。
0259デフォルトの名無しさん
NGNG>(4 = 22 mod 9).
なんだこれは
なんで、≡ではなく＝なんだ？
>別に粗雑とは思えん。
では、説明して欲しい。
その除外されるSyntaxとは何なのか？
そして、そうすると、≡とは一体いかなる意味になるのか？
確かに意地にはなっているが、
それはActors≡Closures(except for Syntax)
と、文中にあったisomorphismが繋がらないからだ。
それともこのSyntaxにもなんか特別な意味があるのか？
0260デフォルトの名無しさん
NGNGそりゃPDP-10の文字コードに≡が無かったからに決まってるじゃん。
＞では、説明して欲しい。
＞その除外されるSyntaxとは何なのか？
Actors ≡ Closures (mod Syntax)とかisomorphismとか、
シャレで疑似数学風に書いてはあるけど、言いたいことは要するに、
"Actors are just closures (except for slight syntax difference)."
ってことでしょ。
「Actors ≡ Closures (mod Syntax difference)」
じゃ数式風の形じゃないから面白くないじゃない。
（ここまでシャレを説明しなきゃなんないってのも
興ざめっつーか萎えるっつーか）
0261無名 (modulo 地元)
NGNG> なんで、≡ではなく＝なんだ？
ﾜﾗﾀ
'＝'じゃなくて'='な。
0262無名 (modulo 地元)
NGNG> "Actors are just closures (except for slight syntax difference)."
closure "with proper tail recursion"と書いておかないと絡まれるかも〜。
0263デフォルトの名無しさん
NGNG>＞なんで、≡ではなく＝なんだ？
>そりゃPDP-10の文字コードに≡が無かったからに決まってるじゃん。
ほう、それでこの時代になっても全く変えていないのか。
>Actors ≡ Closures (mod Syntax)とかisomorphismとか、
>シャレで疑似数学風に書いてはあるけど、言いたいことは要するに、
>"Actors are just closures (except for slight syntax difference)."
>ってことでしょ。
>「Actors ≡ Closures (mod Syntax difference)」
>じゃ数式風の形じゃないから面白くないじゃない。
>（ここまでシャレを説明しなきゃなんないってのも
>興ざめっつーか萎えるっつーか）
分からないに決まっているだろ。
数学的に間違いがあるんだから。
学のない人間にこそ通じる洒落に過ぎない。
俺としては、Schemeとかは他の言語に比べて
数学の諸成果を積極的に取りこんでいる言語だと思っていたので、
数学の記法というかそう言うものに関しては
ちゃんとしていると言うか、一目置いているというかそう思っていたんだ。
まあ別にそういうことならそうでもいい。
それからいっておくと、isomorphicというのは"Actors are just closures"
ではない。これはお前の間違いだ。
というか文脈から言っても違う。
また、≡も「同じ」ではない、一応言っておく。
おそらく「合同」という意味そのままだろう。
>>261
一応≡と統一しようと思っただけで他意はない。
0264デフォルトの名無しさん
NGNG＞>そりゃPDP-10の文字コードに≡が無かったからに決まってるじゃん。
＞
＞ほう、それでこの時代になっても全く変えていないのか。
なんというか、集合論を知らないとそういう固定観念が
生まれるのか
0265デフォルトの名無しさん
NGNG違いぐらい知ってるっつーの。
で、あの論文の中に出てきたisomorphism(って書いてあっただろヴォケ)が、
本当に数学的に厳密な意味での同型性だと思ってるのか？
ただ「それっぽく」シャレで書いてあるだけだろが。
だいたい、ASCII(でもLatin-1でも良いが、DOSでもUnixでもTTYでも
使えるくらいメジャーなcharacter set)で≡をどう書けっつうんだよアフォが。
ほんまにシャレのわからんヤツやのー。Phil Wadlerの爪の垢でも飲め。
0266デフォルトの名無しさん
NGNGftp://publications.ai.mit.edu/ai-publications/pdf/AIM-379.pdf
件の章を読むと、ちゃんとした数学の話でないことは一目瞭然だね。
まあ、「Actorなんてただのlambdaじゃん」と言ったら角が立つだろう
からねえ。HewittってSussmanの同僚でしょ？ だからisomorphism
などとオブラートにくるんで言ったのでは。
0267デフォルトの名無しさん
NGNG>で、あの論文の中に出てきたisomorphism(って書いてあっただろヴォケ)が、
>本当に数学的に厳密な意味での同型性だと思ってるのか？
そんなことは言っていない。
っていうか、お前は真の馬鹿者だな。
そして、どう考えてみても、ボケはお前の方だ。
「同じ」ではない、といっているんだ。
どうしたら厳密に数学的なisomorphicだと俺が言っているんだ？
>ほんまにシャレのわからんヤツやのー。
だ・か・ら、「一般的な意味では」、modはexcept forではない。
modがexcept forであるかどうかの区別も分からん奴には、
洒落になるといっているんだ。
本当に学のない奴だ。
0268デフォルトの名無しさん
NGNG>＞>＞なんで、≡ではなく＝なんだ？
>＞>そりゃPDP-10の文字コードに≡が無かったからに決まってるじゃん。
>＞
>＞ほう、それでこの時代になっても全く変えていないのか。
>なんというか、集合論を知らないとそういう固定観念が
>生まれるのか
少し意味がわかりませんが、もう少し詳細に説明してください。
そしてあなたのご高説を聞かせてください。
言葉は悪いですが、少なくとも私には265の
>だいたい、ASCII(でもLatin-1でも良いが、DOSでもUnixでもTTYでも
>使えるくらいメジャーなcharacter set)で≡をどう書けっつうんだよアフォが。
の方が意味がわかるんですが。
0269デフォルトの名無しさん
NGNG明示されていれば問題になることはない。
ということだろう。
よく使う記号は＝≡〜⇔とかだね。
0270無名の体系 (modulo 差異)
NGNG> だ・か・ら、「一般的な意味では」、modはexcept forではない。
> modがexcept forであるかどうかの区別も分からん奴には、
> 洒落になるといっているんだ。
仲間内での言葉遊びはどんどん逸脱していくものだということを理解して欲しい。
駄洒落等が差異を楽しむ遊びであることを理解すれば納得できると思う。
moduloとexcept forに何の関連も見出せない人がいる、
そのくらい逸脱して初めて大いに盛り上がることが出来るのだ。
仲間内では基本パターンはやり尽くしているからね。
君はこの他愛もない言葉遊びからは仲間外れだが、
君の無理解、不寛容自体も仲間の笑いの対象だ。違うことは面白いのだ。
0272デフォルトの名無しさん
NGNG「Steeleの論文では」moduloはexcept forだ、
というのは、はっきりしてるだろうに。
だれも「一般の」moduloの話なんかしてないってのに。
よい恥さらしだな。
0273test&age
NGNGhoge
0274デフォルトの名無しさん
NGNG=というのは、恒等関係を表すものだ。
同値関係には使用しない。
もちろん恒等関係は同値関係の中に含まれるが、
だからといって、単に同値なものを恒等と言ったりはしない。
それでは記法としては話にならない。
というか、264は、「集合論を知らないと・・・」といっている。
集合論を知らないと生まれる固定観念とは
ここでは何をさしているんだ？
そして、集合論を知っていると生まれる正確な観念とは
それから比較するとどのようなものだ？
俺はそれを聞きたいんだよ。
>>270
おまえさ、俺がsteeleの話が数学的に厳密な同型性だと
どこでいっていたのかを指摘しろ。
実際には、お前の方が遙かに無理解だ。
>君はこの他愛もない言葉遊びからは仲間外れだが、
>君の無理解、不寛容自体も仲間の笑いの対象だ。
他愛がないというより有害だ。
世界はおそらくお前が思っているより広い。
その中で一意に伝達するためには、
しっかりした定義付けや記法が必要だ。
形式化の努力にはそういった意義もあるはずだ。
確かに無理解だが、それは「有害な」言葉遊びのためだ。
■ このスレッドは過去ログ倉庫に格納されています