5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

関数型言語Part2

1 :デフォルトの名無しさん:01/12/03 22:58
前スレ
http://pc.2ch.net/test/read.cgi/tech/987954395/

2 :1:01/12/03 23:01
このスレッドの趣旨は
「関数型言語からRubyへステップアップ」
です。よろしくお願いします。

3 :デフォルトの名無しさん:01/12/03 23:08
関連スレ

関数型プログラミング言語Haskell
http://pc.2ch.net/test/read.cgi/tech/996131288/

ML!!!!!!
http://pc.2ch.net/test/read.cgi/tech/1002111468/

LISP Scheme Part2
http://pc.2ch.net/test/read.cgi/tech/1002584344/

Emacs Lisp
http://pc.2ch.net/test/read.cgi/tech/1004551074/

再帰
http://pc.2ch.net/test/read.cgi/tech/992241842/

4 :1-original>>2:01/12/03 23:08
死んでください

5 :1-original:01/12/03 23:11
つーか、おれにできるのはここまでだょ。
勝手にスレ立てしてごめんょ。魔が差したんだょ。
あとは任せたょ。

6 :デフォルトの名無しさん:01/12/03 23:15
だからlispは関数型じゃねーって。

7 :デフォルトの名無しさん:01/12/03 23:21
えっ?
一応はしりだろ。

8 :デフォルトの名無しさん:01/12/03 23:22
このスレッドの趣旨は
「関数型言語からRubyへステップアップ」
です。よろしくお願いします。

9 :デフォルトの名無しさん:01/12/03 23:33
恐らく流れはこんな感じだろ。

lispは破壊的なリスト操作をしなくてもプログラムが書ける。

代入が無ければ見通しがいいかも。

変数なんて捨てちまえ。

ついでに副作用なんて捨てちまえ。

作用的評価順序なんて捨てちまえ。

最近カレーがンまい!

haskellの誕生。

10 :デフォルトの名無しさん:01/12/03 23:35
―――――このスレで一番痛いところは、
関数型をほんとに理解してるやつが居るのかどうか
怪しいという点だ(おれも含めて)―――――

11 :デフォルトの名無しさん:01/12/04 00:14
>>6

ttp://www.cs.nott.ac.uk/~gmh/faq.html
comp.lang.functional FAQを読むと、SchemeやMLは一応「副作用も許す
のでpureではない関数型言語」という扱いになっている。Lispは論外だ
ね(副作用なしではループも書けないから)。

ところで、FAQだとHaskellも「広い意味での純関数型言語」となってい
る。I/Oがpureとは言いきれないから、らしい。

12 :デフォルトの名無しさん:01/12/04 06:18
>I/Oがpureとは言いきれないから、らしい。
これはどこに書いてある?

13 :デフォルトの名無しさん:01/12/04 07:22
Haskellは完全にpureだろ。

14 :デフォルトの名無しさん:01/12/04 10:01
関数型言語の有用性は、関数型言語のプログラミング作法を、関数型でない言語で試してみるとよくわかるよね。
余計な一時変数を作らないようにしたり、再帰でプログラミングしたりといったことは、関数型言語でなくてもできる(速度的に不利だとしても、ボトルネックだとわかるまではそのままにしておける)。
やってみればデバッグが楽になることがわかるし、その問題への本質的な理解が深まることがわかるよな。

15 :デフォルトの名無しさん:01/12/04 10:47
>>12-13
http://www.cs.nott.ac.uk/~gmh/faq.html#purity

16 :デフォルトの名無しさん:01/12/04 11:24
>Sometimes, the term "purely functional" is also used in
>a broader sense to mean languages that might incorporate
>computational effects, but without altering the notion of `function'

ここ訳してお願い

17 :デフォルトの名無しさん:01/12/04 11:53
>>15
そこにはHaskellのI/Oメカニズムでは実行と評価が分かれてる
と書かれてると思うが、pureとはいい切れないなんて意味じゃな
いだろ?

18 :デフォルトの名無しさん:01/12/04 12:03
>Sometimes, the term "purely functional" is also used in
>a broader sense to mean languages that might incorporate
>computational effects, but without altering the notion of `function'

(直訳)
「関数」の概念は変えないが計算的な作用を組み入れた言語まで意味するよう
なもう少し広義で"純関数型"という用語を使うことがある。

(意訳)
「参照透明性」は壊さないまま、いわゆる副作用も扱える言語まで含めるよう
に、「純関数型」という用語を拡大解釈することがある。

(そういう拡大解釈をしなければHaskellは「純関数型」に含まれない。)

19 :デフォルトの名無しさん:01/12/04 12:08
>>18
意訳のほうがめちゃめちゃ作為的にみえるんだけど。

20 :Kusakabe Youichi:01/12/04 12:11
In article >>16, 16 デフォルトの名無しさん wrote:
> > Sometimes, the term "purely functional" is also used in
> > a broader sense to mean languages that might incorporate
> > computational effects, but without altering the notion of `function'
> ここ訳してお願い

自動翻訳だと

「一般的な言語では"purely functional"という用語は計算結果を含む
より広義にも用いられる場合もある。」

ですね。

meanを動詞と解釈するのもWebにはあるけど、
ほんとのところはどうなんでしょ?
(「卑劣な, 下品な, さもしい, あさましい」だったり:)

21 :デフォルトの名無しさん:01/12/04 12:12
(意訳)
一般には副作用と捕らえる事柄を、作用の概念のみを用いて表せるように
した言語を純関数型ということがある。

(Haskellは一般には副作用となるような言語すら副作用ではなく扱える
完全に純粋な関数型である)

22 :デフォルトの名無しさん:01/12/04 12:57
>>21
それはコンピュータのアクションを扱わない言語が狭義の純関数型で
コンピュータのアクションも扱って、しかもそれが副作用では無い
言語が広義の純関数型と言ってるだけじゃないの?

それによるとHaskellは広義の純関数型だけど、完全に純粋ではない
と言うネガティブな意味ではなくて、純粋なくせに他より強力な
機能を持ってると言うポジティブな意味だと思う。

23 :デフォルトの名無しさん:01/12/04 13:01
>「一般的な言語では"purely functional"という用語は計算結果を含む
>より広義にも用いられる場合もある。」

まあ良いけど「一般的な言語では」ってどうやったらそうなるのよ。

>meanを動詞と解釈するのもWebにはあるけど、
sense to mean を不定詞以外にどう解釈するんだ。

>一般には副作用と捕らえる事柄を、作用の概念のみを用いて表せるように
>した言語を純関数型ということがある。

「一般には」ってどっから湧いて出た?
effectって言葉は原文に1つしかないぞ?

>(Haskellは一般には副作用となるような言語すら副作用ではなく扱える
>完全に純粋な関数型である)

自動翻訳か? 「言語すら扱える」って(藁

24 :デフォルトの名無しさん:01/12/04 13:11
>>23
> まあ良いけど「一般的な言語では」ってどうやったらそうなるのよ。

Computatinal effectsって「一般的な」言語では副作用でしょ?

25 :24:01/12/04 13:19
>>24
レスの仕方を間違えた。

> 「一般には」ってどっから湧いて出た?
> effectって言葉は原文に1つしかないぞ?

Computatinal effectsって「一般的な」言語では副作用でしょ?
「functionの意味を変えずに=作用のみを用いて」でしょう。

26 :デフォルトの名無しさん:01/12/04 13:43
>>22
Monadic I/O以前のHaskellはI/Oを扱っていたが狭義の
純関数型言語だったんじゃないか?
だからその「狭義」の解釈は違っている。

27 :デフォルトの名無しさん:01/12/04 15:56
Hudak先生のお言葉:
Haskell -> lazy but pure
SML/NJ -> eager but dirty!

28 :デフォルトの名無しさん:01/12/04 18:10
いつになったら抽象論から外れるんだろうか。

29 :デフォルトの名無しさん:01/12/04 19:43
>>28
おまえに任せた

30 :デフォルトの名無しさん:01/12/04 22:11
関数型言語の世界じゃ、識別子は短めがナウなヤングにバカウケなの?

31 :デフォルトの名無しさん:01/12/04 23:07
不必要に具象的な識別子をつけるのは流行らないね。
抽象化できるかぎり抽象化するのが通のやり方。

32 :デフォルトの名無しさん:01/12/04 23:09
数学界の悪しき慣習だね

33 :デフォルトの名無しさん:01/12/04 23:19
why?

抽象化された関数を利用するときに具象的な実引数を渡せば良いだけではないの?
つまり、関数を利用する側では、具象的な識別子を使えばいいんだよ。
関数を定義するときはできるだけ抽象的な識別子を使う。
それが通の使い分け。

34 :デフォルトの名無しさん:01/12/05 00:12
いみふめsage
f(g(Kusakabe_Yokaichi ))

35 :デフォルトの名無しさん:01/12/05 00:16
>>33
通でもなんでもないだろ

36 :デフォルトの名無しさん:01/12/05 00:26
少なくともJavaみたいのが良いとは、誰も思わないだろ?

37 :なんだネタか:01/12/05 00:28
 

38 :デフォルトの名無しさん:01/12/05 00:31
識別子は長くも短くもできるんだからどうでもいいだろ。
つまらない議論ばかりだな。

39 :デフォルトの名無しさん:01/12/05 00:36
どうでもいいか?
可読性からいっても、結構重要なことだと思うぞ。
実際JAVAなんて、打ち込んでるだけで嫌になるしな。

40 :デフォルトの名無しさん:01/12/05 00:43
エディタに補完があればどうでもい

41 :デフォルトの名無しさん:01/12/05 00:47
なければどうなんだ?

42 :デフォルトの名無しさん:01/12/05 00:59
そういう環境・コーダはいずれ絶滅します

43 :デフォルトの名無しさん:01/12/05 00:59
なくてもどうでもいい
コピペすれば?

44 :デフォルトの名無しさん:01/12/05 01:02
俺は補完+コピペ使用でも鬱になるが・・・

45 :デフォルトの名無しさん:01/12/05 01:03
38の意見なんてどうでもいい

46 :デフォルトの名無しさん:01/12/05 01:04
ハァ?
お前らなんか勘違いしているようだが
俺たちに生産性やそれを左右する
開発手法・コーディングスタイルなんて関係がないのさ

47 :デフォルトの名無しさん:01/12/05 01:08
なんで?

48 :デフォルトの名無しさん:01/12/05 01:15
残り関数型言語使い 0人

49 :デフォルトの名無しさん:01/12/05 01:16
俺たちの目標は単位を取ることであって
なにかを生産・開発することではない
それにコードも長くて100行程度だから
手法やスタイルは一切不要なのだ
おわかりか?

50 :デフォルトの名無しさん:01/12/05 01:25
「一文字変数なんか使う奴は氏ね」と言われて育った漏れには、
一文字変数使いまくりのHaskellの大胆さに失禁気味です。

51 :デフォルトの名無しさん:01/12/05 01:34
ようは程度問題だろ
JavaやHaskellみたいに極端なのは外基地

52 :デフォルトの名無しさん:01/12/05 04:06
ネーミングは難しい。簡潔なのがベストだが、センスのない人間が
わかりやすくしようとすると、ダラダラ長くなる。結局長すぎて見
通しが悪くなり、かえってわかりにくくなる。

53 :デフォルトの名無しさん:01/12/05 04:36
っつーか、
Javaみたいなinclusion polymorphismな言語では長い名前のほうが合ってるけど
関数型言語みたいなparametric polymorphismな言語では長くしようがないと思われ。
「hd x = ...のxをx以外にどう言えってんだ」って。

54 :デフォルトの名無しさん:01/12/05 04:40
Javaのスタイルに合わせると鬱になる

55 :デフォルトの名無しさん:01/12/05 05:02
Java = 鬱そのもの

56 :朝の心理テスト:01/12/05 05:44
Javaが饒舌なのは、書いてる本人に自信が無い事の現れです。
今日のラッキーアイテムはedlin。

57 :デフォルトの名無しさん:01/12/05 08:28
>>39
だから、長くしようと思えば、Haskellで長くすることもできるし、
Javaで短くしようと思えばすることもできるじゃない。

58 :デフォルトの名無しさん :01/12/05 09:25
verificationが出来る方がいい

59 :デフォルトの名無しさん:01/12/05 10:50
関数の識別子はともかく、
関数の中での変数名は一文字でもいいだろ。

60 :デフォルトの名無しさん :01/12/05 13:04
データに実世界のオブジェクトを表すような名前が必要かどうか。
現実的なプログラムって全然汎用的じゃなくてある決まった処理を
するために作られることがおおい。だから変数名は端的かつ分かりやすい
方がいい。そのために自然言語の意味の借用もありでしょ。
だけど関数型言語のやり方にケチつけてる必要もない。
かれらが表現したいのは個物から離れたものだから。

61 :デフォルトの名無しさん :01/12/05 16:57
未だにPVSマンセーな俺は逝ってよしか?

62 :デフォルトの名無しさん:01/12/05 17:04
関数型と手続き型では変数の担う役割が違うし
手続き型での常識を持ち込まれても…。

63 :デフォルトの名無しさん:01/12/05 21:43
JAVAのライブラリ使ってみろ。
どうやって短くすんだ?

64 :デフォルトの名無しさん:01/12/05 22:30
>>63
ライブラリに頼るのは厨房

65 :デフォルトの名無しさん:01/12/05 22:32
オイオイ、JavaからLibraryとったらなにも残らないよ>64

66 :デフォルトの名無しさん:01/12/06 01:05
ネーミングは簡潔にって事だ

67 :デフォルトの名無しさん :01/12/06 03:08
>>61
pvsマンセー!!!

             逝って来ます...

68 :デフォルトの名無しさん:01/12/06 03:40
実用されてないオナニー言語系の人達の言うことは違うねえ。

69 :デフォルトの名無しさん:01/12/06 03:54
pvsは実用されてますが何か?

70 :_:01/12/06 08:44
関数型言語(lisp)ってあまり実用的でないかもしれないけど影響力は凄いよね。

71 :煽り:01/12/06 10:47
>>70
たとえば?

72 :デフォルトの名無しさん:01/12/06 13:20
>>70
lispは関数型ではないって話のながれだったのでは…

73 :デフォルトの名無しさん:01/12/06 13:21
研究分野で広く使われていることは実用的とは言わないのか。

74 :デフォルトの名無しさん :01/12/06 14:18
>>73
ここの多くのプログラマは、
学生が業務系システムについて何も知らないことをバカにする割りには、
自分らが研究分野について無知なことには無頓着なのでれす。

俺は業務系。研究分野なんて何も知らん。だから何も言わないw

75 :デフォルトの名無しさん:01/12/06 14:56
>>74
ハハハ,鋭い.それでもって,研究動向に無知なことを指摘されると,
「それ(研究)じゃ給料は稼げない」とか言うわけね.

76 :デフォルトの名無しさん:01/12/06 16:31
喰えるか喰えないか、それが問題だ。

77 :デフォルトの名無しさん:01/12/06 16:35
生き延びる人

78 :デフォルトの名無しさん:01/12/06 20:29
重要なのは、それで遊べるかどうかだ。
食える言語は他にいくらでもある。

79 :浮上:01/12/09 03:08
OOと関数型は相容れません

80 :デフォルトの名無しさん:01/12/09 03:16
OOとの違いはよく分かんないけど、
関数型の言語って静的にプログラムの内容を
検証しやすいとかってメリットはあるの?

81 :デフォルトの名無しさん:01/12/09 03:22
副作用が無ければその通りだ。

82 :デフォルトの名無しさん:01/12/09 03:26
>>79
OOを実現した関数型言語はいくらでもある。

83 :デフォルトの名無しさん:01/12/09 03:28
概要は?

84 :デフォルトの名無しさん:01/12/09 03:29
というか
・手続き型
・オブジェクト指向型
・関数型
・論理型
という2種的(w)なカテゴリーに分けることが
既に現実からはなれてしまっているような気がするが。

85 :現実的な回答:01/12/09 03:33
全ての言語は、次の2つに分ける事が出来る。
・実務型
・オナニー型

言うまでもなく、所謂関数型はことごとく後者だ。

86 :デフォルトの名無しさん:01/12/09 03:36
彼女も認めるほどのオナニストですが何か?>85

87 :デフォルトの名無しさん:01/12/09 03:38
>86
こすり過ぎて、関数型言語でショッピングサイトを作ろうなんて
暴挙に出るなよ。

88 :デフォルトの名無しさん:01/12/09 03:51
>>87
ことごとくライバルを打ち負かしてしまい、オナニーに拍車がかかるからな。

89 :デフォルトの名無しさん:01/12/09 04:01
>>85
前者には APL と PL/I と COBOL と VB と C と C++ しかないようですが?

90 :デフォルトの名無しさん:01/12/09 07:26
ADAはぁ?

91 :デフォルトの名無しさん:01/12/09 08:14
このスレ内容濃くて(特に前スレの前半)自分の無知を思い知らされるわ

92 :デフォルトの名無しさん:01/12/09 22:09
前スレがこともあろうにHaskellマンセーで終わっている…!!!!

93 :login:Penguin:01/12/10 02:02
>>92
だめなの?

94 :デフォルトの名無しさん:01/12/10 02:13
>>85
gcc は実務に使えないと?

95 :デフォルトの名無しさん:01/12/10 02:43
?

96 :デフォルトの名無しさん :01/12/10 03:08
やっぱりS式がいいなぁ、ボソ

97 :デフォルトの名無しさん:01/12/10 11:15
>>65

んなことないべ。

>>75

OCamlは?使ったことないんだけど。

98 :94:01/12/10 17:12
>>95
gcc は一旦プロセッサに依存しないツリーを作って、それをプロセッサ依存のコードに展開する方式を
採用している。でプロセッサ依存部分の記述だけど、ソースを見れば分かるように、独自の関数型言
語で書いてある。(see config/i386/i386.md)

あとはデータファイルが関数型言語っぽいデータ構造になってる CAD なんかも、わりとよく見かける
ね。

99 :デフォルトの名無しさん:01/12/10 20:23
>>98
かっこがたくさんあるからって関数型って呼んでたら
関数型やってるひとが怒るぞ。

100 :デフォルトの名無しさん:01/12/10 22:07
>>99
どっちの話?

101 :デフォルトの名無しさん:01/12/11 03:04
たぶんgccの話でしょ。
関数型言語的というよりLisp的だから。
EmacsのStallmanが作ったcompilerだし。

102 :デフォルトの名無しさん :01/12/11 03:21
関数型言語ってシステムの記述に使われたりしてるの?

103 :デフォルトの名無しさん:01/12/11 08:34
>>102
Lispマシンとか(藁

104 :デフォルトの名無しさん:01/12/11 12:33
>>102
SMLもHaskellもコンパイラを書いたりするのに使われているよ.

それから,CMUのFOXプロジェクトではSMLでネットワーク周りのコードを
書きまくってる.

あと,電話交換機のコードで実際に使われていた関数型言語って何だったっけ?

105 :デフォルトの名無しさん:01/12/11 13:20
Erlangだっけな? Ericssonの交換機。(purely functionalではない)
後、オランダでは、運河の排水制御をやっていた。

106 :デフォルトの名無しさん:01/12/12 03:43
このスレで、キャッシュとか部分計算とかいったら、怒る?

107 :デフォルトの名無しさん:01/12/12 09:43
>>106
そんなのは明示的に書かなくても処理系が見抜いてくれることを希望。

108 :無名λ式:01/12/12 09:50
>>106
意味論中立な処理系実装技術、ってことでOKなんじゃないの?
"Partial Evaluation and Automatic Program Generation"も
ほとんど関数型言語の話だよね。

109 :デフォルトの名無しさん:01/12/12 13:09
Stateless な Webアプリケーションって、関数プログラミングに似ているかなっと。

でも、ユーザ・インターフェース上の要求や、パフォーマンス向上を考慮すると、
セッション管理や、各種キャッシング技法や、DBによる状態保存が必要になる。


で、上記のうちの「キャッシング」の記述技法の提供が、「オブジェクト指向」の使命
(の1つ)かな、と言いたかったんですが、、、、

(例: EJB の SessionBean, EntityBean, エクステント管理)

110 :デフォルトの名無しさん:01/12/12 18:25
関数型でキャッシングすれば良いだけの話じゃない?

111 :デフォルトの名無しさん:01/12/12 19:38
理屈(意味論限定)ではそう。

でも実際、セッションや処理コンテキストに応じた、精度の高いキャッシングは、
処理系(HTTPキャッシュや、RDBの結果キャッシュ、Webアプリケーション・サーバ)
では面倒みてくれないから、手書きするのが普通。
んで、局所情報に依存した粒度の細かいキャッシング処理を、アプリ作成者に近い側で記述するには、
オブジェクト指向(やDOA)がよろしいんではないかと。

#関数言語によるWeb構築って(きちんとウォッチしていないからなんだけど)、
#LispでWebアプリ構築っていう話と、OcamlのMooしか知らない。

112 :デフォルトの名無しさん :01/12/12 20:28
関数型言語ではアルゴリズムの記述に注力して、
処理系への設定ファイルのようなものでそういった
細かい問題(であるがとても大事)は片付けられる
ようにならないか?こういったもの誰か作らないかな。

113 :デフォルトの名無しさん:01/12/12 22:12
"Separation of Concerns"で、関数型とキャッシュ管理を分離記述できないのかな?

#徹夜明け&携帯書き込みなんで、ちょっと用語遣いが変 >111

#逝ってくる。

114 :デフォルトの名無しさん :01/12/13 07:29
苫米地さんとこのWebサーバーはどういった感じなんだろう。
apacheの数倍速いらしいけど。

115 :デフォルトの名無しさん:01/12/13 14:40
>>114 苫米地さんとこのWebサーバー
#fj.comp.lang.functional で「有名」だった方ですね。

詳細は知らないけれど多分、マルチスレッド
を使って、単一プロセス内でWebサーバとアプリサーバとWebアプ
リを動かして、コンテキスト・スイッチングを最小限に抑えて高性
能を実現、っといった話のような気がする。所詮、実装技術か?

116 :デフォルトの名無しさん:01/12/13 14:43
>>108 さんくす。
出直してくる。

117 :デフォルトの名無しさん :01/12/13 15:51
>>115
苫米地さんとこは別スレで既存の処理系を使ってると書いてあった。
本当はこういった話は言語レベルで解決すべきではない、という
やり方が関数型言語らしいような気もするけどね。
でもそんなことしていたら実務レベルで使える処理系がいつ出てくることやら。

118 :デフォルトの名無しさん:01/12/13 16:17
λがわかりまくる本ってどれ?

119 :デフォルトの名無しさん:01/12/13 16:17
知りません。

120 :デフォルトの名無しさん:01/12/13 17:40
>>118
やはりλ教の聖書と呼ばれるBarendregt… といいたいけどやはり
大変なので福音書と呼ばれるHindley&Seldinの本あたりでしょうか.
日本語なら高橋正子先生の本でしょう.

121 :デフォルトの名無しさん:01/12/13 20:33
高橋さんの本はちょっと前にアマゾンで注文したところです。

いま新しいプログラミングパラダイム 井田 哲雄
を読んでます。

2章 λ計算と高階プログラミング 横内 寛文
を毎日ちょっとずつ読んでます。
わりと平易に書いてあるけどつらい。。。

122 :デフォルトの名無しさん:01/12/13 21:05
>>118
古い本ですが、私はこの本が面白かったです.

「プログラミング言語の新潮流」 井田哲雄 (共立出版, 1988)

Lisp と Schema の処理系をかじって、次に 型推論って何?
という疑問をもった時に、本書後半の HOPE の説明を読んで、
わかったような気分にひたっていました.

123 : :01/12/15 15:23
関数プログラミング 読み始めた。
ってことでageる。

124 :デフォルトの名無しさん:01/12/15 23:19
前スレから
http://pc.2ch.net/test/read.cgi/tech/987954395/968-981

>やはり言語は実用されているものを例とすべきだ。
>Eiffel等という正直に言って普及しているとは言いがたい言語を例とするのは、
>例示としては頂けない。
>現在の普及率などから考えて、C++やJavaなどを例示とすべきだ。
>その手の議論は言語的な広がりがなくなる。

OO の議論に Smalltalk と Eiffel は欠かせない。

別に Eiffel じゃなくても属性と方法を区別しない OOPL はいろいろある。
Delphi, C#, Ruby, Satherとか。

属性と方法を区別すると再利用しにくいので
OOPL として欠陥だと思う。

125 :デフォルトの名無しさん:01/12/15 23:30
>>124 方法って、メソッドのことか。一瞬ワカラナカタ
Javaもあとからそれに気づいたのか
Beanの規約で属性を表にさらさずにアクセサ方法(Wで
方法のほうに統一しようとしてるし。
すれ違いスマソ

126 :デフォルトの名無しさん:01/12/16 01:12
>>124
2つ質問がある。

>OO の議論に Smalltalk と Eiffel は欠かせない。

なぜ?

それから、Object Pascalがどのような点において
区別していないと言ってるんですか?


なお、方法と属性の弁別について取り上げたのはクラス設計に関連してだ。
言語の完成度は論点ではない。
つまり、クラス設計をする際には、
ある事象とでも言うべきものを抽象化しクラスとするわけだが、
その抽象化は方法と属性と言う観点に注目して行う。
それは関数型言語とはある意味逆なのではないかと言うことだ。
話を俺の論点からずらして反論するのは止めろ。

127 :デフォルトの名無しさん:01/12/16 01:52
>>126
124じゃないけど、論点がわからんなあ。
関数型のように、属性と方法を区別しないのは、OOの設計と反対であるから
区別しないことはOOに向いてないと言いたいのではないのかな?
その点を踏まえて、OOPLにおいて、属性と方法を区別した方が良いと
124は言ってると思うのだが。
なにが論点?

128 :デフォルトの名無しさん:01/12/16 17:23
>>126
>>OO の議論に Smalltalk と Eiffel は欠かせない。
>なぜ?

純粋なオブジェクト指向言語で対照的だから。
Smalltalk は動的型付け、動的リンク。
Eiffel は静的型付け、静的リンク。
Scheme と Haskell みたいな感じかなあ ...

>それから、Object Pascalがどのような点において
>区別していないと言ってるんですか?

Delphi には C#のプロパティと delegate のもとになった機能がある。

>クラス設計をする際には、
>ある事象とでも言うべきものを抽象化しクラスとするわけだが、
>その抽象化は方法と属性と言う観点に注目して行う。

クラス設計をする際には、
インターフェースと(属性とメソッドの)実装に分ける。
だから抽象データ型と呼ぶ。

129 :デフォルトの名無しさん:01/12/16 19:44
話は変わるが、

「命題=型、証明=プログラム」な「構成的ブログラミング」
って、今どーなっているのかな?

型推論と逆の話になると思うが。

130 :126:01/12/17 01:14
>>127
>関数型のように、属性と方法を区別しないのは、
>OOの設計と反対であるから
>区別しないことはOOに向いてないと言いたいのではないのかな?

それはむしろ俺が言いたいことの方に近いのでは?
相手方は、属性と方法を区別するのは
むしろOOPLにとって不完全だといっている。

>>127
>純粋なオブジェクト指向言語で対照的だから。

これは理由にならない。
何度も言うが、言語の完成度なり純粋性は俺の話の反論にはならない。
俺が言っているのは、何度も言うが、クラス設計に関するものだ。
個人的には、C++かJavaが適切だと思ったのは、広く使用されているので、
話が周知されると思ったからだ。
まあしかし、私の話の趣旨からするならば、UML等をいうべきだったかもしれない。

>Delphi には C#のプロパティと delegate のもとになった機能がある。

関数ポインタはOOの場合主としてポリモルフィズムとの関連で言われることが多いし、
実際にそれに向けられている。
高階関数による表現力の増大とは性質が違うのではないだろうか。

またプロパティはここでは関係がない。
と言うより、どう関わってくるのかが
俺には今一つ分からんので説明してください。

>クラス設計をする際には、
>インターフェースと(属性とメソッドの)実装に分ける。
>だから抽象データ型と呼ぶ。

それが俺の話の反論になるとは思えないのだが。
結局、属性とメソッドで分けているのだから。
インターフェースによって隠蔽されていると言うのは
話が違う。
高階関数の場合それ自体がオブジェクトだ。

131 :126:01/12/17 01:19
>>127
>純粋なオブジェクト指向言語で対照的だから。



>>128
>同上

132 :デフォルトの名無しさん:01/12/17 01:58
>>130 は、もしかすると、属性抜きのOOと、関数言語を関連付けようとしているの?

関数型でない普通のOOでは、高階関数なんて使わないと思うが。
実現可能か、と問われれば、1.実行時情報として関数の型を参照できて、2.任意の引き数を扱う事ができて、3.高階関数用プリミティブを用意できれば、可能だと思うが。

133 :デフォルトの名無しさん:01/12/17 02:02
高階関数って何?
高階導関数なら分かるが

134 :デフォルトの名無しさん:01/12/17 02:07
こうかいかんすう【後悔関数】
(名)関数型言語を学んだことを、あとになって悔やむこと。

135 :デフォルトの名無しさん:01/12/17 02:09
>>133
関数をデータとして扱う(引数として取ったり、値として返す)関数のこと。
述語に関する述語(notとか)を高階述語というのと同じこと。

136 :133:01/12/17 02:17
なるほど汎関数や超関数の事か

137 ::01/12/17 02:28
>>130
前スレが読めんのじゃが、もう少し、分かり易く、例を交えて、説明して下さらんかのう。

ちなみに、ワシの記憶によれば、LISPのClosureこそ、OOのインスタンスなんじゃが。

138 :デフォルトの名無しさん:01/12/17 10:40
関数型言語でもOOPできるし、
OOPLでも関数型プログラミングできる。
OOPLでは高階関数が使えないと決まっているわけでもない。
正直、何を議論してるのかわからない。

139 :126:01/12/17 11:59
話の筋道は、
誰かが関数型の特徴とは何か?と聞いていたので、
他の誰かがその回答を色々言っていた。
それで俺としては、高階関数がその特徴なのではないか、
そして、それはある意味OOPLとは逆なのではないか、
と言うことを述べたら、
>>124が、属性と方法を区別するのは
むしろOOPLとしては不完全であるとして、
EiffelやSmallTalk等を例として持ち出してきた。
そこで俺は、126,130のように反論している。

140 :デフォルトの名無しさん:01/12/17 12:04
>>133,134
とりあえず、技術的な話をするつもりがないなら来るな、といっておこう。

141 :デフォルトの名無しさん:01/12/17 12:17
>>136 物理や数値解析系では、そーとも言う。
  分野によって、訳語や用語が違うので、この手の疑問は普通に発生する。

  俺は、数式処理系(Macsyma〜Mathematica) と 命題処理系(ML?)に
  類似性を感じて、興味を持っていたので、乱入大歓迎。

  

142 :デフォルトの名無しさん:01/12/17 12:19
関数型言語(型なし)のエッセンス
構文:
M ::= x | (λx.M) | (M M)

意味:
E[x]ρ = ρ[x]
E[(λx.M)]ρ = cls(x,M,ρ)
E[(M M')]ρ = if E[M]ρ=cls(x,M'',ρ') then E[M'']ρ'{E[M']ρ/x} else ⊥

このくらい簡単にOOPLのエッセンスは書けないものだろうか?
継承とか考えなければやはりアクター計算なのかなあ。

143 :デフォルトの名無しさん:01/12/17 13:10
>>141
では議論を盛り上げるべく、
属性と方法を区別するOOPLが不完全であるかどうかについて、
貴方なりの考えを聞かせてください。

144 :143:01/12/17 13:13
いや、正確には、高階関数が関数型の特徴といえるかでしたね。
すいません。

145 :141:01/12/17 13:22
漏れは、OOPLに 属性とメソッドの区別があっても良い、と思う。
というか、属性とメソッドの区別、というのはシンタックス・シュガー上の問題でしかない、と思う。

146 :デフォルトの名無しさん:01/12/17 13:34
>>145
なるほど、
では、UMLには、Class Diagramと言うのがありますよね?
あの図では、attributeとoperationというものを区別しています。
見ればすぐに分かりますが、
あの図にとってはその区別は重要な一部です。
そのような区別も貴方の言う所では、
シンタックスシュガー(?)になるんですかね?

147 :デフォルトの名無しさん:01/12/17 13:40
Cardelli達がやっていたOOPLの意味論では,オブジェクトはレコー
ドとして表現されていて,属性(インスタンス変数)とメソッドの本
質的な区別は無かったと思います.メソッドというのはインスタンス
変数(この意味論ではレコード要素)にたまたま関数が入ったもので
した.

148 :デフォルトの名無しさん:01/12/17 13:43
>>146
Cardelliの意味論の立場ではその通りで,メソッドと属性は単なる
便宜上の区別でしかないわけですね.この方が理論が整理されて綺麗
では?

149 :デフォルトの名無しさん:01/12/17 13:51
UMLは、オブジェクト指向(OO)というデータ分析方法(DOA)の、記述規約。

オブジェクト指向分析(OOA)では、DOA由来のデータ抽出に加えて、
メソッド抽出も重要なので、アドホックに operation が加わった、という気がする。

DOA/OOA では、多分「状態遷移」みたいな事柄を中心に考えていて、
   DOA   状態 (attribute) を重視、遷移 (operation) を軽視.
   OOA   状態 (attribute) だけでなく、遷移 (operation) も重視.

なのかな、と今思いつきで書いたが、間違っていたらスマソ。

150 :141:01/12/17 13:57
>148 理論のきれいさ、という点では、メソッドと属性の区別が無い方が、便利だと思う。
   所詮、属性って (最下位レベルでは)getter と setter がないと、アクセスできないわけだし。

151 :129:01/12/17 14:00
129です。

「命題=型、証明=プログラム」な「構成的ブログラミング」
って、今どーなっているのか、誰か教えて!

(型推論と逆の話になると思う... )

152 :デフォルトの名無しさん:01/12/17 14:01
言語の話と分析・設計手法(とそのモデル)の話は分けませんか?

153 :デフォルトの名無しさん:01/12/17 14:02
>>151
型推論と逆っていうけど,どういう意味で逆なの?

みんな言葉をいいかげんに使いすぎ!

154 :151:01/12/17 14:04
>>153
うまい説明をするために、しばし考えさせて (泣)

155 :デフォルトの名無しさん:01/12/17 14:06
なるほど、
つまり、属性と方法の区別がないほうがOOPLとしては優れていると。
つまり、Class Diagramでの区別はシンタックスシュガーであると。
俺はそんなことは思ったことがなかったんだが、
そう言う考えのほうがむしろ完全であると言う視点は勉強になった。
その方は分かったんだが、
もう一つの俺の本体の論点たる、
高階関数が関数型の特徴であるかどうかについてはどうでしょうかね?

156 :デフォルトの名無しさん:01/12/17 14:14
>>155
(区別が無いほうが)優れているとは誰もいってないのでは?
関数型言語とオブジェクト指向型言語それぞれの本質的な特徴を
とらえるには,それぞれのモデルとして理論的にできるだけ単純
なものを考えたほうがいいわけで,そのためにメソッドと属性の
区別をわざわざつけないという主張があるわけだ.

個人的にはOOPLの最大の特徴は非同期メッセージパッシングであ
り(現時点でこれをきちんと実現している言語はほとんどないが),
クラスや継承はオマケという気もする.:-)

157 :デフォルトの名無しさん:01/12/17 14:20
>>156

>>124
>別に Eiffel じゃなくても属性と方法を区別しない OOPL はいろいろある。
>Delphi, C#, Ruby, Satherとか。

>属性と方法を区別すると再利用しにくいので
>OOPL として欠陥だと思う。

158 :デフォルトの名無しさん:01/12/17 14:21
ある種の高階関数はCでもかける。qsortとかね。
本質的なのは関数型変数に対して呼び出しと代入しかできないのが普通の言語で、
引数を1つ埋めたり合成したりして新しい関数を作ったり出来るようになっているのが
関数型だと思う。

でも突き詰めればそれはPerlなどのevalを持つ言語でも出来ることだから
「関数型は動的である」と言ってるに過ぎないような。

159 :デフォルトの名無しさん:01/12/17 14:25
>>156
アクターっすね。

SMTPとかの非同期通信経路を使った、分散オブジェクト とか SOAP で実現されつつあるような…

160 :デフォルトの名無しさん:01/12/17 14:26
>>158
高階関数は関数型の特徴ではないと言うことかな?

161 :デフォルトの名無しさん:01/12/17 14:29
OOPの特徴は何かの話は止めてくれ。
それをしだすと話が大幅にずれるし、スレタイトルとも異なってくる。
俺が属性と方法の区別を言い出したのは、
高階関数との絡みでだ。
話すなら関数型に関連付けて話してくれ。

162 :デフォルトの名無しさん:01/12/17 14:30
>>160
関数型「だけ」の特徴ではなくて動的な言語の特徴だと思う

163 :デフォルトの名無しさん:01/12/17 14:36
>>162
それは要するに特徴ではないと言うことを言いたいのか?
他にもあるから。

164 :デフォルトの名無しさん:01/12/17 14:40
>>163
うーん。
高階関数とは何かと考えると、
1・関数を変数として扱える。
2・新しい関数を定義できる。
になると思うのだが、1はCでさえ実現できてしまい、2を考えると「動的である」と
同値になってしまう。
「int型があるのはJavaの特徴か?」ときかれているような気がする。
特徴の一つではあるが、関数型を他から隔てているものではないと思う。

165 :デフォルトの名無しさん:01/12/17 14:41
>>158
eval等のメタ機能で動的に関数を作れることと,計算モデルに最初
からファーストクラスの関数が入ってることは区別してほしいな.

Perlのevalで「動的に」関数を作れるといってるのは,Cでsystem
を使ってコンパイラを呼び出し,コンパイル結果を動的リンクして
「ほら関数が動的に作れたよ」といっているのと一緒.

関数型言語の本質的な特徴は,(1)リダクションにもとづく意味論と
(2)高階関数になるのでは.(1)だけだと項書換え系一般になっちゃう
けど,(2)を入れることで関数型を特徴付けられる.

このスレで困るのは,「他のパラダイムにおいて高階関数を表現でき
るので,高階関数は関数型を特徴付けるものではない」という不思議
な議論をする人がいること.関数型と他のパラダイムは必ずしも対立
するものではない(特にオブジェクト指向とは直交しているといって
もよい)ことに注意してほしいな.

166 :デフォルトの名無しさん:01/12/17 14:43
>>164 付けたし
高階関数は関数型の必要条件だが十分条件ではない。
これが一番簡潔な言い方か。

167 :デフォルトの名無しさん:01/12/17 14:52
>>164
Cだとclosureというか、環境とか実現できんぞ。

168 :デフォルトの名無しさん:01/12/17 14:52
もう少し整理してみる.関数型言語(プログラミングパラダイム)
を特徴づけるのは
 (1)(高階)関数による情報の表現と,
 (2)リダクションによる計算の実行
を主な基盤としていること.これは理論的には(1)(2)だけで全て
(チューリング等価な世界を)表現できるというところから出発して
いるが,実際の処理系ではそれ以外に不純なものも混じっている.

他のパラダイムで(1)(2)に相当することを表現できるが,それは
そのパラダイムが関数パラダイムを内包していることをいっている.
それをイイ悪いの議論に持っていく人もいるのが2chの面白いところ.
でもそれは技術的な議論にはならない.

関数型の面白いところは,(1)(2)だけで世界が表現できることを
示して,現在の計算機アーキテクチャ上でそれなりに効率的な実行
ができることを体現しているところにある.

169 :165,168:01/12/17 15:01
>>162 >>163
他のパラダイムから隔てている特徴は,「基本的に上の(1)(2)だけで
世界を表現すること」では駄目か? 高階関数もリダクションも他の
パラダイムでなんとか表現できるが,それらだけを純粋に取り出した
のが関数型.(現実の処理系に副作用があるのは目をつぶる)

プログラミング言語研究の道具としてこれだけ関数型がメジャーなの
は,手続き型やそれをベースとしたOOなどのパラダイムが関数型を内
包しているから.つまり関数型が提供している計算モデルはそれだけ
普遍的だということができる.

170 :デフォルトの名無しさん:01/12/17 15:04
違う体系(公理系)を計算可能性が等価だからと言って
内包とはいわんだろ。

171 :デフォルトの名無しさん:01/12/17 15:07
>>165
>eval等のメタ機能で動的に関数を作れることと,計算モデルに最初
>からファーストクラスの関数が入ってることは区別してほしいな.
これを区別するのは賛成だが、どちらも高階関数であることには違わない。
もしCの言語仕様にevalがあるのなら「Cでは高階関数がかける」というだろう。
その機能が明白に意味付けできるかどうかは別の議論だ。
・数学的にきちんと意味を定義出来る高階関数が関数型の特徴だ
というのは納得するが。

172 :デフォルトの名無しさん:01/12/17 15:10
計算可能性の話でなく,関数型で書かれた記述を比較的自然に(イン
タプリタなどを書かなくても)他のパラダイムでコーディングできる
ということをいったつもり.きちんと定義するのはちょっと難しい.

173 :デフォルトの名無しさん:01/12/17 15:14
なんでsageで書くの? >170,171

174 :デフォルトの名無しさん:01/12/17 15:22
>>164
しかし、高階関数は関数型の中にあってこそ、
始めてその表現力の飛躍的増大を図ることができる。
つまり、imperativeとは異なり、
プログラムがコマンドの羅列ではなく関数の集合になっている
関数型であってこそ、
高階関数は表現力増大の為に生きてくると思うが。
従って、高階関数が関数型の特徴であると言う時、
それは「int型があるのはJavaの特徴か?」と言うのとは異質だろう。

175 :デフォルトの名無しさん:01/12/17 16:15
>>174
まあそうなんだけど、int型だって
「int型は細かく型チェックするタイプの言語にあってこそ有効だ。VBみたいなバリアント型
がある言語ではその力を十分に生かしきれない。」
とも言えると思うぞ。
俺も高階関数は関数型の中心的な要素だと思う。でももうちょっと考えてみるとそれ
は高階関数と言う概念よりも他の概念のほうがしっくり来るような気がしたのでつい
反論したくなっただけだ。

176 :デフォルトの名無しさん:01/12/17 17:06
関数型プログラミングって、代入がバグの温床だってところから
スタートしたもんだと思ってたんだけど、それは違うの?
高階関数が関数型プログラミングで重要な概念だってことは認め
るけど(高階関数なしに関数型プログラミングするのは効率悪い
からな)、

1)高階関数をサポートしないが、代入を排除しているプログラミング

2)高階関数をサポートしているが、代入を排除しないプログラミング

を比較すると、1の方が関数型プログラミングになっている気
がするんだけど。

177 :デフォルトの名無しさん:01/12/17 17:13
その比較に意味はあるの?>176

178 :176:01/12/17 17:19
>177

たとえばJavaあたりで代入を使わずにプログラミングしたら、
それは関数型プログラミングになってるって感触があるし、
Lisp系でグローバルオブジェクトをあちこちから操作しまく
ると高階関数を上手に使っていても関数型プログラミングに
なってない(バグがとりにくい)って思うから。

179 :デフォルトの名無しさん:01/12/17 17:25
>>130
>>純粋なオブジェクト指向言語で対称的(訂正)だから。
>これは理由にならない。
>何度も言うが、言語の完成度なり純粋性は俺の話の反論にはならない。

反論ではありません。OOの議論になぜ欠かせないか答えただけです。

>またプロパティはここでは関係がない。
>と言うより、どう関わってくるのかが
>俺には今一つ分からんので説明してください

属性のアクセスを抽象化できる。

関数型とOOがある意味逆というのは
関数型はデータ抽象化しないってこと?

180 :デフォルトの名無しさん:01/12/17 17:41
>>179
>関数型とOOがある意味逆というのは
>関数型はデータ抽象化しないってこと?


前スレコピペ

>OO言語では、その機能を十全たるものにするためには
>しっかりしたクラス設計が欠かせないとされている。
>そして、その際には、属性と方法を適切に弁別する作業が欠かせない。
>つまり、「良い」OOからしてみると、
>属性と方法が渾然一体となってしまうような状態は好ましいとはいえない。
>一方で、関数型は、OO的に言うところの方法が
>同時に属性でもあり得ることを奨励し、
>そのことによってより抽象的なアルゴリズムを構築でき、
>表現力が高まるとしている。
>その意味においては、
>両者は理想とする方向が逆なのではないかと思った。

181 :デフォルトの名無しさん:01/12/17 17:57
>そして、その際には、属性と方法を適切に弁別する作業が欠かせない。

本当に?
まあ、不必要に属性を公開すべきでないってことなら賛成だけど。
メッセージパッシングとネームスペースを同じドット記法で
書くから混乱しているだけってことかも知れないけれど。

でも、値を利用する立場からすれば、それが式であることには
代わりはないんで、別にどうでも良い気がするんだけどな。

182 :デフォルトの名無しさん:01/12/17 21:45
>>181

>>143
>属性と方法を区別するOOPLが不完全であるかどうかについて、
>貴方なりの考えを聞かせてください。

183 :デフォルトの名無しさん:01/12/17 22:55
関数型ってのはクラス化しないという意味?

私は割りと好きな手法だ
というのは私はアセンブリ思考の高級言語プログラマーなので
人間側はプログラミング言語よりも仕様書メインで
プログラムは最終的にCPUからみて考えるので
当然goto文相当のものも多く使う、がある程度分離させている。
クラス化(OOP)なものも使うができるだけポインタ渡しの関数を使うようにしている。
その最大の理由は改良や互換性において相互依存度が大きくならないことと
プログラム内に不必要なインスタンスが多数出現するのがいやなため。

これの例で具体的にはOpenGL V.S. DirectXがあると思う

OpenGLはWin95時からずっと同じOpenGL32.dllであり関数型
おんなじかんすうだが実はデバドラのほうへの橋渡しなので
デバドラが新しい関数を提供してくれたら
従来のルーチンに上乗せする形でそれが使える。

一方のDirectXはOOPである。
OOPだから基本クラスを改良すると一から全部やり直し
それでも一応下位互換ルーチンを残しているからいいけれど
新しいインターフェースで作ったプログラムは選択の余地なく
新しいDirectXを入れていないパソコンでは初期化すらできない。

資源の再利用とかはあまり興味ないけれど、環境の変化に対してOOPは弱いのでは?

184 :自明の理:01/12/18 00:35
>>183はアフォ

185 :デフォルトの名無しさん:01/12/18 00:38
>>183
全然違う
逝け

186 :デフォルトの名無しさん:01/12/18 00:42
>>183
関数型は名前の通り関数(写像)で記述(モデル化)するって事だな。

187 :デフォルトの名無しさん:01/12/18 02:28
副作用のない関数型の世界だと、属性ってただの定数では?

副作用のある不純関数型言語だと、高階関数(実装的にはclosure)
ってJavaのインスタンスとほとんど等価だよね(既出だが)。
で、属性の読み出しは引数のないメソッドとみなせるし、属性の
更新も1引数のメソッドと見なせる。

逆に、SmalltalkやJavaのインスタンスは高階関数のようにも使える。

高階関数とか属性はFPLとOOPLとを弁別するキーには全くならんと
思うが。

188 :デフォルトの名無しさん:01/12/18 02:41
>>187
そんなこと言ったらCで関数ポインタを含む構造体のインスタンスは
javaのクラスインスタンスと等価とか言えるんじゃないの?
キリないよ。
結局字面の問題でしょ。

189 :デフォルトの名無しさん:01/12/18 03:23
>>187
それを言いだすと、
ほとんどの言語は関数型言語をエミュレートすることで
高階関数を扱える、とか言っちゃったりするわけで...
字面の問題とまでは言わないけど、
言語自体が「高階関数」という概念を提供しているかどうかは
大きな違いがあると思う。

190 :デフォルトの名無しさん:01/12/18 09:08
VBって関数のポインタ取れなかったよね?VB5以降

191 :デフォルトの名無しさん:01/12/18 11:49
>>187
>副作用のある不純関数型言語だと、高階関数(実装的にはclosure)
>ってJavaのインスタンスとほとんど等価だよね(既出だが)。
>で、属性の読み出しは引数のないメソッドとみなせるし、属性の
>更新も1引数のメソッドと見なせる。

>逆に、SmalltalkやJavaのインスタンスは高階関数のようにも使える。

>高階関数とか属性はFPLとOOPLとを弁別するキーには全くならんと
>思うが。



>>174
>しかし、高階関数は関数型の中にあってこそ、
>始めてその表現力の飛躍的増大を図ることができる。
>つまり、imperativeとは異なり、
>プログラムがコマンドの羅列ではなく関数の集合になっている
>関数型であってこそ、
>高階関数は表現力増大の為に生きてくると思うが。

192 :デフォルトの名無しさん:01/12/18 13:01
187> 高階関数(実装的にはclosure) ってJavaのインスタンスとほとんど等価だよね(既出だが)。

何故、高階関数(実装的にはclosure)なのか、教えて下さい。

193 :デフォルトの名無しさん:01/12/18 14:33
またここでも用語の混乱が起きてる様だね

194 :実装から曲解:01/12/18 14:46
多分動的束縛のLispで、関数を返す関数を作ると、
closureが返るから、高階関数=closure と解釈した
のかな?

195 :デフォルトの名無しさん:01/12/18 15:28
Lisp系の言語でOOPするときは、
クロージャに関数スロットと属性スロットをカプセル化する。
それを見て、高階関数=クロージャと解釈したのかも知れないけど、
高階関数の典型的な使い方からは外れているよね。

196 :179:01/12/18 19:35
対照的であってたみたいね。

>クラス設計をする際には、
>インターフェースと(属性とメソッドの)実装に分ける。
は正確ではないので
 クラス設計をする際には、
 インターフェースと実装に分ける。
に訂正します。

>>126
「属性とメソッドを弁別して抽象化する」というのに反論したんです。
この表現はクラス設計のとき属性とメソッドを区別して設計するみたいです。
これはC言語はグローバル変数とグローバル関数を区別して
設計すると言ってるみたいなものです。
こんな表現は奇妙です。

言ってることは分かったので主張そのもに反論はありません。

197 :デフォルトの名無しさん:01/12/18 23:07
>>196
>「属性とメソッドを弁別して抽象化する」というのに反論したんです。

どこで言っていた?
ちゃんと摘示しろ。


それから、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.

198 :デフォルトの名無しさん:01/12/19 02:46
天才Steeleの"Lambda: the Ultimate Imperative"を読みなさい。
ついでに"Lambda: the Ultimate Declarative"モナー
Actors ≡ Closures (mod Syntax)
という章に、ObjectとClosureがなぜ等価であるのかちゃんと書いてある。

199 :デフォルトの名無しさん:01/12/19 10:08
ははん、なるほど。
OOPは「メッセージパッシング」のメタファで抽象データ型をサポートするけど、
FPはクロージャでそれを実現するし、本質的にそれらは等価だってことか。

[aReciver Message] = (aClosure Proc)

みたいな理解でいい?

200 :124 128 179 196:01/12/19 20:03
論点をまとめます。

関数型とOOが逆というのは高階関数とクラスは違うということらしい。

高階関数とクラスが違うというのは同意。

しっかりしたクラス設計とは
インターフェースと実装を適切に弁別することであって
属性とメソッドを弁別することではない。

>>197 >>180です。

201 :デフォルトの名無しさん:01/12/19 20:34
方向性が逆、という話はあまりしっくり来ないな。
OOPにおけるクラス設計も、より抽象的で本質的なクラスを、
より具象的なクラスから抽出してスーパークラスにまとめて
いく分析・設計プロセスがあるよね。デザインパターンにも
よく出てくる。具象的なクラスばかり作っていてもコードの
共有が進まないからだな。

関数型プログラミングも、共有コードを増やしたいと願って
いることには違いがないから、結局、より抽象的でより本質
的な関数を抽出しようとする。やっていることは同じじゃな
いかと思う。

# というより、デザインパターンの研究は、関数型プログラ
# ミングの研究成果からのフィードバックが大きいと思われ。

202 :デフォルトの名無しさん:01/12/19 22:57
>>198,199
真面目な質問なんだが、
(本質的に)等価であるとは一体全体どのような意味だ?
そして、それは、
そのビヘイビアにおいて同形であるということと
どのように関わって来るんだ?

203 :デフォルトの名無しさん:01/12/19 23:00
>>201
>デザインパターンの研究は、関数型プログラ
>ミングの研究成果からのフィードバックが大きいと思われ。

それはどうかな。
なんともいえないと思いますが。

204 :デフォルトの名無しさん:01/12/19 23:16
>>200
>しっかりしたクラス設計とは
>インターフェースと実装を適切に弁別することであって
>属性とメソッドを弁別することではない。

しっかりしたクラス設計 = インターフェースと実装を適切に弁別すること。
               ≠ 属性とメソッドを弁別すること。

>>180
>しっかりしたクラス設計が欠かせないとされている。
>そして、その際には、属性と方法を適切に弁別する作業が欠かせない。

この文は、
しっかりしたクラス設計 = 属性と方法を適切に弁別すること
なのか?

それよりもさ、君>>200の場合、
属性と方法を区別するOOPLが欠陥があるといえるならば、
Class diagramでの属性とオペレーションの区別が
どのような意味を持つかについて答えてよ。
やはりシンタックスシュガー或は便宜的区別なのか?

今更だがsageる。

205 :デフォルトの名無しさん:01/12/19 23:41
>>201
>OOPにおけるクラス設計も、より抽象的で本質的なクラスを、
>より具象的なクラスから抽出してスーパークラスにまとめて
>いく分析・設計プロセスがあるよね。デザインパターンにも
>よく出てくる。具象的なクラスばかり作っていてもコードの
>共有が進まないからだな。

>関数型プログラミングも、共有コードを増やしたいと願って
>いることには違いがないから、結局、より抽象的でより本質
>的な関数を抽出しようとする。やっていることは同じじゃな
>いかと思う。

質問です。
考えてみると、この発言の趣旨が分かりません。
結局何がいいたいんでしょう?
共有を進めるためのおよそ全てのより本質的な抽象化への努力は
皆お友達だと言いたいのでしょうか?

206 :201:01/12/20 10:03
Schemeのように、コンパイル時の型チェックがなく、
リストのような単純なデータ構造を基盤とする言語の場合はともかく。

強く型付けされた関数型言語の場合、
ある関数の適用範囲は厳密に、揺るぎなく、決定されている(シグニチャ
等を利用してポリモーフィズムを実現したとしても、適用範囲が静的に
決定できることには変わりがない)。
それは、OOPにおいて、クラスの中にメソッドがカプセル化されている
状態と本質的には同じことだと思う。

207 :145:01/12/20 12:56
>>204
145 です。このスレの行き先が心配になってきたもので...


1. 「属性とメソッドの区別はシンタックスシュガー」というのは、
 オブジェクト指向言語を「関数モデル」から見た場合の話です。(>>145,前レス109のFP)

2.オブジェクト指向言語を、DOA や OOA の観点から見る場合は、
   ・属性とメソッドの区別 (>>149)や、
   ・インターフェース(分析モデル) と 実装 を分ける事(>>128)は、
 重要だと思います。

上記二つの解釈の違いは、議論のベースとなる「計算モデル」の違いです。


オブジェクト指向と、ラムダ計算のクロージャ(?) との類似性は、
比較的古い ('80s) 議論だと思いますが、何か新しい要素はあるのでしょうか?

私としては、「オブジェクト指向言語意味論を、関数モデルでいかに解釈するか?」
といったあたり (>>148-149 のCardelli) に関心を持っているのですが。

208 :デフォルトの名無しさん:01/12/20 13:01
論点を決めないディスカッションは混乱をもたらすのみだな。

209 :145:01/12/20 13:23
このスレの主旨: 「関数型言語からRubyへステップアップ」 >>2 :-P

疑問点:オブジェクト指向言語意味論を、関数モデルで記述しようとする試みの
    メリット/デメリットは何か?

210 :デフォルトの名無しさん:01/12/20 14:09
>>209
ここでの論点は、俺的には、

高階関数は関数型の特徴と言えるか? これは概ね話がついた。

属性と方法の区別のあるOOPLは不完全或は欠陥があるのか? 未決

もし不完全でないとするならば、
高階関数を特徴とする関数型は属性と方法を区別するOOPとは
理想とする方向性がある意味逆と言えるか? 未決

ObjectとClosureが等価であるとは一体どのような意味か?
それは、そのビヘイビアにおいて同形であるということとは
どのような関係にあるのか? 不明

こんな感じだろ。

その209の論点は、とりあえずのところは今のトピックではない。
論点自体は至ってまともだが。

211 :デフォルトの名無しさん:01/12/21 00:12
まあ、Rubyなんて低レベルなアマチュア言語の話をする気はさらさら無いけどね。

212 :200:01/12/21 00:39
>>204
>しっかりしたクラス設計 = インターフェースと実装を適切に弁別すること。
>               ≠ 属性とメソッドを弁別すること。

わかりやすい!

>属性と方法を区別するOOPLが欠陥があるといえるならば、
>Class diagramでの属性とオペレーションの区別が
>どのような意味を持つかについて答えてよ。
>やはりシンタックスシュガー或は便宜的区別なのか?

>>149から
>オブジェクト指向分析(OOA)では、DOA由来のデータ抽出に加えて、
>メソッド抽出も重要なので、アドホックに operation が加わった、という気がする。

属性とメソッドを区別しない ≠ 属性とメソッドは同じ概念

属性とメソッドは異なる概念です。(念のため)
区別しないというのは同じように扱うという意味です。

>>210
>属性と方法の区別のあるOOPLは不完全或は欠陥があるのか?

この問題は 関数型オブジェクト指向言語 と 手続き型オブジェクト指向言語 を
比較する方がいいと思います。

関数型オブジェクト指向言語 は
メソッドを高階関数で定義できる点で、手続き型オブジェクト指向言語 と異なります。
また、メソッドを引数として渡すと高階関数が Closure になります。
その他の点はほぼ同じです。(CLOSの多重ディスパッチのような反論はやめてください)

議論の混乱は 関数型言語 と 手続き型オブジェクト指向言語 を
比較したことが原因です。

関数型とOOの比較は
関数型言語 と 関数型オブジェクト指向言語 を比較する方がいいと思います。

213 :デフォルトの名無しさん:01/12/21 05:57
>>212
クロージャと高階関数がまざってないかい?
「メソッドを引数として渡すと高階関数がClosureになります。」
がなんだか意味不明。

「Closureを引数または返値とするメソッドは
高階関数の実装として扱うこともできる」
とは言えると思うが、どうよ?

214 :デフォルトの名無しさん:01/12/21 06:08
>>209
オブジェクト指向言語の型システムを形式化することで
異なる静的型オブジェクト指向言語間でオブジェクトを共有する際の
型検査/型推論のための参照基準ができる。
例えば永続オブジェクトの動的型を表現する時などには
Cardelliの型システムが役立つと思われ。

215 :デフォルトの名無しさん:01/12/21 14:21
>>198,199
Actors ≡ Closures (mod syntax)
というのは、そのまま読むと、
ActorsとClosuresはSyntaxを法として合同であるということになる。
そして、そのような場合においては、知られているように、
ActorsとClosuresは「同値」関係にある。
つまり、Actors is equivalent to Closuresということになる。
これは残念だが、等価であるとはいわない。
等価であるというと意味が変わってしまう。

216 :215:01/12/21 15:56
Actors are 〜 だった。
間違えた。

217 :212:01/12/21 17:04
言語に特化すると議論しにくいので訂正します。

>>210
>属性と方法の区別のあるOOPLは不完全或は欠陥があるのか?
>もし不完全でないとするならば、
>高階関数を特徴とする関数型は属性と方法を区別するOOPとは
>理想とする方向性がある意味逆と言えるか?

この問題は 関数型オブジェクト指向 と 手続き型オブジェクト指向 を
比較する方がいいと思います。

関数型オブジェクト指向 は
メソッドを高階関数で定義できる点で、手続き型オブジェクト指向 と異なります。
また、高階関数の Closure を使える点でも異なります。
その他はほぼ同じです。

議論の混乱は 関数型 と 手続き型オブジェクト指向 を比較したことが原因です。

関数型とOOの比較は
関数型 と 関数型オブジェクト指向 を比較する方がいいと思います。

>>213
>「Closureを引数または返値とするメソッドは
>高階関数の実装として扱うこともできる」
>とは言えると思うが、どうよ?

いえない。

218 :デフォルトの名無しさん:01/12/21 21:04
オブジェクト
関数オブジェクト
クロージャ
高階関数
オブジェクト指向
関数型オブジェクト指向
関数型言語
オブジェクト指向言語

だれか説明して!

219 :デフォルトの名無しさん:01/12/21 21:06
ただのクロージャと、レキシカルクロージャって何が違うの?

220 :デフォルトの名無しさん:01/12/21 21:08
187辺りからわけわからん話題になってるyo!

221 :デフォルトの名無しさん:01/12/21 21:14
>>217
>メソッドを高階関数で定義
定義した時点でクロージャになると思うがどうよ?

222 :デフォルトの名無しさん:01/12/21 21:32
クロージャはオブジェクト指向で言うところのインスタンス。
関数に属性を持たせる概念がクロージャ。
関数(高階関数含む)自体も属性の1つ。

223 :デフォルトの名無しさん:01/12/21 21:36
振り出しに戻る

224 :デフォルトの名無しさん:01/12/21 22:04
クロージャは、関数と環境のセット。
環境っつーのは、ものすご乱暴に言うと、関数が呼び出されようとしている
瞬間の引数や関数から参照される関数の外にある変数の一覧。
スナップショットみたいなもん。
っていうふうに、俺は理解してるんだが。
どーでしょか?>議論中の方

だから、インスタンスのように振舞うこともあるって感じですかね。

225 :デフォルトの名無しさん:01/12/21 22:09
関数オブジェクトは、そのまんま、関数をオブジェクトとして、
あっちこっちもって歩けるようにしたもの。
高階関数は、関数オブジェクトを引数にとる関数。
あ、関数オブジェクトを返すのもそーですっけ?

226 :デフォルトの名無しさん:01/12/21 22:34
一部勘違いしてる人がいた様だけど、
関数型言語とevalはまったく関係ないよ。
(C言語でeval実装〜とか言っていた人がいるので念のため。)
'eval'つーのはLISPで動的にリスト(データ)を評価する手段ってだけ。
不要なevalはなるべく使わないで書くのが良いスタイル。
Schemeの規格でも最近までevalは含まれなかったし。

227 :デフォルトの名無しさん:01/12/21 23:01
evalは反則

228 :デフォルトの名無しさん:01/12/21 23:15
「無限と連続」遠山啓著 岩波新書アンコール復刊 1952年
を読んだが、関数言語と妙にシンクロする。

第3章「もの」と「働き」より
「…群論が現れるまで数学者の考える対象は数か図形に限ら
れていた。…
現代の数学でとくにいちじるしい対立をなしているのは
「もの」の概念と「働き」の概念である。もちろん、一つの
文章はすでに「何かのものが何かの働きをする」という形を
とっているのと同じく、数学のなかにもこの二つが対立して
いることは当然であろう。ガロアの輝かしい功績は、この
「働き」をきわめて明瞭な姿で数学のなかに持ちこみ…」

オブジェクトとか高階関数の話と似てるような気しない?

229 :デフォルトの名無しさん:01/12/21 23:32
つか、オブジェクト志向が目指す方向が、そっちにあるって感じ。

230 :デフォルトの名無しさん:01/12/21 23:56
数学っていってんだから関数型なんだろ?>229

231 :デフォルトの名無しさん:01/12/22 00:03
>>228
数学的記述を目指して開発されたのが
関数型であることを考えるならば、
それはごく当然だろう。
指摘するまでもないことのように思うが。

232 :デフォルトの名無しさん:01/12/22 00:53
>>225
カリー化された関数('a -> 'b -> 'c)なんかも高階関数と呼ばれるよね。

>>217
ハア?じゃあ、メソッドは関数の実装といえると思うが、どうよ?

233 :231:01/12/22 00:57
まあ、計算幾科学の世界では、
計算機科学は「いかにして」の概念を精密に扱う枠組を
提供しようとするものだとされており、
それに対して、数学は「なんである」の概念を
精密に扱う枠組を提供するものとされている。
というか、SICPにはそうある。

しかし、群論などでわかることは、
その「いかにして」を扱うことが
現代数学の主要な特徴になっているということだ。

その意味である種の重なりのようなものを見るのは
いたって自然なことなのかもしれない。

234 :デフォルトの名無しさん:01/12/22 03:01
>>215
Actors ≡ Closures (mod syntax)

Guy Steeleが著者の一人にもなっているHackers' Dictionaryの
moduloの項目を見ろ。(今ならJargon Fileとしてwebで読める。)

Lisp Hacker用語ではmoduloはexceptと読むのだ。

つまり、上は、
「Actorsは(見かけの違いを除けば)Closureとおんなじ」
という意味なのだよ。

235 :デフォルトの名無しさん:01/12/22 03:11
「メソッド」って、ポリモルフィズム無しにはありえないと思ってるんだけど。
おれの感覚おかしい?

236 :デフォルトの名無しさん:01/12/22 10:47
>>233
板違いだけど、群論入門の良書って何。教えて。
HaskellのMonadなんかも半群うんぬんの話がでてきた。
群論って少しは知ってた方がよさそう。

237 :仕様書無しさん:01/12/22 11:29
おれが持っている唯一の数学本。
『数学小事典』 ブルーバックス 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}が存在する。


誰か簡単な説明と表記の間違い指摘を頼む(w

238 :三歳児:01/12/22 12:11
(a*b)*c = a*(b*c)
1*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)

239 :デフォルトの名無しさん:01/12/22 12:25
>>234
そうなのか、なんか笑っちゃうね。
最初からそんな風に書かなければいいと思うが、
その定義はあとづけだな。要するに。
それを天才というべきなのかは議論の余地があるな。
個人的には、"isomorphic in their behavior"に
説得的なものを感じていただけに、少し残念だ。

240 :デフォルトの名無しさん:01/12/22 12:55
>>236
まあ、群論というか、代数学は基本的には、
計算機に大きく関係する方だと思うよ。
数を扱っているからね。

241 :無名λ式:01/12/22 13:30
>>239
つーか、言葉遊びでそ

>>236
数学処女は日本評論社の本辺りから始めるのが良いでしょう。

242 :デフォルトの名無しさん :01/12/22 14:25
数学板の集合論スレや基礎論スレを見てると、
なんか果てしない泥沼にはまりそうで怖くなるね。
短い人生をああいうものに賭けるのは漢だ!w

243 :デフォルトの名無しさん:01/12/22 22:42
>>241
俺にはActors≡Closures(mod Syntax)が
言葉遊びには見えないんだがな。
ActorsとClosuresは、Syntax、
つまり、言葉なり記号なりの配置の仕方
と言う観点からみると、同様の役割・機能・振る舞いのようなものを
持っていると、そういうことを言いたいのではないかと思った。
それを別の言い方で言うと、振る舞いにおいて同形であると、
そういうことなのではないだろうか。
そう考えた方が整合的だと思うが。
それをJargon等を読むような連中には同形の意味がわからんので、
modはexceptなんだといっているのではないだろうか。
言葉遊びと言うにはいささかお粗末だしな。
まあ、俺がいったようなこともある意味言葉遊びだが、
それでもそちらの方が整合的だ。

244 :デフォルトの名無しさん:01/12/22 22:42
>>242
どう公理系を構築すれば大体の場合において支障をきたさずに済むか、だからね。
どんな論もある前提において成り立つにすぎない。
ユークリッド幾何学しか知らない中学生がヒルベルト空間をどう思うか。

245 :デフォルトの名無しさん:01/12/23 17:31
age

246 :217:01/12/23 18:22
>>213 >>221
手続き型OOのClosureを引数または返値とするメソッドは
高階関数とは少し違うような気がします。

正確に知ってる人がいたら教えてください。

>>232
>ハア?じゃあ、メソッドは関数の実装といえると思うが、どうよ?

メソッドの定義は関数の実装といえるという意味なら同意。

247 :デフォルトの名無しさん:01/12/23 19:08
>>246
>高階関数とは少し違うような気がします。
そうだね。
戻値として返される関数は、そのメソッドが所持してる変数などを
「知っている」場合があるし。
関数の振る舞いはメソッドの中身と密接に関わっている。

248 :デフォルトの名無しさん:01/12/23 23:47
>>237
とりあえず、「群(グループ)」についてそれでは意味がわからんので、
計算機科学的に引き直して言っておくと、
なんかしらのassociation(メソッド、関数、演算等)が定義されている
メンバ(属性、変数、数値、文字等々)の集まりだ。
それで、そのassociationがその規則を満たすというものだ。
あくまでも計算機科学的引きなおしだから、
参考程度にとどめて置くように。

249 :248:01/12/24 00:05
誤解のないように言っておくが、
その結合は、勿論メンバの中に含まれている。
つまり、結合もメンバだ。

250 :デフォルトの名無しさん:01/12/24 14:49
>>249
428には「結合」という単語は使われていないようだけど、
「その結合」って何のこと?

251 :デフォルトの名無しさん:01/12/24 17:27
>>250
ん?
associationだけど、なんか変か?
まあ、というか、ある種の働きと言うか
関係と言うかそういうもんなんだが。

>誤解のないように言っておくが、
>その結合は、勿論メンバの中に含まれている。
>つまり、結合もメンバだ。

なんか意味不明な表現になってしまっていて
申し訳ないが、
結合(働き、関係)もメンバ(要素、元)になり得ると言うことだ。

どうでもいいかもしれんが、
一応これから出かけるんで、
質問などにはしばらくは答えられない。

252 :デフォルトの名無しさん:01/12/25 17:49
>>251
もう結合は終わりましたか?

253 :デフォルトの名無しさん:01/12/25 19:25
>>243
Jargon Fileを読んで面白く感じないなら
LispもSchemeも面白いと思わないだろうな...

それはどうでも良いが、Steeleの文章はこの手の言葉遊びばっかりだよ。
RMSらとともにLisp hackerdomの中心にいた人だしね。

moduloをexecpt (for)と読むのが後付けなわけがない。
Imperative論文はjargon-1より後だもの。

自分の勝手な解釈を後付けで補強しようとしてないか?

254 :デフォルトの名無しさん:01/12/25 19:28
>自分の勝手な解釈を後付けで補強しようとしてないか?
オマエモナー

255 :GLS:01/12/25 20:18
スチールです。
moduloは「except for」と読みますが何か?

256 :デフォルトの名無しさん:01/12/25 22:27
>>253
ちょっと聞きたいんだが、
もしexceptならば、
その除外されるSyntaxとは何だ?
また、≡とはJargon的にはどのような意味だ?

257 :デフォルトの名無しさん:01/12/25 23:06
>>253
というか、moduloがexcept forだなんて、
言葉遊びでもなんでもないぞ。
どうしてこれが言葉遊びになるのか…
ただの間違いだ。それも初歩的な。
それを「言葉遊びだ」なんて言われて、
「はいそうですか」とか真に受けるなんて、
お前は「馬鹿」ではないのか?

しっかし、どうしてもそんな数学的に
粗雑な話をするとは思えないな。
お前はそれで幸せなのかもしれんが。
それは具体的にJargon Fileのどこに書いてあるんだ?
本当に「その部分」の作成に関わったのか?

258 :デフォルトの名無しさん:01/12/25 23:40
>>257
俺は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版は読んだ。
その項目を最初に書いたかどうかはしらんが関わったのは確かだろう。

259 :デフォルトの名無しさん:01/12/26 00:00
>>258

>(4 = 22 mod 9).

なんだこれは
なんで、≡ではなく=なんだ?

>別に粗雑とは思えん。

では、説明して欲しい。
その除外されるSyntaxとは何なのか?
そして、そうすると、≡とは一体いかなる意味になるのか?


確かに意地にはなっているが、
それはActors≡Closures(except for Syntax)
と、文中にあったisomorphismが繋がらないからだ。
それともこのSyntaxにもなんか特別な意味があるのか?

260 :デフォルトの名無しさん:01/12/26 00:22
>なんで、≡ではなく=なんだ?
そりゃPDP-10の文字コードに≡が無かったからに決まってるじゃん。

>では、説明して欲しい。
>その除外されるSyntaxとは何なのか?

Actors ≡ Closures (mod Syntax)とかisomorphismとか、
シャレで疑似数学風に書いてはあるけど、言いたいことは要するに、
"Actors are just closures (except for slight syntax difference)."
ってことでしょ。

「Actors ≡ Closures (mod Syntax difference)」
じゃ数式風の形じゃないから面白くないじゃない。

(ここまでシャレを説明しなきゃなんないってのも
興ざめっつーか萎えるっつーか)

261 :無名 (modulo 地元):01/12/26 00:44
>>259
> なんで、≡ではなく=なんだ?

ワラタ
'='じゃなくて'='な。

262 :無名 (modulo 地元):01/12/26 00:48
>>260
> "Actors are just closures (except for slight syntax difference)."

closure "with proper tail recursion"と書いておかないと絡まれるかも〜。

263 :デフォルトの名無しさん:01/12/26 00:51
>>260
>>なんで、≡ではなく=なんだ?
>そりゃ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
一応≡と統一しようと思っただけで他意はない。

264 :デフォルトの名無しさん:01/12/26 01:17
>>>なんで、≡ではなく=なんだ?
>>そりゃPDP-10の文字コードに≡が無かったからに決まってるじゃん。

>ほう、それでこの時代になっても全く変えていないのか。

なんというか、集合論を知らないとそういう固定観念が
生まれるのか

265 :デフォルトの名無しさん:01/12/26 01:45
あのなー、congruenceとisomorphismとequivalenceの
違いぐらい知ってるっつーの。

で、あの論文の中に出てきたisomorphism(って書いてあっただろヴォケ)が、
本当に数学的に厳密な意味での同型性だと思ってるのか?
ただ「それっぽく」シャレで書いてあるだけだろが。

だいたい、ASCII(でもLatin-1でも良いが、DOSでもUnixでもTTYでも
使えるくらいメジャーなcharacter set)で≡をどう書けっつうんだよアフォが。

ほんまにシャレのわからんヤツやのー。Phil Wadlerの爪の垢でも飲め。

266 :デフォルトの名無しさん:01/12/26 02:05
つーか、題名だけじゃなくて中身を読んでみれば良いんでは?
ftp://publications.ai.mit.edu/ai-publications/pdf/AIM-379.pdf

件の章を読むと、ちゃんとした数学の話でないことは一目瞭然だね。

まあ、「Actorなんてただのlambdaじゃん」と言ったら角が立つだろう
からねえ。HewittってSussmanの同僚でしょ? だからisomorphism
などとオブラートにくるんで言ったのでは。

267 :デフォルトの名無しさん:01/12/26 02:49
>>265
>で、あの論文の中に出てきたisomorphism(って書いてあっただろヴォケ)が、
>本当に数学的に厳密な意味での同型性だと思ってるのか?

そんなことは言っていない。
っていうか、お前は真の馬鹿者だな。
そして、どう考えてみても、ボケはお前の方だ。
「同じ」ではない、といっているんだ。
どうしたら厳密に数学的なisomorphicだと俺が言っているんだ?

>ほんまにシャレのわからんヤツやのー。

だ・か・ら、「一般的な意味では」、modはexcept forではない。
modがexcept forであるかどうかの区別も分からん奴には、
洒落になるといっているんだ。
本当に学のない奴だ。

268 :デフォルトの名無しさん:01/12/26 03:09
>>264
>>>>なんで、≡ではなく=なんだ?
>>>そりゃPDP-10の文字コードに≡が無かったからに決まってるじゃん。
>>
>>ほう、それでこの時代になっても全く変えていないのか。

>なんというか、集合論を知らないとそういう固定観念が
>生まれるのか

少し意味がわかりませんが、もう少し詳細に説明してください。
そしてあなたのご高説を聞かせてください。

言葉は悪いですが、少なくとも私には265の
>だいたい、ASCII(でもLatin-1でも良いが、DOSでもUnixでもTTYでも
>使えるくらいメジャーなcharacter set)で≡をどう書けっつうんだよアフォが。
の方が意味がわかるんですが。

269 :デフォルトの名無しさん:01/12/26 03:35
同値関係を示す記号が何であってもその定義が
明示されていれば問題になることはない。
ということだろう。
よく使う記号は=≡〜⇔とかだね。

270 :無名の体系 (modulo 差異):01/12/26 09:36
>>267
> だ・か・ら、「一般的な意味では」、modはexcept forではない。
> modがexcept forであるかどうかの区別も分からん奴には、
> 洒落になるといっているんだ。

仲間内での言葉遊びはどんどん逸脱していくものだということを理解して欲しい。
駄洒落等が差異を楽しむ遊びであることを理解すれば納得できると思う。
moduloとexcept forに何の関連も見出せない人がいる、
そのくらい逸脱して初めて大いに盛り上がることが出来るのだ。
仲間内では基本パターンはやり尽くしているからね。

君はこの他愛もない言葉遊びからは仲間外れだが、
君の無理解、不寛容自体も仲間の笑いの対象だ。違うことは面白いのだ。

271 :みるなー:01/12/26 10:00
んで、>>254-270 は、関数型言語と関係あるの?

272 :デフォルトの名無しさん:01/12/26 14:14
>>267 はほんとに文脈を理解しない愚か者だな。
「Steeleの論文では」moduloはexcept forだ、
というのは、はっきりしてるだろうに。

だれも「一般の」moduloの話なんかしてないってのに。
よい恥さらしだな。

273 :test&age:01/12/26 14:34
   hoge
hoge

274 :デフォルトの名無しさん:01/12/26 14:44
>>269
=というのは、恒等関係を表すものだ。
同値関係には使用しない。
もちろん恒等関係は同値関係の中に含まれるが、
だからといって、単に同値なものを恒等と言ったりはしない。
それでは記法としては話にならない。
というか、264は、「集合論を知らないと・・・」といっている。
集合論を知らないと生まれる固定観念とは
ここでは何をさしているんだ?
そして、集合論を知っていると生まれる正確な観念とは
それから比較するとどのようなものだ?
俺はそれを聞きたいんだよ。

>>270
おまえさ、俺がsteeleの話が数学的に厳密な同型性だと
どこでいっていたのかを指摘しろ。

実際には、お前の方が遙かに無理解だ。

>君はこの他愛もない言葉遊びからは仲間外れだが、
>君の無理解、不寛容自体も仲間の笑いの対象だ。

他愛がないというより有害だ。
世界はおそらくお前が思っているより広い。
その中で一意に伝達するためには、
しっかりした定義付けや記法が必要だ。
形式化の努力にはそういった意義もあるはずだ。
確かに無理解だが、それは「有害な」言葉遊びのためだ。

275 :デフォルトの名無しさん:01/12/26 14:52
>>274
>その中で一意に伝達するためには、
>しっかりした定義付けや記法が必要だ。

同意。
が、ワインバーグの「ライトついてますか?」に登場する警句をひとつ。

「ユーモアを解さない人のために問題を解いてはならない」

276 :デフォルトの名無しさん:01/12/26 14:52
>>272
貴方に聞きたいんだが、
この論文は、LISPコミュニティのようなものに
向けて書かれたものなのか、
それとも広く計算機科学に関わる人々に
向けて書かれたものなのか?

277 :デフォルトの名無しさん:01/12/26 15:01
>>275
>「ユーモアを解さない人のために問題を解いてはならない」

ここではこういうべきだろう。
「間違いをユーモアと言う人のために問題を解いてはならない。」

278 :デフォルトの名無しさん:01/12/26 15:06
>>276
272じゃないけど、件のpaperは
MIT AI Memo 379
となっているから、AIラボのメンバーが想定読者と思われ。

279 :デフォルトの名無しさん:01/12/26 15:07
>>277
読んでから反論しようね。

280 :デフォルトの名無しさん:01/12/26 15:11
>>278
ああ、なるほど。

>>279
は?

281 :デフォルトの名無しさん:01/12/26 16:31
粘着ウザイ
おまえが冗談を解しないのはわかったから
いつまでも必死に力説してないで話戻せよ

282 :君って誰よとか言うな。察して。:01/12/26 16:57
えー、君は>>215かな?
別に君が間違ってるわけでなく、
steele が内輪しか通じない用語を使い
外部の人間を勘違いさせるようなことしたのがいけない
ってことにしといて、そろそろやめようよ。

283 :デフォルトの名無しさん:01/12/26 17:33
最後に一つ

>>281
粘着ウザイ
おまえが数学を解しないのはわかったから
いつまでも必死に力説してないで話戻せよ

284 :オワッチャイヤ:01/12/26 20:23
          / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
   ∧,,∧  < 来週のこの時間は、
  ミ*^ー゚彡日\_「Curry-Howard対応」デスマッチをお送りする予定です.___________
  ミつ  つ======
 ξ ミ  ミ ミ
 ξ,,U,,U,,ミ

285 :デフォルトの名無しさん:01/12/26 20:26
「Curry-Howard対応」デスマッチのリファレンス:

ttp://research.microsoft.com/Users/luca/Drawings/CurryHoward/CurryHoward.pdf

286 :デフォルトの名無しさん:01/12/26 20:42
みんな元気だねー
こんなこと書いてるひまがあったらPPL2002にでも投稿しておくれよ
温泉行こうぜ!

287 :デフォルトの名無しさん:01/12/26 22:36
>>274
おいおい同値関係以上の何かを
含む「恒等関係」などという関係は無いぞ。
もし代数的な同値関係をそう呼んでいるとして
"="をそれ専用の記号と考えているとしたらそれは誤りだ。

288 :そぼくな疑問:01/12/27 02:49
計算機科学では"="は問題空間内の定義に依存するんではないのか?

289 :デフォルトの名無しさん:01/12/27 02:54
ま、「学の無いやつ」なんて、学のあるやつ(本当の意味で学のあるやつなんて、どのくらいいるんだ?)の言う事じゃないと思うな。

290 :デフォルトの名無しさん:01/12/27 03:30
つか、勝手に勘違いして勝手に「間違ってる」と決めつけて
勝手にスティールのせいにした「外部の人間」がひとりいるだけだろ?

バカは無視してさっさと次の話題に行こうよ。

291 :デフォルトの名無しさん:01/12/27 03:40
次の話題つか、なんの話をしてたんだっけ??

292 :デフォルトの名無しさん:01/12/27 03:42
そうだ、話題についていけなくて、クロージャって何?って質問してたんだった。
あと、「メソッド」についても、厳密な定義が欲しかったんだ。
どーなの?

293 :デフォルトの名無しさん:01/12/27 09:49
>>287
は?
ウルトラ馬鹿だなおまえは。
おまえ本当にそんなこと思っているのか?

>>290
>つか、勝手に勘違いして勝手に「間違ってる」と決めつけて
>勝手にスティールのせいにした「外部の人間」がひとりいるだけだろ?
>バカは無視してさっさと次の話題に行こうよ。

スティールのせいにしているとどうして読めるんですか?

294 :デフォルトの名無しさん:01/12/27 09:52
>>290
>勝手にスティールのせいにした「外部の人間」がひとりいるだけだろ

それはすこし世界が狭すぎるとおもう。

295 :デフォルトの名無しさん:01/12/27 10:40
>>288

>>263
>俺としては、Schemeとかは他の言語に比べて
>数学の諸成果を積極的に取りこんでいる言語だと思っていたので、
>数学の記法というかそう言うものに関しては
>ちゃんとしていると言うか、一目置いているというかそう思っていたんだ。

>>289
>本当の意味で

どんな意味ですか?

296 :デフォルトの名無しさん:01/12/27 11:19
単に「そういう言葉遊びだったのか。誤解してたよ。」と言えば
すむことなのに、言葉遊びの方を「有害」な言葉遊びだとか、
学のない奴にしか分からない言葉遊びだとか、
いちゃもんをつけるのは醜いよ。自称「外部」の人よ。

297 :デフォルトの名無しさん:01/12/27 11:45
>>296
おまえこそ話をそらすな。
馬鹿が。

>自称「外部」の人よ。

は?

298 :297:01/12/27 11:48
「おまえこそ」というか、
「おまえは」だな。

299 :デフォルトの名無しさん:01/12/27 12:05
>>296
>単に「そういう言葉遊びだったのか。誤解してたよ。」と言えば

>>263
>俺としては、Schemeとかは他の言語に比べて
>数学の諸成果を積極的に取りこんでいる言語だと思っていたので、
>数学の記法というかそう言うものに関しては
>ちゃんとしていると言うか、一目置いているというかそう思っていたんだ。
>まあ別にそういうことならそうでもいい。

300 :デフォルトの名無しさん:01/12/27 13:53
というかな、
Actors≡Closures(mod Syntax)
は言葉遊びとして理解できるが、
modがexcept forだというのは言葉遊びではない。

301 :デフォルトの名無しさん:01/12/27 15:34
どうでもいいよ。
互いにアホは放置ってことにしとけ。
もうこだわるな。

302 :デフォルトの名無しさん:01/12/27 16:33
>>293
なるほど数学を知らん奴はそういう反応をしめすのか。

303 :デフォルトの名無しさん:01/12/27 16:58
>>302
いや数学を知っていてもそうだと思うよ。

304 :デフォルトの名無しさん:01/12/27 17:09
恒等関係ってなに?
恒等式の間違いじゃないのか?

305 :デフォルトの名無しさん:01/12/27 17:27
>>274
3≡5(mod 2)が恒等ではないとでも言うのかねぇ
それとも3=5(mod 2)と書くべきだと言ってるのかな
あほか

306 :デフォルトの名無しさん:01/12/27 20:00
昔、数学を知ってるけど、計算機のこと全然知らないやつがいて、数学から一歩も外に出られないでかわいそうだったなぁage

307 :デフォルトの名無しさん:01/12/27 21:49
でもまあ数学と計算機科学のどちらが難しいか聞かれたら数学って答えるな。
比較するようなもんでもないけど

308 :高校生:01/12/27 22:50
多分こいつら同値類別しても同じクラスに属するな。。。

309 :デフォルトの名無しさん:01/12/27 23:00
>>308
3個セットギコ付きで4000円(わんふぇす価格)

310 :デフォルトの名無しさん:01/12/27 23:31
同じと同型については、なんともいえないけど、
恒等と同型(同値かどうかは知らない)ということなら、たぶん違うと思うよ。
SCIPの1.3.1をみてみると、

aからbまでの整数の和を計算する手続、
与えられた範囲の整数の三乗の和を計算する手続、
級数の項の並びを計算する手続

の3つを比較して、そこに共通する関数sumを作ってる。

(define (sum term a next b)
 (if (> a b)
   0
   (+ (term a)
     (sum term (next a) next b))))

これが同型写像とか言われるものじゃないかと思う。たぶん。
そんで、恒等写像として、identityを定義している。

(define (identity x) x)

この2つが同じもの、というか、おんなじ役割を持つものかといわれると
やはり違うんじゃないだろうか。
ここから考えると、
同型というものと恒等というものは違うんじゃないだろうかとも思う。

311 :デフォルトの名無しさん:01/12/27 23:33
>SCIPの1.3.1をみてみると

SICPだった。間違えた。

312 :310:01/12/27 23:37
別にsageるつもりはなかった。

313 :デフォルトの名無しさん:01/12/27 23:47
もちろん恒等写像と同型写像は違う概念だが
何の話をしているんだ?>>310

314 :310:01/12/27 23:52
いや、なんか、
Actors≡Closure(mod Syntax)
に関して、それは同じだといっている人と
同型だといっている人がいたんで、
そんで、isomorphismとかいう概念があって、
それをスティールという人が言っていたとあるので、
まあ、同型なんじゃないかなと。
同じという意味ではないのではないかと。

315 :デフォルトの名無しさん:01/12/28 00:00
なんの話をしているのか、判りやすく解説きぼーん

316 :デフォルトの名無しさん:01/12/28 00:02
「関係(aRb)」と「写像(f:a->b)」が混乱してるんじゃない?

317 :デフォルトの名無しさん:01/12/28 00:07
>>305
x^p-1≡1(mod p)
(ただし、pは素数で、xはpで割り切れない任意の整数)

は恒等ではないがな。

318 :デフォルトの名無しさん:01/12/28 00:10
>>317
なんのこっちゃい?
恒等式と方程式(不能も含む)は違うぞ?

319 :デフォルトの名無しさん:01/12/28 00:15
>>318
すまん、何がいいたいのかわからん。
分かりやすく説明してくれ。

320 :デフォルトの名無しさん:01/12/28 00:18
なんでこんなに判りにくいのか謎。
>Actors≡Closure(mod Syntax)
これが出てきてからついて行けなくなりました。>このスレ
なんの話をしてるんだよ。

321 :デフォルトの名無しさん:01/12/28 00:23
>>319
分からんのはこちらだが?
方程式は当然(ほとんどの場合)恒等式ではないが
それがどうした?

322 :310:01/12/28 00:40
>>315
んー、クロージャとオブジェクトの関係について、
スティールっていう人が、Actors≡Closures(mod Syntax)
って言ってるらしいんだよ。これが。
その解釈について、一方の人は、等価であるとか、
"Actors are just closures (except for slight syntax difference)."
であるとか、言っているんだよ。
それに対して、別の人は、それはisomorphicの別の言い方であって、
同型だとか、同値だとか、合同だとか言っているんだな。
それで、そのスティールと言う人はまた別のところで、
isomorphismとか言っているらしい。
だから、前者の人は、isomorphismは
"要するに同じ"って意味だと言っているんだと思う。
ただ、SICPを見ると、同型と恒等は
ちゃんと区別されているような感じだったし、
そこから考えると、等価(たぶん同じってことだと思う)と言うよりも
同型って言った方が正解なんじゃないかなって思った。

323 :デフォルトの名無しさん:01/12/28 00:44
結局、
ActorsとClosureとをちゃんとお勉強して、どういうふうに「同じ」なのか、各自判断せよ。
で、ええのんか?

324 :デフォルトの名無しさん:01/12/28 00:58
>>321

>>274
>3≡5(mod 2)が恒等ではないとでも言うのかねぇ

こう言っていたもんで、
まあそういう式が恒等でない場合を示してみたんだが。
従って、=と≡は違うと。
3≡5(mod 2)はやはり「記法として」、
3=5(mod 2)と書くべきではないと。

というか、274が恒等であるならばこの場合でも=とすべきだと言っていると
305がなぜ思っているのかがよく分からんのだが。今更だが。

325 :324:01/12/28 01:08
>>>274
>>3≡5(mod 2)が恒等ではないとでも言うのかねぇ

>>305
>3≡5(mod 2)が恒等ではないとでも言うのかねぇ

すまん、こうだった。

326 :高校生:01/12/28 01:19
オレは数学の授業をサボっていたので良くわからんが。

同型というならせめてActors→Closureとなる写像
(トランスレータプログラム?)を示してもらいたい。。。

3≡5(mod 2)?同値類?普通はGの正規部分群Hが見つかって
G/Hが再び群になるような構造が存在するから価値がある
のであってこの議論自体は糞ですね。。。

327 :デフォルトの名無しさん:01/12/28 02:05
>>326
>同型というならせめてActors→Closureとなる写像
>(トランスレータプログラム?)を示してもらいたい。。。

それはMr.Steeleにやってもらうしかないですね。

というか、元々そんな厳密な話ではないでしょう。
この同型性も一種のアナロジーだと思いますよ。
ただだからといって、同じってことでいいじゃないかと言うと、
やはり意味のずれが生じると思います。
日常生活の中であっても、同じと同型は普通は意味が違うでしょう。
たぶんですが。
それにやはり技術的な話は
より正確に意味を伝えられる表現を採用すべきだと思います。
下らないかもしれませんが、そのようなより正確な表現の積み重ねなくして
正確な意味の伝達もあり得ないわけですから、
技術者としてやっていく以上
そういうことはとりあえずちゃんとしておいたほうがいいと思いますが。

328 :デフォルトの名無しさん:01/12/28 02:24
「あなたとわたしのにほんご、ちょとちがいます、おー、ずいぶんちがうです。」
って言ってるわけか?こいつら。

つか、どっかほかでやってくれよ、いいかげんよ。

329 :高校生:01/12/28 02:35
327>>
抽象と矮小の違いには気をつけるべきってことだね?
#まぁその場の雰囲気っちゅうのもあるでしょうが。。。

330 :デフォルトの名無しさん:01/12/28 07:35
>>324
すると
x^2-2x+1=0などの方程式は
x^2-2x+1≡0と記述するべきだと?
どこからそんなわけの分からん事を思いついたんだ?

331 :デフォルトの名無しさん:01/12/28 09:45
同型というのは写像に関して言う言葉では?
ある元とある元が同型などという表現は聞いた事がありません。

332 :そぼくな疑問:01/12/28 11:49
変数が入った恒等式は、やっぱり変数がすべての値の
時に成り立たなくちゃだめだんですよね?

333 :デフォルトの名無しさん:01/12/28 12:17
なんかごちゃごちゃくだらねーなー.

Hewittのアクターモデルに対してSteeleがλクロージャを持ち出したんだけど,
これはアクター本来の非同期性については何も言えてなかったんだよ.結局アク
ターモデルの形式化は米澤やAghaの仕事までできなかった.Steeleの仕事自体
はアクターの形式化を離れてそれ自身非常にいいものになったんだけどね.

334 :は?:01/12/28 13:37
>>330
なんでそうなるんですか?
なるわけないだろう。

335 :デフォルトの名無しさん:01/12/28 13:44
>>333
私はそのあたりの歴史を知らないんですが、
そのあなたの言っている話からすると、
ultimate declarativeの
アクターとクロージャの関係についての話は、
結局現代においても妥当性を持つ話なの?
アクターの形式化を離れない場合。

336 :デフォルトの名無しさん:01/12/28 13:52
>>334
そりゃわざわざ記号を区別する必要は全然ない
でも>>324はそう書くと思い込んでいる

337 :デフォルトの名無しさん:01/12/28 13:56
>>331
それについては、Steeleさんに聞いてみてください。
私からはなんとも・・・

338 :デフォルトの名無しさん:01/12/28 14:12
>>336
a ≡ b (mod c)
の場合は、≡を使うべきだといっているだけでは?
というか、ここで=を使うと、
つまり、a=b(mod c)とすると、
話が合わなくなる場合があるっていってるんじゃないの?
x^2-2x+1=0は関係ない話のような気がするけど。
というかこれって、x=1ってことじゃないの?

339 :デフォルトの名無しさん:01/12/28 14:20
>>324は恒等式でないならば=を使うべきではない。と
解釈できてイミフメイ

>x^2-2x+1=0
は当然恒等式ではなく(全てのxで成立することはない)
方程式だから>>324に従えば≡を使うことになる

>3≡5(mod 2)
これは当然恒等式。>>324に従えば
3=5(mod 2)と書くほうが妥当かな

>x≡5(mod 2)
これなら方程式だね

とりあえず>>324は何か重大な勘違いをしているようだ

340 :デフォルトの名無しさん:01/12/28 14:29
>>339

>>324
>というか、274が恒等であるならばこの場合でも=とすべきだと言っていると
>305がなぜ思っているのかがよく分からんのだが。今更だが。

これとの関係は?

341 :デフォルトの名無しさん:01/12/28 17:36
Actors って何ですか?

342 :デフォルトの名無しさん:01/12/28 17:55
俳優です。

343 :デフォルトの名無しさん:01/12/28 18:55
>>340
これじゃん?
はっきり言って何が書いてあるのか分からんが
恒等関係ってなに?

>>274
>=というのは、恒等関係を表すものだ。
>同値関係には使用しない。
>もちろん恒等関係は同値関係の中に含まれるが、
>だからといって、単に同値なものを恒等と言ったりはしない。
>それでは記法としては話にならない。

344 :デフォルトの名無しさん:01/12/28 19:21
≡は合同っていうよね普通。

345 :デフォルトの名無しさん:01/12/28 20:14
はなしずれまくり。しょうじき、よそでやってほしい。

346 :デフォルトの名無しさん:01/12/28 23:45
>>343
うーん、つーか、よく分からんけど、
俺としても、恒等ならば=にしろとは書いてないような気もするけど。
単に同値なだけの時には=にするなといってるだけのような。

恒等関係がなにかは説明できないけど、
等しいということじゃないの?
俺は確かそういう言葉を数学関係の本で見たことあるけど。
何の本でかは忘れたけど。

347 : :01/12/29 00:03
いいかげん、関数型言語の話しろや(゚Д゚)y─┛~~

348 :テfテtテHテヒテgツ?ヨ?ヨ?ツ?ツ?ツ?:01/12/29 00:05
sodesune

349 :デフォルトの名無しさん:01/12/29 01:14
>>346
googleで恒等関係を調べるとどうも
経済学で平衡になる二量の関係のことを
まれにそう言うだけのようだ。
いわゆる同値関係や順序関係の類の数学用語にはなさそうだ。
上にもあるように恒等式のことだろう。

私としてはむしろ除余による同値関係は
a^{p-1}=_{p}1などと単に下付きで書くと美しいと思う
\equivでもいいけどごたごたしていて好きじゃない

>>347
ねたふりなよ

350 :デフォルトの名無しさん:01/12/29 02:39
じゃあネタを振ろう。
関数型言語があるとどうしてそれをOOにしようとする奴が現れるのか?
CommonLisp(関数型??) -> CLOS
ML -> Ocaml
Haskell -> OHaskell
「状態」を捨てるために関数型にしたのに「状態」の塊なオブジェクト指向を
しようって言うのは本末転倒というか、関数型に喧嘩売ってるような・・・・
理由説明を求む。

351 :デフォルトの名無しさん:01/12/29 02:56
関数型でOOというのがよくわからん。
簡単な概要を教えて。

352 :デフォルトの名無しさん:01/12/29 03:02
・OOに対する羨望/あこがれ/幻想を持つ人間が多過ぎるから
・OOを冠する製品を作ると商売になると誤解している人が多過ぎるから
・OOをやっていると自己満足できる人が多過ぎるから
・OOが何であるか本当のところは分かっていない人が多過ぎるから
つまりOOとはソフト産業における壮大なマスターベーションネタなんですな(w

353 :デフォルトの名無しさん:01/12/29 05:53
>「状態」の塊なオブジェクト指向
そりゃ、へたくそが書いたらそーなるだけだろ。

354 :346:01/12/29 15:47
>>349
一応部屋の掃除ついでに
恒等関係が載ってる数学関係の本を見つけたんで、
報告する。

「無限と連続」岩波新書 遠山啓 著 1952年出版

ロングセラーの本だから今でも手に入るはずだと思うけど。
ここにこうある。

「この同値律を満たすものの中には恒等関係a=bがあることはいうまでもない。
それは最も厳しい同値関係であり、また反対に一般の同値関係は
恒等関係のゆるめられたものであると言える。」

一応報告までに。話の腰を折るつもりはないから。

遠山啓という人はどんな人かについて、
http://www.google.com/search?q=%89%93%8ER%8C%5B&hl=ja&lr=
等を参照。

355 :デフォルトの名無しさん:01/12/29 19:04
>>350
1.関数型言語だと、実用的なプログラミングを行うのに不便だから。
2.OOを形式化する事で、例えばデザイン・パターンとか、テンプレートについて、
 客観的な評価をしたいから。

356 :デフォルトの名無しさん:01/12/29 20:19
>>354
遠山啓は(日本で)数学を勉強した人なら誰でも
知っているような有名人だよ。
結局その用法が広まることはなかったようだね。
今現在の数学体系の集合論的定義からすると
何かが「特別」な概念であるとか「厳しい」条件である
ということ自体古臭い言い回しになってしまってる感が
(私には)ある。

357 : :01/12/29 22:12
OHaskell?
Haskellの何処をいじったら、オブジェクト指向になるんだろう?
いまいち想像出来ないな。

358 :デフォルトの名無しさん:01/12/29 23:27
>>356
>結局その用法が広まることはなかったようだね

なかった?
もう2002年になろうという現在においてさえも
絶版ではなく売れているらしいがな。

というかな、この本は、「数学への招待」として書かれた本なんだよ。
厳密に何かを語ると言うよりも、
多くの人に平易に数学の概念を教えようとしている本だと思うがね。
お前はどうやら遠山が数学教育に力を入れていたことは知らないようだな。

>今現在の数学体系の集合論的定義からすると
>何かが「特別」な概念であるとか「厳しい」条件である
>ということ自体古臭い言い回しになってしまってる感が
>(私には)ある。

こういう下らんことを言うな。
それも出版年は1952だ。時代を考えろ、ボケ。

359 :デフォルトの名無しさん:01/12/30 00:01
というか
「カントールの集合論が破壊しつくした廃墟の上に、「結合」
という一つの新しい相互関係を打ち立てるのが新しい代数学
である。」 「無限と連続」遠山啓著 より

昭和20年代の本だけど、数学の入門書でこれよりおもしろい
のないね。
 

360 :デフォルトの名無しさん:01/12/30 00:48
>>358
>>結局その用法が広まることはなかったようだね

>なかった?
>もう2002年になろうという現在においてさえも
>絶版ではなく売れているらしいがな。
実際に使われていないな

>それも出版年は1952だ。時代を考えろ、ボケ。


361 :デフォルトの名無しさん:01/12/30 01:12
>>360
>>それも出版年は1952だ。時代を考えろ、ボケ。
>?



君は結構もぐりだね。
その「無限と連続」を知らないなんて。

362 :デフォルトの名無しさん:01/12/30 01:15
アフォが1匹おるよ。アフォが。

363 :デフォルトの名無しさん:01/12/30 01:20
>君は結構もぐりだね。
>その「無限と連続」を知らないなんて。


364 :デフォルトの名無しさん:01/12/30 01:44
>>363
>>君は結構もぐりだね。
>>その「無限と連続」を知らないなんて。
>?


じゃあ、知ってたし読んだ事もあるってこと?
?だけじゃ駄目だと思うよ。
どのような点がどういう風に分からないのかを明らかにしないと。
それができなければ来ない方がいいと思うよ。
もう恒等関係の話も止めるべきだと思うし。

365 :デフォルトの名無しさん:01/12/30 01:48
>>364
この話にどう関係があるんだ?

366 :デフォルトの名無しさん:01/12/30 01:59
>>353
例えばCLOSでそうじゃないOOをどうしろと言うのかね。
メンバ変数が状態以外の何を保持すると言うのかね。
へたくそとか言う問題じゃなかろ。
「状態」の塊だからこそGUIの構築がOOでやりやすいわけだし。
「状態」の塊でないコードへのポインタを切にキボンヌ。

367 :デフォルトの名無しさん:01/12/30 02:14
>>355
2は同意ですね。なにもHaskell使わんでもとおもいますけど。
1は不同意。GUIとかいいだしたらどうにもならないけど、
そうでないなら別に問題無いとおもいます。
しばらく前に、10個ぐらい関数があって、それの合成の順序を総当たりして(nPn個)
それに無限数列食わせてドウコウってことをやる必要があったんですが、
Haskellだとすぐでした。CやFORTRANでやれと言われたら泣きます。
ま、私にとっては無いと困る「実用的」プログラムだったわけです。
なんかGUIがいるなら別の言語でそれだけすりゃいいんですし。
たしかにMLやHaskellでオフィススイート書けとかいわれたら首吊りたいかも。

368 :デフォルトの名無しさん:01/12/30 02:48
>>366
Smalltalkのクラスのソースでも読んでみろ。

369 :デフォルトの名無しさん:01/12/30 02:54
なんか話が関数型の話に回帰して来ていい感じ。
恒等関係ねぇ。任意の同値関係が成り立つ関係でいいんだよね。
ああ、ばかばかしい。=を一般の同値関係に使わないってのはデマだよね。
誤解が生じなければ混用していいし、されてるんだけどね。
なんか元の話の流れから馬鹿みたいにずれててウザイ。
ただのアナロジーを遊び心で記号使って表現しただけでこんなになるとはね。
Actorsとclosureの実質的な内容に話を戻すか350からのネタを引っ張るかに
しようという方向で逝きましょう。

370 :デフォルトの名無しさん:01/12/30 03:01
>>368
それは何か違う気が。いや、366への答えにはなってるけど。
Smalltalkのクラスはそれ自体オブジェクトだからなぁ。
ここで366が問題にしてるのはクラスとオブジェクトを峻別するタイプの
OOPLのことなんだろうな。そういう言語で実行時に作られるオブジェクトが状態の塊なのは
事実でしょ。
まあ、だとするとCLOSは例としては間違いなんだけどさ。

371 :デフォルトの名無しさん:01/12/30 03:06
>>366
>「状態」の塊だからこそGUIの構築がOOでやりやすいわけだし。
GUIが状態の塊だってだけだろ、でOOはそれ「も」扱いやすい。
まぁ、「メンバ変数」とかのたまってるってことは、C++とかJavaくらいしか頭に無いんだろう。
いや、もしかしたら>>366が言っているのは、逐次実行型のマシンが、そもそも状態の塊だというのかもしれん。
それなら理解はできる。
SmalltalkはOOとしては、すでに1世代以上前ってきがするから、最近のOOの代表にはならないかもしれないが、
インスタンス変数にcontents以外を持たないクラスってのは、結構多かった気がする。
それでも、たとえば、Collectionクラスが#(1 2 3 4 5)っていうのを持っていて、それが「状態」だというなら、
オブジェクトすなはち状態、という意見として聞いておいてもいいがろう。
納得はしないけど。

372 :371:01/12/30 03:12
>>370
OOの「使いドコロ」としてGUIが挙げられる事が多いけど、それがそもそもOOの誤解への第1歩って思う。

373 :デフォルトの名無しさん:01/12/30 03:15
内部状態のないオブジェクトなんか役に立つのか?

374 :371:01/12/30 03:17
>>373
内部状態のあるオブジェクトの例をなにかあげて欲しい。

375 :デフォルトの名無しさん:01/12/30 03:17
関数型からOOに話がずれてるな。350のねたに話を戻そうYO

376 :371:01/12/30 03:19
あ、まさか「内部状態のあるオブジェクトなんかあるのか?」っていう意味じゃない。
内部状態のあるオブジェクトがOOであるがゆえに内部状態を持たなくちゃ行けない、
しかし、関数型言語で同じ事をしようとした場合、内部状態を取り去ることが出来るっていう
例があるなら、知りたい。

377 :デフォルトの名無しさん:01/12/30 03:20
>>374
ほとんど全てのオブジェクト。
最も簡単なのは1ビットのメモリ。
カウンタなんかよく例に使う。

378 :デフォルトの名無しさん:01/12/30 03:23
>>377
ほうほう、じゃぁ、カウンタを例にとって、関数型言語では、どーするの?

379 :デフォルトの名無しさん:01/12/30 03:23
>>376
あるわけがない。

380 :デフォルトの名無しさん:01/12/30 03:26
>>378
カウンタに相当するものは(副作用のない)関数型にはない。
同じ機能を全く違う方法で実現するだけ。

381 :デフォルトの名無しさん:01/12/30 03:28
>>365
つまり、数学知ってそうなのに
恒等関係という言葉を知らない人がいて、
ただそれはその本見れば載っているわけで、
更にいうと、その本は結構有名な本なわけで、
だからもぐりなのかなと。
ただそれだけのことなんだけど。
恒等関係の意味が判らんって言ってた人がいたような気がしたんで。

この発言はそのまま通りすぎてください。

382 :デフォルトの名無しさん:01/12/30 03:35
>>378
こういう質問が出るってことはおまえさん関数型使わない方?
いや、OOは構わんが関数型も宜しくね。
GUIじゃないOOといえば、培風館のLispの本に例があったなぁ。

383 :371:01/12/30 03:36
つまりだ、OOが状態の塊なんじゃなくて、状態の塊のようなGUIみたいなサービスを提供するのに
比較的向いているってことだろ。
(副作用の無い)関数型言語はそれには向いていない。
だから、OOが向いている分野のために、関数型言語にOOを取りいれてみる実験は、アリだとおもうが。
どーだろう? >>350の答えになってるだろうか?

384 :デフォルトの名無しさん:01/12/30 03:41
>>381
恒等関係という言葉は多くの本に載っていないから
一般的な言葉ではないだろう。遠山啓の創作か?
どうでもいいが。

>任意の同値関係が成り立つ関係
この定義は分かりやすくていいね。

385 :382:01/12/30 03:44
>>371=383
うまくまとまった感じかな?
でも関数型言語の利点は副作用が無いことだけじゃなくて、
数学的な感覚をそのまま持ち込めるところなんじゃないのかともおもったり。
367なんかはそういう意味での関数型の恩恵をもろに受けたってことだろうか。
とするとだ、関数型言語にOOを採り入れると言うよりOOを関数型でやってみる
実験って事だな。だとすれば面白いかも知れないな。副作用を許すと言う妥協をしなければだが。

386 :371=378:01/12/30 03:49
>>382
関数型言語は、実際に仕事で使う場面はあんまりないです。
ただ、その前段階の調査とか、検算とか、そういうときにたまにつかいます。

387 :デフォルトの名無しさん:01/12/30 04:08
微妙にネタ切れか?
むぅ。関数型は学生とか言語理論とかやってると絶対使うよな。
仕事(アプリケーションソフトのプログラマ?)とかでは確かに使いがたいんだろう。
新人教育するのにコストかかりすぎるだろうし。Schemeは構文覚えんのは簡単だけど使いこなすのは
とても難しいよな。Haskellなんか覚えんのも使うのも難しいし。大体、入出力があんな
有り様じゃ確かに普通は使いたくなかろう。そこに萌えるのが学生たるゆえ。
Haskellがメジャーに成る日を夢見て今日もλ式。

388 :デフォルトの名無しさん:01/12/30 04:12
>Haskellがメジャーに成る日を夢見て今日もλ式。

なんかカワイくてウケたのでage

389 :デフォルトの名無しさん:01/12/30 09:59
関数型言語で直接プログラミングする機会がどれだけあるかは疑問でも、
JavaやRubyなんかで関数型プログラミングを併用するのはデバッグ効率
が向上するのでステキだよ。

# 無用な代入を避けたり、メソッドオブジェクトを引数に渡したりね。

390 :デフォルトの名無しさん:01/12/30 15:51
まあ、関数プログラミング、というかプログラミング言語理論に関して
一通り勉強した人間なら、
≡とでたら、同値、
isomorphismと出たら、同型、
とまずは訳してみるよな。
いきなり「同じ」とは訳さないよな。
まあ、全部読めば要するに同じってことかと
思えてくるのかもしれないけど。

391 :デフォルトの名無しさん:01/12/30 16:43
つーかレコード型のポインタ渡しが理解できない人が余りに多かったから
発生したんじゃないのか?OO

逆にOOでオブジェクトを構築しておいてそのポインタを渡してやる関数ってのは
関数志向でもありOO志向でもあると思うのだが

出来上がったプログラムの動きを考える場合ooだとプログラム自体の複製が
複数できるので非効率という気がする。
仮想関数関係も関数自体のポインタで切り替えたりできるわけだから
結局は個人の好みとせいのうじゃないの?

oo否定派だけど低レベルとのクッションとして4世代くらいの継承までは
まぁ許容かなってかんがえている。
もっともそうでないとCOMとかも使えないし

392 :デフォルトの名無しさん:01/12/30 18:47
>つーかレコード型のポインタ渡しが理解できない人が余りに多かったから
>発生したんじゃないのか?OO
こういうのって、どの人のOOの捉え方を反映してて、おもしろいよね。

393 :デフォルトの名無しさん:01/12/30 18:49
>OO志向
オブジェクト指向志向?

394 :392:01/12/30 19:03
どの人→その人

395 :デフォルトの名無しさん:01/12/31 00:36
>>384
そう言うことじゃなくて、
やっぱりどの分野にも良書といわれるものがあって、
それを読んでいないで何かをいうのはどうかなって。
つまり、良書とされているものを読まずに
一般的でないとかいうことで知らないことが免責されるかのようなことは、
どうかなと思ったんですよ。
だからもぐりって言ってみたんです。

396 :デフォルトの名無しさん:01/12/31 02:13
>>395
そうは言えある本を必ず学び準拠するべき「良書」と
決めてしまうのは単なる権威主義とでもいうべきものであって、
過去の業績を踏襲しつつも常に反省を忘れないことが重要な
学問にあってそれは望ましいことではない。
それぞれ多種多様な方法で学んだ者々がそろって
時には相対する立場にたって議論をすることが学問の進展や、
個人の理解の促進に貢献すると思われる。ある一つの本を読んでおらず、
そしてそれ故その本における定義や方法を知らないという理由で
議論を拒み非難の対象とするのはいかにも「幼稚」であり、また
「非学術的」な行いではないだろうか。これが個人に対してでなく
派閥間で生じれば互いに意思疎通のない「宗教」とでもいうものにでも
発展しよう。第一そのような事を行えば、どちらが「優れて」いるかなど
永遠に知りえない。常に相手の考えを理性的に判断する態度が
学問には必要だろう。

また、常に進展してゆく学問においてその書物の蓄積は膨大になる。
幸いなことに科学的学問はその結論に一定の収束を見せ、
誰が語ったかは問題にならない。その結果、過去の良書のエッセンスを
取り入れつつ更に改良をほどこし時には新しい結果を盛り込んだ
書物が次々と出版されている。よって過去に良書であった本に
大きく捕われる事はあるまい。ユークリッドの原論は今でも良書と
呼ばれはするがその業績は多くの本に取り入れられており、
我々が顧みることはあまりない。時代の変遷、多種多様な環境の中様々な
方法で勉強するものがおろう。己のたどった過程を相手も
たどるとは限るまい。そのような人々を「もぐり」と言ってしまうのは
いかにも度量が小さいといえよう。また相手もそう思っているやも知れぬ。

397 :デフォルトの名無しさん:01/12/31 14:14
2001年糞スレプログラミング言語部門にノミネートされました。

398 :デフォルトの名無しさん:02/01/01 23:20
>>391
>逆にOOでオブジェクトを構築しておいてそのポインタを渡してやる関数ってのは
>関数志向でもありOO志向でもあると思うのだが

値同値と参照同値の問題はどうなるの?
参照透過性を失ってしまえばもはや関数型とは呼べないような・・・・
「-3」を表現するのに整数クラスのインスタンス「-3」を一意に作って
それへのポインタを使うだけにすると言うなら参照同値=値同値と言うことになるのかな?

関数言語処理系の作成者とかなら必要なんだろうけど、普通のプログラミング
の時にそんな事はしてられないんじゃ? というか、Cで関数指向するくらいならさっさとMLなり
Haskellなりを使うほうがストレスに成らないような。

399 :仕様書無しさん:02/01/04 05:28
遠山先生もいいけど、N.Bourbakiでそ

400 :デフォルトの名無しさん:02/01/04 08:21
>>377
immutableなオブジェクトを作ったり使ったりしたことない人?

401 :デフォルトの名無しさん:02/01/05 00:30
>399
激しく同意。ブルバキだよな、やっぱり。
あ、でも基礎論の当たりちょこっとうさん臭かったりするんだよな。
正則性公理のあたりとか。
つうか、最近の学生は遠山先生の本なんかよんでないだろ。

402 :デフォルトの名無しさん:02/01/05 00:38
>つうか、最近の学生は遠山先生の本なんかよんでないだろ。
ブルバキはもっとだろ。

403 :デフォルトの名無しさん:02/01/05 01:04
ブルバキの本を最近の学生が読むなんて一言も書いてないけど(爆
いや、良書なのになぁ。
でも、ずっと上のほうにあるような言われ方する程遠山センセの本が読まれているわけもなく。

404 :デフォルトの名無しさん:02/01/05 01:55
>>396
つか、そんな大仰な話をしているのではなくて、
なんというか、恒等関係なんて言葉はないというようなことを
言っている人がいたので、
そのことでなんと言うかあげつらっている人がいたようにも見えたので、
ただまあそう言ってみたんだけど。
例えば、関数型言語では、武市さんの本なんかは、
必読とまでは言わないような気もするけど、
やっぱ一通り読んでおかないと議論に参加するのはどうかなとも思うし。
まあそんなようなことを言いたいんだけど。

405 :デフォルトの名無しさん:02/01/05 02:11
もうこの話題止めて398からの話題をひっぱりましょうね。
得るものが少なすぎます。

406 :デフォルトの名無しさん:02/01/05 02:49
議論の相手を選ぶ基準は色々あるだろうが
本を読んだかどうかで決めるなら、スレタイトルは
「武市ってどうよ?」とかにするべきだな。

407 :391:02/01/05 10:52
OO=クラス型≠非関数型 って認識じゃないのか?

折がいいたいのは
クラス型=クラス変数文メンバー関数の本体をメモリに展開する
関数型=作成済み関数のポインタのみを扱う
というのがコンパイラ自体の違いだから使いどころとしてクラス型を使っても
全体的に関数型にできるということ。
あとローテクでいうならば関数型とOOの違いは関数に対してBレジスタなりが
スタックフレームになっているかなっていないかということなんじゃないの?

あとOOじゃないと保持状態が作れないというけれど
レコード型変数で保持してポインタ渡しにするならば
関数自体はコンパイル時に直接生成されるけれど変数は動的に作れるから
プログラムはOOではないけれど機能的には同じで多分実行時メモリは小さい。

これは少なくとも>>376への答えにはなると思う。
例えば>>378はカウンタを例に出しているが

カウンタ値は変数なりファイルなり、あるいは名称や最終更新時間をもったレコードだとして
それがデータベースやファイル、変数やリストになっているとすれば
関数型で先頭アドレスと処理内容を渡してやれば作業はできるし
コードも複雑化しない
OOの場合は実装コードもクラスに記述するか継承するので
パラメータ無しのメンバー関数が作られるが実質的にはスタックフレームが暗黙的に形成されていて

Windowsの場合コントロールごとのステータスと挙動をOOで記述するとわかりやすい気がするが
レコード型の記述と関数型のほうが効率は良い。
実際OOでもソースの中低レベルはそうなっているはず(Ex.DirectXのEnum関係とか)

ということでどう?

408 :407:02/01/05 11:14
>>398 特定の学会に属していなければ関係ないんじゃないの?---参照透過性
できるのとやらないのは違うと思う。
別にレコード参照型で新しいレコードを生成するならば
学者さんいわくところの”関数型”になると思う。
ポインタは保存場所なんだから
プログラマーが節約のために同じところにするかどうかというだけの話

とりあえず折がいっているのはOOに対する関数型
どうしてもProcedure型の関数がいやだというなせば
関数の返り値が新しいレコードのインデックスかポインタになれば
へっぽこがくしゃさんでも気が済むでしょう。
ようは元を残してコピーを作るか、上書きするかってことだと思うよ。−−参照透過性

極端をいうならばアキュームレータの中身はかわるよね。
AccA+AccBをコンピューターでやる場合
結果はAccAに入る
この大原則がある上で参照透過性うんぬんというのは単なる無知とはいえないか?

言語というからには”翻訳”や”変換”があるわけで
卓上でぐだぐだいって単位が取れたり本をだせたとしても
翻訳結果や変換結果を無視してたら意味がない

409 :デフォルトの名無しさん:02/01/05 11:29
>>406
なんていうか、そういうことを言いたいんじゃないんだよね。
恒等関係を知らないなら知らないと言えばいい訳で、
そんな言葉はないとかいうのはおかしいなって思っただけなんだけど。
知ったかぶりはよくないんじゃないかって思うんだよね。
その知らないことについて議論に参加するのも何だか滑稽だし。

410 :デフォルトの名無しさん:02/01/05 12:04
>>408
>極端をいうならばアキュームレータの中身はかわるよね。
>AccA+AccBをコンピューターでやる場合
>結果はAccAに入る
>この大原則がある上で参照透過性うんぬんというのは単なる無知とはいえないか?

>言語というからには”翻訳”や”変換”があるわけで
>卓上でぐだぐだいって単位が取れたり本をだせたとしても
>翻訳結果や変換結果を無視してたら意味がない

それは、ひとつの見識として納得のいくものですけど。
でも、高級言語の価値は低水準の実装を隠すところにありますよね?
関数型言語の良さっていうのは、手続き型高級言語がなんだかんだ言っ
てアセンブラにおける常套句を言語構造に翻案したに過ぎないところ
とは別次元のものだと思うんですよね。
手続き型高級言語がメモリやI/Oのアクセスと制御構造によって成り
立っているのに対して、関数型言語は意味を定義する。その違いは
syntax sugarではないと思うんだけどね。

411 :デフォルトの名無しさん:02/01/05 14:43
>>407
「OOじゃないと保持状態が作れないというけれど」
え、誰が言ったの、そんな事。 (驚愕

412 :デフォルトの名無しさん:02/01/05 14:47
>>408
参照の透明性は
「変数の上書きをしない」ってことよりも、
「同一表現式は同一の値を表す」ことのほうが本質だと思うが。
つまり、同じ変数は常に同じ値を表すだけでなく、
同じ関数に同じ引数を与えてやると、同じ返り値が返ってくるってことが大事。

413 :デフォルトの名無しさん:02/01/05 17:44
>>409
ある用語が正しいか或いは正しい用法かどうかなど
個々の信念の問題であって知識の問題ではあるまい。
もちろん正しい用法においてその言葉は「ある」のであって
そうでなければ「ない」言葉を使っていることになる。
流行語などに対して文句を付けるのをたまに聞くだろう?
「ない」という主張が「おかしい」などということは全くない。
そしてこれは概念を理解しているかどうか、すなわちその事を
知っているかどうかとはまた別問題だ。その点で
「知ったかぶり」という言葉で表される事態では全くない。

この「恒等関係」にしてもその内容からすれば「汎同値関係」とでも
名づけたほうがよっぽどましだろう(と私は思う)。あなたは
そのような言葉は「ない」と主張するかも知れないが。

専門用語でこの様なことはよく起こる。それは研究者同士の
交流が希薄だったり或いは稀に対立したりするからだ。
その場合相手の用法を全く知らないことが多い。
それは「知らないならば議論に参加する資格がない」などと
済まされる問題ではなく、一々確認を必要とする。
最終的な用語についても歩み寄りがない場合もある。
2chでの様に喧嘩腰の人はまずいないが。

414 :デフォルトの名無しさん:02/01/05 19:40
>>413
409が問題にしているのは用語の正誤じゃないでしょ。
はっきりいって、「そのような用語はない」はすごく強い言明だよ。
よっぽど確信がないかぎり、使うべきものじゃないと思うが。

まあ、2chみたいな場で
「これを読んでない奴は議論に参加するな」ってのも
ちょっと乱暴だと思うけど。

415 :376>>391:02/01/05 20:21
答えになってなさそうです。
そもそもCPUに近いところでの動作の話になると、たいていの言語は、
コンパイル後のコードやVMの動作の話になって、その言語の持つ特徴
が、どっかいっちゃうから。

>あとOOじゃないと保持状態が作れないというけれど
おれは>>376ではそんなこと書いてない。
OOであるがゆえに状態を持っている→関数型で書きなおすと状態がなくなってすっきり
っていう例があるのか?って書いたんだ。>>411には通じてるね。
だから答えにはなってないんだよ。

俺があと言いたい事は>>410が書いてるのとだいたい一緒。

416 :415:02/01/05 20:24
376>>407=>>408 (あとで自分で見る時用))

417 :デフォルトの名無しさん:02/01/05 20:38
>>414
>「そのような用語はない」
これは用例がないことを意味するのではなく
それを誤りであるとする言明。用例があるのは
用例に対する応答である以上当然ある。この発言が
発言者の言語に関する正誤感覚に基づいているのは
言うまでもない。この点においてもちろん「すごく強い言明」で
あり、強い信念を感じとれる。この時どの程度多数の支持が
あるかは(発言者に影響しはするが)、特に妥当性に関しての信念ならば
多くの発言者は別問題と考えるだろう。

418 :デフォルトの名無しさん:02/01/06 01:16
>>414
んー、議論に参加するなって言うか、
知ったかで参加するなって言うことなんだけど。
知らないということを前提にして
聞く意味も込めて参加するということならば
2chを問わずかまわないと思ってるけど。

419 :デフォルトの名無しさん:02/01/06 04:50
どれが知ったかなのかをどいつが決めるんだ?
>>418か?おまえは神か?

420 : :02/01/06 10:03
知ったかの本人が気を付ければいい。

421 :デフォルトの名無しさん:02/01/06 10:41
「無知の知」を他人に要求するとはすごいね。

422 : :02/01/06 10:53
別にすごくもないと思うが。
ある程度は誰でもやってる。

423 :デフォルトの名無しさん:02/01/06 11:07
あーあ、こうやって粘着君がいるとせっかくのスレが台無しだよな。
わかった、わかった、知ったかは良くないよ。それは事実だよ。
あなたの主張は認めるよ。
だから関数型言語の理解・研究・発展に貢献する発言をしてください。
あるいは関数型言語のここがダメとかさ。

424 :デフォルトの名無しさん:02/01/06 12:47
>>423
君もね

425 :デフォルトの名無しさん:02/01/06 12:52
>>419
言うことが大げさ

426 :age:02/01/06 12:59
http://www.dream-fact.com/lovers/
http://anny.kir.jp/bbs-a/imgboard.cgi
モロダシ画像、チャイルドポルノ、バンバンアップ!!
おめ@丸見え!!
他では有料のアノ画像常時アップ!!

427 :デフォルトの名無しさん:02/01/06 13:46
前にもどこかで書いたんだけど、関数型言語を使っているときはUnitTestとか
要らない印象があるのね。手続き型言語だと、UnitTestを使って定義域での動
作と定義域外での動作をきちんと検証しないと気が済まない(テスト中毒って
奴ですか)。だけど、Schemeとか使っているときは、テストとプログラミング
が一体化しているというか、わざわざテスト用のコードを書いたりしないな。
まだ経験が浅いからかしら。それとも関数型言語だからかしら。

428 :デフォルトの名無しさん:02/01/06 13:50
>427
テストが問題になるような規模のコードを書かない/書けないから

429 :デフォルトの名無しさん:02/01/06 14:49
>UnitTestを使って定義域での動作と定義域外での動作をきちんと検証しないと気が済まない(テスト中毒って奴ですか)。
きちんと検証するのが、ごくごくあたりまえです。
むしろ、きちんと検証しないとあとがたいへん。
でもしない人も結構多くて、そういうやつがプロジェクトの足を引っ張るんだよなぁ…

430 :デフォルトの名無しさん:02/01/06 21:17
武市先生の訳は巧いと思ふ今日この頃。

431 :デフォルトの名無しさん:02/01/06 23:13
って武市正人(翻訳)「関数プログラミング」ですか?

本屋で見比べて、萩谷昌巳 著「関数プログラミング」
買っちゃいました!

432 :デフォルトの名無しさん:02/01/07 04:23
どの言語が一番おすすめ?

433 :デフォルトの名無しさん:02/01/07 04:24
Prolog

434 :デフォルトの名無しさん:02/01/07 12:43
>>428
>テストが問題になるような規模
ってどれぐらい?

435 :デフォルトの名無しさん:02/01/07 19:54
>>432-433 ってなんだー!Prologは一階述語論理に基づく論理型言語。
     宣言的プログラミングが良く似合う。

     ところでどっかに書いてあったProlog++, Mercury てナニ?

436 :デフォルトの名無しさん:02/01/07 20:48
>>435
Prolog スレにでてたね。

Mercury は
http://www.cs.mu.oz.au/research/mercury/
> Mercury is a new logic/functional programming language
ということで (FAQ for comp.lang.functional にも載ってるし)
このスレ向きですかね。

437 :デフォルトの名無しさん:02/01/07 21:08
http://pc.2ch.net/test/read.cgi/tech/1008220265/n170-171
俺も訊きたい。

438 :デフォルトの名無しさん:02/01/07 21:52
>>434
>>テストが問題になるような規模
>ってどれぐらい?
関数言語厨房が書ける最大の行数+1

439 :デフォルトの名無しさん:02/01/07 22:00
>>438
おいおい、一行か?

440 :デフォルトの名無しさん:02/01/08 04:49
禿しく一行!

441 :デフォルトの名無しさん:02/01/08 10:33
>>427

Hoare Logic とか Curry-Howard isomorphism のあたりかな?
プログラム検証を支援する仕組みとして、
・型システムの導入とか、
・事前条件/事後条件の記述(Eiffel)とか、
・形式的仕様記述言語による仕様記述とか、
いろいろありますよね。

関数型言語だと、どうして「検証するまでもなく」って感じるのかな?
副作用が少なくて、見通しがよいからかな?

442 :デフォルトの名無しさん:02/01/08 10:36
>>435-437 ぁ誤爆してる...

高階関数 と 高階論理 の (類似性) を
誰か教えて頂けないでしょうか?

あとついでに、本スレの流れでいうと、
リフレクション(特にjava.lang.reflect) と 高階関数 って、
何か関係あるんでしょうか、教えて下さい.

443 :デフォルトの名無しさん:02/01/08 22:44
>>442
>高階関数 と 高階論理 の (類似性) を誰か教えて頂けないでしょうか?
はぁ?ちゃんとわかるように質問しろよ。

>リフレクション(特にjava.lang.reflect) と 高階関数 って、
関係無い。

444 :442:02/01/08 23:35
>>443 話をスムーズに進めるために、後者の件から片付けておきます。

>>442
>2.リフレクション(特にjava.lang.reflect) と 高階関数 って、
> 何か関係あるんでしょうか、教えて下さい.


Javaで高階関数を作れないか、という話題がありました。この話題を考えるに、
Javaでは、メソッドの引数や戻り値に、メソッドを指定する事ができないので、
  (1)Javaのリフレクション機能(java.lang.reflect.*)を使って、Methodクラスを返すとか、
  (2)事前に定義済みの内部クラス・インスタンスを返すとか、
  (3)動的にクラスを生成する拡張機能(jakarta.apache.org/bcel や Java上の言語処理系)を使う、
といった答えしか思いつきませんでした.


ラムダ計算やコンビネータ論理が、プログラムの形式的モデルとして有効であるならば、
高階関数ってのは、オブジェクト指向言語実装系において、どのような意味を持つのでしょうか、
あるいは、オブジェクト指向言語を、ラムダ計算やコンビネータ論理でモデル化するのは
適切なのでしょうか?


かなりいい加減に、

  実は「リフレクション」あたりに対応させる事ができるのではないだろーか、

と思いつき、先の質問2. をカキコいたしました。

445 :デフォルトの名無しさん:02/01/09 01:07
http://www.research.avayalabs.com/user/wadler/pizza/Docs/Tutorial/week3/week3.html#firstclass

pizzaでfirst-class functionsだべさ
参考にするべさ

これはinner classとしてJavaにあるということになっとるべさ

446 :444:02/01/09 02:40
>>445 お、これまたずいぶん関数言語っぽいJavaの拡張ですね。>>piza
#  (Generic Java や、JCP14: Adding Generic Types to the Java の祖先ですか.)

結局、この問題は、
「Javaでは first-class functionsの代わりに inner classが実装されているから、
 それを使えば高階関数を作れる」
という回答でよろしいでしょうか?

#  オブジェクト指向の形式モデルなんて言い出したのヴァカみたい>>俺

447 :プロジェクト・リーダー:02/01/09 14:54
プロジェクト・リーダーの役割とは何か?
お教え下さい。

448 :デフォルトの名無しさん:02/01/09 14:55
>>447 すいません、また誤爆しちまったよ.

449 :デフォルトの名無しさん:02/01/09 15:12
また、ってあーた、前科あり?

450 :デフォルトの名無しさん:02/01/10 23:33
>>442
>高階関数 と 高階論理 の (類似性) を

高階論理では述語だけでなく、述語に関する述語や、さらにその上の述語...
などが記述できます。さて、集合A上の述語PというのはPの特性関数
X_P:A->boolと同一視できるので、A上の述語の述語が書けるというのは
(A->bool)->boolという高階関数が書けると言いかえられます。

というように結びつけられると思われ。

451 :デフォルトの名無しさん :02/01/11 03:27
プログラムの検証理論に関して何かよいお手本はないでしょうか?

452 :デフォルトの名無しさん:02/01/11 05:23
プログラム検証ツールは前スレにも出ていたPVS
http://pvs.csl.sri.com/
の他にどのようなものがあるのでしょうか?
ちなみにPVSはマスターするのに最低6ヵ月必要らしいの
ですが、他のものもやはりそれぐらいかかるものですか?

453 :デフォルトの名無しさん:02/01/11 15:47
こっちにも貼っておかなければ…

"Why Functional Programming Matters"の日本語訳
http://www.sampou.org/haskell/article/whyfp.html

454 :デフォルトの名無しさん:02/01/11 18:29
>>452
検証とは違うけどCafeOBJも面白いよ。

455 : :02/01/12 00:54
>>453
それなかなかいいね。

456 :デフォルトの名無しさん:02/01/14 23:31
lispコミュニティにも当てはまるかも…
http://www.towelrecords.com/varitext/001.html

457 :デフォルトの名無しさん:02/01/15 02:49
有名な関数型って、
Haskell、ML,LISP,Scheme,Emacs Lisp
ぐらいですか?

458 :デフォルトの名無しさん:02/01/15 03:03
APL と BackusのFP 辺りも、歴史的には重要鴨。

459 :デフォルトの名無しさん:02/01/15 03:03
>457
http://pc.2ch.net/test/read.cgi/tech/1010157331/l50
のスレの>167さん?

460 :デフォルトの名無しさん:02/01/19 15:00
age

461 :名無しさん@お腹いっぱい。:02/01/22 10:17
.NETの関数型言語はどれだけ使えてる?
知りたいのであげ

462 :デフォルトの名無しさん:02/01/23 01:22
>>457

MLが抜けてます〜


463 :デフォルトの名無しさん:02/01/23 16:06
http://jbbs.shitaraba.com/study/bbs/read.cgi?BBS=18&KEY=1009968275

464 :デフォルトの名無しさん:02/01/23 22:39
>>462
what?

465 :デフォルトの名無しさん :02/01/24 10:27
mercuryとはいかなる言語?
なんかえらいでかいパッケージなんだけどよ。

466 :デフォルトの名無しさん:02/01/25 03:08
>>465
「おいオメー さっきから うるせえぞ
『知りません』『知りません』ってよォーーーー
『知りません』・・・そんな言葉は使う必要がねーんだ
なぜなら オレやオレたちの仲間は その言葉を頭に浮かべた時には!
既にGoogleや書籍で調べがついちまって もうすでに『知っている』からだッ!
だから 使った事がねェーーーッ
『知っている』なら 使ってもいいッ!」

467 :デフォルトの名無しさん:02/01/25 03:18
プログラマは知らねど安請け合い

468 :絵胃碁嫁魔千:02/01/25 04:25
>>466
>>465 は英語読めないんじゃねえの?
mercury って日本語の情報ほとんどないし。

469 :デフォルトの名無しさん:02/01/25 08:34
mercuryのチュートリアルを読んでみた。
論理プログラミングをサポートするMLみたいな感じだね。
現実的な感じがするところが、使えそうな・面白くなさそううな。

470 :デフォルトの名無しさん:02/01/25 12:45
>>466
「気に入らない事でもあったのですか、何か?」

471 :デフォルトの名無しさん:02/01/25 20:04
>>469
MLが論理プログラミングをサポートすると、どうして
>現実的な感じがするところが、使えそうな
なんでしょうか?
そうかなあ?

472 :469:02/01/26 18:37
いや、MLが論理プログラミングをサポートすると現実的になるんじゃなくて、
論理プログラミングをML的にやると現実的になるって印象を
述べております。はい。

473 :デフォルトの名無しさん:02/01/27 05:39
>>472
論理プログラミング言語をつかう人が聞いたら怒りそうだ(笑

474 :デフォルトの名無しさん:02/01/27 06:19
ところでみなさん、どのような言語をお使い・・というか使えると言うか、
そういう状態なのですか?

475 :デフォルトの名無しさん:02/01/27 06:30
DrSchemeは、電卓代わりにいつも立ちあがってます、Win98です。

476 :デフォルトの名無しさん:02/01/27 10:01
Emacs(Meadow)の*scrach*バッファが俺の電卓だなあ。

仕事はRubyだけど、難しくなりそうなプログラムはSchemeで書いて
「本質」に迫ろうとしたり。Rubyで書くと、ad hocなコードで動か
しちゃうことになりがちなので、Schemeでプロトタイピングするこ
とによってそれを避けてます。


477 :デフォルトの名無しさん:02/01/31 02:37
つまりみなさんLisp以外は使っておらんと言うことですか?

478 :デフォルトの名無しさん:02/01/31 03:43
んなわけねーよ

479 :デフォルトの名無しさん:02/01/31 06:20
>>476ad hocなコードって何?

480 :デフォルトの名無しさん:02/01/31 06:44
ここの皆さんの仕事用言語は何ですか?

481 :デフォルトの名無しさん:02/01/31 07:03
COBOLです。

482 :デフォルトの名無しさん:02/01/31 08:59
>>481
ネタじゃないですよね?
とかいいながらおれも
ポストコボルみたいな
Javaだったりするから
人のこと言えないかw。

483 :デフォルトの名無しさん:02/01/31 12:59
>>479
ad hocは普通に辞書に載っている普通の言葉だが。
「特別な」「一度限りの」という意味。
つまり、ここでは、現在解こうとしている問題に
特化したコードを書いてしまうことを指している。
再利用などまったく考えていないコードのことだ
な。Rubyはスクリプト言語だからad hocなコー
ドを書きやすい。Schemeはそうじゃないってこ
と。

484 :デフォルトの名無しさん:02/01/31 13:00
>>483
後付けの、みたいな感じじゃないの?

485 :デフォルトの名無しさん:02/01/31 13:14
スタブを先に作っておいて
中身を後から書いたりすることだと
思ってたが、俺、間違ってる?

486 :デフォルトの名無しさん:02/01/31 13:17
483が正解だと思う

487 :デフォルトの名無しさん:02/01/31 13:21
勉強になりました(485)

488 :デフォルトの名無しさん:02/01/31 13:30
>>483
ad hocな理論、とか言うよね?
あれは「後付け」では?

489 :デフォルトの名無しさん:02/01/31 14:02
http://dictionary.goo.ne.jp/cgi-bin/ej-more_print.cgi?MT=ad+hoc&ID=EJ-003580.txt&sw=0
http://www.dictionary.com/cgi-bin/dict.pl?term=ad+hoc&db=*

490 :デフォルトの名無しさん:02/01/31 14:53
ad hocってのはあれだよな、
国際機関が常設されていない場合なんかを言うと思ったが。
つまり問題が起きるたびに機関を立ち上げて、
終わると閉鎖するって奴。

491 :デフォルトの名無しさん:02/01/31 14:58
>>488
違う、「場当たり的な」と言う意味。その問題にしか適用できないような、
いわば理論とは呼べない程度の理論のこと。

492 :デフォルトの名無しさん:02/01/31 15:48
>>491
ありがとう。

気持ち的には正しい意味で使ってた。
日本語にしようとは思わなかっただけで。



493 :デフォルトの名無しさん:02/02/03 16:33
Excelでマクロも循環参照も使わない場合、関数型言語に似ているといえないでしょうか。

eval がないのが惜しい。

494 :デフォルトの名無しさん:02/02/03 17:33
>>493
>eval がないのが惜しい。
evalって、LISPだけじゃないっすか。
関数型言語とevalは関係ないでしょ。

Excelって再帰できるの?


495 :デフォルトの名無しさん:02/02/04 09:22
>493
Excelに限らず、任意の言語で関数型プログラミングの手法を
使うことはできるよね。FORTRANではさすがにきついが。

496 :デフォルトの名無しさん:02/02/04 20:54
>>495
このあたりどうなのでしょう。
他の言語で関数風にかくことってどの程度可能なのでしょう?

再帰のできない言語では、全然ダメですし、
Javaだってコウカイ関数が使えないのであんまり生かせませんし、

たとえばCの文字列操作のような、関数のような形式で扱えないものも
関数的には扱えないですよね。


497 :デフォルトの名無しさん:02/02/04 21:16
>496
なんで他の言語で関数風に書こうとするんだ?
そんなこと考える時間割くぐらいなら関数型言語でもやってみたら?

498 :デフォルトの名無しさん:02/02/04 21:31
MLスレッドにレスしようと思ったが(そのような書きこみが多くあるため)
MLに限らないので、やや不便ながらこちらに書きこみます。

お初に書きこみます。
私はMLは嫌いではありません。
そういう上で思っていることです。

数学的背景があるからML(など)は別格であるという見方はちょっとどうかと
思います。
私もMLは面白いなとおもうのですが、MLが好きなほかの人の話を聞くと
ときどきやりきれなくなります。

関数型言語が数学的にサポートされているというのは、単に関数型言語が
「ある」数学的視点にとって都合の良い言語というだけであって、それ以上でも
それ以下でもないはずです。
それは言語が優れているということ(この命題はそもそもきちんと定義できて
いませんが)とはイコールではないと思います。
数学的な援軍を得やすいということだけだと思うのです。

たとえば同じ働きをプログラムをどれだけトータルで経済的に開発できるか、
という基準で考えたり、
同じものをどれだけ解りやすく(つまり低い理解力で)作り出せるかといった
風に考えた場合どうでしょう。
数学的な望ましい性質は、単なる手段に過ぎないと思います。
手段と目的がひっくり返っていませんか?

実際、MLは「使えますか?
どなたかがMLスレで書いていましたが、MLには今世の中で多いであろう
要求にたいしてまとまったライブラリがほとんどないと思うのです。
MLを使っている人は一体何をしているのでしょう?言語と戯れているだけで
実際に使おうとしないのですか?実際に使おうとすると自然にいろいろな資
産が残るとおもうのですが。

個人的には関数型には非常な可能性を感じます。
ぜひ、仕様の口上じゃなくて「実績」で他の言語を蹴散らしてください。

499 :デフォルトの名無しさん:02/02/04 23:39
>>498
つーか、この板でつかってるやついるのか?実は498だけだったりしないか?

500 :デフォルトの名無しさん:02/02/04 23:43
>>498
ていうか、実際ML使ってる人なんてほとんどいないと思うけど、
その使ってる人の中には、その数学的な特徴が一番重要で、
それゆえ「自分にとって」別格であると思ってる人がいるん
じゃないかな。
その人がそう思ってることをあなたが否定するのこそ
間違ってることだと思うよ。

501 :デフォルトの名無しさん:02/02/05 00:35
>>499-500
>>498さんは「使う」人にもっと話して欲しくて煽っているんじゃないかな。

502 :デフォルトの名無しさん:02/02/05 05:25
>>498

数学的背景がある、というのは言語の設計哲学とか設計上の方法論というべき
ものではないでしょうか。そもそも関数型言語には他にも目を向けるべき重要
なセールスポイントがいくつもあります。型推論、型チェック、ポリモルフィ
ズム、モジュールなどがそうであり、それらは生産性とか可読性を向上させる
目的で実装されています。

足回りが貧弱な感は否めません。ライブラリがないから誰も使わないのか、誰
も使わないからライブラリが放置されているのか...悪循環。


503 :名無しさん@navi2ch:02/02/05 07:15
数学に対するコンプレックスがあることは否めません。
それはまともなプログラマであれば全ての人が抱くことです。
まずは自分の心に正直になりましょうw。

で、話は変わりますが、
言語として優れていても凡人にとっつきにくいのは
やはり実用的な意味ではゼロに近いです。ですが残り僅かな
ところでかなり有用なのではないでしょうか?
クリティカルなプログラムがCで組まれているのは、
生産性という点から見てもあまり誉められたものではありません。
関数型言語の特性としてプログラムの検証を行えるというのが
強みなのですから、そこをもっと前面に出していってもいいのでは?

既存の言語で既に実現できていることを関数型言語でもやってみろ
という煽りは、2ch的に見ても低レベルだと思います。

私自身は、プログラム検証には興味がありそれ、
それが実在するツールではどの程度実現できているのか、
そんなところが知りたくて今、Haskellを勉強しています。

504 :デフォルトの名無しさん:02/02/05 08:18
MLはとっつにくくないと思います。
C++なんかのほうがよっぽど難しいと思います。

難しいという印象がついているのは、関数型言語と世間との接点にいる人が
数学とかラムダ算法とか理論とか、そういう後光を知らずか知ってか、ちらつ
かせながら、良い言語ですよと言ってしまっている事に原因があると思う。
#強迫神経症のような括弧の嵐、人工知能用の難しい特殊言語という先入観の
#付いてしまったLISPも同様に不幸ですね。

実際、MLの基礎的なことは割とすぐにおぼえられると思います。
大学の講義でMLが使われているところのカリキュラムを見てもそれはわかります。

で、たぶん問題はそのあとで、色々なことをしてみようと思ったとたんに、
こういう時にはこういう風に組む、という情報が少ない。(本もソースも)
C言語などからの「発想転換」が必要なところはなおさら。
そして、ML風をやっと掴んできたところで、ライブラリが何も無いので、
覚えたけど使えない。中級者手前で脱落。

他の言語でできることができないなんて、とんでもないと思います。
Cでウインドウシステムを組むのだって、よく考えればかなり無理をしています。
それがわからないのはライブラリがあるからです。
ウインドウシステムやソケット、データベースなどを、なんらかの関数型に合っ
た流儀でつかえるようなライブラリがあったら、つかると思いますけどね。

検証はたしかにものすごい強みですが、そのためだけに不踏の大地たるML
に踏み込むコストと、検証に向かない言語を検証ツールでがんばって検証
することと比較してどうかと思います。検証がどうしても必要となるようなプロ
ジェクトではお金もかけられるだろうし。
普通に使えるようになったMLで検証が可能だったら人々は中毒になることでしょうが。


505 :仕様書無しさん:02/02/05 08:45
MacOSXがもう少し安かったら、
開発用に使ってもいいんだけどな。
Webアプリ限定だけど。

506 :デフォルトの名無しさん:02/02/05 11:32
要するにライブラリが無いことに文句が言いたいんでしょ?
「C++にはVisualC++があるのに、なんでMLには無いんだ!プンプン」
マイナーな言語何だから仕方ないだろというしかないですなあ。(ワラ

507 :デフォルトの名無しさん:02/02/05 11:42
.NETもしくはmono
これで言い訳は通用しません。
ガチンコです。

508 :デフォルトの名無しさん:02/02/05 11:48
別に各人使いたい言語使ってればいいだけの話で、
他言語との勝負などはム板の掃き溜めである
撲滅スレの住人がやってればよろしい。
まあ、.NETで色々できるようになるんなら良いことじゃないの?

509 :デフォルトの名無しさん:02/02/05 13:31
.NET上の言語って単に各言語の特徴を無くして.NETに乗せてるだけなんだけど。


510 :デフォルトの名無しさん:02/02/05 14:05
.NET批判じゃないよ。現実的な話

511 :デフォルトの名無しさん:02/02/05 14:11
でも上に書いてあるプログラム検証という意味では
同じ土俵に乗ったといえるんじゃないの?

512 :デフォルトの名無しさん:02/02/05 16:16
飛べる力があるのに、どうして飛ぼうとしない。
起きろ!
・・という真摯な内部批判だと思うので、言語の無駄論議といっしょにするのは
どうかと思われ。

.NETは全然解決じゃないですよ。
今だって、やろうと思えばウインドウシステムもつくれないことはない。
機能が無いのではありません。
そこに大地が無いのではなくて、どういうわけか未踏の大地のままなのです。

513 :デフォルトの名無しさん:02/02/06 00:59
たぶん、こういうことじゃないかな。

同じようなこと、一度や二度感じたことのある人は沢山いると
思うんだ。実際、俺も思ったよ。でもって、ちょっと取り組ん
でみたこともある。

でも、実際にやりはじめてみると、CならCですでに実用化され
ている機能を「作り直す」という行為に終始することになるん
だよね。それって、ひどく退屈な上に、実りのなさそうな作業
なんだよね。

だったら、他の言語のライブラリにアクセスする仕組みや、別
のプロセスと通信する仕組みがあればいいってことになりがち
なんだよ。で、そういう機能は関数型言語にもある場合が多い
わけ。

それに気付いた瞬間、萎えちゃうんだよね。
少なくとも俺は萎えた。

あるものを使えばいいじゃん、って思っちゃうんだよ。
だって、使えるんだから。
それがないとどうしても困るってもんじゃないとな。

……というのが、俺の体験談ね。
でも、それでも頑張ってみるのも良いかも知れない。
SML/NJあたりだと、しばらくSML'97が健在っぽいし、日本語で
読める文献もあるわけだし、ライブラリを作ると、使ってくれる
人もいるかも、だしな。


514 :デフォルトの名無しさん:02/02/06 20:03
>>513
出来たライブラリの使い勝手が C と大して変わらないとかなら
あまり欲しくないよね。
でも関数型言語用なわけだし、抽象度が高く柔軟に使えるようなものなら
作る価値があるような気がするし、
そういう方向性で作るならあなたの云うようにならなかったりしないのかな?

515 :デフォルトの名無しさん:02/02/06 22:40
>>514
我輩Haskellはたしなまむのではっきりとはわからないが、
Haskelの公式サイトの
http://haskell.org/libraries/#guigs
を見てください。

>>513 の言っているのは、GTKをまんまくっつけただけなどの「望ましくな
い、抽象度の低い」ライブラリに相当すると思います。
オブジェクト指向のそれのように、関数型に即した抽象化の行われたライブ
ラリがあってしかるべきだと思います。

すでにあるじゃない、という意見なら未来永劫Cを使うということになりませ
んか?なんか、ダメなCOBOL使いの意見みたいです。
リナックスとかリナックスのウインドウシステム作ってる人みたいに、
作ること自体をたのしんでできないかな、とも思うし。


ただ、問題なのは「関数型のための抽象化」の良い案が凡人には思いつか
ないということでしょう。
どこかの研究者か天才プログラマーか、思いついてプロジェクトを始めて
欲しいなと。

516 :514:02/02/09 22:47
まー、みなさんの言うことはおっしゃるとおりなんですが。

俺もチャレンジしないと言ってるんじゃなくって、過去の挫
折体験をカミングアウトしただけなんだけどなー。


517 :デフォルトの名無しさん:02/02/13 03:16
>>516>>513だよね?
ついでに age

518 :デフォルトの名無しさん:02/02/13 10:11
Haskell少々Schemeサパーリな人間の質問です。
Schemeでcurry化って概念はあるのでしょうか?

たとえば、リストの先頭要素とそれ以降のリストの要素の大小を比較し、
小さい要素だけのリストを返す関数を、Schemeのfilter関数(非標準?)を
用いて実現したいわけです。
ちなみに、Haskellなら以下のようになります。

lessThan :: (Num a, Ord a) => a -> a -> Bool
lessThan a b
| a > b = True
| otherwise = False

lessList :: (Num a, Ord a) => [a] -> [a]
lessList ls = filter (lessThan (head ls)) ls

これをSchemeで書くとき、filter関数の(a -> Bool)部分をどう書けば
美しくまとめることができるのか、少々悩んでいます。
filter関数を使わなければ簡単なんですけど、どうせなら使いたい。

519 :デフォルトの名無しさん:02/02/13 10:41
>>518
Scheme少々Haskellサパーリな人間の回答です。

curry 化というのはわからないけど
リストの先頭要素とそれ以降のリストの要素の大小を比較し、
小さい要素だけのリストを返す関数は以下のように書けます。

(define (rm-if-not p lst)
 ;; Common-Lisp の remove-if-not 相当
 (let loop ((lst lst) (r '()))
  (if (null? lst) (reverse r)
    (loop (cdr lst) (if (p (car lst)) (cons (car lst) r) r)))))
(define (less-list lst)
 (rm-if-not (lambda (x) (< x (car lst))) (cdr lst)))

(less-list '(4 3 5 2 4 6 3))
 ==> (3 2 3)


520 :518:02/02/13 11:00
>>519 さん
ありがとうございます。
ちなみにcurry化というのは…正確な定義は忘れてしまいました。

lessThan :: (Num a, Ord a) => a -> a -> Bool
これが型の定義なのですが、 a -> a -> Bool が引数と返り値に相当します。
aに相当する数字二つを引数とするとBoolが返るのはOKとして、
もし引数が一つだけだとしたら、上の定義は右結合なので、
a -> (a -> Bool) となり、aを入力したらBoolが返る式が返り値になる、
というのがcurry化です。
Haskellでのfilter関数の定義が,
filter :: (a -> Bool) -> [a] -> [a]
のように、最初に評価式を必要とするので、curry化を用いると
具合が良かったわけです。
詳しい説明がsampou.orgにあったはずですが、これまた忘れてしまいました…。

521 :デフォルトの名無しさん:02/02/13 12:03
>>520
(define (less-than a b)
 (if (a > b) #t #f))

(less-than 4) ==> Error: 引数が足らん

となるのでそういうことはできない気がします。
Scheme だと

(lambda (x) (less-than 4 x))

みたいにその場で名前なしの手続きを
つくるのが普通じゃないかな?


522 :デフォルトの名無しさん:02/02/13 12:33
>>521
ごめん間違えた
(define (less-than a b)
 (if (> a b) #t #f))

強引に curry っぽいことはできるけど普通に呼ぶときに
面倒になるね

(define (less-than a)
 (lambda (b)
  (if (> a b) #t #f)))

((less-than 4) 1)
 => #t


523 :デフォルトの名無しさん:02/02/14 20:32
全部一変数引数の関数にしておくのね。

#教科書に載ってた、true, false, if-then-else, inc, dec, 自然数,…を表すλ式を
#scheme処理系に入力して遊んだときのことを思い出したよ。

524 :518:02/02/14 21:14
こうすべきだった。 lessList (l:ls) = filter (lessThan l) ls

525 :518:02/02/14 21:20
最初に書いたやつだと先頭要素同士を
比較しちゃうからですね。
空リスト以外はコロン使った方が好みです。

#もばいるしてたら電車逃した(w

526 :デフォルトの名無しさん:02/02/15 07:52
>>518
lessThan の定義ってこれじゃいかんのですか?
lessThan :: (Num a, Ord a) => a -> a -> Bool
lessThan a b = a > b
そもそも定義しなくても
lessList (l:ls) = filter (l >) ls
でいいんじゃないのですか?

527 :518:02/02/15 11:43
>>526
それで十分なんですよね。
電車に乗ってから気がつきました。
まぁ、Schemeでcurry化ってあるの?という疑問から
色々迷走してしまったということで許してください。

528 :デフォルトの名無しさん:02/02/17 16:09
Clean 使ってる人いる?
やっぱ、スレなんて立てたら即過去スレ逝きですかね?(w

529 :528:02/02/18 12:41
過去スレじゃなく過去ログだよ…
使ってる人いないのかな…

530 :age:02/02/18 18:27
ついでに。
http://members.tripod.co.jp/nbz/ref/lambda.html

531 :デフォルトの名無しさん:02/02/19 05:11
>>530
此の範囲だと、正に Lisp だね。
括弧を補うと直ぐに分かる(w

532 :デフォルトの名無しさん:02/02/19 16:17
lambda age
http://wwwfun.kurims.kyoto-u.ac.jp/MtLambda.html

533 :595:02/02/19 16:18
ff

534 :デフォルトの名無しさん:02/02/23 12:15
関数型言語を記事にしたような雑誌はなんでないんでしょうか?
というかプログラミング雑誌らしいものがCマガしかない現状は
ちと恥かしいです。他はライブラリの使い方とかそんなんばっかだし。

どうでしょうか?
2chでもおれのようなDQNが関心もつぐらいだからある程度は売れると
思うんだけど。

535 :保守age:02/02/26 23:57
実際には使用人口それ程多くないだろう
やっぱり雑誌になるのは、C/C++、Java、VB、
かろうじてC#、Pascalだろう。

536 :デフォルトの名無しさんk:02/02/27 00:06
DDJみたいな雑誌があってもいいかなと。
bitが潰れたぐらいだから半分趣味、半分学術
なんていう雑誌は売れないのかな?

537 :デフォルトの名無しさんk:02/02/27 00:06
ごめん、文章メチャクチャ

538 :デフォルトの名無しさん:02/02/27 04:17
>>534
> 2chでもおれのようなDQNが関心もつぐらいだからある程度は売れると
> 思うんだけど。
2chだからこそこれ程盛り上がって、それでわたしや貴方のようなDQN(?)が興味を持つようになるんだと思う。


539 :デフォルトの名無しさん:02/02/28 13:23
http://www.dcs.gla.ac.uk/jfp/


540 :デフォルトの名無しさん:02/03/02 02:49
>>539
素晴らしいです!
ありがとうございます。

541 :デフォルトの名無しさん:02/03/02 04:09
>>518-527
scheamでもカリー化みたいなことは、できるみたいです。
クロージャを使ってね。

ttp://srfi.schemers.org/srfi-26/srfi-26.html

542 :デフォルトの名無しさん:02/03/02 04:58
>>541
Haskell とかのやつより柔軟そうですね。

543 :デフォルトの名無しさん:02/03/02 07:12
プログラミング言語における「型」ってなんなんでしょうか?
ラッセルの理論からもらってきた概念という知識しかありません。
(これすらも間違ってるかもw)

こういった疑問を解消するためにはどんな勉強をしたらいいのでしょうか?
数学的な理論も必要かもしれませんが、抽象的な話は理解に時間がかかるので
実際に使われている言語を使って説明したような本あれば嬉しいです。
よろしくお願いします。

544 :デフォルトの名無しさん:02/03/02 11:53
>>543
MLの教科書でいいんじゃない?
あるいは、もうちょっとformalなほうが良ければ
http://www.cis.upenn.edu/~bcpierce/tapl/index.html
とか。
> The approach is pragmatic and operational;
> each new concept is motivated by programming examples
> and the more theoretical sections are driven by the needs of implementations.
なので、そんなに「抽象的」じゃないし。


545 :デフォルトの名無しさん:02/03/02 12:36
>>543
昔読んだ「データ型序説」って本はよかったよ。

546 :541:02/03/02 13:13
>>542
そうでもないよ。
このクロージャによるカリー化を処理系が
自動的にやってくれてるだけだし。
Schemeは、弱い型付けの言語だから柔軟だということかな?

547 :無名λ式:02/03/02 13:48
>>543
> プログラミング言語における「型」ってなんなんでしょうか?

プログラム断片の性質の一つ。型だけ特別な訳じゃなくて、
同じフレームワークで型推論、データフロー解析、strictness解析が扱える。

関数型言語で考えるのが一番理解しやすい。
Abstract Interpretationとか意味論の本を読むのが一番いいのだが...


548 :543:02/03/02 13:59
>>544 >>545 >>547
ありがとうございます。
個人的に納得がいかないのが
(それが型と関係あるのかは別としても)
変数の型と、関数の値域の違いです。
両者は関係ありそうななさそうな・・・
んー、難しいです。

こういった疑問は函数型言語を勉強すると
解消するものなんでしょうか?
お勧めの書籍をいっぱい教えてもらったので
それ読んでからまたきます。

549 :545:02/03/02 14:09
>>548
あと、英語でよければ、
http://research.microsoft.com/Users/luca/Papers/OnUnderstanding.A4.pdf
はいいペーパーだよ。型に興味があるのなら必読。

550 :543:02/03/02 14:23
>>549
どうもです、早速熟読します。

551 :デフォルトの名無しさん:02/03/02 14:26
わざわざCardelliのものを読まなくても、
プログラミング言語の諸概念について一通り説明してあるような本なら、
型の意義等について載っているだろう。
そういう本は余り日本語では出てないと思うが、
英語では結構ある。

552 :545:02/03/02 14:44
>>551
たしかに読み砕くのは大変かもしれないけど、
それに値するペーパーだと思う。
Cardelliのよりも簡潔で読みやすく、あれだけ包括的かつ深さがある
ペーパーがあったらぜひ教えてほしい。
(煽りじゃなく、ほんとにそう思う)

>>550
いきなり全部を理解しようとすると結構大変だと思う。
まずは全体を流して読んで、それから興味ある部分から
熟読していけば、きっと得るものがあると思うよ。
特にsubtypesとquantified typesあたり。


553 :デフォルトの名無しさん:02/03/02 21:40
「型って何?」という疑問はかなり根本的で、専門家でも大議論になる。
前に型理論メーリングリストでも盛り上がった。
(http://www.cis.upenn.edu/~bcpierce/types/archives/current/msg00271.html)

で、以下は俺の理解。

古典的な意味での型は「値の集まり」。(値の「集合」って書かないのは、ちょっと理論的な理由。
無限に続くかもしれない計算を表すのに極限の概念が必要で、ただの集合じゃなくて、位相が入ってないといけないので。)
「int」は「整数の集まり」だし、MLとかの「string -> bool」は「文字列を受け取って論理値を返す関数の集まり」。

ただ、最近は型の概念も進化してて、それだけではくくれない。抽象型とか。
だから、現代的な意味での型は、「値に対して*どのような操作が可能か*を表す式」ってとこかと。
抽象型だったらインターフェースを経由した操作しかできないし、
(ちょっと専門的だけど)線形型だったら「一回しか使っちゃだめ」ってことを表す。

で、>>548でいってる「変数の型と、関数の値域の違い」ってのはよくわからないけど、
もし「変数の型」と「関数の値域の型」(t1 -> t2のt2)のことをいってるなら、
「型である」という点では別に違わない、ってのが俺の答えなんだが、どうよ。
そもそもたとえばMLの型tは、t ::= int | bool | t1 -> t2 | ...みたく
再帰的に定義されてて、任意の型が、関数の値域の型(t2)になりうるし。

長文&わかりにくくてスマソ

554 :553:02/03/02 22:05
もはや誰も読んでないかもしれんが、補足。

上の見方にしたがえば、「変数xが型tを持つ」ってのは、
「実行時に変数xがとりうる値は、型tの表す集まりに入っている(ないしは型tの表す操作が可能である)」
ってこと。「式eが型tを持つ」とか「関数の値域の型がtである」も同様。
だから「型が(変数や式や関数の)値域」ってのはあながち間違いではないと思われ。

555 :デフォルトの名無しさん :02/03/02 22:13
>>553
読んでますよ!

今pdfファイルをせっせと読んでいる最中なので
何も書き込むことはありません。
だけど一言お礼だけは述べたいと思います。
ありがとうございます。

556 :デフォルトの名無しさん:02/03/02 23:41
>>539>>540
そのJournal of Functional Programmingって
ばりばりの研究者用ジャーナルだけど、ネタ?^^;
Functional Pearlのコーナーは研究者じゃなくても
理解できる&おもしろいかもしれんが。

557 :デフォルトの名無しさん:02/03/03 00:04
雑誌といったらそのくらいというお話

558 :デフォルトの名無しさん:02/03/05 18:37
age

559 :デフォルトの名無しさん:02/03/05 19:34
月刊「型技術」(日刊工業新聞社)
http://pub.nikkan.co.jp/mgz/kata/index.html

560 :デフォルトの名無しさん:02/03/05 19:47
ワラ

561 :デフォルトの名無しさん:02/03/05 20:37
日経関数プログラミング

562 :デフォルトの名無しさん:02/03/05 20:40
行政改革、参照の透明化

563 :デフォルトの名無しさん:02/03/10 12:20
保守age

564 :デフォルトの名無しさん:02/03/16 01:04
>>549
その論文は昔、修論の構想を教官(応用数学系)に説明するときと
最後にまとめるときに重宝しました。ホント。

565 :デフォルトの名無しさん:02/03/16 01:17
正直な話、Cardelliの話は古すぎる。

566 :デフォルトの名無しさん:02/03/16 23:49
functional age
ぼけーっと考えていたんだけど、分散処理って
'(+ 1 2) を他マシンに投げる、という発想から始まったのかな?
下調べまったく無しの書き込みスマソ。

567 :デフォルトの名無しさん:02/03/17 23:31
>>566 シミュレーションとか、エージェントとか、アクターっぽい視点ですね。
 コネクション・マシンあたりは、物理シミュレーションが目的かと。

>>564 恥かしながら知りませんでした。有名なものなのでしょうか?

>>565 今はどのあたりがホットなのでしょうか? 

568 :たとえエミュレタのみでも:02/03/18 00:03
Connection Machine Lisp萌え

569 :デフォルトの名無しさん:02/03/20 23:39
VAXはいいマシンだった、という話を聞いたのですが、
実際触ったことがある方居られますか?

570 :デフォルトの名無しさん:02/03/21 08:26
VAXはとーてもおーそいー♪(ダースベーダーのテーマで)

という歌は聞いたことあります。


571 :たとえエミュレタのみでも:02/03/21 13:37
>>569
板違いだろ。Ultrix上のFranz Lisp使ったことあるぞ。
4.2BSDは使ったことないな。

572 :デフォルトの名無しさん:02/03/25 03:00
関数型言語はgc使うの?


573 :デフォルトの名無しさん:02/03/25 03:54
関数型言語は来年滅びます。

574 :デフォルトの名無しさん:02/03/25 04:35
今日麩の大王でもくるの?

575 :デフォルトの名無しさん:02/03/25 04:41
サイヤ人の来襲があります

576 :デフォルトの名無しさん:02/03/25 09:13
そりゃあいちだいじ。
ピッコロ大魔王か孫悟空を探さなきゃ。

577 :デフォルトの名無しさん:02/03/25 10:29
ハァァァァァァァァァァァッァァァァ

ドドンパァァァァァァ

578 :デフォルトの名無しさん:02/03/25 11:19
荒れて来たか・・・

579 :デフォルトの名無しさん:02/03/25 12:09
('-`)。o○(春だし…)

