関数型プログラミング言語Haskell Part16

[過去ﾛｸﾞ] 関数型プログラミング言語Haskell Part16 (978ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

949: 2012/01/02(月)11:37 AAS
>>945
それ、MonadどころかLISPのS式の時点で示されてるじゃんｗ

950(1): 2012/01/02(月)11:54 AAS
>>948
京都の先生にSICPの訳をdisられた疑惑が浮上して以来2chでの権威はストップ安です

951(1): 2012/01/02(月)12:19 AAS
>>950
disられたってどういうこと？

952(1): 2012/01/02(月)12:26 AAS
モナドは中身はともかく、どう書けるかって話だと確かに関数型捨ててるでしょ。
特にdoを使って書いてると手続き型とほとんど変わらんし、似たようなスパゲティ化もしやすいし。

953(1): 2012/01/02(月)12:30 AAS
>>948
和田（笑）

954(1): 2012/01/02(月)12:54 AAS
>>951
外部ﾘﾝｸ:togetter.com
ここにまとめられてる湯浅先生の発言を、
キチガイが拡大解釈して必死に広めてるだけ。

キチガイ死ねよ。

955: 2012/01/02(月)13:02 AAS
>>948
こういう人は具体的に何故モグリなのか全然説明してくれないから説得力が全くない
権威主義の人って大体そんな感じ

956(1): 2012/01/02(月)13:29 AAS
>>954
なんで自分で噂に根拠与えちゃってるの？
そのままほっとけば単なる噂ですんだのに。

957: 2012/01/02(月)13:43 AAS
クロージャーとかジェネレーターの辺りで完結するべきだった。
最近の関数型はだらだら引き伸ばしているだけ。

958: 2012/01/02(月)13:44 AAS
>>956
根拠のない噂を広める罪がわからないゴミカスのようなキチガイは死ねよ。

959(2): 2012/01/02(月)14:06 AAS
>>952
つまり、プログラマが式をどう考えるかや、コンパイラが式をどう扱うかではなく、
式をどう書くかによって関数型かそうでないかを判断しているのか、お前は

じゃあ、お前の言う関数型を捨てた書き方である

do {x <- getLine; putStr $ "> " ++ x}

これを

getLine >>= putStr . ("> " ++)

こう書いたら、関数型に戻るのか？

あともう一つ、本当にdo表記で似たようなスパゲティ化が起きやすいのか？
お前はdo表記で頻繁にスパゲティ化してしまっているのか？

スパゲティ化という事は、実行順序、Haskellなら計算順序が複雑に絡まるんだよな
それはdo表記だから絡まるのか？むしろdo表記の方が絡みにくくないか？

960(1): 2012/01/02(月)14:14 AAS
>>959
前者に関しては、俺の感覚ではイエス。
後者に関しては俺の書き方が悪かった。
手続き的なコードが縦にダラダラ長くなるとぐちゃぐちゃに見えてキモいってだけなんだ。

961: 2012/01/02(月)14:27 AAS
好き嫌いだけで一歩も進んでないのな

962(2): 2012/01/02(月)14:33 AAS
>>945
どんなもの達をもってきても、それらが｢大体同じである｣と見る視点はいくら
でも作れるわけだが、ListとIOとMaybeは大体同じだというモナドの視点はそんな
ナンセンスな視点ではないのだね？

963(1): 2012/01/02(月)15:05 AAS
>>962
> そんなナンセンスな視点ではないのだね？

「そんな」がどんなのを指しているのか曖昧だな
もっとはっきりと言ってくれ

大体同じであるという視点はどのような集合に対しても適用できるけど、
「どう同じなのかが論理的に説明できる」ことと、
その視点が応用する上で「役に立つ」こと、
この2点が無いとせっかくの発見も後の時代まで残らない

モナドはとりあえず今のところ残ってる

964(1): 2012/01/02(月)15:12 AAS
>>960
お前の手続き的なコードが縦に「ダラダラ長くなる」原因は何だ？
それはdo表記のせいなのか？

お前はもしかして、自分のコードがdo表記で縦にダラダラ長くなったら、
その原因がdo表記にあると考えて、getLine >>= putStr . ("> " ++)
みたいな表記に直すのか？

それとも、キモいって言うだけで、後が続かず終わってるのか？

もし本当にそうなら、関数型や手続き型うんぬんの前に、
プログラムそのもの構造を学んだ方が良いぞ（SICP なんか読みやすくてお勧め）

965(1): 2012/01/02(月)15:26 AAS
>964
縦に長くならなくても、
do {x <- getLine; putStr $ "> " ++ x}
のxも、関数型からすれば嫌だろ。

966: 2012/01/02(月)15:37 AAS
>>965
では構文的な構造が似ている

let x = 3 in f x

これも「関数型からすれば嫌」なのか？

967(1): 2012/01/02(月)15:53 AAS
>>963
最初からモナドと言わずにリストと言えば通じやすかったと思うが。

968(1): 2012/01/02(月)16:15 AAS
>>967
すまん、言わんとしていることがよく分からん
俺の発言の何に対する意見なんだ？

通じやすかったというのは世間にか？それともここ一連の会話の誰かにか？
前者なら最初から委員会の連中はリストはリストと言っている（モナドは後付け）
後者なら誰だよそんな事言ったの

俺は >>962 の
ListとIOとMaybeは大体同じだというモナドの視点はナンセンスかどうか、に対して、
モナドはどう同じなのかが論理的に説明できており、かつ役に立つ視点である、
だからナンセンスではない、という自分の考えを謂わば逆説的に述べただけだよ

969: 2012/01/02(月)16:34 AAS
>>953
それはスーフリの方。
>>959
do表記は手続きっぽくなるから、スパゲティーメイカーになりやすいかも。
スパゲティーにするならせめてカルボナーラかミートソースにしてくれよ。

970(2): 2012/01/02(月)16:36 AAS
手続きっぽくなるとスパゲティになる理由は？
ちゃんと自分の言葉で説明できるか？

971(1): 2012/01/02(月)16:39 AAS
>>968
俺の方が曖昧な言い方ですまんかった。
まず通じやすかったというのは世間に対してという意味だった。
｢ListとIOとMaybeは大体同じだ｣というときの共通性が、言ってしまえばリスト化
（多元化）にあるのだとすれば、モナドなどというよりリストと言った方が
伝わり易いと思ったわけだ。また曖昧なこと言ったかな。
（ナンセンスうんぬんの方はもういいよ）

972(1): 2012/01/02(月)16:57 AAS
>>971
あぁ、なるほどな

> ｢ListとIOとMaybeは大体同じだ｣というときの共通性が、
> 言ってしまえばリスト化（多元化）にあるのだとすれば、

そう解釈してしまったのなら、

> モナドなどというよりリストと言った方が伝わり易いと思ったわけだ。

と言うのも十分に分かる、というか当然の反応だ

ただ残念ながら、少なくとも「それらに見いだした共通性はリスト化だ」
という解釈に関しては間違っている（多元化の意味は分からんが）

Wadler氏が List、IO、Maybeなどにどのような共通性を感じたのかは
Monad型クラスの関数に間接的に表れてはいるが、俺の力ではとても一言で言えない
それこそちゃんと知るには彼の論文や基になったMoggi氏の論文を読まないといけない

ただ、一般的なプログラマには「Monad型クラスの関数がモナドに共通する構造だ」
と言いうだけで応用上は十分だと思う
その共通構造をモナドが応用される前のListやIOに見いだしたと言っていい

973(1): 2012/01/02(月)18:16 AAS
>>972
よくわかってないが、非決定計算、副作用、継続についてはMoggiの最初の論文の中で定式化されてる。

共通性といいたいところは多分普遍的性質のことだろうと思う。
普遍性の構造が共通している、というかそれぞれモナドで整理可能だからモナドなんだろう。

974(1): 2012/01/02(月)18:20 AAS
>>970
デバッグが困難になる。

975(1): 2012/01/02(月)18:25 AAS
>>973
普遍的性質って具体的には？

976: 2012/01/02(月)18:27 AAS
モノイダル圏におけるモノイド対象が存在すること

977: 2012/01/02(月)18:33 AAS
>>975
ある一つの性質から全体の性質が定まることで、
モナドの場合はそれが入れ子状になっている、ようだ。
正直そんな説明できるほどわかってない。

978: 2012/01/02(月)18:46 AAS
>>974
それは全く説明になっていないと思うぞ

>>970 が訊いているのは手続きっぽくなるとスパゲティになる理由だ

[1] 手続きっぽくなる --> [2] スパゲティになる

原因 [1] によって結果 [2] になることを筋道を立てて説明してほしいのだろう

しかし、デバッグが困難になるというのは、さらにその先の結果だ

[2] スパゲティになる --> [3] デバッグが困難になる

デバッグが困難になるからスパゲティになるのではない（[3]-->[2]）
スパゲティだからデバッグが困難になる（[2]-->[3]）

上下前次 1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.181s*