【数学者】Haskellはクソ言語【オナニー】

【数学者】Haskellは� ..

44:デフォルトの名無しさん
05/11/19 12:28:18
　 _ 　 ∩
(　ﾟ∀ﾟ)彡　ハスケル！ハスケル！
　⊂彡
URLﾘﾝｸ(www.haskel.com)

45:デフォルトの名無しさん
05/11/22 00:44:19
手続きコード無闇に繋いでも今は無駄だよ
大抵の処理は高階関数一つで終わりさ
関数型のIOを守るためお前は考え便利さ見失った
手続き忘れたインターフェース<かお>など見たくはないさ
IO 取り戻せ

46:デフォルトの名無しさん
05/11/22 07:51:08
僕はようやくスレをageた。やれやれ。

47:デフォルトの名無しさん
05/11/22 07:55:05
本スレが余りに学術的で居心地が悪くなった
Haskellネタ師の溜り場はここですか？

48:デフォルトの名無しさん
05/11/22 23:22:30
しかし、数学者からみたら他の言語よりはマシだが、まだまだ不満はあるよな。

49:デフォルトの名無しさん
05/11/23 00:56:10
理論的な見地でもまだまだ。処理系の実装においても、
C,C++とはまだ吐き出されるコードに雲泥の差がある。
まだまだ中途半端な存在なんだね。

50:デフォルトの名無しさん
05/11/26 22:20:52
本スレが余りに過疎で居心地が悪くなった
Haskellネタ師の溜り場はここですか？

51:デフォルトの名無しさん
06/01/27 01:34:14
入門書がでるってはなしはどうなりましたかね？

52:デフォルトの名無しさん
06/01/27 02:09:55
入門書出すことに意味があるのかどうか。。
そんなに一般人に媚び売ってどうすんの？

53:デフォルトの名無しさん
06/01/27 19:33:12
あげ

54:デフォルトの名無しさん
06/01/28 23:32:25
Haskellの是非は置いといて>>8には全く同意できない。

55:デフォルトの名無しさん
06/01/28 23:52:03
>>54
たしかに++とか:とかの意味を知らないと>>8では理解しようがないけど、
Haskellを知っていてクイックソートを知らない奴がかりにいたとすると
やっぱりそいつは>>5を見て即座にクイックソートを理解すると思う。
その意味で、>>8が言ってることもそんなに外れてないような気がする。

関係ないが、Rubyあたりでクイックソートを書いても似たようなものになるはずなのに
なんでHaskellの特徴みたいに扱われてるんだろう…

56:デフォルトの名無しさん
06/01/29 00:44:06
プログラムとしては全然直感的じゃないな。
数式に近い

57:デフォルトの名無しさん
06/01/29 02:12:39
手続き型言語じゃないからね。

58:デフォルトの名無しさん
06/01/29 07:12:15
高学歴用言語ですかね

59:デフォルトの名無しさん
06/01/29 07:15:16
Haskell の IRC は賑わってるから、ｲﾊﾟｰﾝ人も多いんじゃないの。

URLﾘﾝｸ(meme.b9.com)

60:デフォルトの名無しさん
06/01/29 11:10:00
>>56
俺にはむしろ手続き型のほうが直感的に思えない

61:デフォルトの名無しさん
06/01/29 11:26:33
それは、抽象化された物が直感的と考えるか、具象化された物を直感的と考えるかの違いじゃないかな。
やっぱり Haskeller は、Haskell のコードからどんなアセンブラが生成されるか直ぐに分かるの?

62:デフォルトの名無しさん
06/01/29 11:32:42
アルゴリズム的

