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

1 名前：デフォルトの名無しさん mailto:sage [2005/09/30(金) 01:34:05 ] C/C++＞＞＞＞(越えられない壁)＞＞＞Haskell 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 ローカル変数がスタックに取得される仕様だと 消費されるスタックの量が予測できないだろ。 ローカル変数と配列の最大数×配列サイズの制限？から再帰の 最大数を決めてもあまり意味があるとも思えない。 ローカル変数をスタックに取らないといけない決まりも無いけど ほとんどの実装で受け入れられないモノを標準仕様を するわけにはいかなかったんだろう。 ってスレ違いごめん 253 名前：デフォルトの名無しさん mailto:sage [2006/07/09(日) 20:45:30 ] ローカル変数のスタック上のサイズは固定でしょ。言語にもよるけどCやC++ならそう。 そんなことも分からんやつしか居ないの？ 254 名前：デフォルトの名無しさん mailto:sage [2006/07/09(日) 21:39:50 ] もっと優しく言ってくれ 255 名前：デフォルトの名無しさん mailto:sage [2006/07/09(日) 21:49:20 ] おれにはツンデレでお願い 256 名前：デフォルトの名無しさん mailto:sage [2006/07/09(日) 22:30:35 ] し、Cの言語仕様にスタックなんて概念は規定されてないんだからねっ！ 257 名前：デフォルトの名無しさん mailto:sage [2006/07/09(日) 22:34:52 ] >>244-256 スレ違いの議論はこの辺で終了して下さい 258 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 00:31:31 ] >>253 だからその固定の変数を最大いくつ宣言できるか判らないでしょ 259 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 02:01:36 ] さらにC99だとスタック上の配列のサイズは実行時に決定できる。 すれ違いなのでこの辺までにしとこう。 260 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 06:35:50 ] >>259 >>256 261 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 12:53:18 ] >>259 偉そうに大嘘で締めないように。無能はしゃしゃり出ちゃいやん。 ま、スレ違いだからやめとくか。 262 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 13:38:02 ] ここは一応 Haskell 本スレじゃないから、 少々脱線した所でどうでもいい気もするけどね。 263 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 13:52:49 ] 少々なら良いけど3日も続くとね…。 面白い話でもないしw 264 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 22:01:26 ] >>260 細かいな。記憶クラスが auto の配列って言えばいいのか？ >>261 C99のマニュアル読んでね。 265 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 22:17:04 ] げ。知らなかった。 int a[hoge()]; なんてやっても動くじゃん。 いままで関数内で捨てちゃう配列にmalloc使っていたのは無駄だったのか。 HaskellとRubyばっかり使っていたせいで、Cはメモリ管理がめんどくさい言語 だとばかり思っててちゃんと調べてなかった。 266 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 22:31:16 ] C99 じゃないと無理だけどな。 267 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 22:34:35 ] Cは99なのにHaskellはまだ98なのかー 268 名前：デフォルトの名無しさん mailto:sage [2006/07/10(月) 22:46:53 ] >>264 しかしそう言い直した途端にスタックの話じゃなくなる罠。 いつまでもひきずってもつまらんので、Haskellの豆知識でも。 GHCでコンパイルされたプログラムがスタックをどのように使うかはわかりにくい。 再帰呼び出しでスタックが深くなっているようにも見えないのにオーバーフローを起こしたりする。 これは、スタックの消費が、呼び出しの深さではなく正格な関数の適用のネストの深さに比例するためだ。 例えばg x = x + 1 - 1 + 1 - ..たくさん.. - 1という関数を定義すると、呼び出しの深さは一であるにも関わらず スタックを大量に消費する。正格な関数である(+)と(-)の適用が深くネストされているからである。 269 名前：デフォルトの名無しさん mailto:sage [2006/07/11(火) 09:42:39 ] スタックが足りなくなったら適当に評価を行って遅延してるのを減らすとか できないの? 270 名前：デフォルトの名無しさん mailto:sage [2006/07/11(火) 11:27:31 ] >>264 嘘を拡大するためだけに前言撤回で復活しなくてよろしい。 271 名前：デフォルトの名無しさん mailto:sage [2006/07/11(火) 19:11:00 ] >>269 未評価の式はヒープに保存されているので、それ自身はスタックを消費しない。 スタックが溢れるのは式を評価しようとしたとき。 272 名前：デフォルトの名無しさん mailto:sage [2006/07/14(金) 00:15:50 ] >>271 スタックあふれた時はヒープ上にスタックを移動して計算したりできないの？ 273 名前：デフォルトの名無しさん mailto:sage [2006/07/14(金) 01:15:45 ] >>272 なんで俺らがそこまでしなきゃいけないわけ？お前何か勘違いしてない？ 274 名前：デフォルトの名無しさん mailto:sage [2006/07/14(金) 01:28:55 ] スタックが溢れそうなのにヒープに余裕があるなどと思ってる素人はモノ喋んな。 275 名前：デフォルトの名無しさん mailto:sage [2006/07/14(金) 03:16:34 ] ・・・ 276 名前：デフォルトの名無しさん mailto:sage [2006/07/14(金) 11:25:17 ] 頭が良くない人ほどすぐ怒る 277 名前：デフォルトの名無しさん mailto:sage [2006/07/14(金) 17:56:55 ] >274は50年前の世界からやってきた時空の旅人 278 名前：デフォルトの名無しさん mailto:sage [2006/07/15(土) 19:52:26 ] >>277 ♪ぼくらは　たびびと 　ときの　たびびと♪ 279 名前：デフォルトの名無しさん mailto:sage [2006/07/16(日) 04:35:58 ] Haskellは、お利口さんに見られたいけど誰もそう見てくれない 哀れな人たちの嫉妬を一身に買って出てるよね。 280 名前：デフォルトの名無しさん mailto:sage [2006/07/16(日) 14:04:58 ] 嫉妬というか、そういう奴らがすがるための言語。 知的な奴は、そういうことを考えずに自己拡張しまくりのLispを使う。 281 名前：デフォルトの名無しさん [2006/07/18(火) 13:14:51 ] 諸君議論しているかね？ 282 名前：デフォルトの名無しさん [2006/07/19(水) 01:50:46 ] Haskell 面白そうなので調べていたら、Clean にたどり着いた。 両方とも、ちょっとしか解ってないが、現時点ではClean の方が良さげに思える。 でも、一般的にはHaskell の方が流行ってるみたい…。 なぜなんでしょう？ Haskell の方が良い！という人の意見が聞きたいです。 283 名前：デフォルトの名無しさん mailto:sage [2006/07/19(水) 02:56:48 ] ttp://groups.google.com.au/group/comp.lang.functional/msg/c09cb40a66558a19 個人的にはCleanって閉鎖的な印象を受けるからHaskellに流れてるだけ。 どっちも元はMirandaだからCommon LispとSchemeくらいにしか違わないんじゃないの？と ろくすっぽCleanを知らないで書いてみる。

---

---

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

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