[過去ﾛｸﾞ] 関数型プログラミング言語Haskell Part16 (978ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
78: デフォルトの名無しさん [sage] 2011/10/10(月) 12:22:16.16 AAS
>>7575(2): デフォルトの名無しさん [sage] 2011/10/10(月) 12:02:03.74 AAS
さて
haskell情報で重宝してるところってどこ？
planet haskell,
stackoverflow
haskell cafe
などあるけど
google search
161: デフォルトの名無しさん [sage] 2011/10/15(土) 19:17:23.16 AAS
>>157157(1): デフォルトの名無しさん [sage] 2011/10/15(土) 19:01:54.05 AAS
Aは haskellerならappricativeを想像するんじゃないかな。
では、mapAdj や mapN (N = Neighborhood) で
>>156156(1): デフォルトの名無しさん [sage] 2011/10/15(土) 18:33:46.42 AAS
mapだと単なる写像とか関手って意味しかなくて、そんなものは型みりゃ一目瞭然でそんなのを型と名前で二回も使ってると
頭痛が痛いみたいな違和感が出てきてちょっとDRY的によろしくない感じ
zipだともうちょっと意味が狭くなって [a] `f` [b] -> [a `f` b]的なリストとfの分配法則みたいな意味が出てくるけど
これも型みりゃだいたい入ってる、こちらは入れてもいい気もするけど
だから隣り合ったを示す言葉とか二つ目を一個ずらすみたいな命名ができると余すところ無く名前と型両方に無駄なく意味をこめることができていいかなぁ
とか思った
「名前と型両方に無駄なく意味をこめる」
なるほど、そういう考え方もあるのですね
わたしは、改めてこの関数を使うプログラマの立場に立って考えてみると、
型シグネチャはライブラリ ドキュメントを見ることでしか確認はせず、
普段ソース中でこの関数を使っている時は関数名しか見ないと思いました
そして、ライブラリ ドキュメントはソースに比べてそう頻繁に見るものではない
（自分がそうなので）
だからソースを眺めた時、この関数を使っているところで、
「何がどのような結果になるのか」という情報が仕舞われた頭の抽斗が開けやすくなる、
抽斗の場所がぱっと思い浮かぶようなキーワードがいいなと
ポイントフリーで使っていると余計にそう感じます
というわけで、私はむしろ型シグネチャで分かる意味・ニュアンスも、
積極的に関数名に入れていこうと、皆さんの意見を聞いて思いました
281: デフォルトの名無しさん [sage] 2011/10/27(木) 00:09:47.16 AAS
>>279279(3): デフォルトの名無しさん [sage] 2011/10/26(水) 23:30:49.18 AAS
遅延評価前提のデータ構造って、よ〜するに制御構造だよね？
これはいつ評価される(べき)か、とか考えつつデータ構造を作りながら、
ふとそう思った。
そう決めてしまうと
発想を狭めることにはなるかもしれないな
397: デフォルトの名無しさん [sage] 2011/11/07(月) 08:10:41.16 AAS
結合順序間違ってるとたいてい型エラーでるし、
そしたら:iで確かめたらいいし。
520: デフォルトの名無しさん [sage] 2011/11/13(日) 02:46:52.16 AAS
それは二つに分岐した一方のオブジェクト指向ではないかい？
649(1): デフォルトの名無しさん [sage] 2011/12/03(土) 02:51:07.16 AAS
haskellで速いプログラムを書くって大変なんですね。。。。
とhaskell初心者 orz...
792: デフォルトの名無しさん [sage] 2011/12/23(金) 10:30:00.16 AAS
STMとか？
821: デフォルトの名無しさん [sage] 2011/12/23(金) 22:45:15.16 AAS
そもそもデザインパターンがつまらんという感覚が良く分からない
846(3): デフォルトの名無しさん [sage] 2011/12/25(日) 19:05:37.16 AAS
>>841841(2): [―{}@{}@{}-] デフォルトの名無しさん [sage] 2011/12/25(日) 18:48:48.79 AAS
まずモナドとIOモナドを区別してくれ
純粋さを保ったまま入出力をする仕組みがHaskellにはあって、IOという名前の型が使われる
モナドというのはある種の型を抽象的に扱う枠組み
(どういう型をどうやって扱うのかは一言では説明できない)
で、IOはたまたまモナドの枠組に適合する(ので、IOモナドと呼ばれる)
で、モナドが知りたいの？IOが知りたいの？
> で、IOはたまたまモナドの枠組に適合する(ので、IOモナドと呼ばれる)
なるほど。
いつまでもIOモナドは難しいと言われ続ける理由がわかったよ。
本当にIOモナドは「たまたま」モナドの枠組みに適合してるの？
わざわざモナドとしての宣言をしているのを「たまたま」というの？
わざわざ色々なIOをモナド則にあわせて整理して宣言しているのを
「たまたま」とか言って誤魔化しているわけでしょ。
学ぶ人達の能力を信用していないから、そうやって誤魔化すわけだ。
そうやって学ぶ人達を信用せずに、ありのままを伝えず、
取って着けたようなすぐバレるデッチアゲばかり言うから、
学ぶ人達はどの言葉を信用すればいいかわからなくなって、
「Haskellは難しい」という結論になっているんじゃないの？
871: デフォルトの名無しさん [sage] 2011/12/25(日) 21:58:46.16 AAS
Haskell で GUI のアプリ作った・作ってる人っている？
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.031s