【アンチ】関数型言語は使えない【玩具】

1 名前：デフォルトの名無しさん [2011/11/08(火) 18:06:57.51 ] 関数型言語は学習コストが高すぎる。 玩具として、研究者や学生の自己満足として、 教科書や黒板を賑わすアクセサリーとして、 あるいは頭の体操としての価値は認める。 だが、仕事ではほとんど使い物にならない。 やれば作れる、実際に作った、そんな言い分は聞き飽きた。 主要なソフトウェアのほとんどは非関数型で書かれている。 関数型がプチブームだが、爆発的に採用が増えているとも考えられない。 いずれ関数型のブームは去るだろう。 仮に関数型が生き残ることがあったとしても、 手続的な言語における一部の機能としてだろう。 175 名前：デフォルトの名無しさん mailto:sage [2011/11/19(土) 23:04:29.52 ] >>172 pyths n = [(x,t,z) | x <- [1..n], y <- [1..n], z <- [1..n], x^2 + y^2 == z^2] 176 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 00:20:09.18 ] >>175 yの代わりにtが混入してる。 177 名前：172 mailto:sage [2011/11/20(日) 02:00:52.12 ] >>174 おｋ把握 def pyths(n) (1..n).flat_map{|x|(1..n).flat_map{|y|(1..n).map{|z|[x,y,z]}}}.select{|x,y,z| x**2 + y**2 == z**2 } end こんなもんかなあ、Rubyだと。 178 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 02:54:00.73 ] これでもいい気はする。 def pyths(n) (1..n) .to_a .combination(3) .select{|x,y,z|x*x+y*y==z*z} end 179 名前：172 mailto:sage [2011/11/20(日) 02:59:41.99 ] …Array#combinationとか初めて知ったぜ 180 名前：デフォルトの名無しさん [2011/11/20(日) 06:49:14.50 ] >>175 >>178 haskellよりrubyの方が短いね 181 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 19:48:27.46 ] なあ、そもそも俺はピタゴラス数を求めるプログラムにしか見えないんだが 結局、何を求めるプログラムなわけ？ 関数型言語って人が見て何をやってるのか分からない言語じゃないのか？ 182 名前：デフォルトの名無しさん [2011/11/20(日) 19:57:20.80 ] 内包表記と関数型言語の関係ってどう解釈したらいいんだろうね。 183 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 20:27:28.37 ] 喫茶店で若いOL風の女性がCTMCP読んでて萌えた 184 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 20:53:48.34 ] そこで 俺のmozartでozozしないか？と聞かないと。意味不明 185 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 21:19:26.49 ] 正直、174だろうが175だろうが、178だろうが それぞれの熟練プログラマが書いたら効率は そんなに変わらなくね？ アセンブラとかなら変わるだろうけど 違うとしたら、178が何をやってるのか理解するのに勉強が 必要だというぐらいだろ 186 名前：デフォルトの名無しさん mailto:sage [2011/11/20(日) 23:21:58.23 ] >>181 ＞ 関数型言語って人が見て何をやってるのか分からない言語じゃないのか？ それは手続き型言語 187 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 00:40:13.63 ] 手続きは 資材を並べていく感じ 関数は 資材を加工する機械に通してる感じ。 188 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 01:07:17.13 ] >>186 関数型は未だにパッと見でわからないです。 189 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 01:08:58.40 ] 関数型は組み合わせ 手続き型は積み重ね 190 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 02:42:58.91 ] 手続き型言語は古典力学 　時間の流れは一方的、開いた系で現実的 関数型言語は量子力学 　時間の流れは存在せず、閉じた系で理論的 191 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 03:23:52.64 ] 手続きは乱雑 関数型は整理 192 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 07:42:39.76 ] 手続き型は系列 関数型は羅列 193 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 08:02:53.73 ] >>174 元ネタが見つからないのでわからないのですが、int しか使わない縛りとかあったのでしょうか。 List<Integer[]> list = new ArrayList<Integer[]>(); for (int x = 1; x <= 100; x++) 　for (int y = 1; y <= 100; y++) { 　　double z = Math.sqrt(x * x + y * y); 　　　if (z <= 100 && (int) z == z) list.add(new Integer[] { x, y, (int) z }); 　} 194 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 08:26:01.80 ] >>193 それ、間違い。浮動小数点数の扱いに慣れてない？ 195 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 08:30:13.71 ] すみません、わからないので教えてください。 196 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 08:36:50.09 ] なんだか、遂に、Ozまで流行りだした。 197 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 08:46:16.00 ] >>196 Prologには既にブームの兆しがあるし、関数型の周辺に 猛烈な勢いで関心が拡がって、渉猟されてる感がある。 198 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 08:48:26.52 ] >>34 Erlang人気は意外だった。 199 名前：205 mailto:sage [2011/11/21(月) 08:50:34.60 ] 何か壊れてる？ >>34 でなくて、>>196だね。 200 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 09:32:35.99 ] >>185 理解するのに勉強が必要って…どれも必要だろう 201 名前：デフォルトの名無しさん mailto:sage [2011/11/21(月) 10:25:56.50 ] >>181 まんま、ピタゴラス数を求める関数でんがな パッと見で分かってるじゃん 202 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 02:11:23.03 ] >>188 当然関数型でも解りやすいのと解りにくいのがある。 Perlの変態コードだってパッと見わからんでしょ。 それに手続き型に何年親しんでから、関数型をどれくらいやったのか？ 単なる慣れの要素もある 203 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 05:13:59.50 ] >>200 その勉強量が違うだろ 多くの人が知らない概念を使ってる場合、 その多くの人は新たに勉強する必要がある 知ってる場合は勉強する必要はない 204 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 12:55:21.67 ] >>202 関数型でわかりにくいというのはどこを指してるのか？ (reduce .. (filter .. (map .. (map .... もなぁーど ... 基本は再帰を乗り越えなアカンっていうのはある。関数型で バッドノウハウだと思ってるのは、末尾再帰くらいかも。 205 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 15:35:23.14 ] ポイントフリーな書き方が出来るようになれば カッコも再帰も最小限ですむよ 206 名前：デフォルトの名無しさん [2011/11/22(火) 16:09:47.64 ] >>205 ハスケルだったらね。ポイントフリーのほうが楽なこと多いよね。 あれで必要以上に複雑なことしなければ、誰だって使えるようになるでしょうよ。 207 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 17:12:14.50 ] 関数型が分からん奴ってunlambdaでもやってんの？ 208 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 19:41:54.44 ] ポイントフリーは難解 209 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 20:10:56.45 ] 関数型が広まらなかったのは、ハードウェアの制限のせい ６４ビットOSが普及すれば、スクリプトより楽な巻子型言語が普及・・・して欲しいなぁ… 関数型言語って、基本的に簡単だけど、要求スペックも無限のメモリ、無限のクロックなんだよね・・・ 通常アプリでメモリやクロック、スレッドを気にしなくてよくなったら、普及すると思うんだ 210 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 20:11:45.59 ] ｘ巻子 o関数 211 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 20:20:11.59 ] 追記（？） それを解消するためのアルゴリズｌムであり、末尾再帰なんだと思う 212 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 20:30:08.07 ] プログラミング言語は道具に過ぎないってことを忘れてるだろ 現実を無視しちゃいかんよ 213 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 21:00:40.61 ] 193のどこが間違えているのか教えてください 214 名前：デフォルトの名無しさん [2011/11/22(火) 21:15:40.50 ] プログラマーか否かに関わらず、 人は手続型で思考する。 だから、先入観の無い子供でも 関数型は手続型より難しいと感じる。 S式や再帰を強調し、ほら簡単だろと言うから 関数型は嫌われてメジャーになれない。 215 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 21:37:40.15 ] 手続き型が自然なのは同意だが 一方数学というのは思考を簡約できる道具なわけで 手続きに関数の表現を盛り込んでいくのがいいと思う 216 名前：デフォルトの名無しさん [2011/11/22(火) 21:41:57.49 ] 手続きが自然ってほんとかな？ 疑問だな。 217 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 21:48:11.68 ] 高校数学あんまやってないプログラマのこと考えたら自明だろ 218 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 21:57:05.12 ] むしろC的なメソッドを先にやってから 中？高？で関数を教えたほうがいいかもしれん 219 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 21:59:19.13 ] 手続きが思考に近いってのには異論はない 220 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 23:01:53.48 ] 末尾再帰がバッドノウハウてどういう意味？ 221 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 23:09:42.98 ] 今日考えていたんだが、 UMLで設計するんじゃなくて、DFDで設計したらいいんだよね？ 222 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 23:23:19.23 ] 状態がないのに自然なわけない 223 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 23:30:49.75 ] 関数言語の簡単さ、綺麗さって オフサイドルールの面も大きいと思う 224 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 23:35:06.03 ] 中括弧言語は それだけで下品になるからなぁ。 225 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 23:51:03.48 ] >>223 MLをディスってるんですか？ 226 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 23:54:47.57 ] >>206 ポイントフリーは読みにくい型エラーの温床になるから あんまりやらないようにしてるんだけど 227 名前：デフォルトの名無しさん mailto:sage [2011/11/22(火) 23:55:21.01 ] でもHaskellって実際のコード見ると妙な演算子があちこちにいるよね <+>とか.|.とか>>=とか 228 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 00:24:00.14 ] ポイントフリーといえば、ほくろ付き巨乳とかあるね。 (.).(.) 229 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 03:27:23.65 ] >227 そうそう、だいたい奇天烈演算子大会になってるよね。 で、演算子の字面見ても殆どイメージ湧かないし。 いや、別に二項演算子が嫌いなわけじゃないけど、セルフドキュメント性が低すぎる。 230 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 05:48:44.62 ] >>214 でも、なぜか x = x+1 等しくないよ？という入門者の意見の多いこと多いこと… この段階では、関数型言語の方が自然らしい 231 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 05:59:42.50 ] でも、そこで躓く入門者というのを見たことがない。 都市伝説なのではないか。 232 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 06:46:58.39 ] >>227 Haskell使いの目指すところが手続的な個所も関数的に書こうとする事だからね… そこが、ちょっと珠に傷って気はする 手続的に書く方が自然なところは手続的に書いて、関数的に書く方が自然なところは関数的に書けば良いのに、とは思うよ 関数的に書ける所では、デッドロックとか考える必要なくて、簡単に並列化できるし、手続的に書く方が自然なところは普通に手続的に書けるんだしさ 233 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 06:51:12.91 ] >>230 でも「三角形のこの頂点のx座標y座標は動かせないよ」と言っても どうして？と言われるぞ… 234 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 06:52:20.60 ] >>231 居た ｘとｙの値を交換するってので、 temp = x x=y y=temp ってするじゃない？ 何でtempが必要なのか。いくら説明しても分からない奴がいた。 メモリの仕組みも習ってるはずなのに、理解できないらしい。 多分、メモリの仕組みそのものが理解できてない。 関数型言語の場合 タプルで受け取って、そのまま交換すればいい swap (x,y) = (y,x) これなら、そういうレベルの人でも分かるだろう。 ・・・と、思いたいｗ 235 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 06:54:08.09 ] >>233 動かす（新しい座標を返す）関数作ればいいだけだろ 236 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 06:55:17.51 ] ハスケラが言う自然ってのはハスケルっぽく書けるということで、 それが日本語で普通に考えた時のやり方と全然違っていても あくまでハスケルっぽいほうが自然なんだよ。 同じように、ハスケラが言う関数プログラミング的というのは ハスケルっぽく書いてあるということで、MLとかLISPとかで スマートに書いてあっても、それは関数プログラミング的じゃないんだよ。 237 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 06:56:36.72 ] >>234 手続き型でもswapぐらい普通に実装できるが。 def swap(x,y): 　　return y, x 238 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 06:58:55.33 ] >>235 そんなので騙せるのは大人だけだよ。 新しい三角形をつくったって、元の三角形は動いてない。 239 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 07:25:25.55 ] >>236 日本語とか以前として、算数/数学っぽく書けるって感じかな 数学に国境はないから、日本とか外国とか関係ない 240 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 07:28:40.77 ] >>237 それを教えてない段階で疑問持たれる訳で 関数型言語は数学ベースだから、そう言う疑問を持たれにくいし、疑問への回答も論理的 (こう言う機能が有るよ!!ではない) 241 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 07:30:44.56 ] >>238 それが、後から元の三角形が必要になった時の利点 (手続き型だと新しい三角形を作る前に保存してないといけない) 242 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 07:44:58.98 ] >>240 教えてない？ あんたが知らないだけでしょｗ 関数型の人ってどこまでジコチューよｗｗ 243 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 07:46:05.59 ] >>241 それじゃ子供どころか大人も騙せないぞｗ それで説明できたつもりでいるようだから、関数型はダメなんだよ 244 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 07:48:17.33 ] こういうスレにわざわざ議論しにくる人は、 叩く方も含めてほぼ100%関数型言語ユーザと思われ。 関数型言語の「メリット」は説明されなくても分かってるのでは。 Haskellでグラフのデータ構造を定義する上手い方法はあるのだろうか。 class Node { Set<Node> edges; ... }; 普通のオブ指手続き言語ならこれだけの話だが。 245 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 07:48:25.78 ] >>239 ハスケルじゃ関数名や変数名はつけないのか？ mapとかfoldとかfilterとかは世界共通の言葉なのか？ ハスケラのジコチューっぷりは世界共通なのか？ 246 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 08:21:07.82 ] >>244 俺はハスケラじゃないんで分からんけど、それってHaskellじゃ難しいの？ データ構造の定義に手続き型とか関係なさそうだが…… 247 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 08:35:38.33 ] >>246 edges への破壊的代入が出来ないとしたら？ 248 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 08:37:53.79 ] Google Trendsで現実見て来いよ 249 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 09:52:48.08 ] Haskellでも破壊的代入はできるんだけどね。 デフォルトじゃできないだけで。 250 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 11:07:12.02 ] 正直、記号の分かりにくさはどっちもどっちじゃないかな >>230 っ PASCAL っ COBOL 他にも手続き型で代入演算子が = でない言語はあったと思うぞ >>234 それも最近の言語は x,y = y,x と書けたりするからなあ 251 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 11:46:48.72 ] >>234 分かるまで、ハノイの塔を実際にやらせてみるとか、どうだろうね。 252 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 11:47:34.34 ] 多重代入サポートしてる言語でも y = x x = y と書いたらもちろん意図した結果にはならないので、なぜこう書いたらダメなのか というのはどのみち理解しないといけないような 変数と値のセマンティックスは値型／参照型云々でも違ってくるので 初心者にとってはそう簡単じゃないのでは エイリアシングからくる初心者にとっては不可思議な問題を とりあえず考えなくともよいという意味では、参照透明だと確かにわかりやすいのかも 253 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:05:31.01 ] 多重代入サポートしてる言語で y = x x = y と書くのは例えばどんなとき？ 僕分からないんで教えて下さい。 254 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:12:03.82 ] 多重代入をサポートしてない言語なら、どんなときに書くか分かるのか？？？ 255 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:13:14.58 ] 二行目の x = y には何の意味も無いよね〜 256 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:13:58.34 ] >>245 え、そこから英語で躓くのかよ 変数や関数に対した英単語でないだろ 257 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:16:56.56 ] 難しい話じゃなくて 関数を書くのは関数型言語の方が楽 手続きを書くのは手続き型言語の方が楽 ってだけじゃねーの？ 258 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:27:23.12 ] デメリット側から言えば たかが map のために functor が必要になるのと たかが代入のために monad が必要になるのと 究極の選択。マシな方を選べ。ってだけじゃね？ 259 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:29:13.69 ] で、具体的には？ 260 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:29:44.44 ] 個人的には。関数は第一級な方が当然便利。 参照透明性は要らん。言語に強制されるのは邪魔なだけ。 261 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:30:55.70 ] なので、純粋ではない関数型言語か closure を扱える手続き型言語がいいね。 262 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:32:17.07 ] ほうほう、君の中ではそうなんだね。よかったね。 263 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:32:31.16 ] で、君は？ 264 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:33:26.59 ] で、君は？ 265 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:33:38.46 ] ここで逃げるのが Haskell 厨 266 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:39:17.71 ] ほんとHaskell厨はクズだな 267 名前：デフォルトの名無しさん [2011/11/23(水) 13:40:57.32 ] これは Haskell 厨のカスさがよく分かるスレですね 268 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:41:25.89 ] っていうか Haskell ってダッセーよな 269 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:43:40.50 ] Haskell はOSすら書けない糞言語 270 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:49:24.41 ] Hasmelって言語があるそうだな 271 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:56:39.61 ] １行 連続ポスト厨が現れるとスレの質が相当低下するからな。 もうこのスレもおしまいかも。もともとフレーマー用だから いいっか。 272 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:57:50.70 ] なるほど、Haskell 厨はそうやって逃げるわけね 273 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:58:58.14 ] もういいか？ 参照透明性って、プログラマの責任で保証するというのでも 大した手間じゃないような気がするんだよな。 言語として副作用を持たないということは本当にメリットなのか？ デメリットの方が大きい気がする。 純粋だってのは認めるが、それは数学的な美学の問題。 プログラマの利益にならなきゃプログラミング言語としては使えないだろ。 274 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:59:04.58 ] 低下って 元々質（）の低いスレで何言ってんだか いいっか。 275 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 13:59:32.66 ] もういいか？ 参照透明性って、プログラマの責任で保証するというのでも 大した手間じゃないような気がするんだよな。 言語として副作用を持たないということは本当にメリットなのか？ デメリットの方が大きい気がする。 純粋だってのは認めるが、それは数学的な美学の問題。 プログラマの利益にならなきゃプログラミング言語としては使えないだろ。 276 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 14:00:33.80 ] 結論：Haskell はクズ 277 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 14:38:01.16 ] >>220 最適化をしようと思ったら、末尾再帰でないものでも無理にでも末尾再帰 のフォームに変換しないといけないけど、それは言語の文法上の話じゃなくて コンパイラやインタプリタより下層の制約から来てる。そこからバッドノウハウ 臭さがある。そんな制約なしにどんな再帰でも最適化されるようなものだったら 末尾再帰にこだわらなくてもいいだろうしね。 278 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 14:46:48.58 ] 多分、扁桃体から直接手を動かしてそうな人は関数型やってる ほとんどの人は相手にしないんだと思う。やっぱり情動の制御 できるように前頭葉を鍛えなきゃ。頑張ってリハビリしたほうがいいよ。 279 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 14:49:42.96 ] >>278 どうしよう、これ．．． 280 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 15:16:18.58 ] >>277 逆に考えるんだ。 そもそも call を jmp に置き換えるのが末尾再帰除去であり、 末尾再帰除去の中で call が自分自身を呼び出している場合がループなのだ。 つまり、手続き型言語の連中が当たり前のように使っている ループという制御構造それ自体がバッドノウハウなのだ。 彼らはバッドノウハウだと思っていないようだが。 281 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 15:20:47.90 ] そうだね。 282 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 15:22:29.65 ] 自動的に末尾再帰に変換して除去してくれるのが理想の最適化コンパイラ ーーーー壁ーーーー プログラマが末尾再帰に書けば除去してくれるのが関数型言語 ーーーー壁ーーーー 末尾再帰を除去できない変わりに破壊的代入とループ構文を導入して プログラマが手作業で末尾再帰除去できるようにしたのが手続き型言語 283 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 15:28:14.17 ] Haskell 使うくらいなら HSP 使うはｗｗ 284 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 15:33:50.46 ] それ随分と目的が違わねｗ 285 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 15:36:18.41 ] HSPは0行でウィンドウが出せる 286 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 16:03:18.11 ] >>280 おれも息を吐くが如く、末尾再帰にはお世話になってるけど、この話と 手続きのループとは話は別かな。 手続きのループに慣れ過ぎると、悪癖プログラマっぽいものしかいなくなる。 少なくともそれで関数をやるとね。せいぜいiterateにしてくれよと言いたく なるけど、副作用の世界が絡んでるから一対一対応じゃない部分があるよね。 見た目も下品なループなんて抹殺すればいいが。藁 287 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 16:05:25.18 ] 万能な Ruby が最強だということが分かった Haskell より速いし 288 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 16:25:00.92 ] alohakun.blog7.fc2.com/blog-entry-812.html 289 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 16:32:58.55 ] あ、勘違いしてた。別ではなかったな。ごめん286取り下げとく 290 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:16:32.58 ] >>287 速い？ ghciは確かに遅いが、ghcでコンパイルした後だとLLじゃ話にならん速さだぞ？ 291 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:23:31.95 ] OCAMLはコンテストでは強いらしいが 初心者ポンと出されて 一日でどこまで作れるようになるかコンテストがあったら 手続きのほうが強そう 292 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:28:20.56 ] どうだろう？ 全くのプログラミング処女を捕まえて、教える場合と、クセのついたプログラマ が学ぶ場合と違ってくるからな。変なクセがある分関数童貞の手続きプログラマ のほうが、プログラミング処女より物分りが悪いってことはよくあるみたいだが。 293 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:32:52.58 ] >>292 具体例も無しに言われても。。。 294 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:36:07.39 ] >>292 例えば？ 295 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:41:50.82 ] OCamlは関数型だけど手続き型でもあるから 純粋指向の人達には軽く見られるけど、習得はし易い部類かと 296 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:44:26.35 ] IO Monadって結局は副作用をランタイムに押し付けて 言語レベルでは知らんぷりしてるだけじゃん。 「臭いものに蓋」で、副作用による依存性の問題に 正面から向き合ってないよね。 297 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:47:27.76 ] 「ｹﾝﾛﾝ!ｹﾝﾛﾝ!」 「うわ、何アイツ、キモ・・・」 「ｹﾝﾛﾝ!ｹﾝﾛﾝ!」 「なんか臭いし・・・関わらないようにしようぜ」「そうね・・・」 298 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:49:00.65 ] ハスケラみたいな排外的で独善的な奴に仕事を任せたくないよね ハスケルで有名なプログラムって、グラディウスとかパールとか 既存のプログラムの書き直しばっかりじゃん 299 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:52:27.80 ] Haskell 厨 「我々は高度な理論に基づいてプログラミング言語を扱っている。実装重視の土方とは違うのだよｗｗｗ」 「またあんなこと言ってるけど」 「いいよ、あいつにはリストの長さを求めるプログラム書かせとくからｗｗｗ」 「そりゃ大仕事だなｗｗｗｗ」 300 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:56:20.95 ] >>293-294 教える経験のある人たちからはそうゆう話は時々出てくるくらい だけど、違うと思うならそれでもいいよ。ずぶの素人より知ってるほうが 難しく感じるっていう話は、多少ショッキングだろうから。 しかしながら、この手のパターンはよくある話なんだよね。 301 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:56:54.90 ] >>300 例えば？ 302 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:58:08.89 ] ML系やSchemeが教育で使われる背景もあったけど、調べてくれ。 303 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 17:59:22.73 ] ほらね。結局逃げるんだよ。 304 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:00:14.49 ] >>302 それはプログラミングではなく計算理論も合わせて教える場合だろう。 305 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:01:49.68 ] >>300 それはどんな言語、どんなパラダイムでもそうなの。 ハスケルだけ特別、関数型だからみたいな事を言うから小馬鹿にされるの。 306 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:02:06.25 ] なんでこんな滑稽なことが起きるのか？という背景だけは触れておくか なまじっか知ってるために、自分の頭にある今までの学習パターンに当てはめる が実は、当てはめたら沼に入るパターンも多いからさ。 プログラミングで変なクセがついたら矯正しづらいってのもよく知られてる けどな。だいたい学習の王道は、副作用もできる関数型から始めるほうが、 いいからね。手続きから始めると、データ構造まで到達して使えるようになるのに 負担が大きいしね。 307 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:02:23.56 ] 結局>>302の中で完結してるんだから、何言っても無駄だと思うよ。 308 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:02:31.42 ] >277 ×　最適化をしようと思ったら、末尾再帰 ○　実用的な大きさのデータを扱おうとしたら、要末尾再帰 309 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:03:22.48 ] >>305 誰がハスケルを取り上げてそんなことを書いた？ さすがに、これ見た時アホちゃう？と思ったよ。 310 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:03:50.40 ] でも関数型言語って、 少なくとも数学的帰納法をすんなり理解できるところまで教育を受けてないと無理でしょ。 311 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:03:57.09 ] >>306 さっきからその特徴的な改行はなんなの？ 312 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:04:45.13 ] さすがに、これ見た時アホちゃう？と思ったよ。 313 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:05:45.07 ] >>310 高校生レベルならOKってことだね。それがわからんというのは プログラミングするにしても、資材を並べるだけしかできないと思うよ。 論理的に考える素養がなさそうだからね。 314 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:07:37.11 ] >>309 いや、アホはおまえｗ 「初心者のほうが、かえって理解が早いことがある」なんてことは 構造化プログラミングの時にも、 アメリカの初等教育でLOGOが流行した時にも、 オブジェクト指向が普及しはじめた時にも、 同じことが言われていた。 関数型だからとか、もうアフォとしか言いようがない。 315 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:07:58.42 ] >>313 いや、普通にパソコン好きな少年なら、 高校生レベルになる前にとっくに「クセ」がついてるでしょ。という意味です。 316 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:08:35.80 ] 「論理的に考える＝関数型で考える」 完全にカルト信者だｗ 317 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:08:42.76 ] >>313 そういう気持ち悪い言い回しするから友達いなくなるんだよ。 318 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:09:21.24 ] ハスケラ発狂ｗ 319 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:10:35.32 ] >>314 頭悪いな。違ったものをすでにみにつけてるものよりか何もないほうが 吸収が良いことがあるという事から、ずぶの素人とすでにやってる人が 学ぶのでは違う。と書いてるんだが。いい加減、わけのわからん早とちり で勝手に都合よく解釈するのは。。。馬鹿な奴にアホと言われても 屁とも思わんよ。鼻で笑ってるだけだから。 くだらんやつ相手にするのも暇な時間だけにしなきゃ。 320 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:12:30.16 ] >>315 その仮定が適切なのか、ちょっとわからんし、一般的だとは思えないよね。 共通のコンセンサスがないというのだけはわかったが。 321 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:12:37.44 ] 関数型厨の選民思想は見ていて爆笑なのだが、 ご本人達は本気で信じているのだということを思うと可哀想でならない。 カルトって怖いね。 322 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:12:50.12 ] さてはこいつ最近Haskell覚えた高校生だな。 中途半端に頭いいからはてなあたりででかい口叩いちゃう系の。 323 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:12:55.95 ] >>319 だから、一般論としてそういう話があるのは一向に構わないけど、 それと「素人は関数型の方がよい」という主張が繋がらないということでしょ 324 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:14:54.31 ] これはあえてキモい振る舞いでハスケラを演じることでイメージダウンを図るハスケルアンチとみた 325 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:15:48.71 ] 素人に勧めるなら、まずはなでしこみたいに、識別子がほぼ全部日本語の関数型言語を 作ってからだな。 326 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:18:18.61 ] >>323 そ。関数型のところに「構造化言語」「LOGO」「LISP」「Java」どれでも当てはまる。 もっと一般化すると、 空手とかで他の道場で変なクセつけた中学生よりも、 はじめて空手を習う小学生のほうが教えやすい。 あたりまえだってｗ 327 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:18:30.48 ] Haskell厨はキモイなぁ 328 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:18:59.53 ] まあ、どっちから始めるのでも構わないけど最初にやる言語は重要だと思うよ。 逆に、整数型が当たり前のように多倍長な言語で入ってしまうと、 そういう事を気にしなければいけない言語に慣れるのは大変だと思う。 手続き型言語の中で言えば、ポインタやメモリ管理なども同じ問題。 Java→C と C→Java のどちらが「二番目の言語」を覚える障壁が低いのか。 関数型言語の方が、手続き型言語よりも高水準だね。より抽象度が高いという意味で。 そこはそうだと思う。 それ以外の話、使う人のレベルがどうとか、初学者にとってどうとか、そんなのは議論の余地大有り。 329 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:19:18.48 ] >>326 うるさい氏ね 330 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:20:06.65 ] >>328 そうだな！君は正しいよ！！ 331 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:22:03.03 ] 「10の階乗ってね、1*2*3*・・・*9*10ってやることなんだよ。」 これなら小学生でもわかる。 「10の階乗とはnの階乗ならn-1の階乗で、1の階乗や0の階乗なら1なんだよ。」 これを小学生が聞いたら「ﾊｧ?」ってなる。 332 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:22:27.82 ] 関数型言語全般はともかく、IO Monadは手続き型を知らない方が学び易いかもな 知ってたら絶対「なんでこんな面倒なこと覚える必要があるの？」 って気になって習得に集中できない メリットを聞いても「参照透過性がむにゃむにゃ……」みたいな説明しかしてくれないし 333 名前：331 mailto:sage [2011/11/23(水) 18:23:18.61 ] 書き間違えたorz 「10の階乗とはnの階乗ならn-1の階乗にnかけたもので、1の階乗や0の階乗なら1なんだよ。」 334 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:24:14.28 ] >>332 手続き型を知らないひとにはIO Monadをどう説明するの？ 結局は参照透明性ムニャムニャになるでしょｗ だって、それが本当の理由なんだから 335 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:25:02.45 ] ｹﾝﾛﾝ!ｹﾝﾛﾝ! 336 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:25:36.09 ] >>334 うるさい氏ね 337 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:25:46.80 ] >>331 そう。それ実はかなり重要なところだと思う。 手続き型言語でも closure なんかは当たり前に取り込まれるけど、 map や filter といったところは、手続き型言語専門の人にとっても簡単。 fold をスッと納得できるかどうか。そこが壁だね。 338 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:28:03.15 ] >>334 知らなかったら疑問に思わないから、「面倒だな、でもそういうもんなのかな」 って学習するんじゃないかな 可哀想だけど 339 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:28:25.24 ] で、その学習しやすい関数型言語って、具体的にはどれのこと？ まさかHaskellさんですか？ 340 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:28:59.35 ] >>328 > 関数型言語の方が、手続き型言語よりも高水準だね。より抽象度が高いという意味で。 ぷ お前が言う抽象度ってのはラムダ抽象だけだろｗ 世の中には他にも色々な抽象があるんだよ。 例えば、関数型言語は高階述語論理よりも抽象度が高いのか？ 341 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:32:01.99 ] >>340 機械語としての0,1ビット列から、より遠くに離れている方が抽象度が高いという意味です。 342 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:33:39.70 ] なんでHaskell厨ってここまで上から目線になれるのかな 343 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:34:32.32 ] ハスケル使える俺ってスゲエ！って酔ってるからじゃないかな？ 344 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:35:03.53 ] >>296 そもそもIOモナドの導入は、参照透明性を守りながら入出力をしたいという 言語の表層の問題を解決するために導入されたものであって、 「副作用による依存性」とか難しいことを解決しようとしてる訳じゃないから、その批判は的外れ 345 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:35:05.73 ] >>339 はい 346 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:35:50.85 ] >>345 氏ね 347 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:36:52.02 ] はてなの灘高生なみのキモさを感じる 348 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:39:28.71 ] reft x = 3; これでxはintとかに型推論して参照透過扱い、 というのはどう？ 349 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:42:34.80 ] 却下 350 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:43:36.25 ] めんどくせーから、お題出して、各言語で書いてみようず 351 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:44:11.05 ] 全くのプログラミング処女を捕まえて、教える場合と、クセのついたプログラマ が学ぶ場合と違ってくるからな。変なクセがある分関数童貞の手続きプログラマ のほうが、プログラミング処女より物分りが悪いってことはよくあるみたいだが。 352 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:46:02.31 ] 理論が美しい言語はHaskell以外に存在しないからね。 不勉強な君たちには理解できないと思うけど。 353 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:48:16.61 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 354 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:52:30.45 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 355 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:53:18.61 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 356 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:53:34.55 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 357 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:54:13.04 ] 発言をコピペしてそんなに楽しい？ ... 幼稚すぎる。 358 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:55:56.02 ] >>351 逆はポール・グレアム始め多く関数型言語覚えてると手続き型言語でも良いプログラマになると聞くが、どっちが本当なんだぜ？ 359 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:57:06.36 ] x多く o多くの優秀なプログラマが 360 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:57:13.35 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 361 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:57:22.09 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 362 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:57:48.58 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 363 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 18:58:10.25 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 364 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 19:00:52.26 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 365 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 19:04:21.81 ] >>358 理由は簡単なんだ、アルゴリズムを理解するのにschemeやML系というのは すごく助けになる。特に木構造の理解には良いし。 だけど、手続き型というのは、文法ノイズが多いことでアルゴリズムを理解 するときに、混同したりということも起こりえるから。そんなこんなで、 データ構造を扱うのが気楽にできるというのもあって、扱う問題に対して 適切なデータ構造とアルゴリズムを選択できるという利点があるからだよ。 感覚的にわかってたら、C++のSTLだってJavaのCollectionだって扱う感覚 が分かるってことからだよ。 366 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 19:06:03.07 ] なんか真性のキチガイにストークされ始めたようなので、 退散する。キモいもん・・・・。 367 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 19:09:15.35 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 368 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 19:09:24.40 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 369 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 19:10:48.96 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 370 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 19:30:57.75 ] いい加減に汁 そして、正々堂々と>>350 371 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 19:35:49.64 ] ハスケラは逃げる口実を与えてくれたことに対して感謝するべきだなｗ 372 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 19:49:34.85 ] >>365 独善の極みだな 吐き気がする おまえみたいのが関数型の普及を妨げていることに気付け 373 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 19:55:05.79 ] >>371 いや、>>350書いたのHaskellerの自分なんですが… 374 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:00:04.02 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 375 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:00:10.35 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 376 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:00:47.78 ] >>358 理由は簡単なんだ、アルゴリズムを理解するのにschemeやML系というのは すごく助けになる。特に木構造の理解には良いし。 だけど、手続き型というのは、文法ノイズが多いことでアルゴリズムを理解 するときに、混同したりということも起こりえるから。そんなこんなで、 データ構造を扱うのが気楽にできるというのもあって、扱う問題に対して 適切なデータ構造とアルゴリズムを選択できるという利点があるからだよ。 感覚的にわかってたら、C++のSTLだってJavaのCollectionだって扱う感覚 が分かるってことからだよ。 377 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:01:44.27 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 378 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:02:05.78 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 379 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:02:43.18 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 380 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:05:11.95 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 381 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:06:55.40 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 382 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:09:24.66 ] 手続型言語厨の逃げですか？ ほら、>>350 383 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:09:27.45 ] なんで発狂してんだ？ OOPのVisitorパターンが冗長だって仄めかされたから？ 384 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:10:13.38 ] 仄めかすも何も自明すぎて 385 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:10:20.73 ] 便乗荒らしじゃないか 386 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:11:43.84 ] >>350 じゃあとりあえず >>244で。 387 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:12:06.47 ] Haskell で回答出てないので。 388 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:15:17.67 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 389 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:15:49.70 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 390 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:16:10.27 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 391 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:17:45.50 ] >>244 >Haskellでグラフのデータ構造を定義する上手い方法はあるのだろうか。 これ悩むんだよね 前やった時はとりあえず計算量無視で関数を作ってみて あとで速度が必要なところだけ定義は同じで内部でSTモナドを使った関数に置き換えた 木構造がシンプルに書けるといっても破壊的代入がないと 大規模なデータではシンプルなコードは実用的な速度が出ない 実用的な速度を出すには手続き型と同じような書き方を回りくどい方法でとらないといけない あと大規模データを延々と処理し続けるようなプログラムだと 遅延評価は思いがけないところでメモリリークを起こしやすいように思う そしてそれを見つけるのが困難 スクリプト的な使い方には非常によいと思う でも、実用的にはOCamlくらいがいいんじゃないかな HaskellはType Classや構文が羨ましいけどね 392 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:17:45.63 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 393 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:17:48.48 ] >>386 ん、若田 ただな。問題は、自分がプログラミングHaskell読み終わってない初心者なんだなｗ 使用例とか、どういう動きを期待されてるのか知らないと、書けんw 教えてくれｗ 394 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:18:44.86 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 395 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:20:24.62 ] >>393 あ、大丈夫 typeで独自の型を作るところまではやってるから、後は何とか出来ると思う あの薄さの入門書でどこまで出来るかやってみたいんだ 396 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:20:45.35 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 397 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:21:05.68 ] なんか 呆れる連中が多いな。Haskell固有の話じゃないのにな。 勝手にHaskell厨と騒いでるのを見てて、ここは、アホの楽園なのかと・・・。 Haskellは純粋だけにOcamlとかと比べても堅物な言語だから、 その点が容易かどうか。最も、難しいところを置いといても プログラミングはできるけどね。 OOPとの対比になるけど、Visitorパターンが理解できたら、 無名関数でやってることと同じようなことがOOP言語ならできるけど OOPでVisitorパターンの位置づけはどうなのかだよ。逆に、 関数型やってる奴のほうが、使えるパターンかもしれんが。 398 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:27:37.78 ] ん、「データ構造　グラフ　Haskell」でググったら、こんなん出てきたが、これで良いのか？ type Graph = ([Int], [(Int, Int)]) ソース www.shido.info/hs/haskell9.html 399 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:28:29.44 ] グラフならペアのリストなりセットでいいような 400 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:32:22.08 ] アルゴリズム系でHaskellに挑むとか、無謀すぎだろ 401 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:35:33.47 ] >>398 そのグラフからエッジを一本削除してください 402 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:37:34.15 ] >>401 ごめん エッジを削除ってのは、どういう動作なの？ >>395=>>398なの 全く分からんでググった 403 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:38:17.39 ] 書けない言語で無理しなくていいよ 404 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:47:09.45 ] >>391 回りくどいって言うが、IORefはOCamlのrefとほとんど同じだよね 名前が長くて鬱陶しいのは認めるけど、実用性をうんぬんするような違いではないと思う しかし自分が普段使ってない言語の実用性が低く見えるのはある程度仕方ないんだろうな 俺も「OCamlってマルチコア対応してないのにどうやって実用プログラム書けるんだろう」とか思うし 405 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:49:13.56 ] >>403 いや、グラフとか、エッジを削除とかの用語が分からんだけ マージソートも、コードなしのアルゴリズムの本で組めたから （「アルゴリズムのキホン」とか言う、これで手続型言語で組めるのかいな？という舐めきった本） 406 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:50:11.42 ] 分からんなら黙ってればいいのに 407 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:51:47.78 ] >>404 いや、それは関数型特有の独善性だから。 勝手に一般化しないでくれ。迷惑だ。 408 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:51:58.75 ] >>406 そんな初心者が書けたら、どうする？ 409 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:53:57.21 ] むしろHaskell勉強しててグラフ理論も知らんとかバランスが悪い 410 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:54:12.61 ] もち、手続型の人たちも、グラフの定義とエッジ削除のコードの準備お願いしますね 411 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:54:37.55 ] >>409 だから、マジ初心者なんだってば 412 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:55:48.62 ] >>407 関数型の独善性って？関数型ユーザの独善性って言いたいの？ それこそ不用意な一般化だろ。同意できないならそうとだけ言えばいい 413 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:55:53.02 ] だから出てこなくていいってば。pyths のコードで「素数って何か知らんけど教えて」といわれてるようなもんだ 414 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:56:21.70 ] pyths関係なかった。あれはピタゴラス数か 415 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:57:50.88 ] グラフを知らないのにどうやってハスケルの動作原理を理解したんだｗｗｗ 416 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:57:59.46 ] >>413 え、Pythsはピタゴラス数であって素数じゃないけど・・・・ 手続型の人が怖がってるんですか? 初心者Haskellerに？ 417 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 20:59:17.38 ] >>412 バーカ、おまえが先に一般化をしたんだろ 他人の一般化を批判する権利はない 自分だけが特別だと思ってる関数型厨の典型だな 418 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:03:52.84 ] >>415 え、グラフ理論（？）とHaskellの動作原理に何の関係が… と、言うか、動作原理は理解してない。・・・と思ってる 419 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:04:38.43 ] >>417 なにそれ。互いのミスを指摘しあうのは議論なら当然だろ 「お前が先に間違えたから俺の勝ちな」とか言っても始まらんよ あと何か一般化が無条件で悪いと思ってる？ 420 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:10:13.08 ] >>404 >回りくどいって言うが、IORefはOCamlのrefとほとんど同じだよね 型がクドくなる 421 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:10:32.29 ] 関数型言語のクイックソートって空間計算量が O(nlogn) という理解で正しい？ 422 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:11:57.63 ] あとSTモナドは型注釈必須なのでめんどくさいから使いたくない まぁunsafeなんちゃらつかえばいいんだけど 423 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:14:28.17 ] >>421 使った端から到達不能になるから O(n)でいいんじゃない？ 424 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:18:09.84 ] >>421 Haskellの有名なやつを念頭に置いてる？ あれは遅延リストだから空間計算量は訳分からんことになる 最悪O(n log n)かもしれない 同じことを正格なリストか配列でやればO(n) in-placeのクイックソートを実装すればもちろん追加メモリは定数で済む 425 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:18:52.60 ] あの・・・ グラフの説明とエッジ削除の説明は・・・ 426 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:19:26.72 ] いや最悪O(n^2)っぽい 427 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:20:19.93 ] >>425 ここはお前の勉強部屋じゃない 428 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:21:48.63 ] >>425 まともなデータ構造の教科書を買うか借りるかぐぐる 429 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:24:32.31 ] ocamlerがHaskellをディスるスレ 430 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:26:00.82 ] 実際ocamlは使い易いし 431 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:27:34.40 ] >>427-428 せめて、手続型言語のコードは出ないんでしょうか? 432 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:41:57.79 ] グラフに 4種類のノルムを定義して それぞれについてダイクストラ 結果に応じて条件分岐して 各エッジに容量を設定して 最大フロー問題 433 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:43:06.45 ] ち、自分で出来ない事を関数型言語は〜とか言わないで欲しいなぁ… 関数型言語の検証ができないじゃないか 自分は文法に惚れただけで、実用可能かどうかははっきりしてないんよ このスレが検証にうってつけだと思ったんだけどな・・・ 434 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:45:11.51 ] Haskellの前は何使ってたんだ？その言語が手続き型なら自分で書けよ。 要はグラフ理論知らないだけだろ？勉強不足。 435 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:46:09.65 ] >>432 ハスケルではつらそうな例を考えて見ました 436 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:51:59.91 ] >>432 いやだから・・・ マジ初心者だから、ダイクストラから分からんのよ… 一応、ググったらCのコード出てきて、typeすら使う必要ないっぽいけど・・・ ダイクストラ法　Haskellでググったらこんなん出てきてるけど type Index = (Int, Int) data Node = Node { cost :: !Int, pos :: !Index, from :: !Index } deriving (Show, Eq, Ord) ソース haskell.g.hatena.ne.jp/route150/20100502/1272792417 こういうのを、自分はちゃんと自分で書きたいんだよ んで、手続型言語のソースが一向に出ないのも、説明が出ないのも何でよ・・・ 437 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:53:04.78 ] 手続きの書き方は自明すぎるから 438 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:54:34.05 ] 面倒くせえからグラフ知らないなら双方向リストでいいよ。それがグラフだ。 439 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:56:10.02 ] >>434 そうよ 手続型だろうが、関数がら多だろうが、それを知らなきゃ書けんのよ マージソートのときは、Haskellでは分かっても、手続型言語で書き方分からんかった（いや、配列じゃなくてリストで作れってなら、今なら作れるけどさ） 色々やったよ CもRubyもJavaもSmalltalkまでやったさ 440 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:56:56.67 ] >>437 なら、それがHaskellで書くヒントになるから書いてほしい 441 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:57:41.76 ] >>439 「グラフというデータ構造を知らないんだから書けるわけないだろ、教えてくれないそっちが悪い」ってか？ それお花畑すぎねえか？ 442 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:59:16.59 ] >>437 勉強してから来てくれ 443 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 21:59:48.77 ] >>440 だから双方向リストでいいって。 末尾に O(1) で要素を add できる。 末尾要素を O(1) で remove できる。 末尾要素を O(1) で取得できる。 一つ前の要素を O(1) で辿れる。 これを満たすデータ構造を作れ。 444 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:01:39.78 ] >>443 グラフ知らない人に オーダー記法使って話しかけるなｗｗ 445 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:03:14.95 ] すまんかったｗｗｗ 446 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:04:09.59 ] てかオーダー気にしないならある意味Haskell最強かもしれんｗｗｗ 代入なんて効率のためにあるようなもんだし 447 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:04:46.76 ] >>443 ふむ、ちょい頑張ってみる 酔っぱらってきてるから、明日とか明後日になるかもだけど、作ってみるよ 448 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:05:32.97 ] 逃げるか。俺も泥酔した状態で443書いたんだけどな。 449 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:07:21.87 ] >>446 うい、無限のメモリと無限のクロックがあれば最強 だから、個人的には６４ビットOSの普及がHaskell普及のカギかな?とか思ってみたり CからC++、さらにLLへと流れてきた延長で 450 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:08:27.37 ] おいおい64ビットOSの普及がカギとか... 451 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:09:02.87 ] >>448 いや、書くよ 今日書けるか自信がないだけ 何つーても初心者（少なくともHaskellはｗ）な上に、酒がまわってきた 452 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:10:27.57 ] ＞CもRubyもJavaもSmalltalkまでやったさ という人が双方向リストを作るのに明日か明後日になる。 それがHaskell 453 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:11:16.27 ] >>450 ぶっちゃけ、コード書くのは楽だけど、LLとはどっこいどっこいだとして、やっぱメモリ食うもんよ クロックの方は、腐ってもコンパイラだから、LLより速いんだけど（Rubyの後でHaskellやってたから、マジビビった） 454 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:12:00.17 ] >>452 いや・・・ 入門書で挫折してるから… 覚えた言語の数が問題じゃないんですぜ？ 455 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:13:05.76 ] >>453 それで、32ビットOSが64ビットOSになるのに合わせて、搭載されるメモリが2^32倍になるのかな？ 456 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:13:12.99 ] 一方ジャバラーはライブラリをそのまま使った 457 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:13:43.78 ] >>443 あ、ついでだけど、双方向リストって英語でなんて書くの？ 関数名＆ファイル名にしたいんだけど 458 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:14:46.47 ] >>456 そりゃそうだろ。ソースを見て写経してもいいが意味ないし 459 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:15:28.20 ] Haskell勉強しようって奴はこんなのばかりなのか？ 460 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:16:02.16 ] 実のところocamlerだがhaskellに偏見を持ちそうだ。 461 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:18:45.42 ] あんたら話しをごっちゃにしすぎ。一次資料に当たれ。 462 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:22:52.94 ] >>455 実用的にはそこまで要らないだろうけど、末尾再帰使わんと、４GBじゃ不足する場面もあるんよね… 末尾再帰よりはループの方が素直なんよ （そういえば、Haskellにもfor関数あるっポイんだが、使い方分からん…。副作用のある関数で使うモナドの糖衣構文do内の引数なし再帰は実質、ラベル付きGotoだから、困るわけではないんだけど…） 自分でfor関数作った方が速いんじゃろか… （doが付く関数内でしか使わんけど） 463 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:23:24.90 ] 圏論の勉強中だから静かにしてくれる？ 464 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:25:09.62 ] >>459 たぶん… かなり稀な方だと自覚してる ウザがられるの分かってるけど、Haskellが一番しっくり来たんで絶賛宣伝中 逆効果かも知れんけど、その時は、真のHaskellerが何とかしてくれると（ｒｙ 465 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:27:35.06 ] >>464 名前欄にHaskellSamuraiとか入れとくといいよ 466 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 22:28:02.88 ] >>433=464 ksg 467 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 23:33:13.41 ] Haskell侍。。。Ocaml岡村。。。。 468 名前：デフォルトの名無しさん mailto:sage [2011/11/23(水) 23:35:21.30 ] はすけるのコードって、どうやってパフォーマンスチューニングするん？ メモリ足りない時とかI/Oの帯域幅が重要な時とか。 469 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 00:34:25.91 ] アルゴリズムの見直しは大きいだろうよ。okazakiを参考にするとか 470 名前：HaskellSamurai mailto:sage [2011/11/24(木) 00:43:21.42 ] 一応、双方向リストっぽいのは出来たんだけど、自信がない… data DList f l = Null | DList f l deriving (Eq, Ord, Show, Read) そもそも、双方向リストってのが、どういう動きするのかが分からんのだもん・・・ 一応、自分の作った双方向リスト（か分からない何か）の使用例 >Null Null >DList Null Null DList Null Null >DList 1 (DList 2 Null) DList 1 (DList 2 Null) >DList (DList Null 2) 1 DList (DList Null 2) 1 471 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 00:57:08.04 ] 上から順に、 空リスト 空リストの空リスト 通常のリストと同じ方向にリスト作成 通常のリストと逆方向にリスト作成 これを使ってO(1)で結果が返るadd関数やremove関数作を作れるかはまだ分からない状態 472 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 01:01:08.94 ] セルに前方と後方へのポインタ２つをつけたらいい。 それを使ってrmapとかrconsとか実装してみればいい。 473 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 01:03:59.62 ] stackoverflow.com/questions/1844195/doubly-linked-list-in-a-purely-functional-programming-language これでも読んどけ。 474 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 01:51:33.02 ] >>315 懐かしいなあ、俺とかプログラミング始めたの小学生のときだわ 初めての言語はBASICだったが 仮に初めてが関数型言語だったとしたら、さんすうの知識でやれたんだろか？ 475 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 04:47:55.03 ] >>419 なるほど、ハスケラってメンヘラなんだな 476 名前：HaskellSamurai mailto:sage [2011/11/24(木) 06:42:56.06 ] >>472 双方向リストモドキを定義しなおし、そのhead関数も定義してみた data DList a = Null | DList (DList a) a (DList a) deriving (Eq, Ord, Show, Read) dhead (DList Null x _) = x dhead (DList xs _ _) = dhead xs 使用例 *Main> dhead (DList (DList Null 2 Null) 1 (DList Null 3 Null)) 2 477 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 07:22:27.25 ] >>404 > OCamlってマルチコア対応してないのにどうやって実用プログラム書けるんだろう Unix.fork または ocamlmpi 478 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 14:40:24.15 ] マルチスレッドもいけるF#最強ってことですね 479 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 15:05:22.40 ] f# はfuntor ない 480 名前：デフォルトの名無しさん mailto:sage [2011/11/24(木) 17:35:22.41 ] >>476 それ、２分木だろ 全然双方向リストになってねえよ 481 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 16:17:52.04 ] >>476 流れは良くわからんが そも双方向リストは単純に再帰定義できないからhaskellでは素直に書けないよ 双方向リストを実装したライブラリというのも、俺は見たことないな どうしても使いたいなら頭を捻るか、STモナドやIOモナドに入れて対応しよう 再帰定義できないデータ型としては例えば他に両端キューやハッシュテーブルがあるけど、 haskellの両端キューは特別な木で実装されてるし（前者）、 haskellのハッシュテーブルはIOモナドの中でしか使えない。（後者） そして普通はハッシュテーブル使うぐらいなら再帰定義可能な平衡二分探索木を使うようだね haskellのやり方というのはそういうものだ 482 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 16:51:50.46 ] >>481 分かりやすく二行でまとめると、 ・手続き型言語やLisp/ML等の大半の関数型言語 --> 双方向リストやハッシュが「自然に書ける」 ・Haskell --> 再帰定義やモナドといった「面倒な手法を駆使しなければ」表現できない ということですかな 483 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 17:13:22.23 ] >>482 他の関数型言語がそれらを自然に書けるかどうかは不勉強なんで良くわからんな ただ、双方向リストで必要な参照型と、ハッシュテーブルで必要な破壊的代入は、どっちもhaskellが生理的に嫌ってる部分だからね その両方を簡単に扱える言語であればどちらも自然に書けるはずだよ モナドはともかく、再帰定義が『面倒な手法』というのは手続き的な発想だな むしろhaskellは再帰を愛しているからこそ、できる限りそれだけで対応したがる、というのが正しい あんまり変わらない？　うん、まあ、そうかもしれんね 484 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 17:35:37.07 ] 手続き型が自然は疑問だよ、読み書きそろばんを小学校のうちに矯正させられ るんだから。 小学校に上がる2年前にタッチタイピング、1年前にLISPで数の概念を教えて 中学卒業前に偏微分まで独学させたらおもしろい子供になると思う。学校では 数学を習うから手続き型も覚えるし、かなりちょうど良いんじゃないかな。 あと小学校で習う筆算の＋−×÷の記法って特殊だよね。あとそろばん習って いる人は今は少ないかもしれないけど、そろばん流暗算も特殊だよね。 余談だけど子供には読み書きもしっかりやらせたいと思っている。とくに書きは 意識的にやらせないと覚えないので意識的にやらせる。プログラミングの習得って 早ければ早いほどプログラミング歴が長くなって、時間感覚が豊富になるよね。 15歳からプログラミングを始めて18歳で考えるプログラミングや世間に対する とらえ方と6歳からプログラミングを始めて18歳で考えるプログラミングや世間に 対するとらえ方はまったく違うものになるだろうね。15歳から始めたヤツは27歳 ぐらい必要だろうし。早くても24歳ぐらいは必要だろうなあ。これは読みと書きにも 言えること。数学はそういう時間感覚があるのか、知らん。 >>230 x = x+1ってx <== x+1の省略記述だよね、厳密には。教育言語のPascalがx := x+1なん だっけ？ >>231 躓きはしないけど「うん？」とはなっていたなあ。 >>232 慣用句だと思って暗記して使うしかないけどなあ。9.9割はパターン認知処理で問題が 起きないので忘却曲線を意識してすべて暗記すればいいと偉い先生が言っていたよ。 >>236 日本語の算術的に考え方で言うとそろばんと升とかの方が歴史は長いんじゃないの？ 近代化のために江戸時代的なものを脱ぎ捨てて今があるけど。 485 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 18:10:20.80 ] >>484 日本の教育システムは、採点し易いか否かを優先してるから、論理性は教える方も解ってないからなあ。 486 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 18:47:52.51 ] >>314 アメリカの教育って今の日本の教育並にウンコだっただけでしょ。 あとプログラミングの教育って相当難しいんじゃないかな。おまえら、 中高でかなり時間割り当てられているはずだけど、古文、漢文自作できるか？ あとA4二枚の英作文できるか？ >>321 選民思想なのかわからないが、人が選択肢している時点で合理的な判断をして いるから合理性は出てくるだろうなあ。 >>331 それただ教えてもらっていないだけでしょ。今の数学の教科書みたいに二段飛び、 三段飛び当たり前だときついけど、小中高のすべて合わせて1,500ページの教科書を 渡して中1まで進めれば勝手に独学して進めるヤツは結構いると思うよ。 >>338 あいさつの概念、作文の概念、読書の概念、算数の概念、活版印刷の概念とか一々 やったら子供は逃げ出すだろうなあ。空手や柔道みたいに型を教えて、何年後かに 分かればいいだけ。 >>474 数学が得意で国語が不得意だったけどベーマガのBasicコードを写しているだけだったな。 付属のリファレンスを読んでみたけど、関数？(学校で習った関数だよな？)？だった。 市の図書館に行っても小難しい本しかないし、ネットもなかったらフリーソフトを 手に入れる手段もなかった。万単位のお金を払ってプログラミング言語を買う概念なんて なかったし、そのソフトを仮に大奮発で買うとテキストを買うのは無理だからなあ。 やっぱり本でどうやって引き込んでいくかが大事な気がする。プチゲーム(ジャンケン ゲーム等)を組ませつつ、数理的な問題も組ませつつ引き込んで行く。 80年代がマイコン全盛なんだっけ？子供向け本も多かったんだろうけど、今はそうい うのが少ないんだろうなあ。子供向けではないけど個人のWebページで言語入門みたい なのがあるからそういうのでアナルファックの味とか覚えるのかな。 487 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 18:59:04.95 ] >>485 論理性も教えるためにゆとり教育ができたんだけどね。小学校は熱心だったようだけど、 中高は一部の先生がボイコットしちゃったたみたいだね。まあ、ゆとり以前に 週5授業とか、予算と教員に教材仕込む時間を設けなかったりとか、色々と問題があった し、ゆとり導入前にマスゴミが学校をガンガン叩いて劇場化して、教員が教えられない 状況を作っちゃったからどうしょうもないんだけどね。子供に一番良くないのは親が 教員を疑うことと教員が自信を持って教えられる環境がなくなることらしい。 アメリカのデータだとインディアン部族の教育が体罰あるらしいが、体罰したからって 変な子供になるわけではないらしい。文明先進民族の白人が勝手に「体罰は良くない」と 注意し始めて、インディアン自身が白人が言っていることの方が正しいと思ってしまって、 教え方にブレが生じて、荒れ始めたらしい。日本は家庭体罰に行政介入できるようになっ ちゃったから家庭教育しづらいわ。子供の人権を盾にやりたい放題させるのは子供自身にも 本当に良くないと思うわ。まあ、この流れは当分止まらないんだろうけどなあ。 488 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 19:12:30.73 ] あと思ったけど手続き型言語の代表言語をいくつか出さないか？ Cであったり、Javaであったり、.netであったり、Perlであったり、Pythonであったり、 RubyであったりだとCの実行速度を持ちつつ、VM上で動くのでOSを環境依存もなく、 Windows対応もよく、文書整形向きでワンライナーもしやすく、可読性もよく、日本人が 作った最強言語と錯覚させる恐れがある。個人戦でVSで戦ったら実際の所はどうなんだろ。 トーナメントつくって議論して勝敗決めていこうか。 489 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 19:25:39.38 ] ここはOcamlerがHaskellerを煽るスレでな 490 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 19:48:23.59 ] Haskellは純粋ゆえに、どうしょうもなく使えないパターンってあるからね。 双方向はそう幽霊だよね。学習用と見たときな明確に欠点かなと思ってる。 スペシャリストとジェネラリストに分けたら、Haskellはスペシャリストなん だよ。Ocamlはまだジェネラリストの顔を持ってる。 手続きが書きやすいかどうかは知らないけど、lispで構造体を使って双方向 リストを作ってみたら、いささかCと変わらん感じがする部分は出てくるよ。 どうしてもポインタ操作で破壊的操作が必要だからね。木構造はHaskellは 大変扱いやすいんだけどなぁ。HaskellというよりML系はというほうが適切か。 だから、木構造を上手に活用する方法を考えだすんだろうね。 HaskellでSICPの後継が欲しいってのもSICPスレで読んだけど、Haskellじゃ どうしても途方もなくめんどくさくなる章があるんだよな。それがHaskell の限界だと思ってるよ。限界を超えようとして頑張ってる人たちも多いけど 大変だよね。その頑張ってる人たちがいるから並行処理に魅力があるんだけ どな。 491 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 19:52:29.20 ] IORefやIOUArrayがりがり書き換えまで含めてHaskellだと思ってる 492 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 20:04:12.52 ] 誰もHaskellで双方向リスト書かないの？ 493 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 20:09:39.54 ] >>492 see >>473 494 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 22:05:39.70 ] ocaml　の特有の基本仕様は大体覚えたんだけど こっからhaskell 覚えてメリットある？ 495 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 22:32:25.61 ] どうしてO(1)のハッシュマップを使わずに O(log(N))の平衡木を使わなけゃならんの？ どうして双方向リストを使わずに 単方向リストや配列を使わなけゃならんの？ 496 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 22:40:34.57 ] >>495 べつにハッシュマップや双方向リストを使いたければ使えば良いよ そのかわりpersistentなデータ構造にはならないってだけ 497 名前：デフォルトの名無しさん mailto:sage [2011/11/25(金) 22:55:32.69 ] >>496 効率の良いデータ構造をモナドの外で使えないのは不便じゃないの？ 498 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 00:02:27.09 ] 不便なこともあるね 499 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 00:24:12.60 ] ノイマン型コンピュータ、もっといえばチューリングマシン自体が手続き型なんだから、 その上で動かす関数型言語がぎこちないのは当然の理屈だな。 500 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 00:46:38.19 ] 手続き型、関数型の概念は共に構造化がベースだから、チューリングマシンとは別カテゴリ。 501 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 00:56:37.11 ] >>495 そのためにありとあらゆる工夫をして高速化してるのがOkazakiじゃなかったっけ？ 良く言えばすごいけど、Okazaki本は話しか聞いてないから見てないけど、SMLで かかれてるんだよな？ 悪く言えば、純粋のためのバッドノウハウと取られかねない。藁 502 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 01:05:55.91 ] Oderskyに空目した 503 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 01:08:08.51 ] それscala病 :-) 504 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 01:15:18.21 ] >>500 んなこたーない。 主流CPUの機械語が全て手続き型なのは紛れもない事実 505 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 01:16:55.39 ] 命令型プログラミング ja.wikipedia.org/wiki/%E5%91%BD%E4%BB%A4%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0 宣言型プログラミング ja.wikipedia.org/wiki/%E5%AE%A3%E8%A8%80%E5%9E%8B%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0 一般に命令型プログラミングは、手続き型プログラミングと同義として扱われる。 506 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 01:18:09.14 ] >>499,500,504 用語がおかしいから意見が食い違う。 機械語は手続き型というより、命令型プログラミングという表現が正しい。 507 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 05:14:39.53 ] ハスケルの人達はLISPを馬鹿にしているけど 結局ハスケルの代数データ型は LISPのcar,cdrのリスト構造の範疇内でしか データを操作できないってことでOK？ 508 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 06:32:13.65 ] >>501 oka S aki ね 509 名前：HaskellSamurai mailto:sage [2011/11/26(土) 07:08:13.68 ] >>480 こんなのも書いてみたけど、双方向リストじゃ・・・ないよね・・・ ジグザグな構造になっちゃうし data DList a = Null | Prev (DList a) a | Next a (DList a) deriving (Eq, Ord, Show, Read) 使用例 Prev (Prev Null 1) 2 >Prev (Prev Null 1) 2 Next 1 (Next 2 Null) >Next 1 (Next 2 Null) Prev (Prev (Next 3 Null)) 1) 2 >Prev (Prev (Next 3 Null)) 1) 2 うーん・・・ 双方向リストの使用例みたいなのが見たい・・・ 510 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 07:09:42.50 ] 双方向リストは定義し難いが無限リストは定義し易い 511 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 07:32:40.18 ] じゃあ双方向無限リストでいいよ。 512 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 07:44:33.01 ] >>492 >>509 『各要素が左右へのポインタを保持する』という実装にこだわらないなら、 つまり、ただ>>443のインタフェースが欲しいだけなら両端キューを使えばいいよ ttp://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data-Sequence.html 513 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 08:30:49.02 ] と、いうか俺の>>481の表現はまずかったな。すまない 『双方向リスト』は再帰定義できないから、 haskellは両端キューを『フィンガーツリー』で実装している 『ハッシュテーブル』は再帰定義できないから、 haskellは連想配列を『平衡二分木』で実装している というのが正しい 514 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 10:57:48.09 ] Haskellはデータサイズが大きくなるとlogNだかの呪いがかかって使い物にならないってこと？ この後どうなっちゃうの？ 515 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 11:25:03.90 ] >>514 >>496 516 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 11:25:19.56 ] ハッシュテーブルのO(1)はメモリ効率の悪さとトレード・オフで実現されてるものだからねえ・・・ 連想配列として常にハッシュテーブルが最適とは限らない なにより一応両方使えるんだから適宜使い分ければよいでしょう 517 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 11:38:15.05 ] >>507 バカにしてるだろうかね？謎だな。エバンジェリストのところのhaskellの wikiがgaucheのなのに。 518 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 11:41:51.84 ] en.wikibooks.org/wiki/Haskell/Zippers 519 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 11:49:20.23 ] learnyouahaskell.com/zippers www.haskell.org/haskellwiki/Zipper ぐぐるとZipperを使えって話があったのでZipperを調べてみた。 520 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 12:37:32.56 ] 木の上を行ったり来たりできるよってことでいいのか 確かに双方向だな 521 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 14:07:35.45 ] >>513 フィンガーツリーや平衡二分木というのはデータ構造に関する 汎用的なアルゴリズムだから、Haskell固有の概念ではない 実際、二分木による連想配列の実装は手続き型言語でも使われる これに沿って>>482を書き直すと、 Lisp/ML等の大半の関数型言語 --> ・手続き型言語の経験者であれば、(破壊的代入を用いる事で) 　その経験を活かして容易く双方向リストやハッシュを実装できる ・もしも参照透明性が必要であれば、(難解ではあるが) 　フィンガーツリーや平衡二分木といったアルゴリズムで実装する事もできる ・どちらを選ぶかはプログラマの判断であり、 　処理系からプログラマには「自由」が与えられる Haskell限定 --> ・双方向リストやハッシュはフィンガーツリーや平衡二分木といった 　(難解な)アルゴリズムを用いなければ実装できない ・プログラマは参照透明性の保証を、常に処理系から「強要」される ということですかな 522 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 14:44:19.31 ] Haskellだと参照透明性が「必ず」保証される MLとかは参照透明性は必要であればプログラマが保証する必要がある と思いきやUnsafeIOとかあるしな 523 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 15:02:03.95 ] 俺はunsafe系は流石に触らないなぁ・・・ といいつつtraceは使うんだけどね 524 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 15:16:27.44 ] Haskellの場合はプログラマが必要に応じて参照透過性を壊せる。 525 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 15:20:47.79 ] だからHaskellなら参照透明性を守ったまま破壊的代入ができるんだって もちろん破壊的代入をしないスタイルの利点(persistentなデータ構造、 状態に関するバグに悩まされない)は失われるけど、それは当然のトレードオフ 526 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 15:25:08.28 ] IOモナドに参照透過性があるって事？ 527 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 15:26:18.51 ] >>522 X: Haskellだと参照透明性が「必ず」保証される O: Haskellだと参照透明性をプログラマが「必ず」保証しなければならない X: MLとかは参照透明性は必要であればプログラマが保証する必要がある O: MLとかはプログラマは参照透明性を保証することもできるし、 　　　　保証しないコードも書けるという「自由」がある 528 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 15:35:00.67 ] >>526 うん。もうちょっと正確に言うと、IOモナドやらIORefやらを使うだけでは Haskellの参照透過性を壊すことはできない unsafePerformIOその他の危険な関数を使えば壊せる 529 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 15:44:10.23 ] ML系って参照透明性のことでschemeみたいに、!の有り無しで見た目区別する みたいな工夫をしてるの？よくしらんねんけど 530 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 16:04:08.75 ] >>525 >だからHaskellなら参照透明性を守ったまま破壊的代入ができるんだって それは「モナドを使えば....」という前提があるわけで、 そのモナドで包んだ範囲内では参照透明性が保証されるという話だろ？ 言い換えると、Haskell処理形は参照透明性が保証されたコードしか受け付けないから、 プログラマが(モナドを使って)保証したコードを書いているという事だ つまり、 Haskell限定 --> ・I/Oや破壊的代入といった参照透明性を阻害する処理については、 　すべてモナドを使わなければコードが書けない Lisp/ML等の大半の関数型言語 --> ・モナドのような難解な概念を持ち出さなくても、自然にコードが書ける ・もちろん>>136のSMLの実例あるように、参照透明性を保証したコードも書ける ということを意味している 手続き型言語およびLisp/ML等の大半の関数型言語に慣れた、いわゆる普通のプログラマにとって たかが入出力ですらいちいちIOモナドを使わなければコードが書けないダメ言語が Haskell 531 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 16:09:14.95 ] まるでIOモナドが魔物ででもあるかのような口ぶりだな 532 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 16:28:38.67 ] >>531 たとえば「読んで; 計算して; 書く」という単純な処理は、 SMLなら以下のような明解なコードになる （他のML族やLisp族でも同様なコードになる） 　let 　　val x = 読む 　　val y = 計算 x 　in 　　書く y 　end それがHaskellでは、こんな初歩のプログラミングですら IOモナドを使わなければコードが書けないだぜ どこをどう考えても 「Haskellはダメ言語」 だろ 533 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 16:29:36.50 ] >>530 単にdo書くだけなのに、そんなに手間か？ 個人的には手続モードと関数モードを行ったり来たりする感覚 534 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 16:35:02.03 ] 一次資料に当たれって。 535 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 16:41:56.76 ] >>533 他人様の作ったモナドを利用するだけの「末端プログラマ」であれば、 それでもいいんじゃね？ 536 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 17:10:47.30 ] 「読んで; 計算して; 書く」というだけの簡単な処理をするだけのために 「副作用」とかいう謎の概念を駆使しないといけない言語と比較するなら、 五十歩百歩だろ 537 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 17:17:48.90 ] 副作用という概念は手続き型言語だけしか使わなくても知っておくべきだと思うが 538 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 17:21:27.86 ] >>535 入力して計算して出力するだけなら、それで十分じゃね？ 何を無駄にモナド作るんだよ 539 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 17:27:14.34 ] >>537 そりゃ、アセンブリ以外の手続き型言語は大抵副作用という概念を持っているからな 540 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 17:29:36.46 ] >>532 Haskellはよく知らんがこんな感じだろ？似たようなもんじゃね do 　　x <- 読む 　　書く y 　　where 　　　y = 計算 x 541 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 17:31:23.33 ] >「副作用」とかいう謎の概念を駆使しないといけない言語 って手続き型言語のこと言ってるんじゃない？ 542 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 17:31:29.19 ] >>540 細かいことを言うとそのwhereはletにしないとxがスコープにないのでエラーになる do   x <- 読む   let y = 計算 x   書く y ますます似てる 543 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 17:40:02.35 ] 似てるどころか一緒じゃね？ 544 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 17:43:37.02 ] まあアンチスレらしく不便な点を挙げるとしたら、 純粋関数として定義したものの、あとからその『内部』でIOを扱いたくなった場合、 printfデバッグみたいにここに一行挟んでー、みたいな気楽な使い方は、残念ながら出来ない。 一度IOを持ち込むとsafeなやり方ではその中から出られなくなってしまうから（つまり、関数の返り値の型が変わってしまう） 545 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 17:48:45.95 ] それはあるね printfデバッグに限ってはDebug.Traceを使うけど 546 名前：HaskellSamurai mailto:sage [2011/11/26(土) 17:55:49.14 ] >>514 いや・・・ 自分が無理に副作用無しの双方向リスト作ろうと奮闘してグダグダにしてるだけ・・・ 今月の数学セミナーによると、計算機科学全般の副作用を数学上で再現するためにモナドが生まれたっぽい つまり、関数型言語のみならず、手続型言語全般の動作を数学上で再現するにはモナドが必要らしい そういう意味では、モナドでオブジェクト指向も再現できるのかも そういう意味で、モナドは副作用のない数学の世界に、副作用を再現する概念なんだよね Haskellのモナドも、良く分からんが、そういう事なんじゃないかと思う それはともかく、自分は双方向リストはじめ、勉強不足すぎるから、しばらくROMるよ 547 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 18:06:31.90 ] HaskellSamuraiさんHaskellスレにおいでよ。 548 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 18:10:16.97 ] 関数型言語を使う予定はないが その考え方はいただいてやったぜ。 C++のSTLとかも影響受けてるんだよね？ 549 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 20:01:17.16 ] >>548 お互いに不完全だけどね 550 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 20:11:11.78 ] 数年すればお互い色々整理されて使いやすくなるだろう 551 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 20:21:34.91 ] そう思って既に１５年 orz 552 名前：デフォルトの名無しさん mailto:sage [2011/11/26(土) 23:38:28.72 ] まあ代入のある関数型言語は全部手続き型言語の影響を受けてると言っていい 553 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 00:13:35.71 ] Fortranの影響を受けてない高級言語など存在しない 554 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 00:33:36.04 ] お互いじゃなくて、Haskellの個性の沿った使い方を丁寧に教える 状況というやつじゃない？You learn a Haskell ...の最後になんで Zipperなのかがよく分かる流れだったよ。 555 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 01:03:33.62 ] 結局のところ、lazy evaluation と eager evaluation の どっちがデフォルトが嬉しい？って話に尽きるのでは eagerな言語では、Haskellとは逆に遅延評価したい処理をモナドに包んだりするわけでさ まあ、普通のプログラマである俺にはlazyがデフォルトは厳しいわ 556 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 07:02:48.01 ] >>547 レベル高すぎて中々書き込めないけど、たまに書き込んでますよ 何ヶ月か前に数学セミナーで圏論の連載が始まるって書いたのも私だったり (今月号で5回目だから、だいぶ前か) 557 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 09:02:38.23 ] for Great Goodって、どこのカルトかと・・・ 558 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 09:35:18.56 ] >>555 >どっちがデフォルトが嬉しい？って話に尽きるのでは いや、それはHaskellの特徴のほんの一部じゃないか 遅延評価よりも重要なものがいくらでもあると思う 型クラス、純粋さ、インデント構文、マクロとか 559 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 09:45:37.55 ] インデント構文が重要？ 560 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 09:54:50.50 ] Haskellに遅延評価がなかったら、で誰か思考実験してみて 561 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 09:58:05.99 ] 俺は重要だと思ってるけど異論もあるだろうな 具体的には、閉じ括弧を書かなくて良い場面が多いので、 関数の最後の引数にdoやラムダ式を書いたり、 激しくネストした関数呼び出しを書いたりしても見難くなりにくい これはコーディングスタイルにかなり影響を与えてると思う 閉じ括弧が少なくなるのはインデント構文だけじゃなくて $の影響もあるけど 562 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 11:20:32.71 ] >>558 cleanで代替できるわけか 563 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 11:34:04.55 ] >>559 横レスだが、個人的には見やすいので助かってる。 プログラミング始めた頃は、これパースしにくいだろ センス無いなーと思ってたけど、使って行くうちに インデント以外の事(データ構造とか)で頭を悩ます ようになったんで、パット見判るのが良い。 564 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 12:05:29.29 ] >>562 開発が止まってるやんけ 565 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 12:05:41.98 ] >>559 読みやすくなる。あれだけ括弧のことを言われるlispでも実は インデントでソースを読んでいるくらい。 566 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 14:52:58.70 ] >>564 つまりハスケルの開発もすぐ止まっちゃうの？ 567 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 17:09:30.54 ] >>563 インデント構文は忘れた頃にコードに手を入れようとするとひどい目に合う haskellでも文脈自由構文使う インデント構文以外選べないpythonは使わない 568 名前：デフォルトの名無しさん mailto:sage [2011/11/27(日) 17:45:13.36 ] そして 「あいつのコード読みにくい。どうしてインデント構文つかわねえんだ」 と陰口叩かれる 569 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 00:16:13.44 ] >>566 Haskellの場合、関数型言語特有の技術の有効性を検証する目的で作られた一面もあるから、まず開発が止まることはない 570 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 00:21:33.60 ] >>567 どっちかと言うと、忘れたころに読み直す時にこそ、インデント構文の方が読み直しやすいと思うんだが、痛い目って、手直しでインデントがズレまくるとか？ 単に関数にまとめるのが下手なだけちゃうんかと 571 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 00:27:44.32 ] >>560 でかいファイルの読み込みでしょっぱな困る コード上は無限リストで一気に全部読み込んでるように見えて、遅延評価で必要になった分ずつ読み込んでいくからメモリがパンクしないのに、遅延評価が無かったら、プログラマの方でメモリがパンクしないように気をつかわにゃならん 572 名前：デフォルトの名無しさん [2011/11/28(月) 00:30:59.17 ] そんでも上手いこと要らないデータは捨てないと同じことだがね 573 名前：532 mailto:sage [2011/11/28(月) 01:07:30.76 ] >>540,542,543 しばらく待ってみたが、残念な解答ばかりだな >>532では明確に書いていなかったけど、もしも「お題」を書くとしたら、 　モナドを使わずに「読んで; 計算して; 書く」という処理をHaskellで書きなさい 　ここで、ごく単純な逐次処理なのだから、再帰の使用は禁止します というものになる。後だし条件かもしれないが、それくらいは推測できるだろ？ >>532では「(Haskellじゃ)IOモナドを使わなければコードが書けない」と書いてあるんだから Haskellのdo記法や>==はモナド向けの構文糖だ お前等はそんなことも知らないナンチャッテ・ハスケラなのか？ Haskellという言語の表層だけで満足して酔っているお前等は「ドカタ・ハスケラ」だ 574 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 01:40:12.96 ] 関数型でdo構文みるのは苦痛だな。見苦しいというのか、出来る限り避けたいよね。 575 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 02:11:32.12 ] (>==)の結合性を教えていただきたいものだなｗｗｗｗ 576 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 05:43:18.62 ] >>569 そりゃcleanも同じだ Haskellだけ特別だと思ってる？ 577 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 07:35:43.93 ] >>571 正格なHaskellなら間違いなくiteratee使うだろ 578 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 07:38:25.72 ] >>573 >モナドを使わずに「読んで; 計算して; 書く」という処理をHaskellで書きなさい 「モナドを使わずに」なんて妙な条件を読み取れって方が無茶だろｗ もともと >SMLなら以下のような明解なコードになる と書いてあったから、モナドを使って同様に明快なコードになることを示しただけ 579 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 07:45:37.09 ] >>574 Haskellのdoならすごく読み易くない？ (>>=)やラムダを多用したコードの方が汚く見える Haskellに限らず逐次実行のための仕組み一般(OCamlの;とかも)を指しているなら、 それなしでどうやってプログラム書くのか 580 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 08:09:58.63 ] do記法の中に(>>=)を混ぜるのが最強 異論は認める 581 名前：デフォルトの名無しさん [2011/11/28(月) 09:18:03.28 ] >>573 >==が>>=のタイポだとしてもお前話にならないから帰っていいよ。 582 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 09:43:06.23 ] 煽るにも技術的なバックグラウンドが必要だな。 583 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 11:25:50.20 ] >>578 そもそも「読んで計算して書く」って、それ自体が手順だしな… 手続き的に書くほうが自然だし、ちゃんと要所でそれが出来るのがHaskellなんだし 584 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 11:33:31.02 ] アンチの質が低すぎてアンチスレがアンチスレになっていない件 585 名前：デフォルトの名無しさん [2011/11/28(月) 13:14:13.04 ] Haskellの長所でありクソな点は、計算の中に副作用を入れるのがモナドをやりくりしないといけなくてめんどくさいことですし。 副作用のある手続きの中に計算を入れるのは他の言語と大差ない。 586 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 15:31:59.75 ] >>579 どうしても避けられないところはあるけど、極力避けてるよ。 doの中ってやっぱり手続き臭が強くって、あのクサさは最悪だと感じてるから。 まるで卵の腐った匂いだ。 587 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 16:30:50.72 ] 硫黄大好き 588 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 18:23:53.51 ] >>583は結局、手続き的な記述の利点を認めているわけで、 だったら手続き型ベース+関数型スタイルでいいだろうとなる。 にもかかわらず関数型マンセーなのは矛盾を感じるな。 >>586 のハスケル原理主義のほうがかえって好感が持てる。 589 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 18:31:41.98 ] >>1はScalaやF#なんが含めて煽りたかったんだろうが、 まさかHaskeller対その他になるとはな。 590 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 19:04:37.27 ] >>588 HaskellもMLも十分、手続き型言語とのハイブリッドだよ 逐次実行、破壊的代入、複雑な入出力、どれも避けて通れないアプリは多いんだから、 これらをうまく書けないような言語は汎用言語として欠陥がある >だったら手続き型ベース+関数型スタイルでいいだろうとなる。 それよりも関数型ベース+手続きスタイルが良いと思ってる奴がHaskellとかMLを使ってるだけ 591 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 20:29:45.70 ] >>588 手続き型「にも」利点があるし、そのほうが書きやすく直感的な処理もある 592 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 20:58:07.30 ] 自分は、 できるだけ関数型で書いて、副作用を少なくする 効率やどうしても副作用が必要なところは関数やマクロに閉じ込める というのが良いと思ってる。 593 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 21:52:28.86 ] 賛成反対はともかく、それはなぜ？ 594 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 22:15:34.63 ] >>592 卵の腐ったのが嫌いな人なんですが、同感です。 最初は、副作用が無い版をつくってチューニングしてだんだん形にしていく。 595 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 22:21:54.52 ] >>593 デバッグのやりやすさだと思うよ。手続き型の書き方を利用していくと 関数の作用が、複数にまたがるために、エラー箇所の見積もりが面倒になる。 一つくらいだったら、さほど問題はないけど、複数同じようになってみたら ちゃっちゃと作っていく関数型スタイルを壊すだけになるんだよ。トレース にしてもプロファイルにしても煮詰める箇所を定めやすい。 だから、一つ一つの関数の作りはシンプルでというのは、自分の中では鉄則。 でも、doなんて多様するとね。。。あとが大変なのよ。 596 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 23:37:26.50 ] do記法が嫌いな人って結構いるんだなぁ・・・意外 597 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 23:49:48.58 ] if 〜 then 　〜 else 　〜 と書けないのが悲しい 598 名前：デフォルトの名無しさん mailto:sage [2011/11/28(月) 23:50:44.17 ] そんなのたった二つスペース入れるだけでいいじゃんかｗｗｗ 599 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 00:26:59.17 ] blog.raynes.me/blog/2011/11/27/the-clojure-community-and-me/ この人１７歳でClojureの本を出すらしい。最初の言語はHaskellと言って るとのこと。 600 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 00:29:11.48 ] １３でHaskellの師匠を見っけたのか。 中学生でも関数型は可能だな。 601 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 00:31:33.65 ] A lot of people wonder if learning Haskell, a purely functional language, as a first language would make OOP languages be as difficult to learn and understand as functional languages are to OOP developers. My answer, given my experiences, is no. Learning a functional language first gave me the programming foundations that I needed to understand OOP and how it compared to other paradigms. と答えてるな。 602 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 01:06:33.44 ] 関数型を最初に勉強したらOOPの勉強が困難になるかっていうとそんなことないお 関数型のおかげでOOPの習得に必要なプログラミングの基礎も身についたお だから初心者も関数型から入ったらいいお！Prolog最高だお！ ってことか 603 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 05:06:14.90 ] >>600 Scratchは色々な国の小学生に使われているよ。 しかもSmalltalkで改造されたパーツが小学生間で流通してるよｗ 604 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 07:15:13.10 ] >>597 Haskell 2010では書けるようになった 605 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 10:19:26.34 ] >>592 良識人登場 606 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 11:46:44.56 ] >>590 汎用言語なんてあったか？ 607 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 12:50:17.46 ] >>603 だから。。。何？ 608 名前：デフォルトの名無しさん mailto:sage [2011/11/29(火) 19:02:18.26 ] 今時は13歳はもうビッチってことだろｗ 609 名前：デフォルトの名無しさん mailto:sage [2011/12/02(金) 02:32:46.15 ] template用途だと関数型言語は理にかなっているよね C++だってtemplateは純粋関数型言語だし まぁあれは構文が腐っているけど 610 名前：デフォルトの名無しさん mailto:sage [2011/12/02(金) 07:46:44.41 ] テンプラと関係あるっけ？ 611 名前：デフォルトの名無しさん mailto:sage [2011/12/03(土) 06:10:29.62 ] >>597 むしろ、elseなしが書けないわけですが・・・ パターンマッチあるから、困ることもないんだが 612 名前：デフォルトの名無しさん [2011/12/03(土) 09:21:52.54 ] そういう時はifじゃなくてwhenじゃない？ 613 名前：デフォルトの名無しさん mailto:sage [2011/12/03(土) 22:07:14.99 ] >>610 入力のソースを変形して出力するという処理だから関数型に適している 614 名前：デフォルトの名無しさん mailto:sage [2011/12/04(日) 19:41:46.01 ] 関数型「でも」できるってのと、 関数型「のほうが上手く」できるってのは ずいぶん違う話だぞｗ 615 名前：デフォルトの名無しさん mailto:sage [2012/01/18(水) 12:42:04.49 ] しかも、関数型のストライクゾーンは狭いしな。ど真ん中だと最高なんだけどね 616 名前：デフォルトの名無しさん mailto:sage [2012/01/18(水) 14:07:49.72 ] ど真ん中に来ないと打てないのは三流以下 617 名前：デフォルトの名無しさん mailto:sage [2012/01/18(水) 18:10:14.27 ] >>615 ど真ん中にはショボいトイプログラムしかないけどな。 618 名前：デフォルトの名無しさん mailto:sage [2012/01/18(水) 18:51:15.48 ] GCの停止時間とかシビアな性能が求められるプログラム以外は何でもいける 619 名前：デフォルトの名無しさん mailto:sage [2012/01/18(水) 18:54:56.64 ] かつ、高速演算とか細かなIO制御だとかもしなければ 620 名前：デフォルトの名無しさん mailto:sage [2012/01/18(水) 21:37:38.51 ] そんな事言ったらC言語だけでいいじゃん。 621 名前：デフォルトの名無しさん mailto:sage [2012/01/18(水) 23:00:49.28 ] 大規模データも勘弁 622 名前：デフォルトの名無しさん mailto:sage [2012/01/18(水) 23:16:20.34 ] 手続きでも関数型でもオブジェクト指向でもなんでも書ける言語も多いけどな。 人間だっていろいろな言語に対応できたほうが良いだろうに。 関数型は使えないとか、俺は馬鹿ですって言ってるようなもんだ。 623 名前：デフォルトの名無しさん mailto:sage [2012/01/19(木) 01:15:47.03 ] 読み書き出来て使いこなせるけど 馬鹿の一つ覚えみたいにそればかり使わない っていうのが一番尊敬出来るし信用出来る 624 名前：デフォルトの名無しさん mailto:sage [2012/01/19(木) 01:16:59.89 ] 他人に無理やり薦めない 強制しないってのもな 不況は勘弁 625 名前：デフォルトの名無しさん mailto:sage [2012/01/19(木) 01:17:41.43 ] ｘ不況 ｏ布教 626 名前：デフォルトの名無しさん mailto:sage [2012/01/19(木) 04:48:42.83 ] >>622 が関数型言語を知らないのはガチｗ 627 名前：デフォルトの名無しさん mailto:sage [2012/01/19(木) 07:49:43.56 ] >>626 関数型言語使えるなら、コード書いてちょ 628 名前：デフォルトの名無しさん mailto:sage [2012/01/19(木) 21:54:43.61 ] >>619 細かなIO制御は難しいが, 高速演算とかならLISPでもできるな 最近はそうでもないが， 高速演算/並列演算を最適化する研究は FORTRANとLISP中心で行われていた LISPは関数型じゃないって言ってしまえばそれまでだけど 629 名前：デフォルトの名無しさん mailto:sage [2012/01/19(木) 23:28:34.37 ] 「細かなIO制御」って言葉の意味が分からんけど、 語感から推測する限りでは別に関数型と相性が悪いようには思えない 630 名前：デフォルトの名無しさん mailto:sage [2012/01/21(土) 00:44:47.58 ] IO制御っていうかメモリ管理のことじゃない？ GCは、関数型言語でしか採用されてないわけじゃないし、 計算速度で言ったら、C言語かFORTRANしかいらないのかってことになるし、 批判が的外れなんだよね。 631 名前：デフォルトの名無しさん mailto:sage [2012/01/21(土) 12:19:36.90 ] >>630 どうしてIO制御はメモリ管理のことだと思った？ どっかから謎電波を受信しちゃった？ 関数型言語使うやつって、みんなこんな馬鹿ばかりなの？ 632 名前：デフォルトの名無しさん mailto:sage [2012/01/21(土) 12:56:53.35 ] >>631 ×）関数型言語使うやつって、みんなこんな馬鹿ばかりなの？ ○）Haskell使うやつって、みんなこんな馬鹿ばかりなの？ 633 名前：デフォルトの名無しさん mailto:sage [2012/01/21(土) 13:58:29.84 ] 関数型言語を使えない奴は馬鹿。 理解出来ないから、使えないことにしたいんだろ。 634 名前：デフォルトの名無しさん [2012/01/21(土) 19:40:42.50 ] Haskellが得意な分野って何かある？ 構文解析くらいか？ 635 名前：デフォルトの名無しさん mailto:sage [2012/01/21(土) 22:14:01.84 ] ハスケラが得意なのはアニメキャラの女装とオナニー。 636 名前：デフォルトの名無しさん mailto:sage [2012/01/22(日) 13:12:11.54 ] >>631 IO制御を何のことだと思ってるだろう？ 謎電波受信かｗ やっぱ馬鹿だな。 637 名前：デフォルトの名無しさん mailto:sage [2012/01/22(日) 13:52:08.59 ] 本家Haskellスレでお前らtailも満足に書けない アホ呼ばわりされてるじゃんw tail -f じゃないよ？ただのtailだよ？ 638 名前：デフォルトの名無しさん mailto:sage [2012/01/22(日) 14:06:08.39 ] >>636 ねえ、どうしてIO制御はメモリ管理のことだと思い込んじゃったの？ 哂ってあげるから正直に書いてみてごらん？ 639 名前：デフォルトの名無しさん mailto:sage [2012/01/22(日) 16:04:04.23 ] >>638 あほやの〜ｗ 640 名前：デフォルトの名無しさん [2012/01/22(日) 16:09:50.34 ] awabi.2ch.net/test/read.cgi/poverty/1327050821/3 641 名前：デフォルトの名無しさん mailto:sage [2012/01/22(日) 16:39:50.06 ] >>634 自分は＋演算子と同じ動きする演算子を定義しようとして、数字から再定義してペアノの公理（succ)作っちゃったけど、数学とはすごく相性良いね 自然数しか扱えないのを作ったけど、整数・分数への拡張はすぐ出来る自身はある 少数は・・・カウンタブルな無限じゃないから、独自定義は無理かな・・・ 柔軟性と実行速度だけなら、ＬＬを上回ってると思うよ （ghciやrunghcだとＬＬより遅いけど、コンパイルできる形にしてghcで実行ファイルにするとＬＬより１００倍速くらいになる） あと、ＬＬが得意とする文字列処理はＨａｓｋｅｌｌの方に軍配が上がる Ｗｅｂ系はＬＬよりＨａｓｋｅｌｌで作ったほうが楽なんじゃなかろうか 構文解析と繋がるけど、こんなブログ記事もある 正規表現を超える d.hatena.ne.jp/kazu-yamamoto/20090309/1236590230 642 名前：デフォルトの名無しさん mailto:sage [2012/01/22(日) 16:51:10.57 ] >>641 succで四則演算から再定義して大量の整数演算しても コンパイルすればLL言語よりも１００倍速くなるのか？ にわかには信じられない話だなあ。 643 名前：デフォルトの名無しさん mailto:sage [2012/01/22(日) 16:51:42.69 ] Haskellの文字列は遅すぎるだろ LLの文字列操作の方がずっと速い（Cで実装されてるし） 644 名前：デフォルトの名無しさん mailto:sage [2012/01/22(日) 17:43:40.79 ] >>637 Haskellスレは実用より理論な人が集まってるからなあ 645 名前：デフォルトの名無しさん mailto:sage [2012/01/22(日) 17:58:59.11 ] >>642 ただし、同じアルゴリズムに限る が、頑張ればＬＬと同じアルゴリズムは書けるよ 自分は、アルゴリズムやデータ構造の専門家じゃ無いが、ググレばづぐ出るし、分かりやすい （それを言ったら、Ｃの（ｒｙ） 646 名前：デフォルトの名無しさん mailto:sage [2012/01/22(日) 22:12:54.54 ] >>644 seekしてファイルの末尾から順番に読む程度のコードが書けなくて 理論もクソもあるか 647 名前：デフォルトの名無しさん mailto:sage [2012/01/23(月) 04:55:33.71 ] >>645 書けるかどうかじゃなくて、 Haskellでsuccで再定義された四則演算が LL言語のビルトイン四則演算の１００倍速いのかと 訊いているのだが？ 648 名前：デフォルトの名無しさん mailto:sage [2012/01/23(月) 06:27:37.62 ] >>647 そんなの、succのが遅いに決まってるだろ ＨａｓｋｅｌｌのビルトインとＬＬのビルトインを比較しない理由は？ 649 名前：デフォルトの名無しさん mailto:sage [2012/01/23(月) 10:10:20.41 ] >>644 X 実用、理論 O ルーチンワーク、これから開拓 650 名前：デフォルトの名無しさん mailto:sage [2012/01/23(月) 10:20:33.99 ] tailも書けないアホが何を開拓するの？ 651 名前：デフォルトの名無しさん mailto:sage [2012/01/23(月) 23:07:48.08 ] >>648 じゃあ何のためにsuccを定義するの？ 652 名前：デフォルトの名無しさん mailto:sage [2012/01/24(火) 07:03:06.28 ] >>651 haskellだと、あらゆるものを抽象化出来るって聞いたから、じゃあ+演算子と同じものを独自実装出来るんかいな？と、作ってたら、数字も抽象化する必要があって、知らん間にsuccになった ありていに言えば、ただの興味本位だよ 653 名前：デフォルトの名無しさん mailto:sage [2012/01/24(火) 07:05:27.27 ] you succ 654 名前：デフォルトの名無しさん mailto:sage [2012/01/24(火) 08:28:59.22 ] >>652 ただの興味本位ってわけじゃないと思うぞ。 655 名前：デフォルトの名無しさん mailto:sage [2012/01/24(火) 18:49:02.06 ] >>652 で、それがどうして「使える」ことにつながるの？ 656 名前：デフォルトの名無しさん mailto:sage [2012/01/24(火) 20:45:38.30 ] アルゴリズムを使いまわせる。 こういう基本的な関数を定義するのは、別に関数型にかぎらずに、 似たような処理をするところは、同じように書きましょう。 出来れば同じ関数を使いましょうってことで、そうすれば書く量も読む量も減って メンテナンスしやすくなる。 657 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 07:20:58.08 ] >>655 ? 使えるって？ succ自体は糞の役にもたたんよ？ 言語としての抽象度が高いからこそ簡単に書けるんだろうなって書いてて思っただけで 658 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 09:25:48.95 ] 抽象度ｗ 659 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 11:18:22.60 ] 今時succで四則演算を再定義できないってよっぽどいまいちな言語だろ 関数型言語の特徴とは思えんのだが 660 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 11:21:01.47 ] 再帰的データ型を定義できるかどうかだろ？ 661 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 13:06:55.36 ] 色んな言語のsuccを見てみたい 662 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 17:17:09.53 ] Cだと厳しい、C++やGCのある言語なら余裕 別にHaskellである必要は全然ないな 663 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 17:34:43.44 ] 既存の型とのマッピングを定義して、 その上でsuccやadd等を定義すればいいだけ。 typedef unsigned int nat; nat succ(nat n) { return n+1; } nat add(nat n1, nat n2) { if ((int)n1) return add(n1-1, succ(n2)); else return n2; } 664 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 17:41:51.34 ] >>663 それだとunsignedを使ってるから、自然数を自分で定義していない 665 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 17:44:43.73 ] >>664 じゃあunsignedを取ればいいｗ まあunsignedがあろうがなかろうが、その構造をsucc関数で構成した上で addを定義しているのだから、ペアノ自然数の実装として何の問題もない。 666 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 17:47:11.80 ] いやintとかunsignedとか使ったらさすがに自明すぎるんじゃね 667 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 17:49:03.60 ] 2^32で循環してるから自然数の定義にならない 668 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 17:49:14.67 ] keep it simple and stupid 669 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 17:51:04.11 ] >>667 int=32bit とは限らないよｗ ちなみに扱える自然数の数に上限があるのはHaskell等の関数型言語も同じ。 670 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 17:53:25.08 ] >>667 君が定義した自然数で2^128を求めてみてよｗ 多倍長整数にマップすれば問題ないが、 例えばHaskellあたりの代数データ型では無理だと思うよｗ 671 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 17:58:42.79 ] 循環していたら公理と矛盾するだろ 有限のリソースをもった計算機上で全ての自然数を列挙できないのは別の話 672 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 18:01:23.89 ] ペアノ式の自然数の定義って 「自然数とは、0か、自然数の後者である」 をなるべく自然にプログラミング言語に翻訳したものだと思ってたけど違うの？ 673 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 18:03:28.47 ] nat succ(nat n) { if(n == UINT_MAX)exit(-1); return n+1; } これで循環しない 674 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 18:51:53.51 ] >>670 Haskellは上限無いと思うんだけど、、、 675 名前：デフォルトの名無しさん mailto:sage [2012/01/25(水) 22:22:43.79 ] どんな言語だろうが、計算機上のリソースは有限なんだから 必ず上限がある。 だから自然数は決して実装できない。 676 名前：デフォルトの名無しさん mailto:sage [2012/01/26(木) 04:49:09.80 ] >>674 式の内部表現のグラフノードのポインタのビット数が決まっているからダメ 677 名前：デフォルトの名無しさん [2012/01/26(木) 06:32:42.87 ] ペアノの公理が簡潔に書けても実用性とあまり関係ない。 「数学と相性が良い」ってのも同様。 MathematicaやMaximaはHaskellより よっぽど数学寄りだが使い道は限定されている。 構文解析と教育、マの趣味としては活躍する 678 名前：デフォルトの名無しさん mailto:sage [2012/01/26(木) 06:57:37.66 ] >>663 +の逆演算である-を使っちゃいかんだろ +も-も使わず定義汁 自分は元々+演算子の再定義でsucc作ったんだぞ？ つまり、-演算子も同時に再定義してる 679 名前：デフォルトの名無しさん mailto:sage [2012/01/26(木) 07:12:41.65 ] +演算子を抽象化出来るか？が、自分のテーマだったから、既存の算術演算子(+,-,*,/,%)は使用しないのが絶対条件だった (さすがに=は使わないと定義出来ないんで使うけど) 680 名前：デフォルトの名無しさん mailto:sage [2012/01/26(木) 11:20:15.81 ] Cならポインタ演算p++をsucにするのが無難では？ つかこんなのC以外なら簡単。 その言語が使えるかどうかの指標にならない 681 名前：デフォルトの名無しさん mailto:sage [2012/01/26(木) 12:12:09.43 ] zero = () succ = lambda x : (x,) pred = lambda x : x if x == zero else x[0] itr = lambda f, x, y: x if y == zero else itr(f, f(x), pred(y))  add = lambda x, y: itr(succ, x, y) sub = lambda x, y: itr(pred, x, y) mult = lambda x, y: itr(lambda z: add(x, z), zero, y) def quo_and_mod(q, x, y):     r = sub(x, y)     if r == zero: return (succ(q), zero) if x == y else (q, x)     else: return quo_and_mod(succ(q), r, y) quo = lambda x, y: quo_and_mod(zero, x, y)[0] mod = lambda x, y: quo_and_mod(zero, x, y)[1] 682 名前：デフォルトの名無しさん mailto:sage [2012/01/26(木) 13:11:29.22 ] 結局、関数型言語由来の機能に頼ってる件 683 名前：デフォルトの名無しさん mailto:sage [2012/01/26(木) 17:40:08.76 ] へー、何が関数型由来なのか言ってご覧？ ちなみにクロージャは関数型由来じゃないよｗ 684 名前：デフォルトの名無しさん mailto:sage [2012/01/26(木) 21:59:36.02 ] 昔、オブジェクト指向にもケチ付けてる奴は居たよなあ 685 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 04:32:17.58 ] 関数型にケチつけるつもりはないが Haskellこそ至高みたいな意見は鼻につく succが書けた程度で言われると特に 686 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 05:57:42.32 ] >>684 今でもオブジェクト指向にケチつけてるハスケラがいるねぇｗ 687 名前：デフォルトの名無しさん [2012/01/27(金) 06:02:24.04 ] ほうなるほどなるほど 688 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 07:52:17.63 ] succどうしが等しいとか、どっちが大きいとか、比較出来るようにする仕組みはhaskellが楽 689 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 08:45:24.18 ] >>688 後出しかよ。 口だけじゃなくてその根拠となってる比較のコードを書いてくれ。 690 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 10:25:36.30 ] >>688 ほう、>>663のやり方なら整数比較でOKだが、それより簡単なのかｗ 691 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 12:17:34.48 ] gt = lambda x, y: sub(x, y) != zero lt = lambda x, y: sub(y, x) != zero ne = lambda x, y: gt(x, y) or lt(x, y) eq = lambda x, y: not ne(x, y) 692 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 13:07:52.77 ] driving(Eq,Ord) この一行をsucc型定義の下に追加するだけ 693 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 13:21:01.28 ] >>692 いや、Ordはderiveするだけじゃダメだろ 694 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 13:21:21.03 ] Haskellの文法や型システムや勝ち抜きの比較が便利なだけで 関数型言語の特徴ではないような 仮に副作用を認めるunsafeHaskellみたいなものが存在しても 同じように書けるだろう MLやLISPみたいな手続き型の言語に対して関数型言語は参照透明という制約が増えているから ミスを減らせるとかの利点はあっても簡単にかけるってことはないんじゃないの？ 695 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 13:22:10.80 ] >>693 え、出来てるけど。。。 696 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 13:25:37.41 ] >>694 え、MLもLispも一般的には関数型言語と言う認知だと思うけど。。。 まさかλ計算由来のラムダが関数型言語由来の機能じゃないとは言わないよね？ 697 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 13:27:26.39 ] >>696 まさか、ラムダ計算が関数型言語由来だとか 馬鹿なことは言い出さないよなw 698 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 13:33:20.72 ] >>696 いやこのスレの上の方の流れだと OCamlerがHaskellerを煽ってる感じだったから 699 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 14:17:40.62 ] MLが手続き的ねえ…面白杉 700 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 14:19:11.80 ] >>678 いや、>>663が使っている-はintの-であってnatの-じゃないからOKだろｗ 701 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 14:22:01.28 ] >>695 全ソースplz 702 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 15:03:08.87 ] >>692 なんだ。succを自分で書くなんてマゾいこと言うから 全部自分で書くのが好み（お勉強目的）なのかと思ったが、そうでもないの？ だったら>>681は何も書かなくても ==, !=, >, < で比較できる ideone.com/ui1NR 703 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 15:48:04.82 ] >>699 MLは手続き的だろ 定義すら上から順番に実行（？）される 704 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 17:12:45.32 ] ほう、ハスケルはEOFから逆順にでもパースされていくのかな？ 705 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 17:33:38.71 ] Haskellは定義を任意に並べ替えてもプログラムの意味が変わらないってことだろ 706 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 17:59:32.58 ] >>696 ラムダがあれば関数型言語になるなら 今時の言語は大抵関数型言語になっちゃうんだが perlやPHPやmatlabが関数型言語なのか？ 707 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 18:54:16.66 ] >>705 行単位でシャッフルしたら構文エラー出まくりなんだがｗ 708 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 18:59:58.31 ] 「定義」って書いてあるのが読めねーのかアホ 709 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 20:44:08.00 ] >>706 ラムダが有れば関数型言語とは言ってないだろ ラムダが関数型言語由来の機能だと言ってるだけだろ 710 名前：デフォルトの名無しさん mailto:sage [2012/01/27(金) 21:22:41.20 ] >>709 >>697を100回読み直せ 711 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 02:35:31.04 ] >>703 > >>699 > MLは手続き的だろ > 定義すら上から順番に実行（？）される それは名前のスコープをどう定めているかの問題であって手続き型言語か関数型言語かとは別問題。 OCamlなどのML一族の言語は関数型原理主義の立場から言えば手続き型言語だけれど、関数型言語として認識しているのが（恐らく圧倒的な）多数派。 MLの場合、どうしても必要となればref型の変数を用いた破壊的代入が使えるというだけで、普段はほとんど使用せずに書かれているから。 （バグなどで異常終了した場合のデバッグ用の情報を自分で残したい場合なんかには、ref型への代入があるのはとても便利。 あれがなければ多くのLisp環境みたいに専用のデバッガやトレーサーが用意されてないとMLプログラムのデバッグ作業は難しいと思う） なお、>>696の > え、MLもLispも一般的には関数型言語と言う認知だと思うけど。。。 Lisp、特にScheme以外のポピュラーなLispを関数型言語という認識は今では少数派だと思う。 現実のLispプログラミングは昔からPROGフィーチャーをガンガン使った手続き的なコーディングが占める比率が高いからね。 Schemeにもグルーピングのためのbegin式があるが、他のLispにおけるPROGほどには使われているようには見えないし、 高階関数を用いたプログラミングの比率は恐らくSchemeは他のLispよりもかなり高いと思う。 （プログラミングの教科書や参考書を見ても、Scheme以外のLispに対するテキストは高階関数の活用なんかには それほど力を入れていないのに対して、Schemeプログラミングの教科書は高階関数をどうやって活用するかに相当な比重を 置いて書かれているものが多い。特にIndiana学派の連中が書いたSchemeの教科書や参考書はその傾向が顕著） 712 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 03:36:22.86 ] >>711 名前のスコーピングだけの問題じゃねーだろ IOだって副作用なんだからref使わなくても順序は発生する これ実行してみろよ let f () = print_endline "aaa" let _ = f () let f () = print_endline "bbb" let _ = f () 713 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 04:41:28.60 ] schemeのトップレベルのbeginは少なくとも((lambda()))には変換できない マクロは1つのリストしか返せないので複数のトップレベルdefineを 行うマクロを実現するにはbeginは特殊化されてないといけない CLではどうだったかな 714 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 04:42:36.26 ] あ、副作用抜きでそういう仕組みが要るという話ね 715 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 06:36:20.65 ] 純粋関数型言語は使えない LispやMLはどうでもいい 716 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 07:49:42.20 ] >>712 IO に使うファイルハンドラが ref そのものだろ 717 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 08:04:14.99 ] >>716 out_channelの型は隠蔽されてるからOCaml的にはref型じゃないだろ それに>>711はそういう意味でref型って言ってないと思うぞ > MLの場合、どうしても必要となればref型の変数を用いた破壊的代入が使えるというだけで、普段はほとんど使用せずに書かれているから。 それともMLではIOは殆ど使用せずに書かれてるのか？ 718 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 08:35:57.17 ] >>717 だとすると俺には >>712 が何を言いたいのかわからない 719 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 08:45:00.13 ] MLは let x1 = e1 in let x2 = e2 in e3 と let x2 = e2 in let x1 = e1 in e3 で意味が変わるんだよね。 720 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 08:47:53.06 ] 正格評価だからね 721 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 08:52:10.99 ] >>718 MLにおいて式が順番に評価されることは 「名前のスコープをどう定めているかの問題」ではない 722 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 08:54:27.78 ] let f () = print_endline "aaa" let _ = f () let f () = print_endline "bbb" let _ = f () これを IO モナドを使って Haskell で書いたら順序の問題が発生しないの？ 723 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 08:54:57.98 ] 「MLにおいて」というのが意味不明ってこと 724 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 08:57:03.98 ] 関数型言語であり、かつ手続き型言語でもある、というのが無難な落としどころだろう 725 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 08:59:50.04 ] >>722 誰も順序の問題が発生しないとは言ってない >>705だと言ってる 726 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 09:55:07.42 ] >>719 ML(Standard ML)の場合: 　　let val x=1 in let x=2 in x end end　　(* Result: 2 *) 　　let val x=2 in let x=1 in x end end　　(* Result: 1 *) Haskell(Gofer)の場合: 　　let x=1 in let x=2 in x　　-- Result 2 　　let x=2 in let x=1 in x　　-- Result 1 MLは意味が変わるけど、同じくHaskellも意味が変わる >>720 上で示したように、非正格評価であるHaskellも(スコープの変化に応じて)意味が変わる >>721の指摘が正しい おそらく>>719,720は正格評価/非正格評価の意味を誤って解釈していると思われる 727 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 09:59:07.38 ] >>724 つまり、do記法を構文糖として定義しているHaskellは、 関数型言語であり、かつ手続き型言語でもある、というのが無難な落としどころなのですね たいへんわかりやすいです 728 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:04:37.57 ] >>726は変数束縛の隠蔽をしてるからHaskellでも意味が変わる これはスコープの問題 >>719の例とは違うだろう 729 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:11:07.62 ] 関数型言語スレからコピペ >334 名前: 283 Mail: sage 投稿日: 2011/09/29(木) 18:17:12.26 >>>298,323 > >FP >　---- 壁0. 変数の壁 ---- >Haskell >　---- 壁1. 純粋性(副作用)の壁 ---- >SML/OCaml >　---- 壁2. 型推論の壁 ---- >Scheme >　---- 壁3. 末尾再帰最適化/局所定義式の壁 ---- >========<< 越えられない壁 >>======== >Smalltalk/Ruby >　---- 壁4. 条件判定式の壁 ---- >Perl/Python/JavaScript >　---- 壁5. クロージャ/ラムダ式の壁 ---- >========<< 越えられない壁 >>======== >C/C++/Java...etc 730 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:12:46.18 ] let x = M in N ってのは、MLなら x = M; N だが、Haskellなら #define x (M) N; ということだな。 #define の順序を入れ替えても意味は変わらない。 731 名前：726 mailto:sage [2012/01/28(土) 10:19:22.14 ] >>728 では、変数束縛を隠蔽しないコードの例だ こちらの例のほうが、(>>726よりも)>>719の例に近いだろうと思う ML(Standard ML)の場合: 　　let val x=1 in let val y=2 in x-y end end　　(* Result: ~1 *) 　　let val y=2 in let val x=1 in x-y end end　　(* Result: ~1 *) Haskell(Gofer)の場合: 　　let x=1 in y=2 in x-y　　-- -1 　　let y=2 in x=1 in x-y　　-- -1 変数束縛が隠蔽されなければ、MLもHaskellも意味は変わらない もし反論あるなら、MLとHaskellで結果が変わる(>>719ではない)例の提示をキボン 732 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:20:21.53 ] >>727 do   a <- x   b <- y   return a + b これは次の構文糖だよ？ x >>= (\a -> y >>= (\b -> return a + b)) 順序を関数合成で表すからこそ純粋関数型言語なわけよ MLは順序を関数以外で表現するから手続き型言語と言われるわけ 733 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:21:52.71 ] >>730 >だが、Haskellなら >#define x (M) >N; > >ということだな。 >#define の順序を入れ替えても意味は変わらない。 いったい、とことどこを「入れ替えた」の？ 日本語として意味不明な文章だ 734 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:21:58.05 ] >>701 前書いたのそのままで良ければ -- 自然数を定義 data NaturalNum = Zero | PlusOne NaturalNum deriving (Eq,Ord,Show,Read) -- 加算を定義 Zero +^ n = n m +^ Zero = m m +^ n = inc m +^ dec n -- 減算を定義 Zero -^ n = n m -^ Zero = m m -^ n | m == n = Zero m -^ n = dec m -^ dec n -- インクリメント（１＋）を定義 inc n = PlusOne (n) -- デクリメント（１−）を定義 dec (PlusOne (n)) = n -- 自然数を独自自然数へ変換 int2NaturalNum 0 = Zero int2NaturalNum n = PlusOne (int2NaturalNum (n-1)) -- 独自自然数を自然数へ変換 naturalNum2int Zero = 0 naturalNum2int n = 1 + naturalNum2int (dec n) 735 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:26:57.31 ] >>733 $ cat a.txt #define F(UNIT) print_endline "aaa" #define UNDER_SCORE F(UNIT) #define F(UNIT) print_endline "bbb" #define UNDER_SCORE F(UNIT) $ cpp a.txt # 1 "a.txt" # 1 "<built-in>" # 1 "<command-line>" # 1 "a.txt" 遅延評価では何もしない 736 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:31:13.94 ] >>732 ML(Standard ML)で順序を表すには、;(セミコロン)演算子を使う そして、>>732のような手続きの表現には、;演算子と参照型を組み合わせる ! a x ; ! b y ; a + b ここで、;演算子は2引数で常に後者を返すという、まさしく関数であるけれど、 はたして>>732の目には、 ;演算子が「関数以外」の何に見えているのだろうか？ 737 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:36:55.32 ] >>731 >>719のe1やe2の式中でref型使ってれば変わるよ 738 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:39:38.95 ] >>736 自分で参照型「も」使うって書いてるじゃん 739 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:42:14.17 ] ハスケル以外はみんな不純！ 740 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:43:15.33 ] 不純だから劣ってるって話でもないんだけどね 741 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:47:57.48 ] >>738 MLが参照型「も」使うから手続き型であるというのなら、 「関数以外」の do「も」使う Haskell も手続き型ということになるよね それともHaskellにとってdoは関数なのかな？ その場合、関数doの型定義(定義域と値域)は？ 742 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:52:09.04 ] doは只の構文糖だけど、refって構文糖なの？ いや、MLはHaskellのdoの中にずっと居るようなもんだと 思えばそうなのか？ 743 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:55:28.86 ] >>737 もちろん二つのref型への代入を入れ替えれば、意味が変わるのは当然の事 そして、Haskellにはそもそもref型が存在しないから、入れ替えを行いようが無い で、何を言いたいの？ 744 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:58:27.42 ] >>743 >>719で結果が変わる（かつ未定義にならない）のはMLが正格評価だから 745 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 10:58:47.42 ] MLのrefはデータ型ですよ 関数ではありません Haskellのdoが(「関数以外」の)構文糖であるように.... 746 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:01:48.64 ] ただの構文糖のdoを指して「関数以外のものを使ってる」という>>741は意味不明 表記法法が違うだけで使ってるのは関数 747 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:03:49.18 ] 裏でこっそり副作用起こしてる「純粋な」関数w 748 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:11:49.35 ] >>732 ＞ x >>= (\a -> y >>= (\b -> return a + b)) Haskell わからんのだけど、これって (lambda a -> (lambda b -> a + b) y) x と何がちがうの？ 749 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:13:12.74 ] >>744 >>>719で結果が変わる（かつ未定義にならない）のはMLが正格評価だから 違うだろw >>719で結果が変わるのは参照型への代入を使った例外的な場合のみ それ以外の一般的な式においては、(Haskellと同様に)意味は変わらない(>>731を参照) Haskellで意味が変わらないのは、参照型が存在しないので入れ替えようがないから その代わりに(MLにはない)doという「関数以外」のモノが存在する そして、do記法の中で式を入れ替えれば(MLと同様に)意味が変わる 結局、ここまでの手続き的か否かという議論の中で、正格評価/非正格評価の違いは無関係 あえて関連性を言えば、 　非正格評価であるHaskellでは参照透明性がくずれるref型を導入「できない」から、 　do記法という「関数以外」の異物を導入した という点かな 750 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:17:05.06 ] >>746 Haskellの do が「ただの構文糖」にすぎない、というのなら、 MLの ref も「ただのデータ型」にすぎない、としないと>>746は矛盾を抱えるよね？ 751 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:17:13.34 ] >>749 let x = ref 0 let f () = x := !x + 1; !x let a = f () in let b = f () in   a - b へー、これで a - b が決定されるのは正格評価と関係ないんだ あとdoは構文糖だっていってんだろ 表記が違えば関数じゃなくなるのかよ 752 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:24:53.46 ] >>751 関係ないよ。 753 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:26:05.08 ] >>747 机にかじりついて勉強ばかりしている頭でっかちよりも、 時には裏でこっそり「不純な」xx交遊するほうが、生きていて楽しいよねw 私は純粋で品行方正ですなんて、どこかの政治家みたいでかえってうさん臭い 754 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:29:42.76 ] >>748 >>=は二項演算子だから、bind という関数に置き換えて書くと bind x (lambda a -> bind y (lambda b -> return a + b)) 755 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:30:59.08 ] それただの言い換え・・・ bind って関数の定義を教えてほしいんですけど・・・ 756 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:32:57.98 ] >>752 じゃあこれは？ let a = f () in let b = f () in   print_int b;   print_int a;   a - b 757 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:35:10.25 ] >>755 bind :: [a] -> (a -> [b]) -> [b] 758 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:35:42.61 ] >>748 >>=は二項演算子だから、bind という関数に置き換えて書くと bind x (lambda a -> bind y (lambda b -> return a + b)) 759 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:36:19.75 ] あれ？何で前に書き込んだ内容が...？ 760 名前：749 mailto:sage [2012/01/28(土) 11:36:37.96 ] >>751 >へー、これで a - b が決定されるのは正格評価と関係ないんだ うん、関係ないよ 関係するのはref(参照型)の使用 繰り返しになるけど、refを使わなければ意味はHaskellと同じ(>>731を参照) あとrefは「ただデータ型」だっていってんだろw 761 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:38:48.75 ] >>756 関係ないよ 正格と非正格で評価順序が違うから、 副作用のある式を評価すれば当然結果は変わるけど、 正格でも非正格でもそれぞれの評価戦略に従って a - b の値は一意に決定されるよ。 762 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:40:45.02 ] 参照透過で停止するならチャーチロッサー性により結果は同じ 763 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:43:14.27 ] >>761 だからrefを使っててもa - bが定まるのは正格評価だからだろ a = f () と b = f () のどっちを先に評価するかで結果変わるんだから もし print_int で出力する時点で評価する遅延評価なら 結果が変わっちゃうだろ 764 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:44:53.23 ] >>763 ＞a = f () と b = f () のどっちを先に評価するか それはマイナスという二項演算子の定義の問題 正格評価と全然関係ない 765 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:48:55.03 ] 参照透過ならまぁそうだね。 766 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:51:23.77 ] >>757 [a] ってのは何？ 767 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:52:28.11 ] MLは参照透過じゃないからね 768 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:54:57.03 ] haskellもリストは、完全に参照透過じゃないと思うけど、、、 769 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:55:26.27 ] Haskell は建前参照透過とでも言ったところか 770 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 11:58:20.28 ] >>766 []はリストじゃない？ 一般的には  (>>=) :: m a -> (a -> m b) -> m b  じゃないの？ Haskell知らんけど（定義はwebからコピった） OCamlなら (>>=) : 'a t -> ('a -> 'a t) -> 'a t return : 'a -> 'a t 771 名前：749 mailto:sage [2012/01/28(土) 12:05:23.04 ] >>763 だからrefを使わなければ、正格評価でも非正格評価でも結果は同じ(>>731を参照) そしてrefが使えば結果は変わるけど、そもそもrefの存在が許されるのは正格評価だけで、 非正格評価では(参照透明性が崩れる)refの存在は許されない もしも非正格評価でrefが使えてかつ結果が同じであれば、 その理由が正格/非正格の違いであると考察する事は正しいと思う しかし、残念ながら非正格評価ではrefが使えないから、比較そのものが成立しない 従って、両者の差異を決定付ける要因とは、refを使う/使わないという違いであると結論付けられる ハァ、疲れたョ ここまで書けば納得してもらえるかな？ 772 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 12:43:21.61 ] let x = ref 0 let f () = lazy (x := !x + 1; !x) let (!$) x = Lazy.force x let a = f () in let b = f () in   print_int (!$ b);   print_int (!$ a);   (!$ a) - (!$ b) lazyで遅延評価するとref型を使ってもletの順番には異存しないよ 773 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 13:25:02.71 ] 極端なこと言えば、 非正格評価のメリットって無限リストを扱えることだけじゃん。 それだけのために失っているものが大きすぎじゃね？ 774 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 17:34:04.06 ] 他にも色々なボトムを回避できるけど？ 775 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 20:16:56.19 ] ここまで説明されてもさっぱりわからない いや、判ろうとしないだけだ なんつって なんつって orz 776 名前：デフォルトの名無しさん mailto:sage [2012/01/28(土) 20:26:38.85 ] >>766 汎用のリスト型(aとかbとかのちゃんとした名前は代数型とか何とか言ってた気がする) リストの中身はどんな型でもおk(ただし、中身各要素の型は同じ型で統一しないとダメ) c++のテンプレートとか、c#,javaのジェネリックみたいなもん 777 名前：aaa ◆sVVR0Q7eM2 mailto:sage [2012/01/31(火) 11:47:27.11 ] a 778 名前：デフォルトの名無しさん mailto:sage [2012/02/01(水) 09:43:15.15 ] 最近、アンチスレが隔離スレとして機能してないので他のスレが迷惑な件。 779 名前：デフォルトの名無しさん mailto:sage [2012/02/01(水) 14:21:12.28 ] 今c#使ってて のvarを覚えた var という暗黙の型を持つことができます。 暗黙的に型指定されたローカル変数は、型を宣言した場合と同様に厳密に型指定されますが、コンパイラが型を決定します。 次に示す 2 つの i の宣言は、機能的に同じです。 とのことことだが関数の人これどう思う？ static関数でvar でやってけば関数っぽくなるのでは？ 780 名前：デフォルトの名無しさん mailto:sage [2012/02/01(水) 14:24:51.69 ] var を メソッドのシグニチャに記述はできないが、できるようにしたらという意味かな。 F# はそういった実装になってる。

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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