580 :デフォルトの名無しさん:02/03/25 13:04
('-`)。o○(春休みかぁ。いいなぁ。。。)

581 :デフォルトの名無しさん:02/03/25 13:12
>>553
位相とか無限とか濃度とか考えなきゃいけないのかな?
コンピュータでは、普通無限を扱わないようなきが。。。


582 :デフォルトの名無しさん:02/03/25 13:38
普段から、自然数や無限大は扱ってるような気が…

583 :デフォルトの名無しさん:02/03/25 18:55
あーぁ最近メインの研究を疎かに,ラムダラムダ言っているような気がするなぁ

584 :デフォルトの名無しさん:02/03/25 19:07
>>581
測度と重さもね。

585 :デフォルトの名無しさん:02/03/25 19:42
>>582
コンピュータで無限大を?
オーバーフロー アンダーフローじゃなくて?

586 :デフォルトの名無しさん:02/03/25 19:52
正格とか非正格って、無限の概念と関係あるかな?

587 :デフォルトの名無しさん:02/03/25 20:13
>>586
関係なし
最外簡約と最内簡約は実行する順番が違う
解析木を上から攻めるか、下から攻めるかの違い

588 :デフォルトの名無しさん:02/03/25 21:32
Lazy Evaluationで無限リストを処理、とか考えてしまった〜

589 :デフォルトの名無しさん:02/03/25 23:18
無限リストの実現は、遅延評価に拠っている。
その意味では関係あるといえる。

590 :デフォルトの名無しさん:02/03/25 23:51
最内簡約だと無限リストは永久ループになっちゃうかなねー

591 :デフォルトの名無しさん:02/03/26 06:40
関数型言語ではリストの要素に自分自身を入れることは出来るんですか?

592 :デフォルトの名無しさん:02/03/26 08:55
出来ますよ、っていうか、関数型でなくても出来る言語ありますよ。

593 :ななしー:02/03/26 15:58
出来ない言語ってあるかな?
non-strict関数型言語の場合、letrecが強力にサポートするから、宣言型風に書ける。

letrec x = 1:2:3:x; // 1:2:3:1:2:3:1:2:3:1:2...

594 : :02/03/26 16:36
�x00b;

595 :デフォルトの名無しさん:02/03/26 20:32
>>592
自分自身を入れると倫理的におかしくなりませんか?

596 :デフォルトの名無しさん:02/03/26 22:11
再帰だから問題なし?


597 :意味なしー:02/03/26 23:36
int x[] =
┌────┐
│    1│
├────┤
│    2│
├────┤
│    3│
├────┤
│ (int)&x│
└────┘

598 :デフォルトの名無しさん:02/03/26 23:39
わざわざ表にするほどの…

599 :デフォルトの名無しさん:02/03/26 23:52
>>591
強い型付けをもつものだとだめだと思ふ。
>>593
これは、自分自身が要素になっているわけではないと思ふ。


600 :デフォルトの名無しさん:02/03/26 23:54
厨房ですが600頂きます、失礼しますた

601 :デフォルトの名無しさん:02/03/26 23:57
>>599
CommonLispに関してはどうでしょうか?できますか?

602 :デフォルトの名無しさん:02/03/27 00:08
>>601
当然です。Scheme最強です

603 :デフォルトの名無しさん:02/03/27 08:45
ここも春厨だらけ


604 :デフォルトの名無しさん:02/03/28 10:21
>>581
再帰があれば「無限に続く計算」は表せるでしょ。
さらにlazinessがあれば「無限に長いリスト」も定義できるし。
そういうのの意味論に極限(つーか不動点)が出てくる。

>>595
倫理的…(ぼそ)
ocamlならこんな感じ。破壊的代入とかは使ってないよ。
要するに再帰的な値の定義さえできれば良いわけだ。
強い型付けでも、再帰型があればノープロブレム。

# type t = T of t list | I of int ;;
type t = T of t list | I of int
# let rec x = [I 1; I 2; T x] ;;
val x : t list = [I 1; I 2; T [I 1; I 2; T [I 1; I 2; T (以下略)


605 :デフォルトの名無しさん:02/03/28 10:50
>>604
こんなのもあるYO!

> ocaml -rectypes
Objective Caml version 3.01

# let rec x = [x] ;;
val x : 'a list as 'a =
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[.]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
#


606 :604:02/03/28 11:37
再帰と極限と不動点にどういう関係があるんだ、とか思った奴のために。
長文なので興味がない人は無視してけろ。非ドキュソ大の数学科や情報科学科なら
そういう授業があると思うが、みんな興味を持たないので人気がない…

まずは高校数学の復習(?)から。

    a_{n+1} = 0.5 a_n + 1

という漸化式を考える。_nとか_{n+1}とかは下付きの添字ね。
a_nのn→∞での極限は2になるんだが、これは

    f(x) = 0.5 x + 1

なる関数fの不動点なんだ。いいかえると、

    x = 0.5 x + 1

って方程式の解が極限になってる。
直観的には「数列が収束するあたりでは値が一定になる」って感じ。

さて、じゃあ再帰的関数の例として、

    fact(i) = if i <= 2 then 1 else i * fact(i-1)

なる関数factを考える。このfactはどんな関数なんだ?って知りたかったら、

fact(i) = if i <= 2 then 1 else i * fact(i-1)
    = if i <= 2 then 1 else i * (if i-1 <= 2 then 1 else (i-1) * fact(i-2))
    = if i <= 2 then 1 else i * (if i-1 <= 2 then 1 else (i-1) * (if i-2 <= 2 then 1 else (i-2) * fact(i-3)))
    = ...

みたく、再帰的定義をどんどん展開してみればいいわけだ。
こうやって展開した極限が、factの意味になる。
再帰的定義を展開していった極限を考えているのでであって、
fact(i)のi→∞での極限とは違うので、混同しないように注意。

だから、factって再帰的関数は、

    f_n(i) = if i <= 2 then 1 else i * f_{n-1}(i-1)

みたいな漸化式で定義される関数列f_nの、n→∞での極限になるわけだ。
ただし初項f_0(i)は常にエラーを返すってことにしておく。

いいかえると、

    F(f) = if i <= 2 then 1 else i * f(i-1)

なる作用素Fの不動点がfactなんだ。以上。

って、こんな説明じゃ元から知ってる人しかわからないか…


607 :デフォルトの名無しさん:02/03/28 22:52
>>606
>直観的には「数列が収束するあたりでは値が一定になる」って感じ。
ループ(再帰)の終了条件(不動点)で良いのでは?
『計算機プログラムの構造と解釈』SICPにも載ってるね

608 :デフォルトの名無しさん:02/03/29 02:49
あとは、位相と濃度と測度かよ。
面倒な宿題だなあ・・・

濃度:関数言語やってる人は濃い
測度:関数言語やってる人は逝くのが速い
位相:関数言語やってる人がこのスレにはイパーイ居そう...

#ふぅ、完了


609 :デフォルトの名無しさん:02/03/30 12:37
>>607
ループの終了条件と不変条件は別と思われ。
>>581>>608
位相はともかく、濃度とか測度とかも関数型言語の意味論に必要なの?
まあユーザとして使うだけなら、どれも要らなさそうだが(笑)

610 :デフォルトの名無しさん:02/03/30 12:39
>>608
ワラタage

611 :デフォルトの名無しさん:02/03/30 13:01
お前ら位相とか不動点とか言いたいだけちゃんかと小一時間(以下略)
なんかプログラム板っつーより数学板みたくなってきたな:-)


612 :デフォルトの名無しさん:02/03/30 13:12
言語自体が理論で固めて作られてるちゃんうかと。
むしろ理論なしに関数型言語をどうやって語るのかと小一時間(以下略)

と、門外漢は思ったりするのでした。
個別の言語仕様は別スレあるしいいんでないの?

613 :デフォルトの名無しさん:02/03/30 15:32
数学板なんてあったのか。
いままで知らんかった!

614 :デフォルトの名無しさん:02/03/31 02:29
>613
相当古くからあるよ。確か99年にはもうあった。

615 :モナBERT:02/03/31 09:50
>606
漏れ、今から細かぁ〜い三村マサカズ風ツッコミするで。
> factって再帰的関数は、
>     f_n(i) = if i <= 2 then 1 else i * f_{n-1}(i-1)
> みたいな漸化式で定義される関数列f_nの、n→∞での極限になるわけだ。

関数列f_nの極限かいっ!
関数列f_nのunionの極限だろ。


616 :sage:02/03/31 12:43
http://pc.2ch.net/linux/index.html#2

617 :名無しさん@Emacs:02/03/31 12:56
関数型最強の言語は?

618 :デフォルトの名無しさん:02/03/31 12:58
APL

619 :デフォルトの名無しさん:02/03/31 13:00
最強とか言いだすと荒れそうだが、俺が好きなのは scheme
というか他を知らないとも言う。

620 :デフォルトの名無しさん:02/03/31 13:27
既出ですか?
http://www.yfcbookshelf.com/ml_lisp_scheme.htm
ML / Lisp / Scheme

621 :デフォルトの名無しさん:02/03/31 15:19
The Little Schemer ついに注文してしまった。

622 :デフォルトの名無しさん:02/03/31 16:47
>>621
これも面白いよ。

「関数プログラミング」 萩谷 昌己 著 日本評論社
ISBN4-535-60817-2

前書きより一部引用
引用始め
本書は一般教養としてのプログラミングの教科書である。
欲をいうならば、高校生に読んでもらったり、高等学校で
使ってもらったりすれば大変な幸せである。、、、省略、、、
BASICやFORTRANやPascalやC言語やC++やJavaの経験
は反面教師としてのみ有効である。
引用終わり


623 :デフォルトの名無しさん:02/03/31 19:17
配列をうまく扱える関数型言語って何がある?
SISALとか使っている奴はいるんだろうか。

;; I-structureはなしね

624 :デフォルトの名無しさん:02/03/31 22:29
関数型言語は状態変化が記述しずらいので 一般受けしないらしい。

625 :デフォルトの名無しさん:02/03/31 23:20
>>623
J言語。


626 :604:02/04/01 12:26
>>615
すげえ、誰もわかんないだろうと思って誤魔化したのに、しっかりばれてる…

627 :618:02/04/01 12:50
>>623
だから APL だって…げ、>>625 さんきゅ!
そんなのがあったとは知らなんだ

628 :デフォルトの名無しさん:02/04/03 08:28
APLを普通のキーボードで打てるようにしたのがJ言語です。
APLは事実上、APLマシンでしか使えませんが、J言語は普通のPCで使えます。


629 :デフォルトの名無しさん:02/04/03 11:39
ここの言語研究のプロの方の考えを聞きたいところなのですが、
反復的なインクリメンタル開発ということに適した言語とは何でしょうか?

RUPの開発の主軸に、ユースケース駆動、アーキテクチャ中心、反復的かつ
インクリメンタルな開発というものがあります。
先の二点からはOOPLという解がある程度適しているとは思いますが、
最後の反復的な開発スタイルにはOOPLではどうも上手く行かないような気がします。
RUPは基本的にはソフトウェアはコンポーネント指向であるべきと考えているよう
なので、その中身のパーツたるコードまでOOである必要はないと思うのです。
というと何かOOPL信者さんに喧嘩を売っているようにも読めてしまいますが、
私はそういったことではなくて、あくまで「現場」という効率がのみが重視されるところに
おける最適解について個人的に考えたいと思っています。
現場では様々な要素が関係してくるので、方法論一般として何かを書くのは
難しいと思いますが、ここは2chということで主観的な考えを聞かせて頂けたらな、
と思います。

なお関数型言語に関する知識はlispをかじった程度の知識しかありません。
よろしくお願いします。

630 :ななし:02/04/03 12:22
>>629
CLOS

631 :デフォルトの名無しさん:02/04/03 13:40
>>629
現場の最適解って言ったら、プログラマのレベルを設定しないと。
COBOLしかできないプログラマにはどんな開発でもCOBOLが最適解。
勉強してからやらせるとしても、
例えばML勉強させても悲鳴をあげないくらいのプログラマが
そこそこいる「現場」ってのは俺には想像できないけどな。

632 :デフォルトの名無しさん:02/04/03 15:19
ML勉強させても悲鳴をあげないくらいのプログラマが複数いたら、
ばらして、別々の現場担当させるな、おれだったら。
だから、1箇所に「そこそこ」な人数は集まらないと思う。

633 :デフォルトの名無しさん:02/04/03 20:25
>>632
MLって勉強しやすくないですか?むしろ。

634 :デフォルトの名無しさん:02/04/03 21:10
LISPとSCHEMEってなにが違うの?よくSCHEMEはLISPの方言っていうけど
何が違うかさぱーり。コードみても同じっぽいし。というか
理解してないから同じに見えるんだけど。名前違うとかじゃなくて
何が違うのかおせーて、神よ。


635 :デフォルトの名無しさん:02/04/03 21:49
Lispには方言がたくさんあったので、Common Lispという仕様がまとめられま
した。Lispと言ったら代表的なのはこれです。

Scheme はその方言のひとつです。特徴としては、レキシカルスコープ、末尾
再帰、継続などのサポートが挙げられます。仕様は必要最小限の機能だけを盛
り込んだとても小さなものです。

勉強するなら個人的にはSchemeをお勧めします。ちなみに私は勉強中なもので
上に書いたことは不正確かもしれませんが、それにはこれからえらい人がツッ
コミをいれてくれるでしょう。

何を言ってるかわからなかったら自分で調べてみてくださいな。Lisp/Scheme
スレの頭に参考ページがいろいろあるので見てみませう。


636 :デフォルトの名無しさん:02/04/03 21:51
>>633
「現場」には、COBOL以外全ての言語が勉強しにくいと感じるプログラマーや
VB以外は全く頭に入らないプログラマーがたくさんいます。
ごくわずかな例外がマ板やム板を覗き、その中のごく少数がこのスレを見てます。
>>634のような者でも「現場」の中ではエリート中のエリートなのです。

637 :デフォルトの名無しさん:02/04/03 22:59
>>634

勉強するならSchemeがおすすめ。
小さいのと、高階関数の取り扱いがすっきりしてる。
小さいけどパワフル。
Guy Steele も言っているよ。

Small is beautiful.
Small is powerful.
Small is easy to understand.
I like Scheme programming language because it is small.
It packs a large number of ideas into a small number of features.

Scheme and the Art of programming
MIT press
from Foreword

638 :デフォルトの名無しさん:02/04/04 00:46
>>637
その代わり、ライブラリ関係で苦しむかもね。
SLIB とか SRFI の実装とかあるけども。


639 :638:02/04/04 00:53
用途にもよるけど、Scheme だったら Python が良いと思うよ。
手続き型にもオブジェクト指向にも関数型にも書けるし、ライブラリも充実してる。
Windows でも Mac でも Unix でも問題なく使えるし、Scheme に比べてかなり
とっつき易いという事もある。

Scheme が悪いとは言ってないよ。私も Scheme 勉強中だし。
Unix 限定のプロダクトなら Guile で良いとも思うし。

640 :638:02/04/04 00:57
何か日本語変だし・・・(鬱

641 :デフォルトの名無しさん:02/04/04 01:00
 みなさん再帰と言えばGEBを読んだ世代ですか?

642 :デフォルトの名無しさん:02/04/04 01:34
教えてクンだが、なぜschemeやMLや関数型言語なの?
CやJAVAやってきて本屋でふと関数型言語、SCHEMEの本みたら
なんだこれ?ってかんじだったんだけど。
すでに語られてると思うが関数型の実用的なメリットって
なに?教えてくれ。


643 :デフォルトの名無しさん:02/04/04 04:49
>>641
世代なんてあるのか?
俺は少し前に買ってきたけどまだ読んでいない…。

>>642
http://www.sampou.org/haskell/article/whyfp.html
でも、この文書は関数型言語をすでにかじってる人じゃないと
あまりピンとこない気もする…。

644 :デフォルトの名無しさん:02/04/04 05:28
RUPが必要なプロジェクトにおいて関数型言語が使われたことってあるのかな?

645 :デフォルトの名無しさん:02/04/04 06:57
>>642

こんなの読んでみたら。

bit 1999.3月号 特集いま欲しいブレークスルー 
「関数プログラミング」 武市正人 著 
共立出版


ACMチューリング賞記念講演集 
1977 Turing Award Lecture
「プログラミングはフォン.ノイマン.スタイルから解放されうるか?
関数型プログラミング.スタイルとそのプログラム代数」  
ジョン.バッカス  共立出版
       
               

646 :デフォルトの名無しさん:02/04/04 07:10
XMLのXSLTとか関数型プログラミングに近いのかな?

647 :デフォルトの名無しさん:02/04/04 07:16
>>642

もし、古本屋でみつかったら。

「ソフトウェア考現学 基礎概念への最新おもしろガイド」
萩谷 昌己 著 CQ出版
4.新しいプログラミング.スタイルに向かって

昭和60年の本です。
萩谷先生によれば関数プログラミングは
変数、代入、GOTOと真っ向から戦い続けている老戦士なんだって。



648 :デフォルトの名無しさん:02/04/04 07:23
「関数がなく GOTO だらけ」から「構造化プログラミング」へのベクトルの
延長線上に「関数型プログラミング」がある気がする。

649 :デフォルトの名無しさん:02/04/04 07:32
http://research.microsoft.com/projects/clrgen/
正直これに期待。

650 :デフォルトの名無しさん:02/04/04 07:46
プログラミング言語の研究とそれの実装技術は分野として別なんでしょうか?
学術的なカテゴリーとしては。

651 :ななし:02/04/04 09:24
>>650
プログラミング言語の研究⊃実装技術の研究
実装技術の研究≠実装してみました



652 :デフォルトの名無しさん:02/04/04 10:05
さっそく関数プログラムを本屋で買ってきます。
ばりばり勉強だぜぃ

653 :デフォルトの名無しさん:02/04/04 10:17
http://research.microsoft.com/projects/sml.net/
はいつでるんだろう・・・

654 :デフォルトの名無しさん:02/04/04 10:53
>>649
それのタイトルはCOM+2.0・・・
.NETってCOMになんか依存してるの?

655 :デフォルトの名無しさん:02/04/04 21:01
>>642
関数型言語の良い点?
一杯あるぞ。
ここや「LISP Scheme」板
「関数型プログラミング言語Haskell」板
「関数型プログラミング言語ML」板
などで外出なネタだ。
過去ログ見てみたら?

ちなみに俺が思う手続き型言語に比べて関数型言語の利点は
普通にプログラムを書いても1関数1状態なる点だと思う。
手続き型言語は、状態が入り乱れた理解しずいらいソースになりやすい。 

656 :デフォルトの名無しさん:02/04/04 21:05
スレを板と呼ぶ…

657 :デフォルトの名無しさん:02/04/04 22:29
ム板は、メタ板?

658 :デフォルトの名無しさん:02/04/04 23:09
http://jp.franz.com/jlug/ja/resources/implementations.html

Common Lispの処理系でおすすめなのってどれ?
Win2000, Linux で動くフリーのやつ。

659 :デフォルトの名無しさん:02/04/04 23:12
>>658
こっちのスレ逝ったほうがいいんでねぇの。
http://pc.2ch.net/test/read.cgi/tech/1016211619/l50

660 :デフォルトの名無しさん:02/04/04 23:32
関数型言語の普及にとって最大の障壁は
人は思考形態の変化を簡単には受け入れ
られないってことでは?


661 :デフォルトの名無しさん:02/04/04 23:32
clispにキマッテルだろ

662 :デフォルトの名無しさん:02/04/05 04:24
ttp://www.franz.com/downloads/#acl

ttp://www.xanalys.com/software_tools/products/lww.html



663 :デフォルトの名無しさん:02/04/05 06:52
>>660
それなりの能力を持ったプログラマなら何の問題もないと思うけど。
それよりもライブラリが充実していないのがまずい気が。

664 :デフォルトの名無しさん:02/04/06 10:35
>>660
そうでもないぞ
10代の人なら数ヶ月で新しい語順に対応できると思う
20代以降の人も、半年ぐらいで慣れると思う。

>>663
禿同
IO+GUI+TCP/IPのライブラリ付きの良い処理系ができるといいねー
ところで関数型言語にスレッドのライブラリって要るんやろか?
マルチスレッド無くても継続やlambdaでやってしまうことが多いから。
どなんだろう?

665 :デフォルトの名無しさん:02/04/06 11:50
>>664
継続切り替えのスレッドは協調型でしょ。
lambdaでやる、ってなに?
どのみちプリエンティブなやつはOSの助けが要る。
実装はgcまわりが大変かも。

666 :660:02/04/06 12:06
>>663
>>664
柔軟な頭脳、若い頭脳のノイマンからの脱出に期待。


667 :デフォルトの名無しさん:02/04/06 17:54
>>666
ノイマン型って、そんなに悪いもんか?
そんなに悪いものじゃないと俺は思うけど。
他に良いものある?

668 :デフォルトの名無しさん:02/04/06 18:02
悪くは無いけど、もう発展しなそう。今だって大昔の理論がハードの
発展で実用化してるだけで、何も目新しい理論無いだろ?

669 :デフォルトの名無しさん:02/04/06 18:07
所詮コンピュータなんて、正しく早く計算してくれる機械なんだから。
それに実用化されているっていうのは結構重要だと思う。
利点も欠点も判ってるっていうことだから。

670 :デフォルトの名無しさん:02/04/06 18:13
米軍が量子型の開発をしているそうだけど、
「わたしたちにとって」実用的になることは……ね。

671 :デフォルトの名無しさん:02/04/06 18:18
DNAコンピュータとかもあるね。
計算(パターンマッチ)は速いけど、一杯ある計算結果から
正しい結果を取り出すのが大変らしい。
実用的になるんだろうか?


672 :デフォルトの名無しさん:02/04/06 18:55
まあ
暗号化・認証の方向ではそこそこいける鴨

673 :デフォルトの名無しさん:02/04/07 06:38
DNAコンピューターって名前かっこいい

674 :デフォルトの名無しさん:02/04/07 06:50
はぎゃー先生マンセー

675 :デフォルトの名無しさん:02/04/07 10:30
核酸計算機って呼ぼうぜ。

676 :デフォルトの名無しさん:02/04/11 02:11
sage

677 :デフォルトの名無しさん:02/04/13 15:13
脱線しすぎage

678 :デフォルトの名無しさん:02/04/13 19:33
量子コンピュータといえば、Haskellのlist monadみたいなノリで
量子計算を定式化した計算体系があったような。関数型言語のチャンス?(w
実用化しなきゃ無意味だけど…

679 :デフォルトの名無しさん:02/04/24 03:16
age

680 :デフォルトの名無しさん:02/05/02 12:35
XSLTマンセー

681 :デフォルトの名無しさん:02/05/02 13:09
Why did you MANSEI about XSLT ?

682 :デフォルトの名無しさん:02/05/02 13:11
XDuceまんせー
http://xduce.sourceforge.net/

683 :デフォルトの名無しさん:02/05/02 13:23
>>681
http://www.topxml.com/xsl/articles/fp/

684 :デフォルトの名無しさん:02/05/02 15:22
何となくは感じていたことだが、
タグがいかにも面倒。

685 :デフォルトの名無しさん:02/05/02 15:34
>>684
S式だと親近感が沸かない人が沢山いるらしいので・・・

686 :デフォルトの名無しさん:02/05/02 15:36
>>685
Haskellと比較しているけど・・・

687 :デフォルトの名無しさん:02/05/02 15:56
>>684
えーと…気分転換に括弧を<>に買えてみるとか
<list 'a 'b 'e>
=><a b e>
なんとなくXMLっぽいかな。

688 :デフォルトの名無しさん:02/05/02 16:00
>>687
なんとなくチョンっぽい。

689 :デフォルトの名無しさん:02/05/02 16:01
藁藁

690 :デフォルトの名無しさん:02/05/02 16:17
>えーと…気分転換に括弧を<>に買えてみるとか
(´ー`)

<`∀´>

691 :デフォルトの名無しさん:02/05/02 18:30
超先生…

692 :デフォルトの名無しさん:02/05/03 11:08
お前ら、形式的仕様記述スレの回し者でございますか…?

99 :98 :02/05/02 13:12
∀といってもこういうの↓じゃないぞ

(・∀・)

100 :デフォルトの名無しさん :02/05/02 13:17
>>98
最近それに見えてしまって困ってるんです(まじ深刻

101 :デフォルトの名無しさん :02/05/02 13:19
(・∀・) (・∃・) (・∧・) (・∨・)

102 :デフォルトの名無しさん :02/05/02 13:20
(゜¬゜)

103 :デフォルトの名無しさん :02/05/02 13:44
>>101-102
やめてくれ、これからそういう記号を扱う講義があるんだから…(笑)


693 :名無しさん@お腹いっぱい。:02/05/07 08:29
職業プログラマだから日々の仕事においてCやC++で仕事をする上で必要な
ことを勉強するわけだけど、それとは別に学問としてのプログラミングも
勉強したい。つまり言語の理論的な根拠とかね。

関数型言語はそういったことを求めるプログラマの期待には応えてくれるもの?
数学の知識(代数、基礎論)はほんの僅かですがあります。

694 :ななし:02/05/07 09:41
>>693
http://www.amazon.co.jp/exec/obidos/ASIN/4000050060/qid=1020731621/sr=1-3/ref=sr_1_2_3/250-3651387-8720210
http://www.amazon.co.jp/exec/obidos/ASIN/4000061909/qid=1020731621/sr=1-4/ref=sr_1_2_4/250-3651387-8720210
http://www.md.chalmers.se/~rjmh/tutorials.html
でどうよ?

695 :名無しさん@お腹いっぱい。:02/05/09 08:36
>>694
ありがとうございます。
とりあえず、「論理とプログラム意味論」を注文しました。
とうちゃっくが楽しみです。

696 :デフォルトの名無しさん:02/05/10 16:41
>>693
http://www.amazon.co.jp/exec/obidos/ASIN/489471163X/ref=sr_aps_d_1_1/250-9503446-8059411
おすすめ。

697 :694だ〜!:02/05/10 22:38
>>694
あ、いい忘れたけど、上の二つはどちらもλ計算バリバリです。
MLも登場します。

ちょっと希望とは違ったかも〜、って時もまた相談してね。

698 :デフォルトの名無しさん:02/05/15 00:50
副作用のないage

699 :デフォルトの名無しさん:02/05/15 01:42
>>691
< `ш´> < 角張った顔が超先生に見えるかニダーに見えるか。それが君の人生を表している。
>>698
上手い。


700 :デフォルトの名無しさん:02/05/15 01:47
頭の中がオブジェクト指向な人は関数型言語を受け入れにくい,
なんてことを言われたのですが,そういうもんですかねぇ

701 :デフォルトの名無しさん:02/05/15 02:31
>>700
そりゃオブジェクト指向は副作用が(ほぼ)必須だから。
オブジェクトって状態のカタマリじゃん。

702 :デフォルトの名無しさん:02/05/15 02:42
関数型にも副作用はありますよ
必須ですよ、ええ

703 :デフォルトの名無しさん:02/05/15 02:57
>>702 は何のことを言ってるかわからんけど(実装の話?)、
OOだと*プログラマにとって*副作用を使いまくるスタイルが自然だろう。
「メッセージを受け取ると内部状態が変わる」というのが
ありがちなOOの計算モデルだから。

704 :デフォルトの名無しさん:02/05/17 18:51
結局、副作用を使わないと何も出来ないということでいいですか?

705 :デフォルトの名無しさん:02/05/17 19:03
参照透明性が確保できれば副作用ありまくりでも、
関数プログラミングとしては何の問題もないような気が・・・

706 :デフォルトの名無しさん:02/05/17 19:07
>>705
どういうこと?
局所的な副作用を含むコードということ?
例を示してみよ。


707 :デフォルトの名無しさん:02/05/17 19:52
>>705
例えばファイルとかにはバンバン書き込むけど
そのファイルを参照(読み出し)できなければ
プログラムの参照透明性は確保できるとか?

708 :デフォルトの名無しさん:02/05/17 22:52
>>707
それは意味がわからない。

709 :デフォルトの名無しさん:02/05/17 22:56
>>707
っていうか、子ね

710 :デフォルトの名無しさん:02/05/17 23:01
>>707の脳は腐っている。不純度100%。

711 :デフォルトの名無しさん:02/05/18 16:54
>>707の脳は透明です

712 :デフォルトの名無しさん:02/05/18 17:00
マジレスしておくと、
 http://www.dcs.ed.ac.uk/home/jrl/

 "When is a functional program not a functional program?"
に、「副作用を使ってても参照透明になるのは、どういう場合か?」
みたいな論文も一応はある。

713 :デフォルトの名無しさん:02/05/18 17:05
マジレスすると
 http://www.dcs.ed.ac.uk/home/jrl/
にある
 "When is a functional program not a functional program?"
は「副作用を使用してる関数が参照透明になるのはどういう場合か」
みたいな論文。そういう研究も一応は存在する。

なんか凍ったので再投稿してるんだが、二重カキコになったらすまん。

714 :デフォルトの名無しさん:02/05/18 17:08
>>711
どうして透明なんだ?
空っぽという意味で透明ということならば納得できるが。

715 :711:02/05/18 17:15
>>714
もちろん空っぽという意味
ネタに解説、カコワルイ>漏れ

716 :名無しさん@Emacs:02/05/18 23:11
>>707
Concurrent Clean のユニークタイプがそんな感じじゃない?
Concurrent Clean に詳しい方いませんか?

717 :デフォルトの名無しさん:02/05/19 00:16
>>716
CLEAN LANGUAGE REPORT VERSION 2.0 Section 9.1: Basic Idea Behind Uniqueness Typingより
> It is guaranteed by the type system that fwritec has private access to the file such that overwriting the file can be done
> without violating the functional semantics of the program. The resulting file is unique as well and can therefore be passed
> as continuation to another call of e.g. fwritec to make further writing possible.

脳ミソが透明だったのは707ではなく
>>708-711 >>714-715 だったようだな。(禿藁

718 :デフォルトの名無しさん:02/05/19 01:12
>>717
訳してくれ。
おれには無理なのでよろしく。

719 :デフォルトの名無しさん:02/05/19 01:27
>>707>>717の内容がどう一致するのか誰か説明してくれ。

720 :デフォルトの名無しさん:02/05/19 01:42
ていうか、例え707が間違ってるとしてもいきなり
連続で罵倒される発言には見えんが。
不自然すぎる。

721 :デフォルトの名無しさん:02/05/19 02:00
>>720=707
ちゃんと説明しる!


722 :720:02/05/19 02:12
>>721
俺は707じゃないが、707の言ってることぐらい説明しなくても
わかるだろ。(ワラ
ファイルを書き込む副作用があっても、参照しないから透明性は
確保されるってことだろ?

723 :デフォルトの名無しさん:02/05/19 02:39
>>720
っつーかさ、最近特に煽りオンリーなアフォが増えてないか?


724 :デフォルトの名無しさん:02/05/19 03:02
>>722
それは何か意味あんのか?

725 :デフォルトの名無しさん:02/05/19 03:55
全く読み出さないというのは極論だが、
ファイルの同一位置に対して
読み → 書き → 読み の順序はダメだが
読み → 書き とか
書き → 読み といった
パターンのアクセスだけであることを保証できれば
参照透明性は確保されてるだろ?

726 :デフォルトの名無しさん:02/05/19 04:01
>>724
意味が無いから問題なんだろ。
意味が無くなってしまうのに>>705はなぜ問題が無いのか、
意味がある別の状況だとしたらどういうことなのか。
こういうことを聞いてるんだろう。

727 :デフォルトの名無しさん:02/05/19 04:32
実際的な意味としては「副作用ありまくり」でも
参照透明に解釈できれば問題ない、ってことでわ。

たとえばモナドやCleanのunique typeはそんな枠組みだな。


728 :デフォルトの名無しさん:02/05/19 04:33
>>723
つーかさ、意味わかってないのに煽り入れて、後で自爆するやつ、増えてる気がする。

729 :デフォルトの名無しさん:02/05/19 12:22
723=728は自作自演か?とかいってみる。

730 :723:02/05/19 12:30
>>729
ちがうよ

731 :デフォルトの名無しさん:02/05/19 20:35
unique typeって何よ?
マイナーな理論出すならちゃんと説明してくれ

732 :デフォルトの名無しさん:02/05/19 20:40
>>731
データオブジェクトへの参照が1つであることが保証された型。
2つの変数から同時に参照しようとするとコンパイラがエラーを出す。
uniqueなベクタなら、破壊的に書き換える実装でも参照透明性は崩れない。

ESP処理系の「1ビットリファレンスカウンタ」とか、linear logicとか
も似てるね。

733 :デフォルトの名無しさん:02/05/19 20:41
>>731
マイナーか?


734 :デフォルトの名無しさん:02/05/19 20:42
>>733
マイナー中のマイナーの、どマイナーです。

735 :731:02/05/19 20:46
>>732
説明ありがとう。
>uniqueなベクタなら、破壊的に書き換える実装でも参照透明性は崩れない。
これどういうこと?
vectorの状態は変わるんでしょ?

736 :デフォルトの名無しさん:02/05/19 20:56
例えば
let (new_vector, old_value) = set_vector(vector, index, new_value)
in <body>
とする。

<body>のなかでvectorはもう参照できない(参照したらエラー)

set_vectorは、概念的には「vectorのうち、index番目だけを
new_valueに書き換えた新たなベクター(と、index番目に入っ
ていた元の値の組)を返す」わけだが、実装としては上書きし
ちゃってもだれも気が付かない。


737 :デフォルトの名無しさん:02/05/19 21:02
>>736
monadの方が、言語の意味論を拡張しないですむので良いかも。

738 :731:02/05/19 21:03
>>736
ああ、言わんとする事がわかりました。


739 :731:02/05/19 21:15
噛み砕いて考えると、他に参照が無ければ関数の値渡し引数を参照渡しに
していいってことかな。

740 :デフォルトの名無しさん:02/05/19 21:22
>>739
意味不明。

741 :739:02/05/19 21:31
>>740
つまりだ、
func_a(structure a) {
 func_b(a);
 print a.value;
}
とかだとfuncは値渡ししないと後のprintで結果が変わる可能性があるけど、
func_a(structure a) {
 print a.value;
 func_b(a);
}
ならfunc_bには参照渡ししても値の変化を気にする必要が無い、
ということを言いたかったの。
これでもだめ?

742 :739:02/05/19 21:37
さらに言うと、>>741の後者は末尾呼び出しなので、
末尾呼び出しは自然とこの性質を持ってることになるよ、ね?
func_aの最初〜func_b呼び出しまでの間なら、
破壊活動を行っても参照透過性は保てると。

743 :デフォルトの名無しさん:02/05/19 21:46
ナンカズレテルキガスル

そういう順序依存のプログラムで参照透明性を気にするんなら
もともとモナドとか使うしかないよね。

それと、参照透明な言語では引数をコピーしてもしなくても
意味は変わらないので、値渡し/参照渡しという区別を言語は
しないと思う。まあ実装としては「ポインタの値渡し」が普通
だろうけど。

744 :デフォルトの名無しさん:02/05/19 22:18
モナドおいしそう

745 :デフォルトの名無しさん:02/05/19 22:42
unique typeは、linear typeのバリアントのようなものだよ。

746 :705:02/05/19 22:48
というか、俺はそういうことが言いたかったんじゃなくて、
関数プログラミングでは、副作用があっては行けない
というようなことが言われていたような感じだったので、
別に参照透明性が確保できれば、副作用の有無は
関数プログラミングにとってはさほどの
問題ではないのではないかと、
実際モナドは、破壊的変更と参照透明性の両立を
目的とした技術であると言えるわけだし。
だから、707のような、
どのような場合に関数は参照透明であり得るかと言う議論は、
微妙に話がずれているのではないかと言うことだよ。
とまあ、思ったわけだ。

747 :デフォルトの名無しさん:02/05/19 23:19
unique typeがマイナーとかいう奴は、
モナドやlinear typeがマイナーだと言っているようなもんだと思うが。
やはりストリームベースが本流か?環境渡し技術なんて邪道か?
それこそ頭空っぽだな。逝って来い。

748 :デフォルトの名無しさん:02/05/19 23:58
>>747
頭がMirandaで止まってる人もいるのですよ。

749 :デフォルトの名無しさん:02/05/20 00:09
>>731が鞭なだけ。

750 :デフォルトの名無しさん:02/05/20 01:16
つーか、uniqueness typingのことをunique typeっていわれても
何のことかわからない人が多かったと思われ…

751 :デフォルトの名無しさん:02/05/20 01:28
>>737 736からするに、言語のOperational Semanticsは変えずに、構文的に
uniqe typeの型チェックができればいいだけでは?

752 :751:02/05/20 01:31
まとめると、モナドは型システムも変更しないで参照透明性が実現
できるが、unique typeだと、型システムは変更するが(Hindley-Milner
からは少しずれるが)、意味論は変えずに参照透明性が実現できる、
ということでよろしいか?

間違っていたらスマソ

753 :デフォルトの名無しさん:02/05/20 01:33
>>750
それは駄目だよ〜ん

754 :デフォルトの名無しさん:02/05/20 01:37
>>750
なんじゃそら…

unique typeを使う型付け体系がuniqueness typingだろ。表裏一体。


755 :デフォルトの名無しさん:02/05/20 01:46
>>751-752
typing systemが違えば当然セマンティクスは違ってくると思うのだが。

あと、参照がuniqueかどうかのチェックは構文的な(文脈自由な)チェッ
クじゃ無理だよ。

756 :デフォルトの名無しさん:02/05/20 01:50
>>752
hindley-milner?

つか、違いは、モナドが黙示的な環境渡し機構なのに対して、
unique type attributeを持つオブジェクトは、
明示的に渡されるっつーことだよ。

757 :デフォルトの名無しさん:02/05/20 06:24
>>755
>あと、参照がuniqueかどうかのチェックは構文的な(文脈自由な)チェッ
>クじゃ無理だよ。

よほど簡単な型システムじゃないかぎり、型がつくプログラムの集合自身
文脈自由じゃないと思われ。心配するな。


758 :デフォルトの名無しさん:02/05/20 13:37
>>752
hindley-milnerではなく、mycroft-milnerを拡張してるんだよ。
似てはいるけど、linear typeそのものではなく、いくつか違う点があるよ。

759 :750:02/05/20 14:22
む、ほんとだ…。俺が無知でしたゴメン

760 :デフォルトの名無しさん:02/05/23 01:31
CleanのObject I/O LibraryをHaskellに移植するというものを
ちょっと見てみた。
Linear typeのようなものを導入するのかと思いきや、
モナドを使っていた。
正直な話、若干無理がある気がしないでもない。

761 :デフォルトの名無しさん:02/05/24 10:36
まあ、無理をしてみて、どんな具合いか調べるわけでしょ?

762 :デフォルトの名無しさん:02/05/24 23:47
モナドはお菓子のホームラン王です

763 :デフォルトの名無しさん:02/05/25 00:30
調べるっつーか、継続するんだとよ。
個人的には、ライブラリそのものの移植はできるとおもうよ。
それはさほど難しくないと思う。
俺が言っているのはそのことではなくて、
Cleanと同様の表現力を持って使えるとは思えないということだよ。

764 :デフォルトの名無しさん:02/05/25 02:24
だから、何が足りなくて、同じ表現力にならないのか研究するわけでしょ?

765 :デフォルトの名無しさん:02/05/25 19:54
表現力というと書きやすさとかそういった主観的な話なのかな。
in-placeで部分書き換えが可能なデータとかならmonadでできる
ように思うのだけど。

766 :デフォルトの名無しさん:02/05/25 22:46
書き易さは主観的な問題なのか?

767 :デフォルトの名無しさん:02/05/25 23:03
表現力というのは、ここでは
参照透明性を壊さない限りでの、
より制限のないオブジェクトへのアクセスということだよ。
そのことは、より高い表現力を担保し得ると思うんだが。
モナドは、正直な話、入出力リソースに対する制限が強すぎる上に、
その制限は、純粋関数型言語にとって
甘受しなければならないものとは思えない。
つまり、制限対利益のバランスが取れてないと言いたいんだが。

768 :KOKUYO:02/05/30 14:10
質問!!
member関数を、第2引数のリストの深いレベルまで
第1引数を探索して取り除くように拡張した関数はどうやって
作ればいいんですか?
あと、二重以上のリストを第一引数として受け取り、
深さ1のリストとして返す関数はどうすればいいんですか?
動作例)(makeflat '(a(b c)((d(e)f)g)h))  
    →(a b c d e f g)

769 :デフォルトの名無しさん:02/05/30 14:30
>>768
まあ、宿題がんばってくれ。心の中で応援してるぞ (藁

770 :デフォルトの名無しさん:02/05/30 15:10
>>768
宿題は自分でやりましょう。

771 :デフォルトの名無しさん:02/05/30 16:58
>>768
flattenで検索すれ

772 :デフォルトの名無しさん:02/06/08 21:39
OcamlとF#誰か日本語化してくれ。

773 :デフォルトの名無しさん:02/06/09 18:27
>>772
F#についてはそのうち俺がやってやろう
期待しないで待っておれ

774 :デフォルトの名無しさん:02/06/10 11:34
comp.lang.functionalより

Apparently, Simon Peyton-Jones asked them to add a tail-call primitive in the virtual
machine language, somehing absolutely necessary for getting an efficient
implementation of any functional languages.
In fact, the many projects that tried to compile an FP to the JVM failed because of the inability to
optimise tail-calls (something your average C-compiler doesn't even do
right) - there were other reasons why the JVM is not an ideal VM for FPs,
but this is a critical issue.

775 :デフォルトの名無しさん:02/06/10 19:42
>>774
糞サンのJVMは末尾再起しないが、
IBMは末尾再起(MSも)する。

IBMを使えばいいのだ。

776 :デフォルトの名無しさん:02/06/10 19:58
javacはともかくとして。

Java VM でtail recursion optimizeできないって、どおゆーこと?
詳しく教えて

777 :776:02/06/10 21:22
よく意味がわからないので、確認してみる。

単純な末尾再帰最適化って、
(1)終了条件満たしてなかったら
(2)引数スタック書き換えて
(3)関数の先頭付近にジャンプ!
だよね。JavaVMでできそう。


778 :デフォルトの名無しさん:02/06/10 22:15
JAVAVMではスタックフレームの再利用ができないという罠。


779 :デフォルトの名無しさん:02/06/10 22:24
なんで?
じゃ、スタックフレームをローカル変数にコピーしてから操作すればいいんでないの?

780 :デフォルトの名無しさん:02/06/10 22:32
>>779
JVMのドキュメントでも読ま!

Simon Peyton-Jones御大がそんな低レベルな事で悩んでると思うなぼ!

781 :デフォルトの名無しさん:02/06/10 22:36
ごめん、大昔JavaVM第一版買ったけど、
読む価値見出せなかったから、
前の職場の本棚で肥やしになってる。

#だって当時の連中って、HotJava α版 とか解析してプログラミングしてたし、
#技術的にはSmalltalkの焼き直しっぽくて、型推論とか検証システムとか面白ソーナ仕組みが一切なかったから
#放置しますた

782 :デフォルトの名無しさん:02/06/10 22:39
ってゆーような、意味不明な言い訳はあっち置いといて、と。

末尾再帰の件は、重箱の隅突っ付くような些細な問題であって、
JavaVMが 関数型言語のVMとして不適であるのには別な理由があるって書いてるね。
原文どこ?

783 :デフォルトの名無しさん:02/06/10 22:49
しらん。
フライブルグ大学の奴がcomp.lang.functionalで
書き込んだ内容をコピペしただけ。

784 :デフォルトの名無しさん:02/06/10 22:56
ちぃっと話題がずれるけど。

世間知らずだった昔は、
comp.*  読むに値する学術スレ
alt.*  コピペ嵐、AA嵐が跳梁跋扈する2ちゃんのような玉石混合のスレ
とか思ってたけど、comp も以外と糞っすね。

785 :デフォルトの名無しさん:02/06/10 23:06
comp.lang.functionalも同じような話題を繰り(以下略

786 :デフォルトの名無しさん:02/06/10 23:14
向こうには、「FAQを嫁」とか逝って怒り出すオジ^H^Hオニイサンが居ると思われ

787 :デフォルトの名無しさん:02/06/11 00:05
AVAYAはよくみるな〜
Wadler? と思ってしまう私

788 :デフォルトの名無しさん:02/06/11 13:37
Unfortunately, tail-call primitive interacts badly with the the
stack-inspection based security model.

See
http://research.microsoft.com/~adg/Publications/details.htm#stack-inspection

Personally, I think the need to do tail call optimizations is a bit
overrated. There are a few examples where you absolutely need it, but most
of the time I'm happy to just write a while loop, or only have a local set of
mutually recursive functions turned into gotos.

789 :デフォルトの名無しさん:02/06/11 14:36
comp.lang.functionalを初めて見たけど、
'vs'とかいう単語がいきなり目に飛び込んできて、
あー、どこも変わらないんだなってオモイマスタ。

790 :デフォルトの名無しさん:02/06/11 15:26
武田騎馬軍団vs関数型言語

791 :デフォルトの名無しさん:02/06/11 21:24
>>788
はいはい、
JavaVMにはセキュリティ検証ってゆう
検証システムがあるのが特徴でしたね.
んで、スタック使わないtail recursion は
本来意図したセキュリティ検証を実行できないからだめ、
って、本当にセキュリティホールになるのかー?

JavaVMで実現不可能なtail recursion が本当に必要なレアケースって、
なんでしょね?(複数のtail recursion 可能な関数を混合した再帰呼び出し?)

792 :デフォルトの名無しさん:02/06/14 00:21
lexerとかオートマトンとか。(同じだけど)>791

793 :デフォルトの名無しさん:02/06/15 23:15
投資家切込隊長が、
パソコン業界が発展するには
もはや演算能力を上げるだけでは駄目で、
フォンノイマン型を脱するような
ブレークスルーが必要だといっていた。

ということで、関数型言語age

794 :デフォルトの名無しさん:02/06/15 23:26
> 投資家切込隊長

誰?

795 :デフォルトの名無しさん:02/06/15 23:33
関数型言語だと、フォンノイマン型を脱するのか?


796 :デフォルトの名無しさん:02/06/15 23:55
昔、九大の人がデータフロー計算機上で、関数型言語の実装の研究してたね。

797 :デフォルトの名無しさん:02/06/16 00:39
>>794
知らないならいい

798 :デフォルトの名無しさん:02/06/16 01:02
>>793
 そいつ、10年前にパソコン用拡張ボードで、
 Lispボードとかニューラルネットワーク・ボードとか、ニューロファジー・ボードとか
 出てたのを知らないんだろう.
 #俺はニューロ・ファジーやってた会社2社ほど会社訪問ったっけ。なつかしー
>>794
 このスレの>>1だろ
 http://science.2ch.net/test/read.cgi/infosys/1007295778/l50
>>796
 すげー興味あり。情報きぼん
 #出世魚プロジェクトとか、おもろいネタプロジェクトが多いな

799 :デフォルトの名無しさん:02/06/16 02:31
>>793
>フォンノイマン型を脱するような
>ブレークスルーが必要だといっていた。

それくらいのことはどこのDQNでも言えるという罠

800 :デフォルトの名無しさん:02/06/16 12:43
そーいや DSPも非ノイマン系。
ついでに言うと、DSPも10年以上前は日本優位だったらしーが、
国内半導体メーカの失策等で劣位になったとかならないとか。

凍死家さんはバイオ・インフォマティックにでも闘志して下さい

801 :デフォルトの名無しさん:02/06/16 14:23
801ゲトー

802 :デフォルトの名無しさん:02/06/16 14:54
10年前と今を比較するには若干の無理が(以下略

803 :デフォルトの名無しさん:02/06/16 16:28
自分は門外漢ですが、最近関数型言語を使い始めて思ったことです。
高速化を狙うなら関数型言語は良いと思います。

最近メモリーや演算回路はどんどん高速化していますが、データを要求してから
レスポンスが帰ってくるまでのターンアラウンドタイムが伸びがちです。

メモリーはランバス等の登場で転送速度自体は高速化していますが、
反面、データリクエストに必要な時間は複雑な回路を動作するため時間が非常に
かかります。
演算回路も動作クロックが高速化していますが、パイプライン段数は大きくなる一方です。

多分回路間の距離の問題だとおもうのですが、言えることは

小さい回路の高速化は簡単
データ転送量は大きくしやすい
ターンアラウンドタイムは縮まらない
これらは物理的問題と思われるため悪化しても改善しない

こういう状況では OOPL は、ものすごく不利です。
たとえば、OOPL の特徴のひとつで、オブジェクトの参照を駆使しますが、
参照というのは非常に小さいデータで、さらに参照先のメンバ変数を参照する
などということをしようものなら、CPUはひたすら小さなメモリーリクエストばかりと
いうことになります。
これではまるで、ダンプにうまい棒一本のせて右往左往するようなもので、
コンピュータの高速化の恩恵は期待できません。

また、深いパイプラインは分岐に非常に弱いです、メソッドを呼び出しまくると
実行時は分岐だらけです。

反面、関数型言語では、大きなデータのコピーが可能だと楽になる。
深いパイプラインには命令スケジュールが必須だが、それに必要な計算依存関係が
明白なプログラミングスタイルである。

そういうわけで、現在のプロセッサでも関数型を高速化に使うのは悪くないと思います。
その延長線上に非ノイマン型があってもいいんじゃないかなと思います。

これからの言語の方向性として関数型言語のライブラリとしてOOPサポートライブラリを入れるのが良いのではと思っています。

そんな訳で、関数型のメリットはだんだんと大きくなってきていると思う今日この頃です。
C言語的な利用目的の現代的な置き換えができないかと思ってたりします。




804 :デフォルトの名無しさん:02/06/16 21:14
>>803
10点/100点くらい

805 :デフォルトの名無しさん:02/06/16 22:05
>>804
採点基準を示せ

806 :デフォルトの名無しさん:02/06/16 22:23
>>803
確かに、エンベデットやシステム記述の方面にも
関数型言語を使えるようにしようとしている動きもあるよ。

807 :デフォルトの名無しさん:02/06/22 01:00
>>802-803
意味不明なので、省略せずわかるように説明して下さい
つうか、説明するのが面倒なら、レス付けない方がマシ

と煽りに煽りを入れるテスト


808 :デフォルトの名無しさん:02/06/22 02:59
>>807
802 はともかく 803については、どこが意味不明なのか書いてみたら?
一通り説明になっていると思うが・・・

809 :デフォルトの名無しさん:02/06/22 09:58
>>803
条件分岐がパイプラインを詰まらせるって、
関数型言語を実行しても分岐だらけに変わりないだろ。
その関数型言語のソースコードレベルに「if」があまり直接出ないだけで、
機械語レベルでは条件分岐だらけだと思うが。

810 :807:02/06/22 10:54
>>808
 >>803は、
 「関数型言語だと静的解析が容易だから、
  投機的実行を含む、CPUパイプラインのスケジューリングが容易、
  だから今時のCPUは関数型言語に向いている(コンパイラーを作成しやすい)」
 ってなニュアンスかな。
 で、詳細に検討しようとすると、例えば >>809 みたいな疑問/反論が出る、と。

>>806
 面白そうな話題ですね。Embedded UML & OCL でしょうか?

811 :デフォルトの名無しさん:02/06/22 11:12
条件分岐はパイプラインを詰まらせるのではなくて壊すが正解
パイプラインが詰まる原因はスケジューリングが難しいケースに起こるが正解
だと思う
803 の言いたいことは参照透明が維持されていれば、
その先のことを考えなくても済むので、スケジューリングをするときの障害が少ないと言う事では?


812 :デフォルトの名無しさん:02/06/23 16:50
>条件分岐がパイプラインを詰まらせるって、
>条件分岐はパイプラインを詰まらせるのではなくて壊すが正解
ちなみに分岐は条件分岐ではなく、無条件分岐のことをいっていました。
確かに、説明不的確ではあります。
さらに、パイプラインが詰まることと分岐とは別問題です(まったくという訳ではないのですが・・・)。
あと説明中の OOPL が良くないですね、別に OOPL に限った事ではなく
「手続き型」と「関数型」の違い・・・ひょっとしたら「手続き型」と「それ以外」
かもしれませんが・・・

シンプルに説明しますと、

スケジューリングするとは、式の評価順序を入れ替える

というです。

手続き型では、例えばメソッドはプログラムの「評価されるにしかるべき行にあること」が重要な訳です。
ここで「評価順序を入れ替」に対して「評価されるにしかるべき行にある」はお互いに相反する事です。
関数型では、評価結果が次の評価に必要になる前ならばどこにあっても良いのです。
だから、制限付きながらも「評価順序を入れ替」を許容するわけです。
「評価順序を入れ替」が可能なら、スケジューリングも可能ということになります。
「手続き型」では入れ替えしても問題ないものを無理矢理探し出す作業が出てくるわけですが、そんなものはそれほど巧くいくわけもないのは道理たと感じています。

>その関数型言語のソースコードレベルに「if」があまり直接出ないだけで、
>機械語レベルでは条件分岐だらけだと思うが。
これは実装次第です、コンパイラ屋の気合次第です。(^^;
ちなみに僕は条件選択よりも、高階関数が嫌いです。
高階関数にも良い方法があるらしいのですが、まだ調べていません。


813 :デフォルトの名無しさん:02/06/25 13:40
それは関数型言語が
並行処理に適合しているということにも繋がりますかね?

814 :デフォルトの名無しさん:02/06/25 14:08
ベータ簡約だっけ?

815 ::02/06/25 16:57
この問題を教えて下さい
3×3行列Aに対し
1,Aを読み込みAの行列式を出力
2,Bを読み込みA×Bを出力
3,|A|≠0の時のA^-1を出力


816 :デフォルトの名無しさん:02/06/25 19:04
>>815
ふぅ。宿題は自分でやれ。

817 :デフォルトの名無しさん:02/06/26 00:35
みんな! tail recursionとtail-call optimizationを混同しちゃ駄目だ!!
tail recursionはtail-call optimizationの特殊な場合にすぎなくて、
(相互再帰は駄目だけど単独再帰なら)JVMでもgotoで簡単に実装できるし、
stack inspectionの問題もないはずだ!!!

亀レス&もし既出だったらスマソ

818 :デフォルトの名無しさん:02/07/01 11:50
素朴な疑問で恐縮なんだが、
VMで実装することになんか意味あんの?
だいいち使うのか?
あんまりすごさを感じないんだよね。

819 :デフォルトの名無しさん:02/07/02 00:17
インタプリタ型言語に多少メリットがあるんじゃないかな?
多様な言語->共通言語->機械語の形態で
各種コンパイラ言語 -> C -> 機械語
によって各種機種依存から逃れるという目的の流れが
JAVAその他インタプリタ言語 -> JAVAVM -> 機械語(なんかちょっとずれている気もする)
に変わった方がインタプリタには都合が良いということでは?
よく言われるマシンアーキテクチャの共通化とかいう旗印はCに出来なかった以上JAVAVMにも不可能と見た。
考え方は時代の違いくらいだしね・・・


820 :デフォルトの名無しさん:02/07/03 09:47
個人的には、あの重さにいまいちなじめない。
インタプリタ:遅いけど手軽
コンパイラ:コンパイル作業あるけど、速い
って言う発想になじんじゃってるから、
コンパイル作業あるし、速さもたいしたことない
っていうのには抵抗感あるよ

821 :デフォルトの名無しさん:02/07/14 19:43
>>812
パターンマッチなんてifだらけだよ.

822 :デフォルトの名無しさん:02/07/14 19:49
インタプリタ: 遅いが簡単
コンパイラ: 速いが面倒
なんとかならないの?

そんなあなたに partial evaluation (w

823 :デフォルトの名無しさん:02/07/15 16:58
>>821
そういうレスはなんか意味があるのか?

824 :デフォルトの名無しさん:02/07/16 22:58
dat落ち防止age

825 :デフォルトの名無しさん:02/07/21 15:29
SML/NJなら(対話的環境という意味で)インタプリタで、かつ
実行する瞬間にコンパイルもしてくれるが、どうよ?

826 :デフォルトの名無しさん:02/07/22 13:04
それはVMの話とは関係にゃーでよ

827 :デフォルトの名無しさん:02/07/27 00:31
何とはなしにageてみる

828 :デフォルトの名無しさん:02/07/28 08:36
.


829 :デフォルトの名無しさん:02/07/28 12:31
>>176
初学者です。
「代入をしない」で初期設定ファイルから初期設定ができるん
ですか?
Schemeでは下の様にすると代入してます。さらにdataを
変数に代入しないとプログラミングなんてできないと思うの
ですが。
(define data (call-with-input-file "./data.db" read))

830 :デフォルトの名無しさん:02/07/28 12:46
>>829
はあ、普通に束縛するだけで破壊代入する必要はないと思うけど…
何となく「代入しない」を勘違いしてるように見えます。
まずは関数型言語の入門書でも読んでみたらどうでしょ?

お勧めとしては武市先生の「関数プログラミング」が入門者向けでかつ分量もたいしたことない。
その本が手に入らなければ、MLの入門書はいろいろ出てるみたいだから読んでみたら?

831 :デフォルトの名無しさん:02/07/29 09:38
「環境の中に入ってしまう」という感覚が
わからないと難しいと思われ

はぎゃ先生のほうの「関数プログラミング」の
ほうがいいかも。


832 :デフォルトの名無しさん:02/07/29 09:54
>>829
・変数の出現と同時に値の「代入」を行なう。(未定義の値を排除)
・「代入」は一度だけしか行なわれない。(値が変わらない)
という考え方です。(変数の生存期間中値が変わらない)

そして、関数型言語の人たちはこれを「代入」とは呼びません。
C言語の人たちも「定義」と呼んでいます。

833 :C言語のひと:02/07/29 11:01
「初期化」と呼んでいます。

834 :デフォルトの名無しさん:02/07/30 02:20
>>832
schemeの場合は同ブロックの既存の変数を上書きdefineした場合、
古い値は永遠に参照できなくなるから、意味的には完全に「代入」。
つーか、環境書き換えるってことはシンボルの意味が変わるってこと。
関数型の視点からみると、ネストされたletが>>832のそれに当たると思う。
またはlambdaのネスト。

835 :デフォルトの名無しさん:02/07/30 08:53
>>834
LISP系やScheme系が「代入」を持っているのはその通りだが、
ラムダ束縛が「代入」に相当するとは思わない。

836 :デフォルトの名無しさん:02/07/31 04:48
>>834
define で変わるのって、 symbol に対応する address とか…だよね。
普通の意味での「代入」って、 set! とかの方だと思う。
define だと…例えば、既存の closure からは、古い値が見えるから。

837 :石敢當:02/08/02 22:29
ICFP Programming Contest のページができました。

http://icfpcontest.cse.ogi.edu/


838 :デフォルトの名無しさん:02/08/12 22:22
 別の板で下のようなのがありました。関数型でドンピシャなのって
ありますか?
 Cleanなんて近そうですが・・

>質問
(1) >UnixとWindowsで使えて
(2) >GUIと日本語(出来ればUTF8がいいな)が使えて
(3) >GPLじゃないバイナリがつくれて
>ありますか?

839 :デフォルトの名無しさん:02/08/12 22:38
つーかマルチだろ。

840 :デフォルトの名無しさん:02/08/12 23:37
>例えば、既存の closure からは、古い値が見えるから。
名前でアクセスすりゃ見えねえよ

841 :LISPスレ 686:02/08/13 13:25
>>839
失敬な。>>838 は私ではありません。誰か別の人です。
とは言え、Scheme に限らずとも知りたくはありますね。

842 :デフォルトの名無しさん:02/08/14 00:07
>>838
Gaucheはどうよ。GaucheはSchemeの一実装。
次のバージョンでGUI対応。いつ出るのかは不明。

843 :デフォルトの名無しさん:02/08/14 00:17
OCaml

844 :デフォルトの名無しさん:02/08/14 23:16
Gaucheはインタプリタ・・・
バイナリ作れるのか・・・?
というか、目的ちがくないか・・・?

845 :デフォルトの名無しさん:02/08/14 23:18
おれの!

schemeは!

バイナリ作れるにょー

846 :コギャルとHな出会い:02/08/14 23:19
http://kado7.ug.to/net/


朝までから騒ぎ!!
   小中高生
 コギャル〜熟女まで
   メル友
  i/j/PC/対応

女性の子もたくさん来てね
  小中高生大歓迎です                 
全国デ−トスポット情報も有ります。
全国エステ&ネイル情報あります。

  激安携帯情報あります。

847 :デフォルトの名無しさん:02/08/15 13:12
OCamlって、
Win版だと、VCが無いといけないのか?

848 :あげ:02/08/15 20:59
>>847
cygwin版もあるょ

849 :デフォルトの名無しさん:02/08/16 03:30
ょ、ってまさか・・・

850 :デフォルトの名無しさん:02/08/16 05:12
半導体チップ設計で最大手(だと思う)のCadence社
のある設計ツールのスクリプト言語がSKILL++というので、
Schemeだった.manualにも
Cadence-supplied Scheme called SKILL++
とか
SKILL++ is designed with IEEE Scheme and CFI Scheme compliance in mind,
とか書いてある.ファイルを見たら括弧だらけでびびった.
なんでSchemeだったんだろう.
(1)たまたまそのツールを作るチームでSchemeが好きなやつがいた.
(2)Schemeをスクリプト言語とすると半導体チップが非常に協力に
  設計が出来る何かしらの理由がある.
もし(2)なら是非知りたいものだ.
そんだけ.

851 :デフォルトの名無しさん:02/08/16 07:12
>>850
(3)MIT出身者がいるとか(w
アプリケーションの補助スクリプトとしてLISP系を選ぶ利点は
emacsやAutoCADとかで証明されてると思うけど、わざわざ
CommonLISP互換にしたり、オリジナルな独自LISPを一から設計
するよりは、お手軽にschemeを使った方が良いと判断された、
ってこともあるんでは。schemeなら機能的に不足は無いし。
メジャーなLISP系としては仕様が一番軽いし、組みこみでも実績あるし。
使う側からすれば、分厚いマニュアルを読まなくても良いに越したことはない。

852 :デフォルトの名無しさん:02/08/16 07:26
逆にschemeのデメリットってなんでしょうか?

853 :デフォルトの名無しさん:02/08/16 07:34
ライブラリが少ない。


854 :デフォルトの名無しさん:02/08/16 09:42
あとは?

855 :デフォルトの名無しさん:02/08/16 09:50
わかる人が少ない。
「普通のやつらの上を逝け」には競争相手が知らないことは逆にメリット
だみたいな感じに書いてあった、、気がする。

856 :デフォルトの名無しさん:02/08/16 09:53
LISPがメジャーになったら、それはそれで嫌だぞ。オレは。

857 :デフォルトの名無しさん:02/08/16 09:59
>>856
何で?

858 :デフォルトの名無しさん:02/08/16 10:01
>>857
想像力が無いな。
例えば、もしも2ちゃんに「LISP板」が立ったら、を考えてみろ。

859 :not 857:02/08/16 11:21
>>858
別に良いんじゃないの

860 :デフォルトの名無しさん:02/08/16 12:04
>>858
「C板」すらないのに、そんな心配いらねーよ!

861 :デフォルトの名無しさん:02/08/16 13:33
>>851
ああ、(3)が一番しっくり来る.それだ.
たしかに関数型言語でOCamelとかじゃなくてschemeを選ぶというのは
分かるのですが、
関数型言語を選ぶというのは(AutoCADなどで実証されたとありますが)
なぜなんでしょう?アプリのカスタマイズ用スクリプトはやることが決まっている(emacsはいろいろできるけど)から、ライブラリの
少なさが問題にならない、とか?たしかにAutoCADなら文字列操作や
ネットワークやらの操作をするための部品をあらかじめ用意しておかなくても
全然OKなわけで.

そういえばGIMPもそうですな.(AutoCADがそうだったというのは初めて
知りました.)

862 :デフォルトの名無しさん:02/08/16 16:58
>>852
括弧の多さが可読性を低下させている

863 :デフォルトの名無しさん:02/08/16 17:33
なんでみなさん、gccに対するプラグインという形ではなく、一から
コンパイラを作りたがるんでしょうか?こんなんだからいつまでたっても
メジャーな処理系が出てこないと思うんだけど。

864 :デフォルトの名無しさん:02/08/16 17:35
>弟子が尋ねた。「先生、私は先生がカッコをまるで魔術師の ように扱ってい
>るのを常々敬服しています。どうすれば先生のようになれ るのでしょうか?」
>師「えっ? カッコ? あ、そうか。そんなものもあったな。いやあ、 すっかり
>忘れておったわ」


865 :デフォルトの名無しさん:02/08/16 18:13
>>864
んなこといってるから、メジャーにならないという罠。

866 :デフォルトの名無しさん:02/08/16 20:17
セミコロンがセパレータだったりターミネータだったりよくわからなかったり、
省略可能だったり、とか考えると、すんげー単純でイイ、と思うけど > 括弧

>>863 gcc のフロントエンドにコレ系の言語を載せるには、
gcc というフレームワークと gcc のバックエンドには荷が
重いと思われ。


867 :デフォルトの名無しさん:02/08/16 21:00
>>858
car板とcdr板は立ったから、あともう一息。

868 :デフォルトの名無しさん:02/08/16 22:25
じゃあ次はcons板で。

869 :デフォルトの名無しさん:02/08/17 00:08
gccってコンパイラとして使われてる技術は古いよね

870 :デフォルトの名無しさん:02/08/17 00:37
それらに加えてatom板とeq板が立ったら
五色不動の完成だな。

871 :デフォルトの名無しさん:02/08/17 13:23
>>869
最新のコンパイラ技術とはどんなのですか?
たしかにgccの実装技術に関する参照論文は古いのが多いですが。。。

872 :デフォルトの名無しさん:02/08/17 14:40
>>861
構文が基本的に()だけで済むっていうのは
補助言語としては使いやすくていいのでは。
()の上に構築される文法は仕様が基本的にかっちりとあるわけだし。
Lisp知らない人が多いのが問題だとは思うが‥
(GIMPの script-fu も確かにそうですね)

873 :デフォルトの名無しさん:02/08/17 14:41
MIT出身者ワラタ。(笑)

874 :デフォルトの名無しさん:02/08/18 03:33
MITってなに?マサチューセッツのMITですか?

875 :デフォルトの名無しさん:02/08/18 11:53
>>863
関数型言語の有名人を集めたMSがどんな仕事をしてくれるのか
とくと拝見させて頂きましょう。また先生方の実務能力も。
そして我々GNUツール大好き人間はその成果を頂くと。。。

876 :デフォルトの名無しさん:02/08/18 12:46
>>875 MSR の成果が単純に MS に行くわけじゃない。
例えばラシッド先生とかさ。知らない?

先生方の能力はghcがバンバンバージョンupしとることと
バンバン論文が出とることで証明済みと思う。C# が c--
だったらなぁ、とは思ったけど。

>>874 Wizard Book が Scheme 本としても MIT の
教科書としても有名ですが何か

877 :デフォルトの名無しさん:02/08/18 12:55
>>874
武蔵工大じゃねぇの?

878 :デフォルトの名無しさん:02/08/18 13:21
>>876
ghcって、Glasgow Haskell Compiler?

879 :デフォルトの名無しさん:02/08/18 16:13
だからghcはあんなにパフォーマンス悪いんだな

ナットク

880 :デフォルトの名無しさん:02/08/18 18:31
実務能力ってコーディングすることなのか?

881 :デフォルトの名無しさん:02/08/25 20:53
最近元気ないね。どうしたの?

882 :デフォルトの名無しさん:02/08/26 00:07
夏バテ

883 :デフォルトの名無しさん:02/08/27 02:43
>>862
括弧の多さは可読性低下には繋がらない。
慣れだよ。

884 :デフォルトの名無しさん:02/08/27 02:52
>>883
繋がるよ。括弧に頼ってインデントが減る傾向にあるから。
お手本とされるプログラムでも、大抵はCより減ってる。

それに、インデントがもっとあっても、他の言語よりは、慣れるまで
に少し時間を要する。

885 :デフォルトの名無しさん:02/08/27 02:54
あと、Cは、()と{}と何もなしと、ただのインデントの四種類によって、
ネスト関係が一目でわかりやすい。括弧が一種類しかないLispよりも。

886 :デフォルトの名無しさん:02/08/27 03:10
CでLispのように{}を使いまくったプログラムは書いちゃいけないの?

887 :デフォルトの名無しさん:02/08/27 03:29
いけないの

888 :デフォルトの名無しさん:02/08/27 08:15
()ばかり使わないで[とか]も使えよ。
もっとも初心者には余計読み難くなるけどな。

889 :デフォルトの名無しさん:02/08/30 13:00
>>884
> 繋がるよ。括弧に頼ってインデントが減る傾向にあるから。

具定例を挙げてみてくれ。
インデントが減るだけでなく、可読性も減ると貴方が思う例を。


890 :既出か?:02/09/03 03:33
プログラミング言語の概念と構造[新装版]
http://www.pearsoned.co.jp/washo/prog/wa_pro59-j.html

>本書は、アジソン・ウェスレイ発行/星雲社発売で1996年に発行された、Ravi Sethi著『Programming Languages』の
>初版の翻訳です。品切れになっていたものですが、、このたび新装版として発行しました。したがって、内容
>には変更がありません。


うれしぃぃぃぃぃいぃぃxぃぃぃぃぃぃーーーーーーーーーーー。

891 :デフォルトの名無しさん:02/09/03 03:39
日本語版チラリと見て、
これは買わなくてヨシと思いつつ、
原書の方は買ちゃた覚えが(汗だく

892 :デフォルトの名無しさん:02/09/03 03:40
こっちではまだ見れない。
http://www.amazon.co.jp/exec/obidos/ASIN/4894717700/

893 :デフォルトの名無しさん:02/09/03 09:17
関数型言語を勉強するときはまったく新しいことを勉強するつもりで
英語オンリーでやるのが良さそう。日本語文献はいいのが少ないからね。

894 :デフォルトの名無しさん:02/09/03 09:36
http://japan.cnet.com/Enterprise/News/2002/Item/020902-3.html

895 :デフォルトの名無しさん:02/09/03 11:34
つかよ、新装版じゃなくて、
第2版翻訳しろよ。

896 :デフォルトの名無しさん:02/09/08 00:50
>>893
よくある発想だが、
それに頓挫するのもよくあることだ。

897 :美しい:02/09/09 21:38
美しいわ

898 :デフォルトの名無しさん:02/09/10 19:09
>>896
英和辞書引いても、今度はその日本語の用語を理解しないと
いけないからね。Cができる人がJavaを覚えるのとはちょっと違う。
数学辞典の英訳書があると何かと便利かな。

899 :デフォルトの名無しさん:02/09/11 13:03
関数型言語は、HPCに向いてるのか?

900 :デフォルトの名無しさん:02/09/13 15:09
>>899
研究費をもらってくるための旗印としては、
データフロー記述だから並列実行に適しており云々
とかいうあたりがありがちかな

901 :デフォルトの名無しさん:02/09/13 17:10
ぐぐればたくさんでてきそうだにゃ〜

902 :デフォルトの名無しさん:02/09/14 10:59
HPCって何?

903 :デフォルトの名無しさん:02/09/14 13:42
High Performance Computing
http://www.dcs.qmul.ac.uk/SEL-HPC/Articles/HpcArchive.html
http://www.dcs.qmul.ac.uk/SEL-HPC/Articles/GeneratedHtml/hpc.functional.html

904 :デフォルトの名無しさん:02/09/27 21:07
ホシュ

905 :デフォルトの名無しさん:02/10/06 20:31
C++プログラマのためのラムダ入門
http://www.sun-inet.or.jp/~yaneurao/intensive/spt1.html

906 :デフォルトの名無しさん:02/10/07 13:32
つかな、そう言うのって微妙に話が違うんだよな。

907 :名無しさん@Emacs:02/10/08 00:07
>>905
「C++プログラマのためのHaskell入門」とか、正面から入門してちゃんと習得
できるようなアプローチだったらいいのだけれど、C++な頭脳のままで理解で
きるところだけつまみぐいしようとすると結局
「よくわからん」や「それって**で済むじゃん」とかいうもったいない結論
になってしまう罠。


908 :デフォルトの名無しさん:02/10/09 18:54
Yutaka Oiwa, Eijiro Sumii, and Tatsurou Sekiguchi

この人らはどこの学校の人?
俺学会はよく知らないんで、教えて欲しいんだが。

909 :デフォルトの名無しさん:02/10/09 18:59
ストーカー?

910 :デフォルトの名無しさん:02/10/09 19:00
いや、そんなんじゃなく真面目に。

911 :デフォルトの名無しさん:02/10/09 19:02
http://web.yl.is.s.u-tokyo.ac.jp/~oiwa/ja_JP.ISO-2022-JP/
東大の院生のよう。

912 :デフォルトの名無しさん:02/10/09 19:04
愚グルで調べた。
みんな東大だった。
なーる。

913 :デフォルトの名無しさん:02/10/09 19:05
つーか、この人ら何かしたの?

914 :デフォルトの名無しさん:02/10/09 19:07
http://icfpcontest.cse.ogi.edu/

915 :デフォルトの名無しさん:02/10/09 19:21
今年はpain of c++チームは出なかったのか。。。

916 :デフォルトの名無しさん:02/10/10 01:20
ABCLあげ

917 :デフォルトの名無しさん:02/10/10 02:01
米澤圏大活躍

918 :デフォルトの名無しさん:02/10/10 02:02
関数言語じゃないだろうが

919 :デフォルトの名無しさん:02/10/10 07:54
がんがれ武市圏

920 :デフォルトの名無しさん:02/10/11 03:53
ふっへっ
ふっへっ

921 :デフォルトの名無しさん:02/10/13 09:00
lisp schemeスレで、lambdaだけのループ制御が話題になってますが、
これって、λだけでループが組めるという証明になるんでしょうか?
(schemeのdefine,set!に該当するものを使わずに、)
MLとかHaskellでも同じ様なのが作れるんでしょうか。

922 :デフォルトの名無しさん:02/10/13 09:41
/.Jになにやらスレが。


923 :デフォルトの名無しさん:02/10/13 10:26
ガイシュツ

924 :デフォルトの名無しさん:02/10/13 11:31
昼から用事があった。

925 :デフォルトの名無しさん:02/10/13 16:16
>>921
そりゃそうでしょ.
理論的に再帰でループは書けるがループで再帰は書けない.
もちろん効率は別ね.

926 :デフォルトの名無しさん:02/10/13 16:37
しったかはけーそ

927 :デフォルトの名無しさん:02/10/13 16:52
じゃぁ、スタックマシンがハードウェアで提供されてなかった時代に
Lispで再帰書くのも無理だったんだろうね。

928 :デフォルトの名無しさん:02/10/13 16:56
Lispは、1950年代に再帰型FORTRAN上に実装されますた(ワラ

929 :デフォルトの名無しさん:02/10/13 16:57
なんてことないない

930 :デフォルトの名無しさん:02/10/14 06:39
>>921
haskellは末尾再帰対応してないから無理。
MLは可能っぽいけど、構文的に書けるか不明。

931 :デフォルトの名無しさん:02/10/14 09:44
つか既出

932 :デフォルトの名無しさん:02/10/14 19:32
?

933 :デフォルトの名無しさん:02/10/15 09:14
>>930
?????どゆこと?????

934 :デフォルトの名無しさん:02/10/15 09:24
キシュツ

935 :デフォルトの名無しさん:02/10/15 21:54
つまり概出ってこと?

936 :デフォルトの名無しさん:02/10/15 22:16
>>921 ttp://www.ececs.uc.edu/~franco/C511/html/Scheme/ycomb.html


937 :デフォルトの名無しさん:02/10/16 10:07
なにが既出?
ちゃんと日本語しゃべれ

938 : :02/10/17 00:15
対応してないわけ無いだろう。
下らんこと引っ張るな。

939 :デフォルトの名無しさん:02/10/17 11:44
MLで書くとどうなるの?

940 :名無しさん@Emacs:02/10/18 14:36
2ch最古(と思われる)λスレ
http://piza.2ch.net/log/prog/kako/935/935986860.html

941 :デフォルトの名無しさん:02/10/31 16:09
http://www.cs.nott.ac.uk/~gmh//faq.html
結局どれにすればいいんだ?

942 : :02/10/31 19:31
>>941
Mercuryにしてください。

943 : :02/10/31 21:52
Win版が、cygwinか.NETというのが減点対象

944 :デフォルトの名無しさん:02/11/01 03:07
http://www.is.titech.ac.jp/~kando9/work/Progress/TypeSystem/OverLoading.html
Hindeley/Milner型システムというものに関心があるのですが、
なにかよい文献はありますでしょうか?日本語じゃないかな。

945 :デフォルトの名無しさん:02/11/01 03:24
>>944
卒研リンク(泣)....

型推論の説明してる本だったら、
必ず触れてる話だと思うよ。

例えば岩波の本。

946 :デフォルトの名無しさん:02/11/01 03:34
>>945
え”ご本人さんですか?それはすみませんでした。。。
悪意があったわけではないのでお許しを。m(  )m

明日本屋さんでざっくり見てきます。それにしても
日本語でこういったネタを扱ってるサイトって少ないですね。

947 : :02/11/01 13:21
OOP vs. FPの話がcomp.lang.functionalで盛り上がっているのは何故?

948 :デフォルトの名無しさん:02/11/01 14:01
ちょろっと見たけどあんまりおもしろくはないですねえ

949 :デフォルトの名無しさん:02/11/01 23:43
型付きλって何なの?

950 :デフォルトの名無しさん:02/11/01 23:48
何といわれても。
どの程度の知識を前提に説明すればよいのやら。

951 : :02/11/02 01:04
>>949
ftp://ftp.cs.kun.nl/pub/CompMath.Found/HBKJ.ps.Z

Lambda Calculi with Types

952 :デフォルトの名無しさん:02/11/02 02:54
これってプログラミング言語でいう「型」とは意味違う?

953 : :02/11/02 15:00
ちみのいうところの、「プログラミング言語でいう型」とはなんぞや?

954 :デフォルトの名無しさん:02/11/02 18:32
952じゃないけど、
>>953
データの集合。あるデータxが型tとは、x∈tのこと。通常、型t1,t2には重なりがないが、継承などを考えて重なりをもたせることもある。
代数で言えばsort。

この観点からどう答えますか?

955 :デフォルトの名無しさん:02/11/03 00:44
さあ。

956 :デフォルトの名無しさん:02/11/03 06:33
関数型言語ファンなら Curry-Howard isomorphism くらいは
ウンチクとして知っておいた方が良いと思われ
しばしばMLが利用される問題の例だし


957 :デフォルトの名無しさん:02/11/03 07:53
>>956
恥ずかしい奴だ。
聞きかじりの知識を、そーゆー言い方で自慢する奴を見ると、反吐がでる

958 :デフォルトの名無しさん:02/11/03 07:54
>しばしばMLが利用される問題の例だし
聞いた事ありまへんなー。
例きぼんぬ

959 :デフォルトの名無しさん:02/11/03 09:03
>>957
気に障ったようで申し訳ない
>>958
例えばこんなんとか
ttp://www.csse.monash.edu.au/~jnc/Cwrapper.ps
卒論くらいで似たようなことをさせる人はいるんじゃないかな


960 :デフォルトの名無しさん:02/11/03 11:36
卒業研究かよっ!

961 :デフォルトの名無しさん:02/11/03 11:37
そろそろ次スレですか?

962 :デフォルトの名無しさん:02/11/03 11:55
>>956
で、型(sort)と かりー・はわーど対応の繋がりは何?

とりあえずFred(>>959)で、Higher Order Logicを複数のsortに展開してるって辺り?


963 :デフォルトの名無しさん:02/11/03 12:01
ようするに、「Curry-Howard対応使って型からプログラムを生成する試みがあった」と言いたかっただけじゃないかと…

964 :デフォルトの名無しさん:02/11/03 12:50
それよりもよー、
型付きλ計算の型と、
「プログラミング言語における型」の違いがよく分からんのだが。

965 :デフォルトの名無しさん:02/11/03 13:27
ごまかしに入ったな

966 :デフォルトの名無しさん:02/11/03 13:29
>>964=逝ってよしの1

967 :デフォルトの名無しさん:02/11/03 13:41
964=955

968 :デフォルトの名無しさん:02/11/03 13:48
>>964
何を型といってるかによるけど違いはないよ。
高階関数がどこまで扱えるかどうかは言語によるけど。
ただ >>954 のように型を集合と考えるのに対して >>956 の挙げた
型を命題とする見方は typed lambda の応用に独特だと思う。
この辺のイントロでよくまとまってるのは >>951 の5章かな。
もっと平易なのがよければ冗長だけど↓
ttp://nicosia.is.s.u-tokyo.ac.jp/pub/essay/hagiya/7bits/shoumei_kata


969 :デフォルトの名無しさん:02/11/03 13:59
このスレってtail recursionしてない?

970 :デフォルトの名無しさん:02/11/03 14:04
いつまでも同じ話題にしがみ付いていて、
恥ずかしくないの?

971 :デフォルトの名無しさん:02/11/03 14:11
さあ、そこんとこは少なくとも俺には分からない。

972 :デフォルトの名無しさん:02/11/03 14:51
ということでこのスレは終わりかな。
まともな議論を死体人は数学板でやるのがいいと思う。
ここは何もしらいない厨房が分ったふりをして書き込む板なので。

973 :デフォルトの名無しさん:02/11/03 18:51
数学板で煽りの入らないまともな議論をするのは非常に難しいという罠

974 :デフォルトの名無しさん:02/11/03 19:40
論理スレとか酷いことになってますねえ。

975 :デフォルトの名無しさん:02/11/03 23:15
>>968,>>971-972が「何もしらいない厨房が分ったふりをして書き込む」のサンプルな罠

976 :デフォルトの名無しさん:02/11/03 23:48
具体的なことを何一つ書き込まないのは所詮厨房という罠

977 :デフォルトの名無しさん:02/11/13 12:25
977

978 :デフォルトの名無しさん:02/11/16 22:12
>>975
あふぉぅ

979 :デフォルトの名無しさん:02/11/17 15:55
979

980 :デフォルトの名無しさん:02/11/17 18:36
この書き込みで 980 超えたので、
次スレ立てるなら数日中に立てないと dat 落ちします。
スレ住人の人よろしくお願い。

981 :デフォルトの名無しさん:02/11/17 18:40
>>976-979
 >>976

982 :デフォルトの名無しさん:02/11/17 19:04
次スレ立てました。

関数型言語Part3
http://pc3.2ch.net/test/read.cgi/tech/1037527388/


983 :デフォルトの名無しさん:02/11/17 21:19
983

984 :デフォルトの名無しさん:02/11/17 21:24


985 :デフォルトの名無しさん:02/11/17 23:39
985

986 :デフォルトの名無しさん:02/11/18 13:56
986

260 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)