63:デフォルトの名無しさん
06/01/29 11:56:15
C に変換して gcc でコンパイルしてるけど
どんなコードになるのかわかりません(⊃д`)

64:デフォルトの名無しさん
06/01/31 10:05:43
もっと議論しろ

65:デフォルトの名無しさん
06/01/31 17:59:21
そもそも「直感的」という言葉じたいが曖昧で主観的なものだから
議論の土台としてふさわしくない。みたいな？

66:デフォルトの名無しさん
06/01/31 18:50:26
では話題を変えてもよいぞ

67:デフォルトの名無しさん
06/01/31 19:31:37
何か聞きたいことがあるなら素直に質問しろよw

68:デフォルトの名無しさん
06/01/31 20:16:46
取敢えず俺ははすけるの事をまるで知らないので、
このプログラミング言語の良さを自慢して俺をワクワクさせろ。

69:デフォルトの名無しさん
06/01/31 21:24:42
Haskellの素晴らしさは>>68みたいな馬鹿には使いこなせないところだ。
どうだ、魅力的だろ。

70:デフォルトの名無しさん
06/01/31 21:30:42
ぱっと思い付くのはこんなところだな。

・高級言語の基本的な特徴を備えている。
メモリ操作はほとんど意識する必要がない。全部GC任せにできる。
そもそもGCの存在すら意識しなくてもいいくらいだ。オブジェクトは全部(参照やポインタでなく)値。
関数も値。手続きも値。

・代数的データ型
「タグつき共用体」とか「バリアント」とか呼ばれる奴だ。
これ一つでstructにもunionにもenumにもなる。萌え。
うまく言えないが、とても素晴らしい。

・美しい構文
予約語よりも記号を多用した簡潔な構文だ。とくにwhere節(>>5にもあるように、
ローカル変数を関数本体の後で定義する機能)は手放しがたい。

・モナド
CやPascalのセミコロンを多重定義できる機構だと思ってくれ。文が実行される文脈を定義することができる。
非決定モナドを使えば複数の選択肢から一つを決定するたびに世界の方が分裂する計算を表現できるし、
継続モナドを使えばgotoすらかわいく見える邪悪な制御構造を使うことができる。
誰にも読めないソースをつくり出すには絶好の道具だ。

・強力な静的型システム
多重定義と総称性(generics)が自然に統合されたそれなりに単純な型システムがある。
特に、型推論があって、こまごまとした指定をせずとも型に頼ったプログラミングができる。
総称的な関数はそうでない関数と同じように書けるし扱える。

ワクワクしたか？したらとっとと勉強しろ。

71:デフォルトの名無しさん
06/01/31 21:37:53
そうだな、なかなかワクワクしてきた。
では俺様に参考書を薦めるがよい。

72:デフォルトの名無しさん
06/01/31 21:50:46
Haskellは今年中にマスターしてみせる

73:デフォルトの名無しさん
06/01/31 22:03:37
>>71
Haskell: The Craft of Function Programming
はとても良い本だが、俺はこれ以外に入門書を読んでいないので比較はできない。他には、
Introduction to Functional Programming using Haskell
あるいは、
The Haskell School of Expression
が有名なようだ。

webで学ぶなら、Yet Another Haskell Tutorialがほとんど唯一のまとまった入門書だと思う。

74:デフォルトの名無しさん
06/02/01 22:34:44
限量子使えるバージョンもあるよ０うだが、、、
なんか面白いことできる　∀x∀y ∃z　

75:デフォルトの名無しさん
06/02/01 23:38:33
顔文字にしか見えない → (∀

76:デフォルトの名無しさん
06/02/13 20:56:42
初心者がHaskellを学ぶのに役立ちそうな文書:
URLﾘﾝｸ(www.sampou.org)
URLﾘﾝｸ(www.sampou.org)
URLﾘﾝｸ(www.sampou.org)
URLﾘﾝｸ(www.sampou.org)

77:デフォルトの名無しさん
06/02/14 01:46:36
役立ちそう、じゃなくて実際にいいか悪いか教えて欲しい。
文書はとにかくあれば何でもおーけーみたいのはちょっと。

78:デフォルトの名無しさん
06/02/14 03:03:11
2番目は何もわかんない状態で役立つ。
3番目は2番目が半分以上わかるぐらいで役立つ。
4番目はGHCは読めないけどもっと普通のなら読めるぐらいになったら役立つ。
1番目はモナドがわかんない時に役立つ。

79:デフォルトの名無しさん
06/02/14 03:23:28
スレタイに反して、良スレだな、ここは。

80:デフォルトの名無しさん
06/02/14 06:13:50
>>78
本当に役立つのかどうか不安なレスだな。
効用: 読んだことに満足する、だったりして。

81:デフォルトの名無しさん
06/02/14 06:40:14
>>77
俺は>>76じゃないけど、正直なところ、今日本語で読める文章で
Haskellを学び始めるのに適したものはないと思う。
一ヶ月ほどで本が出ると思われるのでそれを待つか、
MLの入門文書を読んで関数型言語に慣れてから「やさしいHaskell入門」を読むのが
近道なんじゃないだろうか。

82:デフォルトの名無しさん
06/02/14 07:23:10
76だが、>>81に激しく同意。俺は>>76の2番目を半分ぐらい読んだ状態。
後はコード読んでHaskellの世界を開拓(Hack)してゆくしかないと思う。

83:デフォルトの名無しさん
06/02/14 09:27:48
Hackell

84:デフォルトの名無しさん
06/02/14 09:45:31
オライリーから
Haskell hacks
が出るのはいつの日のことですか

85:デフォルトの名無しさん
06/02/15 04:54:51
>>84
オライリーの中の人にもオナニーと思われてる予感

86:デフォルトの名無しさん
06/02/15 04:56:35
>>85
そだね。近所なんだからよく相談するようにね。

87:デフォルトの名無しさん
06/03/05 06:14:03
age

88:デフォルトの名無しさん
06/03/05 06:34:28
オライリーとオナニーって似てるよね。

89:デフォルトの名無しさん
06/03/15 02:08:50
>>88
ねーよｗｗｗｗｗｗ

90:デフォルトの名無しさん
06/03/15 02:19:03
オナイニー

91:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 20:17:15
TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

92:デフォルトの名無しさん
06/03/23 17:07:28
ハスケル学んでて報われるかな？
10年以内に

93:デフォルトの名無しさん
06/03/24 12:09:37
言語はNEED TO KNOW

94:デフォルトの名無しさん
06/03/25 02:30:23
入門本の評判は？
発売ってまだだっけ？

95:デフォルトの名無しさん
06/03/25 03:53:29
>>92
言語を覚えているかどうかなんて些細な問題でしかない。
君が勉強すべきなのは数学だ。
さもなくば、ゲームが作りたいというならＡＰＩやらライブラリやらの仕様書でも読んでろ。

96:デフォルトの名無しさん
06/03/27 17:42:46
1流の2chブラウザを作ってWindowsからamigaまで制覇するのが夢です。

97:デフォルトの名無しさん
06/03/27 17:50:35
まずは一流と表記することからはじめるか

98:デフォルトの名無しさん
06/03/27 18:29:53
言語について解説した本がほしい
あの三冊ともSICPと同じことやらされて飽きる

99:デフォルトの名無しさん
06/03/27 19:02:02
>>98
そんなあなたにGentle introduction to Haskell

100:デフォルトの名無しさん
06/03/27 23:49:57
これってどないですか？
URLﾘﾝｸ(www.amazon.co.jp)

101:デフォルトの名無しさん
06/03/28 00:03:37
↑まだ届いてない

102:デフォルトの名無しさん
06/03/29 20:13:54
Haskell製2chブラウザﾏﾀﾞｰ?

103:デフォルトの名無しさん
06/04/06 06:05:36
Haskellの59%は真空で出来ています
Haskellの23%は鍛錬で出来ています
Haskellの8%は気の迷いで出来ています
Haskellの7%はミスリルで出来ています
Haskellの3%は成功の鍵で出来ています

成功の度合いは低い…

104:デフォルトの名無しさん
06/04/09 17:10:57
それ入門書だよね。ネットに分かりやすいチュートリアルあるのに本買うのはもったいなくないか？
プログラミング初めてってんならいいかも知れんけど。

105:デフォルトの名無しさん
06/04/09 17:54:21
わかりやすいチュートリアルってYAHTのこと？

106:デフォルトの名無しさん
06/04/09 18:48:35
やさし(くな)いHaskell入門かも

107:デフォルトの名無しさん
06/04/09 19:16:47
Gentle

108:デフォルトの名無しさん
06/04/09 20:09:30
紳士的なHaskell入門

109:デフォルトの名無しさん
06/04/09 20:19:15
そのうち萌えるHaskell入門とか出てきそうだ。

110:デフォルトの名無しさん
06/04/10 10:13:34
応用Haskell入門

111:デフォルトの名無しさん
06/04/10 21:07:48
応用は本気で欲しいな。

112:デフォルトの名無しさん
06/04/10 21:11:23
>>100
読みました。
一言で言うと、トイレットペーパーの方がマシでした。

113:デフォルトの名無しさん
06/04/10 21:41:54
まあ、理解できなかったらただの紙切れだわな

114:デフォルトの名無しさん
06/04/12 22:31:00
転職に有利ってことはないんだろうな。

115:デフォルトの名無しさん
06/04/13 05:00:22
>>5
単に名前の付けかたがまずいだけのような...
>>8
は分かりやすい。

116:デフォルトの名無しさん
06/04/13 05:08:36
何でこんなマイナー言語スレ同時進行してんの？

117:デフォルトの名無しさん
06/04/14 07:05:29
叩きネタが一瞬で尽きたのに誰も削除依頼しないから

118:デフォルトの名無しさん
06/04/14 16:19:39
プログラム言語界を席巻するのは時間の問題だから。

119:デフォルトの名無しさん
06/04/15 18:06:17
削除依頼しようと思う人がいないほどマイナーだから

120:デフォルトの名無しさん
06/04/16 12:50:32
どんなに凄くても研究用じゃ実用にならないよな。
いつ根本から変わるかもわからんし。

121:デフォルトの名無しさん
06/04/16 14:58:42
Haskellはたしかに一番美しいと思うが
どの本も最初にエレガントな解を見せておいて
実用的には別解が必要ですと来る。
その解説がものすごく手続き的。

122:デフォルトの名無しさん
06/04/16 15:11:27
>>121
例えばどんな本？

123:デフォルトの名無しさん
06/04/16 16:06:52
Haskellの初心者向け本出てたな。
迷わず買ったが、むずくて即挫折です

124:デフォルトの名無しさん
06/04/16 20:44:25
>>123
MLあたりから始めて遠回りしてみたら？

125:デフォルトの名無しさん
06/04/20 21:17:08
最強を目指すならばすべからく遠回りせよ

126:デフォルトの名無しさん
06/04/22 08:52:33
はすけらーって延々と議論ばかりやってて一向に動くものを作らなさそう。
現場で役に立たないタイプの典型。

127:デフォルトの名無しさん
06/04/22 12:00:55
若林史江さんは、19歳で株を始められたそうです。

URLﾘﾝｸ(www.fumie-w.com)
URLﾘﾝｸ(be-dream.jp)

高校を卒業するまでの私の人生はまさに順風満帆。
そんな時、突然告げられたのが父の会社の倒産。
ようやく私も事の次第がわかってきて、暗い将来を考えると涙が止まらなくて……。
「看護大に行くのはもうあきらめよう」と泣いていると、兄がこう言ってくれたんです。
「夢だった看護師をあきらめなきゃならないのはかわいそうだと思う。
でも、どんな仕事に就こうが、その世界で成功すればいいだけだよ。
……自分が置かれている分野でトップになれた人が成功者だと思う」
と慰めてくれたんです。
救われましたね～、この言葉で。
「よし！頑張るしかない。
妹もいるし、家にお金を入れなきゃいけないんだから働こう！」
と気持ちを切り替えることができたんです。

同じ19歳でも、人生いろいろですね。

128:デフォルトの名無しさん
06/04/22 13:07:19
若林史江さんの成分解析結果 :

若林史江さんの36%は夢で出来ています。
若林史江さんの24%は乙女心で出来ています。
若林史江さんの14%は毒電波で出来ています。
若林史江さんの11%は花崗岩で出来ています。
若林史江さんの8%は鍛錬で出来ています。
若林史江さんの5%は根性で出来ています。
若林史江さんの1%は真空で出来ています。
若林史江さんの1%は株で出来ています。

129:デフォルトの名無しさん
06/04/22 19:35:40
そのコピペシリーズってよく見るけど、何が面白いのかサッパリ分からんのだ。

130:デフォルトの名無しさん
06/04/22 20:17:16
>129
コピペじゃない。
っ【成分解析カドルコア】

131:デフォルトの名無しさん
06/04/23 01:41:05
へえ。
占いツール（？）なのか。

ググッたけど、激しく落とす気しねーｗ

132:デフォルトの名無しさん
06/04/23 14:00:21
芸人が腰を振りながら変なポーズで叫ぶ新手のネタか何かと思ってたよ。
テレビ見ている人は、その状況が勝手に脳内補完されるから面白い（流行っている）のかな、と。

まあ、俺はテレビ見ないからな。

133:デフォルトの名無しさん
06/04/23 19:59:53
あなたの生活なんてだれも聞いてません。

134:デフォルトの名無しさん
06/04/23 20:03:08
>>132
最近の芸人はどれもコンセプトは一緒でつまらん。
ちょうど、他人のレポートを写して書き方をちょこっと変えて提出する学生と同じ。

135:デフォルトの名無しさん
06/04/26 01:30:25
>>134
芸人はバラエティー番組の部品だから。
usefulな部品が同じようなインターフェイスを持つようなもの。

136:デフォルトの名無しさん
06/04/26 01:56:51
>>135
そういう環境に最適化しちゃったやつは環境の変化になかなかついてこれないから淘汰されるよ。ついてこれるのは変化に対応できたやつだけ。

137:デフォルトの名無しさん
06/04/28 09:44:05
テレビ屋も視聴者も
今の芸人に移植性なんて期待してないんだよ

138:デフォルトの名無しさん
06/04/28 15:33:39
それ違う

139:デフォルトの名無しさん
06/04/29 22:00:52
＞はすけらーって延々と議論ばかりやってて一向に動くものを作らなさそう。
＞現場で役に立たないタイプの典型。
会社入れば、こういうことを仰る輩の実力が痛い程味わえますね。

140:デフォルトの名無しさん
06/04/30 15:03:44
>>134
>最近の芸人はどれもコンセプトは一緒でつまらん。　

ああ、>>134　も成長したんだな。良かった良かった。

あと一つ教えてやる事があるとすると、
何もそれは「最近」に限ったことではない。
昔から同じ。

単に　>>134　が昔の芸人を知らなかっただけ。

141:デフォルトの名無しさん
06/04/30 16:58:44
芸人はどうでもいいよ

142:デフォルトの名無しさん
06/04/30 17:11:43
質問です。

Haskellと芸人のつながりを教えてください。

143:デフォルトの名無しさん
06/04/30 17:13:48
だからどうでもいいっていってんだろ。

144:デフォルトの名無しさん
06/04/30 17:19:26
>>143
あなたは私ですか？
私が気にしているのに、なぜどうでもいいという答えが出てくるんですか。
まじめに考えなさい。

145:デフォルトの名無しさん
06/04/30 17:23:08
黙れ小僧！それが人にものを訊ねる態度か！

146:デフォルトの名無しさん
06/04/30 20:50:43
数学的だと美しいの？主観の問題じゃ？

147:デフォルトの名無しさん
06/04/30 21:09:13
ククク…混沌こそが美しい

148:デフォルトの名無しさん
06/04/30 21:20:32
>>146
数学的つーより、定義を書き下すスタイルが美しいと思う。

149:デフォルトの名無しさん
06/04/30 21:20:51
>>146
時よとまれ！お前は美しい！

150:デフォルトの名無しさん
06/04/30 21:22:49
シンプルな計算モデルに基づいてすべてを記述できるのが美しい

151:デフォルトの名無しさん
06/04/30 21:23:27
美しいの計算モデルなのさ！！！

152:デフォルトの名無しさん
06/04/30 21:43:08
妖星は二度と輝かぬ！

153:デフォルトの名無しさん
06/04/30 21:55:15
わが生涯に一片の副作用なし！

154:デフォルトの名無しさん
06/04/30 22:02:19
観察可能な副作用のない人生のなんと矮小なことか。

155:デフォルトの名無しさん
06/04/30 22:47:58
無駄がないのが美しく感じる。

156:デフォルトの名無しさん
06/04/30 23:15:42
表面上は副作用無いけど、
ぶっちゃけ実質的には副作用ある。

157:デフォルトの名無しさん
06/04/30 23:24:21
実質的にはあるものを、表面上は無いように見せかけようとしてきたのが
プログラミング言語の歴史だ。

158:デフォルトの名無しさん
06/04/30 23:27:52
>>157
そのコピペのソースはどこ？

159:デフォルトの名無しさん
06/04/30 23:55:23
副作用に実質も糞もないだろ。
副作用って言葉自体が言語レベルの(表面上の)概念なんだから。

160:デフォルトの名無しさん
06/05/01 00:04:13
haskellに副作用はありません。
副作用があるとかなんとか、馬鹿が鳴いてるだけですから無視してください。

161:デフォルトの名無しさん
06/05/01 02:20:35
確かに main の返す値は常に等しいが・・・。

162:デフォルトの名無しさん
06/05/01 16:21:26
宣言的プログラミングってやつとは全然違う？近い？

163:デフォルトの名無しさん
06/05/01 18:01:17
違います

164:デフォルトの名無しさん
06/06/02 19:25:52
諸君、議論したまえ。

165:デフォルトの名無しさん
06/06/02 21:16:53
>>64か？
そろそろ勉強始めろよ。和書も出たんだし。

166:デフォルトの名無しさん
06/06/03 18:55:27
Haskellって、アルゴリズムを書くには便利そうだけど、
それだけで完結するようなプログラムもありえないので、
ビジネスロジックだけをこれで書いて、ほかの言語から
呼び出せってモノなんでしょ？

もっといえば、ストアドみたいな。

167:デフォルトの名無しさん
06/06/03 19:43:52
>>166
そういう使いかたもあるけど、そのための言語と言う訳ではない。
宣伝文句は「general purpose programming language」だし、
ライブラリの整備もかなりの部分は「全部Haskellで書く」方向に向かっている。

そもそも、なんでロジック以外を書くにはHaskellは不便だと思うんだ？

168:167
06/06/03 19:46:36
自己レス

>そもそも、なんでロジック以外を書くにはHaskellは不便だと思うんだ？
いや、実際不便なんだが、それは主にライブラリの不備のせいであって、
言語がそっちを指向してる訳じゃないと思うがどうよ。

169:デフォルトの名無しさん
06/06/03 20:44:04
>>165
はーい＾＾

170:デフォルトの名無しさん
06/06/04 00:48:32
>168
簡単な解説ページしかみてないので今ひとつ自信はないんだけど、
I/O関係でムリを通そうとしてる雰囲気がほのかに・・・。

そんなんだったら、ほかの言語から呼び出すのにとどめたほうが、
みんな幸せになれそう。

正規表現を拡張して独立したプログラム言語にしようとしてるような、
ミョーな意固地さを感じる・・・。

171:デフォルトの名無しさん
06/06/04 01:59:34
Haskell.NETで何とかならんかな、その辺は。

172:デフォルトの名無しさん
06/06/04 02:13:40
Haskell.NETは間違いなくベーパーウェアのまま終わる

173:デフォルトの名無しさん
06/06/04 16:13:06
C++のメソッドに対するconstってあるでしょ。
あれは、オブジェクトの状態を変えないって意味がある(実際はちょっと違うけど)
SICPにもあるけど、副作用や参照のせいで出てくるバグ(side-effect bug)も、
結構無視できない。

私の場合だけど、
副作用がある部分と、副作用が無い部分を切り分けられないかと思い
様々な言語を探していたらHaskellとかCleanとか(*)に突き当たった。

そのように見れば、IOモナドで副作用を切り分けるのもそんなに違和感が無いんじゃないかな。

(*)研究用の(実用的でない)言語なら他にもあるみたい。
URLﾘﾝｸ(computing-dictionary.thefreedictionary.com)

174:デフォルトの名無しさん
06/06/04 18:11:25
はやくおまいら実用的なライブラリこさえてください。

175:デフォルトの名無しさん
06/06/04 18:47:20
GHCはOpenGL+GLUTがついてるぜ
サンプルコードぐぐってやる気なくしたけど

176:デフォルトの名無しさん
06/06/04 20:12:00
>>170
たぶんIOモナドの事を言ってるんだと思うが、IOをモナドで表すのは
どっちかというと言語の詳細であって、それほどプログラミングのスタイルが
影響を受ける訳じゃない。
たとえ内部が正規表現で出来ていようと、その上で普通にコードがかけるなら
問題ないんじゃないだろうか。

という訳で、別に無理をしていても良いと思うんだが、個人的には
HaskellのIOがすごく無理をしているようには感じられない。うまく言えないけど。

177:デフォルトの名無しさん
06/06/04 20:26:01
しかし、純粋関数的に書いていたコードに副作用を加えたい場合、
let x = ...を
x <- ...
に書き換えたり、
戻り型を a から IO a や State s a に書き換えなければならない事を思うと、
Haskellで書いたプログラムのモジュール性が低いと言えなくもない。

ただ、元々副作用無しで書こうと思っていたコードに、
副作用を加えるというのは、そもそも設計段階で間違っていたとも言える。

ここで言う副作用の例は、性能評価コードや、ロギング等のための、
呼び出しカウント、ファイル出力などを考えている。
でもこういうのは他の代替可能な手段があるかもしれない。

始めからIdモナドで書けばいい、と言ってしまえばそれまでだけど。
この辺の議論ってどっかに書いてないかな。

178:デフォルトの名無しさん
06/06/12 06:41:11
諸君、さらに議論を続けたまえ。

179:デフォルトの名無しさん
06/06/12 07:32:33
そうやって話の腰を揉むのはよせ

180:デフォルトの名無しさん
06/06/12 07:56:57
俺のおっぱい揉んでよ。

181:デフォルトの名無しさん
06/06/12 07:59:16
氏ねデブ

182:デフォルトの名無しさん
06/06/12 11:30:40
議論を再会したまえ。

183:デフォルトの名無しさん
06/06/12 19:07:16
お前ら面白すぎ

184:デフォルトの名無しさん
06/06/13 14:00:58
べつに面白くはないでしょ

185:デフォルトの名無しさん
06/06/14 21:56:33
議論を展開したまえ。

186:デフォルトの名無しさん
06/06/15 22:47:18
おっぱいもまれたい男はデブかどうか。

ピザには間違いない。

187:デフォルトの名無しさん
06/06/17 07:48:34
その議論は終了したまえ。

188:デフォルトの名無しさん
06/06/17 09:40:35
学者様は議論の開始・展開・終了がノンコストで行われると考えてるらしい。
実際の開発では、プログラムの開始・展開・終了の間で
作業者間でのコミュニケーションが行われ、そこのコストがもっとも大きいというのに。

189:デフォルトの名無しさん
06/06/17 13:19:08
じゃあトップが一人で全部設計してあとはコーディングだけすれば
ノンコストだろ。コミュニケーションにコストがかかるとか言ってる
>>188方がDQNだろ

190:デフォルトの名無しさん
06/06/17 14:25:09
>>187
したまえ

191:デフォルトの名無しさん
06/06/17 20:41:33
>>189
俺にはこのボケに対するうまいツッコミが思いつかない

192:デフォルトの名無しさん
06/06/18 09:54:29
今北んだが、何でコミュニケーションのコストの話になったんだ？
誰が学者様なんだ？

コミュニケーションにコストがかかるのは承知だが、
なんでそれをHaskellのスレで議論する必要が？
もっとテクニカルな話しようや

193:デフォルトの名無しさん
06/06/18 10:01:35
俺はテクニックの話はどうでもいい。
研究的内容について議論してくれ。

194:デフォルトの名無しさん
06/06/18 11:58:33
研究的内容って？何を求めているの？

195:デフォルトの名無しさん
06/06/18 15:41:09
>>194
「新規性」だよ

196:デフォルトの名無しさん
06/06/18 23:12:56
このスレで？w
んな高尚なもの求められても。。そういうのは大学のお友達とたっぷり議論するといいよ。

197:デフォルトの名無しさん
06/06/18 23:15:25
第一こんな所に降りてくるネタなんぞに新規なものなど存在しない。
何かHaskellの新しい機能を触ろう、ってんならagreeだが。

198:デフォルトの名無しさん
06/06/19 17:24:47
arrowってモナドと何が違うの？

199:デフォルトの名無しさん
06/06/19 17:34:25
やっとアローズまでたどり着いたか。遅かったね。

200:デフォルトの名無しさん
06/06/19 23:18:19
頭の回転の速さよりもセレンディピティの方が重要だと思う。

201:デフォルトの名無しさん
06/06/21 01:36:11
クソスレでまじめな議論に飢える情報弱者ｗｗｗ

202:デフォルトの名無しさん
06/06/22 06:15:11
新しいものとか、テクニカルなもの、セレンディピティはおおいに結構。
Haskellの超絶技巧なテクニックだとか、こんなアプリをHaskellで書いた！とか、
こんな新しいプログラムの書き方がある！とか
そういう内容でいいんじゃないの

203:デフォルトの名無しさん
06/06/23 00:00:10
>>202
お前このスレ立てただろ。文体からすぐわかんだよ。
自分ひとり選民意識でいるんじゃねぇよ。
↓↓↓

プログラム板から来ました
ｽﾚﾘﾝｸ(php板)

204:デフォルトの名無しさん
06/06/24 15:40:43
議論をレジュームしたまえ。

205:デフォルトの名無しさん
06/06/27 21:48:43
Haskell使える人ってこれからどんどん増えて行くというのに、選民もクソもないでしょ。

206:デフォルトの名無しさん
06/06/28 01:51:37
Haskellは流行りません。研究者の一人として断言します。

207:デフォルトの名無しさん
06/06/28 02:26:49
>>206
理由をぜひ聞きたかったりするんだが…。
これから勉強しようかと思ってるけど、ひょっとして無駄？

208:デフォルトの名無しさん
06/06/28 06:23:53
>>207
自分の「ものの考え方」のバリエーションが広がるだけでも
全く無駄ではないよ

209:207
06/06/28 08:35:59
>>208
あっ、いや、ある程度はもう知ってるのだけど、
Haskellは実用的にも使えるのではないかと思って
標準的な関数の使い方を全て勉強しようかという
矢先に >>206 を見たので…。

210:デフォルトの名無しさん
06/06/28 17:52:27
Haskell は面白いけど、あんまり実用的ではないように見えるなあ。
それほど効率が求められないものや、
あるいはそれほど効率に影響のないプログラムなら問題ないけど、
効率上、副作用は必要悪だと思うなあ。

211:デフォルトの名無しさん
06/06/28 18:10:21
Haskellが遅いのは遅延評価のせいであって、副作用は関係ないだろ。

212:デフォルトの名無しさん
06/06/28 23:24:57
別に商用になるかどうかと流行るかどうかは関係ないでしょ。
書籍も出たことだし、Smalltalkやlisp/schemeに迫る程度には「流行る」かと。
あまり理由も示さずに間抜けな断言をするのは研究者としてどうなんだろう。

あと、副作用があれば参照が使えるので例えば再帰の代わりにforループが書ける。
Cみたいなクイックソートが書ける。副作用は、Haskell自体の遅さというより、
効率的なプログラムが書けるかどうかに掛かってくる、ということを>>210は言いたかったんでは。

213:デフォルトの名無しさん
06/06/28 23:33:02
「Haskellは流行りません」って、Haskellを知らずに言ってるならただの馬鹿だし、
Haskellの利点を踏まえた上でそんなことを軽々しく断言されても…ちょっとアレな人な気がする
どこの馬の骨ともわからん(プログラミング言語の?)研究者が何と言おうと、流行るもんは流行るし。

214:デフォルトの名無しさん
06/06/28 23:55:56
俺も馬の骨だが、Haskell は一般向けには流行らないと思うなぁ。
そもそも流行っている事が最も重要な人は使っていないんじゃないかな。

215:デフォルトの名無しさん
06/06/29 00:12:06
流行らないと「思う」には同意。ただ断言できるほど物を知らないorz

>そもそも流行っている事が最も重要な人は使っていない
これの日本語的な意味がわからん。読めん。

216:デフォルトの名無しさん
06/06/29 01:13:18
「はやっている　＝＝　もっとも　じゅうようなこと」だと　かんがえる　ひとは　つかっていないんじゃないかな。

217:デフォルトの名無しさん
06/06/29 02:45:50
絶対流行らない。
仕様を理解してもらえないと思う。

218:デフォルトの名無しさん
06/06/29 03:20:34
でもさ、むかし、Lispすげー流行ったじゃん？

219:デフォルトの名無しさん
06/06/29 05:28:17
>>212
forループと(効率的に)同等なものは破壊的代入を使わなくても書ける。
Haskellでも破壊的クイックソートは書ける。
リストに対しては書けないけど、これはむしろ当然だろう。

副作用があることと、代入スタイルのプログラミングができることを混同しているように見える。
「必要悪」とされるべきは代入スタイルのプログラミング。
Haskellには副作用は無いけど、代入スタイルのプログラミングをサポートしているから、
これをHaskellが遅い理由にするのはおかしい。

220:デフォルトの名無しさん
06/06/29 05:52:08
便乗質問で申し訳ないんですが、
100MB を超えるような巨大配列を取り扱うような
科学技術計算でも大丈夫ですか？
参照透明性ということで、配列要素を一部分変更するたび毎に
配列の全コピーし直してるのかと思っているのですが大きな誤解ですか？
どうしても副作用のあるコードを書きたくなってしまいます。

221:デフォルトの名無しさん
06/06/29 06:12:19
>>220
Haskellの配列は二系統あって、一つが変更毎に完全なコピーを作るIArrayインタフェースで、
もう一つがコピーなしで破壊的操作ができる代わりにモナドを通した操作しか認めないMArrayインタフェース。
だから、この点に関しては問題ない。科学技術計算をする上で他に障害が無いかは保障しかねるけど。

222:デフォルトの名無しさん
06/06/29 06:40:16
>>221
MArray インターフェースですか。
そういうのが有ったんですね。それで勇気が出ました。とっても重要な情報です。

多分、他には根源的な支障はないと思います。
あともう一つ高速化手法として
最近流行の並列プログラミングもしたいのですが、
こっちは Haskell ではまだまだの段階なのかな？と勝手に思っています。

223:デフォルトの名無しさん
06/06/29 08:38:35
>副作用があることと、代入スタイルのプログラミングができることを混同しているように見える。
IORef等への参照セルへの代入は「副作用」として知られていますが何か？
少なくとも空間効率を意識したプログラミングは副作用がないとできない。と思う。
時間効率についてはオーダーの議論で逃げればいいけど。

224:デフォルトの名無しさん
06/06/29 08:43:28
>絶対流行らない。
>仕様を理解してもらえないと思う。
C++のバッドノウハウ集や、Javaの複雑なgenericsを理解できるなら、
Haskellの多相型や型クラスを理解するのはそう難しくはないでしょ。
GoFのVisitorやMementoパターンが理解できるなら、高階関数を使いこなすのも特に問題ないかと。
どれも一時期流行したもの。

Haskellが凡人に理解できないと思うのは、それこそ選民意識じゃない？

225:デフォルトの名無しさん
06/06/29 09:11:42
>IORef等への参照セルへの代入は「副作用」として知られていますが何か？
言葉遣いの問題だが、副作用ってのは「関数適用や式の評価に際して計算以外のことを行うこと」
であって、IORefの操作はこの定義に当てはまらないので副作用とはいえないと思う。
そのためにわざわざ「代入的プログラミング」という言い方をしたんだが。

>少なくとも空間効率を意識したプログラミングは副作用がないとできない。と思う。
>時間効率についてはオーダーの議論で逃げればいいけど。
言葉の問題を除いて、同意。

226:デフォルトの名無しさん
06/06/29 15:06:19
IORef とかって、IORef とかを取り除く時にコピーが発生するんじゃないの？

227:デフォルトの名無しさん
06/06/30 01:40:42
でもまあ、Haskellで科学技術計算なんてCに比べると10倍以上遅いんで、
する気にならないですけどね。

228:デフォルトの名無しさん
06/06/30 05:45:34
>>227
あ～。いいんですよ。とりあえず速度は。
最終的にどんな感じのプログラムになるか実際に見てみたいんですから。
それに計算対象や入力によって速度をそれほど気にしない場合もありますし。

229:デフォルトの名無しさん
06/06/30 08:10:05
C言語でカリカリにチューニングした速い実装を書いて、
Haskellでさくっとかいた実装の出力と比較して検算する (Nバージョンプログラミング)
というのはアリかもしれないね。

230:デフォルトの名無しさん
06/06/30 08:26:59
>言葉遣いの問題だが、副作用ってのは「関数適用や式の評価に際して計算以外のことを行うこと」であって、
わざわざ反論するのも面倒だけど、言葉使いの話をするならば、反論させてもらう。
何度も書くが、副作用(side effect)ってのはIORefへの代入も含むと一般に考えられている。
例えばSICPで、Schemeに代入の機能を入れる所で、side effect bugという言葉が出てくるし、
何より IORefを扱うモナド IOモナドは「副作用」を扱うモナドじゃないか。
IOモナドやState使わないと代入は純粋関数的に書けないでしょ。

適当にぐぐっただけでも(Cleanのマニュアルだが)
URLﾘﾝｸ(sky.zero.ad.jp)～zaa54437/programming/concepts/index3.htm#a6
>代入は、純粋な関数型言語では排除されている。というのも、代入演算子は副作用(side effect)を
>伴う為、参照透明性(referential transparency)が破壊されてしまうからである。

「狭義の副作用」という言葉があるのかどうかは知らないが、一般には代入も副作用と考えられている。

231:デフォルトの名無しさん
06/06/30 09:46:16
>>230
誤解を招く言い方だったが、俺が指摘したかったのはそこじゃない。
>何より IORefを扱うモナド IOモナドは「副作用」を扱うモナドじゃないか。
違う。「入出力」を「副作用なしで」扱うモナドだ。
ここで言う「入出力」にはIORefの操作なんかも含める。

なんでこの区別にこだわるかというと、
・>>210は「Haskellに副作用が無い」という前提で話している。
　だから少なくともこの文脈ではHaskellのIOを副作用と呼ぶのは不適切。
・unsafePerformIOなどによって導入される本物の副作用との区別ができたほうが良い。
という理由から。

232:デフォルトの名無しさん
06/06/30 12:27:10
ああ、言いたいことは分かったよ。

IOモナドは副作用を陽に扱わない。
Haskellは、副作用を表現するIOモナドを純粋関数的に「繋いで」、mainとして定義するスタイル。
繋いだアクションが逐次実行されることで、実行形式は副作用を伴うプログラムとして動作する。
一方、unsafePerformIO はIOモナドとは違い、Haskellの遅延評価のステップの途中で
本当に「副作用的に」評価される(純粋関数の枠を壊している)。
それを言いたいのは分かった。

>・>>210は「Haskellに副作用が無い」という前提で話している。
>　だから少なくともこの文脈ではHaskellのIOを副作用と呼ぶのは不適切。
どうしてその前提が読み取れるのか分からんけど。
というか明らかに IOモナドを副作用を扱うモナドでそ。unsafePerformIOと区別したいのは分かったが。
Haskellで副作用を表現できることはもはや常識なわけで、
「Haskellは副作用を(表面上)追い出した為にIOモナドというややこしい形でしか扱えない。しかし副作用は効率的なプログラムを扱う上で必要悪だよな。もっと簡単にならんのか？」
という風に読んだ。

233:とおりすがり
06/06/30 22:38:41
・形式的にはHaskellのソースコードの中に副作用を伴う要素は無いものとみなせる。

・副作用をいわば「ランタイム側に追い出す」ための仕組みがIOモナド。
　そういう意味でIOは副作用を扱っているといえる。

（・でも本当に副作用を持つ禁断の関数も実はある。）

ってことでFA?

状態機械の仕様をフローチャート的にではなく構成的に
定義できるのってキモチイイな
do構文使ってると普通の逐次処理言語とあまり変わらないけど。
まあ気分の問題で。

234:デフォルトの名無しさん
06/06/30 23:03:53
>do構文使ってると普通の逐次処理言語とあまり変わらないけど。
そう。というかlet文も考えようによっては逐次型っぽい。

for文やwhile文がなくて、オブジェクトのアップデートができない事を除けば、
手続き型言語も関数型言語もそんなに変わらない。
更にHaskellは純粋関数的なので順序を気にしなくていいんだけどね。

235:とおりすがり１
06/06/30 23:52:32
fib = 1:1:zipWith (+) fib (tail fib)
= 1:1:2:3:5:8:12 ....

これはおなじみHaskell版フィボナッチ数列
遅延評価の例として一度はお目にかかるという。

これはリストのある要素の値を
遅延評価を利用して
同じリストの手前の要素から構成しているのがミソ。

#解説は「フィボナッチ Haskell」でググるといっぱいでてくるので略

236:とおりすがり２
06/06/30 23:55:06
で話かわってmain関数の値の話。

これって要するに最終的には

main = (IO a) >>= (IO b) >>= (IO c) >>= (IO d) ......

というふうに(IO x)を>>=でつないだ数珠繋がりに簡約されるわけで。

(IO x)中にはキー入力とか、画面出力とか、メモリの上書きとか
逐次処理言語の命令コードやサブルーチンのようなものが詰まってる。

>>232とかで言ってるアクションてやつ
ちなみに(return x)で作った(IO x)はNOP（何もしない）が入ってるとみなす。

237:とおりすがり３
06/06/30 23:59:14
>>236のミソは
ループや分岐に相当する(IO x)は無いってこと。

なぜそれでこまらないのかというと、

フィボナッチ数列のときに
ある要素を決定するのにそれより前の要素の値を利用したように

条件分岐で次の処理として(IO y)を繋げようか(IO z)を繋げようか決めるのに
それより前の(IO x)の値をみて決める事ができるから。
あるいはそこで打ち切ってプログラムを終了してもいい。

つまり、Haskellで副作用のあるプログラムを書くってことは

フィボナッチ数列を定義するように
コマンド列を定義しているようなもの

238:とおりすがり４
06/07/01 00:03:08
とまあ
そういう風にオイラは理解したわけです。

239:デフォルトの名無しさん
06/07/01 06:11:52
合ってると思うっす。

240:デフォルトの名無しさん
06/07/01 06:30:18
>>232
>どうしてその前提が読み取れるのか分からんけど。

>「Haskellは副作用を(表面上)追い出した為にIOモナドというややこしい形でしか扱えない。しかし副作用は効率的なプログラムを扱う上で必要悪だよな。もっと簡単にならんのか？」
>という風に読んだ。

そう読めるのに気付かなかった。

入出力のことを副作用と呼んでるようだが、副作用とは式の簡約の過程で入出力を行うことであって、
入出力そのもののことではないだろ。
それとも、「副作用」という言葉をそういう意味で使うことを支持する典拠があったりするのか？

多くの言語では、入出力を扱う唯一の方法が副作用なわけで、入出力と副作用を混同してもさして問題はないだろうが、
そうでない言語(たとえばHaskellやClean)の話をするときはちゃんと区別して話したほうが良いと思う。

>というか明らかに IOモナドを副作用を扱うモナドでそ。
>>231に書いたように「副作用なしで」IOを扱うためのモナド、とするのが普通だと思う。
How to declare an imperativeから引用
>This section relates the monad approach to input-output to four other widely used
>approaches: synchronised streams, as used in earlier versions of Haskell; continua-
>tions, as used in Hope; linear types, as used in Clean; and side effects, as used in
>SML.

241:デフォルトの名無しさん
06/07/01 08:52:27
手続き型言語の代入でも、裏で全メモリの値を渡してると考えれば副作用ではないな

242:デフォルトの名無しさん
06/07/02 00:07:46
>そうでない言語(たとえばHaskellやClean)の話をするときはちゃんと区別して話したほうが良いと思う。
なるほど、完全に同意しましたです。すまない。

更に How to declare an imperative の文がとてもわかりやすい。ありがとう。
入出力、といえば副作用と思っていたけど、同期ストリームもそうだよな。
自分ではhGetContentsくらいしか使わないけど。
linear typeで入出力ができるのもCleanのマニュアルの序章で分かる(world as value)。
しかし。。。continuationでどうやって入出力するのか??

>それとも、「副作用」という言葉をそういう意味で使うことを支持する典拠があったりするのか？
あなたが言うように、副作用と入出力を混同していた。典拠はない。

243:242
06/07/02 00:15:21
誤解を招くと悪いので少し書くと、hGetContents自体の型は Handle -> IO StringなのでIOモナド。

ただ、hGetContentsから得たStringは遅延評価の度にファイルやネットワークデバイスから読み出される。
(データがなければブロックする)
この「遅延読みString」を処理する部分は旧来のストリーム・プログラミングっぽい（よね？

244:デフォルトの名無しさん
06/07/06 22:15:48
C言語だと言語仕様として再帰は32回までしか保証しない(だっけ)とかだから、
再帰による33回目の関数呼び出しとそうでない呼び出しで意味が大きく変わってくる。

245:デフォルトの名無しさん
06/07/06 23:06:29
>>244
うそつけ。Cの仕様書にそんなこと書いてないぞ。

246:デフォルトの名無しさん
06/07/07 04:38:43
何かそういう類いのあった気がするよ。
for のネストの回数とか意外なものに、
最低保証回数が仕様として決められている。

247:デフォルトの名無しさん
06/07/07 06:46:28
つ[5.2.4 Environmental limits]
だが、再帰回数はない。

248:デフォルトの名無しさん
06/07/07 08:25:32
そうなのか。

249:デフォルトの名無しさん
06/07/07 08:32:38
>>244
少し考えれば、再帰を32回まで完全保証する事が不可能だって分かるだろ。

250:デフォルトの名無しさん
06/07/08 09:19:47
へ？不可能なの？スタックさえ確保しておけばいいんじゃねーの？

251:デフォルトの名無しさん
06/07/08 09:22:30
>>249
ああ、確かにそうだな。

252:デフォルトの名無しさん
06/07/09 01:07:02
>>250
ローカル変数がスタックに取得される仕様だと
消費されるスタックの量が予測できないだろ。

ローカル変数と配列の最大数×配列サイズの制限？から再帰の
最大数を決めてもあまり意味があるとも思えない。

ローカル変数をスタックに取らないといけない決まりも無いけど
ほとんどの実装で受け入れられないモノを標準仕様を
するわけにはいかなかったんだろう。

ってスレ違いごめん

253:デフォルトの名無しさん
06/07/09 20:45:30
ローカル変数のスタック上のサイズは固定でしょ。言語にもよるけどCやC++ならそう。
そんなことも分からんやつしか居ないの？

254:デフォルトの名無しさん
06/07/09 21:39:50
もっと優しく言ってくれ

255:デフォルトの名無しさん
06/07/09 21:49:20
おれにはツンデレでお願い

256:デフォルトの名無しさん
06/07/09 22:30:35
し、Cの言語仕様にスタックなんて概念は規定されてないんだからねっ！

257:デフォルトの名無しさん
06/07/09 22:34:52
>>244-256
スレ違いの議論はこの辺で終了して下さい

258:デフォルトの名無しさん
06/07/10 00:31:31
>>253
だからその固定の変数を最大いくつ宣言できるか判らないでしょ

259:デフォルトの名無しさん
06/07/10 02:01:36
さらにC99だとスタック上の配列のサイズは実行時に決定できる。
すれ違いなのでこの辺までにしとこう。

260:デフォルトの名無しさん
06/07/10 06:35:50
>>259
>>256

261:デフォルトの名無しさん
06/07/10 12:53:18
>>259
偉そうに大嘘で締めないように。無能はしゃしゃり出ちゃいやん。

ま、スレ違いだからやめとくか。

262:デフォルトの名無しさん
06/07/10 13:38:02
ここは一応 Haskell 本スレじゃないから、
少々脱線した所でどうでもいい気もするけどね。

263:デフォルトの名無しさん
06/07/10 13:52:49
少々なら良いけど3日も続くとね…。
面白い話でもないしw

264:デフォルトの名無しさん
06/07/10 22:01:26
>>260
細かいな。記憶クラスが auto の配列って言えばいいのか？

>>261
C99のマニュアル読んでね。

265:デフォルトの名無しさん
06/07/10 22:17:04
げ。知らなかった。
int a[hoge()];
なんてやっても動くじゃん。
いままで関数内で捨てちゃう配列にmalloc使っていたのは無駄だったのか。

HaskellとRubyばっかり使っていたせいで、Cはメモリ管理がめんどくさい言語
だとばかり思っててちゃんと調べてなかった。

266:デフォルトの名無しさん
06/07/10 22:31:16
C99 じゃないと無理だけどな。

267:デフォルトの名無しさん
06/07/10 22:34:35
Cは99なのにHaskellはまだ98なのかー

268:デフォルトの名無しさん
06/07/10 22:46:53
>>264
しかしそう言い直した途端にスタックの話じゃなくなる罠。

いつまでもひきずってもつまらんので、Haskellの豆知識でも。

GHCでコンパイルされたプログラムがスタックをどのように使うかはわかりにくい。
再帰呼び出しでスタックが深くなっているようにも見えないのにオーバーフローを起こしたりする。
これは、スタックの消費が、呼び出しの深さではなく正格な関数の適用のネストの深さに比例するためだ。
例えばg x = x + 1 - 1 + 1 - ..たくさん.. - 1という関数を定義すると、呼び出しの深さは一であるにも関わらず
スタックを大量に消費する。正格な関数である(+)と(-)の適用が深くネストされているからである。

269:デフォルトの名無しさん
06/07/11 09:42:39
スタックが足りなくなったら適当に評価を行って遅延してるのを減らすとか
できないの?

270:デフォルトの名無しさん
06/07/11 11:27:31
>>264
嘘を拡大するためだけに前言撤回で復活しなくてよろしい。

271:デフォルトの名無しさん
06/07/11 19:11:00
>>269
未評価の式はヒープに保存されているので、それ自身はスタックを消費しない。
スタックが溢れるのは式を評価しようとしたとき。

次ページ