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

1 名前：デフォルトの名無しさん mailto:sage [2005/09/30(金) 01:34:05 ] C/C++＞＞＞＞(越えられない壁)＞＞＞Haskell 152 名前：デフォルトの名無しさん mailto:sage [2006/04/30(日) 21:43:08 ] 妖星は二度と輝かぬ！ 153 名前：デフォルトの名無しさん mailto:sage [2006/04/30(日) 21:55:15 ] わが生涯に一片の副作用なし！ 154 名前：デフォルトの名無しさん mailto:sage [2006/04/30(日) 22:02:19 ] 観察可能な副作用のない人生のなんと矮小なことか。 155 名前：デフォルトの名無しさん mailto:sage [2006/04/30(日) 22:47:58 ] 無駄がないのが美しく感じる。 156 名前：デフォルトの名無しさん mailto:sage [2006/04/30(日) 23:15:42 ] 表面上は副作用無いけど、 ぶっちゃけ実質的には副作用ある。 157 名前：デフォルトの名無しさん mailto:sage [2006/04/30(日) 23:24:21 ] 実質的にはあるものを、表面上は無いように見せかけようとしてきたのが プログラミング言語の歴史だ。 158 名前：デフォルトの名無しさん mailto:sage [2006/04/30(日) 23:27:52 ] >>157 そのコピペのソースはどこ？ 159 名前：デフォルトの名無しさん mailto:sage [2006/04/30(日) 23:55:23 ] 副作用に実質も糞もないだろ。 副作用って言葉自体が言語レベルの(表面上の)概念なんだから。 160 名前：デフォルトの名無しさん mailto:sage [2006/05/01(月) 00:04:13 ] haskellに副作用はありません。 副作用があるとかなんとか、馬鹿が鳴いてるだけですから無視してください。 161 名前：デフォルトの名無しさん mailto:sage [2006/05/01(月) 02:20:35 ] 確かに main の返す値は常に等しいが・・・。 162 名前：デフォルトの名無しさん mailto:sage [2006/05/01(月) 16:21:26 ] 宣言的プログラミングってやつとは全然違う？近い？ 163 名前：デフォルトの名無しさん mailto:sage [2006/05/01(月) 18:01:17 ] 違います 164 名前：デフォルトの名無しさん [2006/06/02(金) 19:25:52 ] 諸君、議論したまえ。 165 名前：デフォルトの名無しさん mailto:sage [2006/06/02(金) 21:16:53 ] >>64か？ そろそろ勉強始めろよ。和書も出たんだし。 166 名前：デフォルトの名無しさん mailto:sage [2006/06/03(土) 18:55:27 ] Haskellって、アルゴリズムを書くには便利そうだけど、 それだけで完結するようなプログラムもありえないので、 ビジネスロジックだけをこれで書いて、ほかの言語から 呼び出せってモノなんでしょ？ もっといえば、ストアドみたいな。 167 名前：デフォルトの名無しさん mailto:sage [2006/06/03(土) 19:43:52 ] >>166 そういう使いかたもあるけど、そのための言語と言う訳ではない。 宣伝文句は「general purpose programming language」だし、 ライブラリの整備もかなりの部分は「全部Haskellで書く」方向に向かっている。 そもそも、なんでロジック以外を書くにはHaskellは不便だと思うんだ？ 168 名前：167 mailto:sage [2006/06/03(土) 19:46:36 ] 自己レス >そもそも、なんでロジック以外を書くにはHaskellは不便だと思うんだ？ いや、実際不便なんだが、それは主にライブラリの不備のせいであって、 言語がそっちを指向してる訳じゃないと思うがどうよ。 169 名前：デフォルトの名無しさん [2006/06/03(土) 20:44:04 ] >>165 はーい＾＾ 170 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 00:48:32 ] >168 簡単な解説ページしかみてないので今ひとつ自信はないんだけど、 I/O関係でムリを通そうとしてる雰囲気がほのかに・・・。 そんなんだったら、ほかの言語から呼び出すのにとどめたほうが、 みんな幸せになれそう。 正規表現を拡張して独立したプログラム言語にしようとしてるような、 ミョーな意固地さを感じる・・・。 171 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 01:59:34 ] Haskell.NETで何とかならんかな、その辺は。 172 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 02:13:40 ] Haskell.NETは間違いなくベーパーウェアのまま終わる 173 名前：デフォルトの名無しさん [2006/06/04(日) 16:13:06 ] C++のメソッドに対するconstってあるでしょ。 あれは、オブジェクトの状態を変えないって意味がある(実際はちょっと違うけど) SICPにもあるけど、副作用や参照のせいで出てくるバグ(side-effect bug)も、 結構無視できない。 私の場合だけど、 副作用がある部分と、副作用が無い部分を切り分けられないかと思い 様々な言語を探していたらHaskellとかCleanとか(*)に突き当たった。 そのように見れば、IOモナドで副作用を切り分けるのもそんなに違和感が無いんじゃないかな。 (*)研究用の(実用的でない)言語なら他にもあるみたい。 computing-dictionary.thefreedictionary.com/Euclid 174 名前：デフォルトの名無しさん [2006/06/04(日) 18:11:25 ] はやくおまいら実用的なライブラリこさえてください。 175 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 18:47:20 ] GHCはOpenGL+GLUTがついてるぜ サンプルコードぐぐってやる気なくしたけど 176 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 20:12:00 ] >>170 たぶんIOモナドの事を言ってるんだと思うが、IOをモナドで表すのは どっちかというと言語の詳細であって、それほどプログラミングのスタイルが 影響を受ける訳じゃない。 たとえ内部が正規表現で出来ていようと、その上で普通にコードがかけるなら 問題ないんじゃないだろうか。 という訳で、別に無理をしていても良いと思うんだが、個人的には HaskellのIOがすごく無理をしているようには感じられない。うまく言えないけど。 177 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 20:26:01 ] しかし、純粋関数的に書いていたコードに副作用を加えたい場合、 let x = ...を x <- ... に書き換えたり、 戻り型を a から IO a や State s a に書き換えなければならない事を思うと、 Haskellで書いたプログラムのモジュール性が低いと言えなくもない。 ただ、元々副作用無しで書こうと思っていたコードに、 副作用を加えるというのは、そもそも設計段階で間違っていたとも言える。 ここで言う副作用の例は、性能評価コードや、ロギング等のための、 呼び出しカウント、ファイル出力などを考えている。 でもこういうのは他の代替可能な手段があるかもしれない。 始めからIdモナドで書けばいい、と言ってしまえばそれまでだけど。 この辺の議論ってどっかに書いてないかな。 178 名前：デフォルトの名無しさん [2006/06/12(月) 06:41:11 ] 諸君、さらに議論を続けたまえ。 179 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 07:32:33 ] そうやって話の腰を揉むのはよせ 180 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 07:56:57 ] 俺のおっぱい揉んでよ。 181 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 07:59:16 ] 氏ねデブ 182 名前：デフォルトの名無しさん [2006/06/12(月) 11:30:40 ] 議論を再会したまえ。 183 名前：デフォルトの名無しさん mailto:sage [2006/06/12(月) 19:07:16 ] お前ら面白すぎ 184 名前：デフォルトの名無しさん mailto:sage [2006/06/13(火) 14:00:58 ] べつに面白くはないでしょ 185 名前：デフォルトの名無しさん [2006/06/14(水) 21:56:33 ] 議論を展開したまえ。 186 名前：デフォルトの名無しさん mailto:sage [2006/06/15(木) 22:47:18 ] おっぱいもまれたい男はデブかどうか。 ピザには間違いない。 187 名前：デフォルトの名無しさん [2006/06/17(土) 07:48:34 ] その議論は終了したまえ。 188 名前：デフォルトの名無しさん mailto:sage [2006/06/17(土) 09:40:35 ] 学者様は議論の開始・展開・終了がノンコストで行われると考えてるらしい。 実際の開発では、プログラムの開始・展開・終了の間で 作業者間でのコミュニケーションが行われ、そこのコストがもっとも大きいというのに。 189 名前：デフォルトの名無しさん mailto:sage [2006/06/17(土) 13:19:08 ] じゃあトップが一人で全部設計してあとはコーディングだけすれば ノンコストだろ。コミュニケーションにコストがかかるとか言ってる >>188方がDQNだろ 190 名前：デフォルトの名無しさん [2006/06/17(土) 14:25:09 ] >>187 したまえ 191 名前：デフォルトの名無しさん mailto:sage [2006/06/17(土) 20:41:33 ] >>189 俺にはこのボケに対するうまいツッコミが思いつかない 192 名前：デフォルトの名無しさん mailto:sage [2006/06/18(日) 09:54:29 ] 今北んだが、何でコミュニケーションのコストの話になったんだ？ 誰が学者様なんだ？ コミュニケーションにコストがかかるのは承知だが、 なんでそれをHaskellのスレで議論する必要が？ もっとテクニカルな話しようや 193 名前：デフォルトの名無しさん mailto:sage [2006/06/18(日) 10:01:35 ] 俺はテクニックの話はどうでもいい。 研究的内容について議論してくれ。 194 名前：デフォルトの名無しさん mailto:sage [2006/06/18(日) 11:58:33 ] 研究的内容って？何を求めているの？ 195 名前：デフォルトの名無しさん mailto:sage [2006/06/18(日) 15:41:09 ] >>194 「新規性」だよ 196 名前：デフォルトの名無しさん mailto:sage [2006/06/18(日) 23:12:56 ] このスレで？w んな高尚なもの求められても。。そういうのは大学のお友達とたっぷり議論するといいよ。 197 名前：デフォルトの名無しさん mailto:sage [2006/06/18(日) 23:15:25 ] 第一こんな所に降りてくるネタなんぞに新規なものなど存在しない。 何かHaskellの新しい機能を触ろう、ってんならagreeだが。 198 名前：デフォルトの名無しさん mailto:sage [2006/06/19(月) 17:24:47 ] arrowってモナドと何が違うの？ 199 名前：デフォルトの名無しさん mailto:sage [2006/06/19(月) 17:34:25 ] やっとアローズまでたどり着いたか。遅かったね。 200 名前：デフォルトの名無しさん [2006/06/19(月) 23:18:19 ] 頭の回転の速さよりもセレンディピティの方が重要だと思う。 201 名前：デフォルトの名無しさん mailto:sage [2006/06/21(水) 01:36:11 ] クソスレでまじめな議論に飢える情報弱者ｗｗｗ 202 名前：デフォルトの名無しさん mailto:sage [2006/06/22(木) 06:15:11 ] 新しいものとか、テクニカルなもの、セレンディピティはおおいに結構。 Haskellの超絶技巧なテクニックだとか、こんなアプリをHaskellで書いた！とか、 こんな新しいプログラムの書き方がある！とか そういう内容でいいんじゃないの 203 名前：デフォルトの名無しさん mailto:sage [2006/06/23(金) 00:00:10 ] >>202 お前このスレ立てただろ。文体からすぐわかんだよ。 自分ひとり選民意識でいるんじゃねぇよ。 ↓↓↓ プログラム板から来ました pc8.2ch.net/test/read.cgi/php/1150778053/ 204 名前：デフォルトの名無しさん [2006/06/24(土) 15:40:43 ] 議論をレジュームしたまえ。 205 名前：デフォルトの名無しさん mailto:sage [2006/06/27(火) 21:48:43 ] Haskell使える人ってこれからどんどん増えて行くというのに、選民もクソもないでしょ。 206 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 01:51:37 ] Haskellは流行りません。研究者の一人として断言します。 207 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 02:26:49 ] >>206 理由をぜひ聞きたかったりするんだが…。 これから勉強しようかと思ってるけど、ひょっとして無駄？ 208 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 06:23:53 ] >>207 自分の「ものの考え方」のバリエーションが広がるだけでも 全く無駄ではないよ 209 名前：207 mailto:sage [2006/06/28(水) 08:35:59 ] >>208 あっ、いや、ある程度はもう知ってるのだけど、 Haskellは実用的にも使えるのではないかと思って 標準的な関数の使い方を全て勉強しようかという 矢先に >>206 を見たので…。 210 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 17:52:27 ] Haskell は面白いけど、あんまり実用的ではないように見えるなあ。 それほど効率が求められないものや、 あるいはそれほど効率に影響のないプログラムなら問題ないけど、 効率上、副作用は必要悪だと思うなあ。 211 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 18:10:21 ] Haskellが遅いのは遅延評価のせいであって、副作用は関係ないだろ。 212 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 23:24:57 ] 別に商用になるかどうかと流行るかどうかは関係ないでしょ。 書籍も出たことだし、Smalltalkやlisp/schemeに迫る程度には「流行る」かと。 あまり理由も示さずに間抜けな断言をするのは研究者としてどうなんだろう。 あと、副作用があれば参照が使えるので例えば再帰の代わりにforループが書ける。 Cみたいなクイックソートが書ける。副作用は、Haskell自体の遅さというより、 効率的なプログラムが書けるかどうかに掛かってくる、ということを>>210は言いたかったんでは。 213 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 23:33:02 ] 「Haskellは流行りません」って、Haskellを知らずに言ってるならただの馬鹿だし、 Haskellの利点を踏まえた上でそんなことを軽々しく断言されても…ちょっとアレな人な気がする どこの馬の骨ともわからん(プログラミング言語の?)研究者が何と言おうと、流行るもんは流行るし。 214 名前：デフォルトの名無しさん mailto:sage [2006/06/28(水) 23:55:56 ] 俺も馬の骨だが、Haskell は一般向けには流行らないと思うなぁ。 そもそも流行っている事が最も重要な人は使っていないんじゃないかな。 215 名前：デフォルトの名無しさん mailto:sage [2006/06/29(木) 00:12:06 ] 流行らないと「思う」には同意。ただ断言できるほど物を知らないorz >そもそも流行っている事が最も重要な人は使っていない これの日本語的な意味がわからん。読めん。 216 名前：デフォルトの名無しさん mailto:sage [2006/06/29(木) 01:13:18 ] 「はやっている　＝＝　もっとも　じゅうようなこと」だと　かんがえる　ひとは　つかっていないんじゃないかな。 217 名前：デフォルトの名無しさん mailto:sage [2006/06/29(木) 02:45:50 ] 絶対流行らない。 仕様を理解してもらえないと思う。 218 名前：デフォルトの名無しさん mailto:sage [2006/06/29(木) 03:20:34 ] でもさ、むかし、Lispすげー流行ったじゃん？ 219 名前：デフォルトの名無しさん mailto:sage [2006/06/29(木) 05:28:17 ] >>212 forループと(効率的に)同等なものは破壊的代入を使わなくても書ける。 Haskellでも破壊的クイックソートは書ける。 リストに対しては書けないけど、これはむしろ当然だろう。 副作用があることと、代入スタイルのプログラミングができることを混同しているように見える。 「必要悪」とされるべきは代入スタイルのプログラミング。 Haskellには副作用は無いけど、代入スタイルのプログラミングをサポートしているから、 これをHaskellが遅い理由にするのはおかしい。 220 名前：デフォルトの名無しさん mailto:sage [2006/06/29(木) 05:52:08 ] 便乗質問で申し訳ないんですが、 100MB を超えるような巨大配列を取り扱うような 科学技術計算でも大丈夫ですか？ 参照透明性ということで、配列要素を一部分変更するたび毎に 配列の全コピーし直してるのかと思っているのですが大きな誤解ですか？ どうしても副作用のあるコードを書きたくなってしまいます。 221 名前：デフォルトの名無しさん mailto:sage [2006/06/29(木) 06:12:19 ] >>220 Haskellの配列は二系統あって、一つが変更毎に完全なコピーを作るIArrayインタフェースで、 もう一つがコピーなしで破壊的操作ができる代わりにモナドを通した操作しか認めないMArrayインタフェース。 だから、この点に関しては問題ない。科学技術計算をする上で他に障害が無いかは保障しかねるけど。 222 名前：デフォルトの名無しさん mailto:sage [2006/06/29(木) 06:40:16 ] >>221 MArray インターフェースですか。 そういうのが有ったんですね。それで勇気が出ました。とっても重要な情報です。 多分、他には根源的な支障はないと思います。 あともう一つ高速化手法として 最近流行の並列プログラミングもしたいのですが、 こっちは Haskell ではまだまだの段階なのかな？と勝手に思っています。 223 名前：デフォルトの名無しさん mailto:sage [2006/06/29(木) 08:38:35 ] >副作用があることと、代入スタイルのプログラミングができることを混同しているように見える。 IORef等への参照セルへの代入は「副作用」として知られていますが何か？ 少なくとも空間効率を意識したプログラミングは副作用がないとできない。と思う。 時間効率についてはオーダーの議論で逃げればいいけど。 224 名前：デフォルトの名無しさん mailto:sage [2006/06/29(木) 08:43:28 ] >絶対流行らない。 >仕様を理解してもらえないと思う。 C++のバッドノウハウ集や、Javaの複雑なgenericsを理解できるなら、 Haskellの多相型や型クラスを理解するのはそう難しくはないでしょ。 GoFのVisitorやMementoパターンが理解できるなら、高階関数を使いこなすのも特に問題ないかと。 どれも一時期流行したもの。 Haskellが凡人に理解できないと思うのは、それこそ選民意識じゃない？ 225 名前：デフォルトの名無しさん mailto:sage [2006/06/29(木) 09:11:42 ] >IORef等への参照セルへの代入は「副作用」として知られていますが何か？ 言葉遣いの問題だが、副作用ってのは「関数適用や式の評価に際して計算以外のことを行うこと」 であって、IORefの操作はこの定義に当てはまらないので副作用とはいえないと思う。 そのためにわざわざ「代入的プログラミング」という言い方をしたんだが。 >少なくとも空間効率を意識したプログラミングは副作用がないとできない。と思う。 >時間効率についてはオーダーの議論で逃げればいいけど。 言葉の問題を除いて、同意。 226 名前：デフォルトの名無しさん mailto:sage [2006/06/29(木) 15:06:19 ] IORef とかって、IORef とかを取り除く時にコピーが発生するんじゃないの？ 227 名前：デフォルトの名無しさん mailto:sage [2006/06/30(金) 01:40:42 ] でもまあ、Haskellで科学技術計算なんてCに比べると10倍以上遅いんで、 する気にならないですけどね。 228 名前：デフォルトの名無しさん mailto:sage [2006/06/30(金) 05:45:34 ] >>227 あ〜。いいんですよ。とりあえず速度は。 最終的にどんな感じのプログラムになるか実際に見てみたいんですから。 それに計算対象や入力によって速度をそれほど気にしない場合もありますし。 229 名前：デフォルトの名無しさん mailto:sage [2006/06/30(金) 08:10:05 ] C言語でカリカリにチューニングした速い実装を書いて、 Haskellでさくっとかいた実装の出力と比較して検算する (Nバージョンプログラミング) というのはアリかもしれないね。 230 名前：デフォルトの名無しさん mailto:sage [2006/06/30(金) 08:26:59 ] >言葉遣いの問題だが、副作用ってのは「関数適用や式の評価に際して計算以外のことを行うこと」 であって、 わざわざ反論するのも面倒だけど、言葉使いの話をするならば、反論させてもらう。 何度も書くが、副作用(side effect)ってのはIORefへの代入も含むと一般に考えられている。 例えばSICPで、Schemeに代入の機能を入れる所で、side effect bugという言葉が出てくるし、 何より IORefを扱うモナド IOモナドは「副作用」を扱うモナドじゃないか。 IOモナドやState使わないと代入は純粋関数的に書けないでしょ。 適当にぐぐっただけでも(Cleanのマニュアルだが) sky.zero.ad.jp/〜zaa54437/programming/concepts/index3.htm#a6 >代入は、純粋な関数型言語では排除されている。というのも、代入演算子は副作用(side effect)を >伴う為、参照透明性(referential transparency)が破壊されてしまうからである。 「狭義の副作用」という言葉があるのかどうかは知らないが、一般には代入も副作用と考えられている。 231 名前：デフォルトの名無しさん mailto:sage [2006/06/30(金) 09:46:16 ] >>230 誤解を招く言い方だったが、俺が指摘したかったのはそこじゃない。 >何より IORefを扱うモナド IOモナドは「副作用」を扱うモナドじゃないか。 違う。「入出力」を「副作用なしで」扱うモナドだ。 ここで言う「入出力」にはIORefの操作なんかも含める。 なんでこの区別にこだわるかというと、 ・>>210は「Haskellに副作用が無い」という前提で話している。 　だから少なくともこの文脈ではHaskellのIOを副作用と呼ぶのは不適切。 ・unsafePerformIOなどによって導入される本物の副作用との区別ができたほうが良い。 という理由から。 232 名前：デフォルトの名無しさん mailto:sage [2006/06/30(金) 12:27:10 ] ああ、言いたいことは分かったよ。 IOモナドは副作用を陽に扱わない。 Haskellは、副作用を表現するIOモナドを純粋関数的に「繋いで」、mainとして定義するスタイル。 繋いだアクションが逐次実行されることで、実行形式は副作用を伴うプログラムとして動作する。 一方、unsafePerformIO はIOモナドとは違い、Haskellの遅延評価のステップの途中で 本当に「副作用的に」評価される(純粋関数の枠を壊している)。 それを言いたいのは分かった。 >・>>210は「Haskellに副作用が無い」という前提で話している。 >　だから少なくともこの文脈ではHaskellのIOを副作用と呼ぶのは不適切。 どうしてその前提が読み取れるのか分からんけど。 というか明らかに IOモナドを副作用を扱うモナドでそ。unsafePerformIOと区別したいのは分かったが。 Haskellで副作用を表現できることはもはや常識なわけで、 「Haskellは副作用を(表面上)追い出した為にIOモナドというややこしい形でしか扱えない。しかし副作用は効率的なプログラムを扱う上で必要悪だよな。もっと簡単にならんのか？」 という風に読んだ。 233 名前：とおりすがり mailto:sage [2006/06/30(金) 22:38:41 ] ・形式的にはHaskellのソースコードの中に副作用を伴う要素は無いものとみなせる。 ・副作用をいわば「ランタイム側に追い出す」ための仕組みがIOモナド。 　そういう意味でIOは副作用を扱っているといえる。 （・でも本当に副作用を持つ禁断の関数も実はある。） ってことでFA? 状態機械の仕様をフローチャート的にではなく構成的に 定義できるのってキモチイイな do構文使ってると普通の逐次処理言語とあまり変わらないけど。 まあ気分の問題で。 234 名前：デフォルトの名無しさん mailto:sage [2006/06/30(金) 23:03:53 ] >do構文使ってると普通の逐次処理言語とあまり変わらないけど。 そう。というかlet文も考えようによっては逐次型っぽい。 for文やwhile文がなくて、オブジェクトのアップデートができない事を除けば、 手続き型言語も関数型言語もそんなに変わらない。 更にHaskellは純粋関数的なので順序を気にしなくていいんだけどね。 235 名前：とおりすがり１ mailto:sage [2006/06/30(金) 23:52:32 ] fib = 1:1:zipWith (+) fib (tail fib) = 1:1:2:3:5:8:12 .... これはおなじみHaskell版フィボナッチ数列 遅延評価の例として一度はお目にかかるという。 これはリストのある要素の値を 遅延評価を利用して 同じリストの手前の要素から構成しているのがミソ。 #解説は「フィボナッチ Haskell」 でググるといっぱいでてくるので略 236 名前：とおりすがり２ mailto:sage [2006/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 名前：とおりすがり３ mailto:sage [2006/06/30(金) 23:59:14 ] >>236のミソは ループや分岐に相当する(IO x)は無いってこと。 なぜそれでこまらないのかというと、 フィボナッチ数列のときに ある要素を決定するのにそれより前の要素の値を利用したように 条件分岐で次の処理として(IO y)を繋げようか(IO z)を繋げようか決めるのに それより前の(IO x)の値をみて決める事ができるから。 あるいはそこで打ち切ってプログラムを終了してもいい。 つまり、Haskellで副作用のあるプログラムを書くってことは フィボナッチ数列を定義するように コマンド列を定義しているようなもの 238 名前：とおりすがり４ mailto:sage [2006/07/01(土) 00:03:08 ] とまあ そういう風にオイラは理解したわけです。 239 名前：デフォルトの名無しさん mailto:sage [2006/07/01(土) 06:11:52 ] 合ってると思うっす。 240 名前：デフォルトの名無しさん mailto:sage [2006/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 名前：デフォルトの名無しさん mailto:sage [2006/07/01(土) 08:52:27 ] 手続き型言語の代入でも、裏で全メモリの値を渡してると考えれば副作用ではないな 242 名前：デフォルトの名無しさん mailto:sage [2006/07/02(日) 00:07:46 ] >そうでない言語(たとえばHaskellやClean)の話をするときはちゃんと区別して話したほうが良いと思う。 なるほど、完全に同意しましたです。すまない。 更に How to declare an imperative の文がとてもわかりやすい。ありがとう。 入出力、といえば副作用と思っていたけど、同期ストリームもそうだよな。 自分ではhGetContentsくらいしか使わないけど。 linear typeで入出力ができるのもCleanのマニュアルの序章で分かる(world as value)。 しかし。。。continuationでどうやって入出力するのか?? >それとも、「副作用」という言葉をそういう意味で使うことを支持する典拠があったりするのか？ あなたが言うように、副作用と入出力を混同していた。典拠はない。 243 名前：242 mailto:sage [2006/07/02(日) 00:15:21 ] 誤解を招くと悪いので少し書くと、hGetContents自体の型は Handle -> IO StringなのでIOモナド。 ただ、hGetContentsから得たStringは遅延評価の度にファイルやネットワークデバイスから読み出される。 (データがなければブロックする) この「遅延読みString」を処理する部分は旧来のストリーム・プログラミングっぽい（よね？ 244 名前：デフォルトの名無しさん mailto:sage [2006/07/06(木) 22:15:48 ] C言語だと言語仕様として再帰は32回までしか保証しない(だっけ)とかだから、 再帰による33回目の関数呼び出しとそうでない呼び出しで意味が大きく変わってくる。 245 名前：デフォルトの名無しさん [2006/07/06(木) 23:06:29 ] >>244 うそつけ。Cの仕様書にそんなこと書いてないぞ。 246 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 04:38:43 ] 何かそういう類いのあった気がするよ。 for のネストの回数とか意外なものに、 最低保証回数が仕様として決められている。 247 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 06:46:28 ] つ[5.2.4 Environmental limits] だが、再帰回数はない。 248 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 08:25:32 ] そうなのか。 249 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 08:32:38 ] >>244 少し考えれば、再帰を32回まで完全保証する事が不可能だって分かるだろ。 250 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 09:19:47 ] へ？不可能なの？スタックさえ確保しておけばいいんじゃねーの？ 251 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 09:22:30 ] >>249 ああ、確かにそうだな。 252 名前：デフォルトの名無しさん mailto:sage [2006/07/09(日) 01:07:02 ] >>250 ローカル変数がスタックに取得される仕様だと 消費されるスタックの量が予測できないだろ。 ローカル変数と配列の最大数×配列サイズの制限？から再帰の 最大数を決めてもあまり意味があるとも思えない。 ローカル変数をスタックに取らないといけない決まりも無いけど ほとんどの実装で受け入れられないモノを標準仕様を するわけにはいかなかったんだろう。 ってスレ違いごめん

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef