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

**デフォルトの名無しさん** · 2019/01/29(火) 09:05:47.90

関数型プログラミング言語 Haskell について語るスレです。

haskell.org (公式サイト)
https://www.haskell.org/
日本Haskellユーザーグループ
https://haskell.jp/

前スレ
関数型プログラミング言語Haskell Part31
https://mevius.5ch.net/test/read.cgi/tech/1506447188/

**デフォルトの名無しさん** · 2019/10/13(日) 08:24:39.79

競プロでもあるまいしアルゴリズムを非直観的なものに変形させる必要がどこにある？
そんなに漸化式が好きなら iterate (\xs -> [last xs+1,last xs+2..last xs+n]) でもやってろ

**デフォルトの名無しさん** · 2019/10/13(日) 12:28:55.45

プログラミング運算やると計算量がオーダーレベルで変わるよみたいな話もあるから
非直感的な宣言をすることがいつも無駄とは限らないだろう
今スレで話題になってる例が教育的によいかどうかはわからんが

**デフォルトの名無しさん** · 2019/10/13(日) 12:35:18.14

効率的な計算量になるようにコンピュータが計算して最適化してくれたらいいのに

**デフォルトの名無しさん** · 2019/10/13(日) 14:20:50.34

なにしてんの
mylist n = [ [(m - 1) * n + 1 .. m * n] | m <- [1 .. n] ]
とかじゃだめなの

**デフォルトの名無しさん** · 2019/10/13(日) 14:25:29.07

ただでさえO(n^2)なのにiterateとかやったらO(n^3)じゃん

**デフォルトの名無しさん** · 2019/10/13(日) 15:19:23.66

mylist n = take n $ chunksOf n [1..]
がダメらしいからそれもダメなんじゃない？知らないけど

**デフォルトの名無しさん** · 2019/10/14(月) 07:17:52.00

>>537
7000円

>>533
手続き型言語をやっていると非直感的ですが、そうで無い人(プログラミング未経験含む)だと割とこっちもメジャーなので、こっちが浮かぶのが関数脳を作れた基準？にしてます。

**デフォルトの名無しさん** · 2019/10/14(月) 13:10:48.92

n個の品物が入るナップサックがn個あって
1,2,3...と番号の書かれた品物を順番にいれていく
等々いくらでも行動的比喩が可能な問題に対して数式的に考えることが自然ねぇ・・・
まあ人間の思考傾向を議論するつもりはないけど
少し考えればシンプルに解ける問題は少し考えろと主張をしたいんだとしても
我々手続き的ゾンビにとってmylistの例が「直観性」を犠牲にするほどシンプルだとは思えないけどね

**デフォルトの名無しさん** · 2019/10/15(火) 00:51:42.29

チューリング完全なもの同士は等価である
Haskellと他の言語が等価であることを直感的に表現しているのがモナドだ
この文脈ではモナドが直感的だと思わない奴の直感はあてにならない

プログラミング未経験者ってのは文脈無視するのを正当化するための道具にされてるだけだろう

**デフォルトの名無しさん** · 2019/10/15(火) 08:43:19.81

隠そうとして隠し切れなかったのがモナド

**デフォルトの名無しさん** · 2019/10/16(水) 01:24:19.49

モナドっていうネーミングも謎

**デフォルトの名無しさん** · 2019/10/16(水) 01:58:12.16

ニョモレとかムニャンプの方が良かった？

**デフォルトの名無しさん** · 2019/10/16(水) 02:26:39.80

モノモノイド

**デフォルトの名無しさん** · 2019/10/16(水) 22:21:13.29

モナド＝単一子＝世界の究極の根本要素

でもHaskellのモナドは外部とのやり取りを隠蔽してる脇役みたいなものでしょ

**デフォルトの名無しさん** · 2019/10/16(水) 22:25:37.91

無理やり型合わせするためだけの言い訳だな。
くっだらねーとしか思わんかったわ。

**デフォルトの名無しさん** · 2019/10/16(水) 23:44:14.52

そう思ってでもまだこちらをのぞいているってことは
かなり気に入る・気になる部分もあったんだよね。

どんなところがよかったの？あるいは気になったの？

**デフォルトの名無しさん** · 2019/10/17(木) 03:04:05.52

CSで使われる用語って何かのめたふぁか知らんけど
無理に数学に合わせて造語っててかえって判り難さが増すというね

**デフォルトの名無しさん** · 2019/10/17(木) 03:47:00.30

モナドが分からんという人が多いのは
哲学のモナドと混同してるからだろうな
全く無関係の別物だと理解する必要がある

**デフォルトの名無しさん** · 2019/10/17(木) 04:08:11.17

いやそれはない

**デフォルトの名無しさん** · 2019/10/17(木) 06:05:35.66

モナドはわかっても何が凄いのか全然わからん教えてくれ

**デフォルトの名無しさん** · 2019/10/17(木) 07:39:25.89

哲学と数学の違いは「嘘を言ってはいけない」という点にどこまで集中するかの違い
すごいものを作るより有害なものを作らないことをどのぐらい重視するか

**デフォルトの名無しさん** · 2019/10/17(木) 08:37:09.64

たしかにモナドすごいすごいって言う人っていざ説明させると説明できないよねw
せいぜい受け売り止まり

**デフォルトの名無しさん** · 2019/10/17(木) 09:27:30.90

では説明お願いします

**デフォルトの名無しさん** · 2019/10/17(木) 09:56:17.77

受け売り止まりじゃない説明はよ

**デフォルトの名無しさん** · 2019/10/17(木) 10:16:38.68

モナドはただのデザインパターンの一つだろ

**デフォルトの名無しさん** · 2019/10/17(木) 10:44:35.23

>>560
俺は話聞いてるだけ
強引なHaskell推しに困ってる

**デフォルトの名無しさん** · 2019/10/17(木) 10:44:48.97

モナドほどの抽象化しただけで画期的じゃん
イテレータとか用意してデータ構造によらないコンテナへの共通インタフェースとさらにそれへの特別なシンタックスシュガー用意した言語ぐらいならあった
モナドなんか用意してdo記法なんてシンタックスシュガー用意してプログラミング言語における手続き的処理やその他諸々を抽象化した

**デフォルトの名無しさん** · 2019/10/17(木) 10:57:50.46

抽象化できてるか？
手続き型と同じっぽく見えるけど、いざ活用しようとすると同じようには使えなくて意味不明な型エラーで詰まる
結局のところモナドの仕組み理解できてないと使いこなせない
これは抽象化できてないってことでしょ

**デフォルトの名無しさん** · 2019/10/17(木) 11:46:58.33

そりゃ任意の手続き型言語を再現できるわけではないから完全な抽象化ではないけど

手続き型的な処理とか、失敗する可能性のある処理とか、非決定的処理だとか、そう言った諸々をまとめてモナドとして一般化してる
そのおかげでそれら全てで共通にdo記法やモナド向けの関数といったものが使えて、各種毎に個別に関数を用意したり覚えたりする必要が減る

自作のDSLなどを構築するときにも
モナドインタフェースを実装するだけでdo記法やモナド向け関数群を使えるようになる
他言語でDSL構築は結構大変だし、オレオレDSLなんてどういう仕様かわかりにくいけど、haskellなら型から検索したり型を見たりすることでどういうアクションがあってどうやって使うのかがわかる

**デフォルトの名無しさん** · 2019/10/17(木) 11:49:22.03

これがC++だったらJavaScript環境を作ってC++の仕組みを隠蔽するかもな
Haskellでも同じことをする自由はある

**デフォルトの名無しさん** · 2019/10/17(木) 21:34:43.47

関数脳になるとどんな利点があるのかな？
手続記述は使い回ししにくい？

参照透過性が確保されていて型の情報があれば
算法の記法が手続き的か定義的かを問わず
どちらでもいいような気もするが

**デフォルトの名無しさん** · 2019/10/18(金) 00:47:49.97

>>551
Haskellのモナドって関数型で命令的な処理の書き方をしたいってことだろ
要するにLispにPROGフィーチャー入れたのと同じような動機だろ

**デフォルトの名無しさん** · 2019/10/18(金) 06:44:38.21

>>562
絶対違う

**デフォルトの名無しさん** · 2019/10/18(金) 09:49:47.43

>>569
全然違うんだよなぁ…

**デフォルトの名無しさん** · 2019/10/18(金) 12:21:22.11

コンストラクターがオーバーロードできないから別の列挙型に同じタグ名がつけれないんだけど
どうしたらいい？

**デフォルトの名無しさん** · 2019/10/18(金) 12:40:18.58

>>569
学び始めはそう理解したが bind 演算子とか融合とか進んで
現時点では切り分けや共通化の便利な道具と思ってる

**デフォルトの名無しさん** · 2019/10/18(金) 12:41:41.68

>>572
自分だったら根本的な構造を見直すかな

**デフォルトの名無しさん** · 2019/10/18(金) 17:04:05.16

>>574
kwsk

**デフォルトの名無しさん** · 2019/10/18(金) 20:30:34.81

>>572
DuplicateRecordFields 拡張を使うとできるようになるっぽいよ。
http://lotz84.github.io/haskell/extensible-record.html

**デフォルトの名無しさん** · 2019/10/18(金) 20:44:14.39

>>576
俺も一瞬それ思ったけど同名データコンストラクタもできたっけ？

**デフォルトの名無しさん** · 2019/10/18(金) 21:22:19.66

>>577
コンストラクタの方か。見間違えてた

**デフォルトの名無しさん** · 2019/10/18(金) 22:18:25.57

data 宣言を別モジュールに分けて
両方が必要なら import ... as ... で別名をつけるって方法はどう？

**デフォルトの名無しさん** · 2019/10/18(金) 22:56:52.03

モナドを導入することで副作用のない
「副作用のチェーンをつくって渡す。」
ちなみに実行は副作用させるというバカみたいなレトリックを実行してるだけ。
バカはそういうものをありがたがるんだよ。
そしてそういうものをありがたがるというのはバカみたいに本質なんだな。

**デフォルトの名無しさん** · 2019/10/18(金) 23:39:51.57

モナドのごとく回りくどく分かりにくい文だな

**デフォルトの名無しさん** · 2019/10/19(土) 00:07:09.37

>>575
Haskellは個人の趣味・自己啓発の道具の範疇なので
参考にならないでしょうが…

名前がかぶるのはどこか機能がかぶってたりするかなと
型の使い方を見直したり組み合わせる関数を見直したり
所属するモジュールを移動したりとか。

どうしても名前がかぶるってときは英語名や日本語名
ときには中国語とかも借用する（ただし英字を使う
ローマ字やピンイン表記）か密接に関係する事柄の
接頭辞をつけてる。

**デフォルトの名無しさん** · 2019/10/19(土) 00:15:25.34

>>580
モナドで副作用・副作用もどきを扱えるけど
モナドの全てが副作用・副作用もどきを伴う
わけではないでしょ。

リストもMaybeもEitherもモナドとして扱う
定義はされているが別にそれをつなげても
副作用があるわけでなし。

**デフォルトの名無しさん** · 2019/10/20(日) 21:44:47.02

非決定計算やIOが同じモナドというククリで実現できるのが大変興味深いです

**デフォルトの名無しさん** · 2019/10/20(日) 23:54:14.30

なぜそんなにお前らがモナドについてあーでもないこーでもないと話し合ってるのかがわからない
モナドなんていたってシンプルな考え方なのに

モナドなんて単純にどうやって関数を合成するかというルールにすぎない
より正確には、「モナディックな関数」を合成するルール

では、モナディックな関数とは？それは"装飾された値"を返す関数のこと。
どんな装飾が施されたかについては、文脈によって様々だが、たとえば…

・エラー -> 失敗を表すデータもとりうる値 MaybeとかEither Error
・非決定性 -> いくつもの値を同時に表す値 List, Array
・副作用 -> 副作用自体を表すデータ Effect, Aff
・状態を扱う -> 状態を表すデータとセットになった値 Reader , Writer, State

**デフォルトの名無しさん** · 2019/10/21(月) 00:25:00.67

シンプルな考え方合成ルールといいつつ
肝心のルールの中身を説明しないで
利点や応用分野のみ紹介する
典型的な日本人話法

モナドは単なる自己関手の圏におけるモノイド対象だよ。何か問題でも？

**デフォルトの名無しさん** · 2019/10/21(月) 00:50:05.83

いやだから装飾のされ方は物によって様々だって言ってるじゃん
ルールの中身も当然装飾のされ方によって様々なんだから画一的に述べられないってわからないか？

一つ言えるのはbindとpureの定義を与えるってことくらいだが
あるいは同値な定義だが、関手であることを要請した上でjoinとreturnを与えるのでも構わない
数学者のモナドの定義を述べているお前ならこっちのほうが好みかもな

**デフォルトの名無しさん** · 2019/10/21(月) 11:02:55.47

「自己関手の圏」の中身を説明しないからわけがわからない
関手の合成は積？
恒等関手は単位対象だが終対象ではない？
うっかり始対象になったりしたらそれ積じゃなくて和じゃないか

**デフォルトの名無しさん** · 2019/10/21(月) 12:39:15.34

中身は数学で明示されてるのでは

**デフォルトの名無しさん** · 2019/10/21(月) 14:07:32.87

自己関手の圏におけるモノイド対象としてモナドを理解することは、必ずしもプログラミングのためになるものではないから必須ではない。

それでもそれを理解したいのであれば、プログラミングの文脈で理解するのではなくて、ちゃんと圏論の文脈で理解した方がいい。
Bartosz MilewskiのCategory theory for programmerがわかりやすくておすすめ。

**デフォルトの名無しさん** · 2019/10/21(月) 14:17:03.91

【僕用メモ】

・bind と pure の定義を与える
・関手であることを要請した上で join と return の定義を与える

両者は同値である。

**デフォルトの名無しさん** · 2019/10/21(月) 14:44:27.76

だめな理系人間の特徴
初学者に対してひたすらwhatを説明
だいたいコミュ障を併発してる

**デフォルトの名無しさん** · 2019/10/21(月) 14:53:31.64

この人のことか
http://masa-lab.hateblo.jp/entry/2019/02/01/110041

**デフォルトの名無しさん** · 2019/10/21(月) 15:19:59.07

>>593
そうでもなくね？っていうか内容がHaskellに関係なかったw

**デフォルトの名無しさん** · 2019/10/21(月) 15:38:45.76

お前らって圏論なにで勉強したの
英語の本読んだの？大学の授業とかで習ったの？

**デフォルトの名無しさん** · 2019/10/21(月) 15:49:09.35

数学の本買って独学

**デフォルトの名無しさん** · 2019/10/21(月) 16:22:57.20

知らん用語が出て来るから初学者で戸惑う人が多いだろうが
内容は小学生でも理解出来るレベル

**デフォルトの名無しさん** · 2019/10/21(月) 16:52:11.20

Basic Category Theory, Tom Leinster　
英語で読んだ

◆QZaw55cn4c · 2019/10/21(月) 22:01:25.88

>>598
翻訳でもない和書ってありませんかね…

**デフォルトの名無しさん** · 2019/10/22(火) 02:26:17.25

>>595
数学教室 πの焼き方と、プログラマーのための圏論。
ただ、読んだ後に意味を吟味して閃きが必要だった。

まず普通の関数とモナドな関数を同じと見做す考え。

IOモナドの入力は基本、文字列を受け取るので数文字列を受け取って、整数に変換後2倍する関数を作るとする。

getLine >>= \s -> return $ 2 * read s

これと同じ効果の普通の関数を作ってみる。

getLine’ s = 2 * read s

このgetLineとgetLine’をそれぞれ部分適用で見かけの変数を減らす形に変形。

getLine >>= return.(2*).read

getLine’ = (2*).read

この場合、2つの関数は型と引数からの入力か入力装置からの入力かしか違いがない。
関数の中身から見れば、いつ、どんな文字列が来るか分からない。同じ数文字列が来たら同じ結果を返すと言う意味では同じと見なせる。

**デフォルトの名無しさん** · 2019/10/22(火) 02:26:29.61

そして、圏論の主張は変数は引数無しの関数でも有ると言う事。
以下は関数である。

f x = 2 * x

しかし、部分適用されたカリー化関数は関数でもあり、変数でもある。

f = (2*) (関数でもあり、関数という値を返す変数でもある)

すなわち、x = 1のようなただの変数も、つねに1を返すxと言う引数の無い関数と見なせる。

x = 1 (1と言う値の入った変数であり、常に1を返す引数無しの関数でもある)

Haskellでは表現できないものの、さらに言えば数そのものも圏論では値であり、変数であり、関数である。
単純に書くと以下の通りだが、

1 = 1

ペアノの公理(ペアノ数)を使った方が概念的に分かりやすいかも知れない。

data Nat = Zero | Succ Nat

1 = Succ Zero

**デフォルトの名無しさん** · 2019/10/22(火) 03:15:18.03

ちぃOrdの使い方覚えた

https://ideone.com/LForVF

**デフォルトの名無しさん** · 2019/10/22(火) 07:00:59.60

>>590
youtubeにある彼のビデオレクチャーも良いよ

**デフォルトの名無しさん** · 2019/10/22(火) 11:37:49.35

モノイドのところがよくわからんかったけど読み物として面白かった
https://chrispenner.ca/posts/wc

**デフォルトの名無しさん** · 2019/10/22(火) 13:56:22.87

>>604
ちょっと待て
モノイドのところが一番の肝で面白い部分だろ

**デフォルトの名無しさん** · 2019/10/22(火) 21:21:34.69

>>601
>数そのものも圏論では値であり、変数であり、関数である。

もしその様な表現が可能な拡張がされた場合何が起きる出来るんですか？
数値に新規の型を設定して値で変数で関数みたいな扱い出来ないかな

**デフォルトの名無しさん** · 2019/10/22(火) 21:31:09.36

圏論うろおぼえだけどそれって圏論の範疇だっけ？
圏論ってマッピングする理論であってその対象が値か関数か変数か関知しないのでは？
値が関数ってのはラムダ計算から来るものでしょ
確かにそれらを組み合わせて計算理論になるわけだけど

**デフォルトの名無しさん** · 2019/10/23(水) 02:22:17.73

>>601
お前が圏論を全く理解していないことは良くわかった

圏論には「関数」とか「値」とか「変数」といった概念はない
「対象」と「射」との２つの概念があるだけだ

だからお前の次の

＞数そのものも圏論では値であり、変数であり、関数である

これは単なる間違いさえ通り越して全くのナンセンス
圏論には値も変数も関数も存在しないのだから

何を対象として何を射とするかは個々の具体的な圏によって異なる

**デフォルトの名無しさん** · 2019/10/23(水) 02:25:20.92

>>608
ああ、ちょっと簡単に書きすぎたね
確かに関手

**デフォルトの名無しさん** · 2019/10/23(水) 02:29:17.74

>>609は書いてる途中で間違って送信してしまった

>>608
ああ、ちょっと筆（じゃなくてキーボード）が滑って簡単に書きすぎたね
確かに関手とか自然変換といった概念も圏論にはあるが、これらもある圏から見れば射や対象に過ぎない

いずれにしても圏論には値や関数や変数といった概念はない

**デフォルトの名無しさん** · 2019/10/23(水) 03:34:04.69

では何らかの制限がないと取り扱いが難しいよね
例えば英語と日本語の翻訳で使われる意味を咀嚼変換するロジックを圏論だと言われたら
なんか凄く難しそうだなとか

**デフォルトの名無しさん** · 2019/10/23(水) 07:48:02.01

別に集合論だって写像の集合を考えればいいわけでそんなのは圏論を持ち出さなくても十分
重要なのは圏論は写像の合成(関数合成)を抽象化して扱う理論だということで
だからこそa -> IO bを射とする圏を作れればそこでの射の合成方法は普通の関数合成と同じように扱える
で実際にIOはクライスリトリプル(Monadのインスタンス)を定義できるからa -> IO bを射とするクライスリ圏が定義できる

**デフォルトの名無しさん** · 2019/10/23(水) 15:46:04.24

質問です。
当方数学科卒で学生時代圏論は死ぬほど使ってました。
しかしアーベル圏という純数学的なお話知ってるだけで、計算論に応用する話は全く勉強した事ない状態です。
そういう人間が圏論の計算論への応用を勉強したいときオススメの教科書、参考書は何かご存知ですか？
抽象圏論や数学基礎論も少しかじった事があるのでその手の話が出てきてもあまり困る事はないと思ってます。

**デフォルトの名無しさん** · 2019/10/23(水) 18:37:44.76

そこまで圏論に詳しいなら逆に世の中の有象無象の情報処理の実態を
見て新しい提案ができるんじゃないかと思うけどどう？

**デフォルトの名無しさん** · 2019/10/23(水) 18:48:53.05

型推論とモナドがわかったら解散でいいじゃん
だらだら続けるとサンクコストが増える

**デフォルトの名無しさん** · 2019/10/23(水) 20:01:33.78

浮動小数演算みたいなある種のモナド則が成り立たんものを考えると、
逆にモナド則のありがたさがわかる。
そんな程度で十分だよ。

**デフォルトの名無しさん** · 2019/10/23(水) 22:29:52.97

どちらかと言えば、モノイドの方が役に立つ

**デフォルトの名無しさん** · 2019/10/23(水) 22:51:28.42

浮動小数点のモナド？
モナド則の結合律っぽい奴は普通の関数で言うなら
f (g x) == (f . g y) x を要請してるのであって
f,gの計算には依存しないから浮動小数点が破壊することはないよ

**デフォルトの名無しさん** · 2019/10/23(水) 22:55:47.94

ミス f (g x) == (f . g) x だった

**デフォルトの名無しさん** · 2019/10/24(木) 01:14:02.96

f x = x / 0.3
g x = x * 0.3

**デフォルトの名無しさん** · 2019/10/24(木) 01:19:57.43

ghci でやってみたら循環小数にならなかった。macOSの電卓でも。
へぇ～。

**デフォルトの名無しさん** · 2019/10/24(木) 01:57:21.20

>>613
> そういう人間が圏論の計算論への応用を勉強したいときオススメの教科書、参考書は何かご存知ですか？
> 抽象圏論や数学基礎論も少しかじった事があるのでその手の話が出てきてもあまり困る事はないと思ってます。

理論計算機科学（以下、TCSと略）への圏論の応用を勉強したいのならば、最もベーシックなテキストとしては

1. Andrea Asperti & Giuseppe Longo: Categories, Types, and Structures, 306+xii pp., MIT Press (1991)
型理論として単純型付きλ計算と２階の型付きλ計算それぞれに対する圏論的意味論を議論している他、
型無しλ計算の意味論を展開する上で不可欠な再帰的領域方程式とその解に対する圏論的な見方も解説している。
更にHaskellなどで喧しいモナドやKreisel圏についても解説している。（関数プログラミング言語へのモナドの応用は
本書の著者の１人であるLongoの論文から全てが始まった）
この本の最大の欠点は誤植がとても多いことと昔のMacで書かれていてテキスト中の数式も図も美しくないことだ。
なお、現在は書籍としては品切れになっていたと思うが、著者のHPから電子的に無料で入手可能になっていたはずなのでネットで探して下さい。

2. Roy L. Crole: Categories for Types, 335+xvii pp., Cambridge University Press (1993)
様々な型理論（型理論は(関数)プログラミング言語とその型システムを形式的体系としたものと考えて良い）に対する圏論的意味論を議論している。

3. 横内寛文：プログラム意味論，261+vi pp.，共立出版 (1994)
久しく品切れになっていたが少し前に増刷されたので現在はジュンク堂などの大型書店などの店頭で買えるはず。
表示的意味論、型無し・型付きλ計算、領域理論、関数型言語の意味論について１つずつ章を設けて解説した後、この本で必要とする圏論の解説がされ、
プログラミング言語の表示的意味論で必須の再帰的領域方程式とその解法に対する圏論からのアプローチと
λ計算の意味論としてλモデル・λ代数・圏論的モデルとしてのCCC（デカルト閉圏あるいは積閉包圏）について解説している。

この他にもTCSへの圏論の応用としてはオートマトン理論への応用や代数的仕様記述言語の意味論への圏論の応用
（こちらの意味論ではデカルト閉圏は使われない）などがある。

**デフォルトの名無しさん** · 2019/10/24(木) 02:41:27.79

>>622訂正と補足

まず1に関する説明中の次の箇所を訂正します。つい筆が滑ってKleisliをKreiselと書いてしまった。

誤> 更にHaskellなどで喧しいモナドやKreisel圏についても解説している。（関数プログラミング言語へのモナドの応用は
正> 更にHaskellなどで喧しいモナドやKleisli圏についても解説している。（関数プログラミング言語へのモナドの応用は

それから、

> なお、現在は書籍としては品切れになっていたと思うが、著者のHPから電子的に無料で入手可能になっていたはずなのでネットで探して下さい。

と書いたが、無料の電子版は著者の一人であるLongoの次のURLよりPDFファイルの形で配布されている。

https://www.di.ens.fr/users/longo/files/CategTypesStructures/book.pdf

**デフォルトの名無しさん** · 2019/10/24(木) 09:09:56.34

>>618
浮動小数においては
(a+b)+c != a+(b+c)
なんだよ。

**デフォルトの名無しさん** · 2019/10/24(木) 19:35:38.99

>>624
だからこそ「モナド則の結合律のこと言ってるの？あれは関数合成的な話だから関係ないよ」
って言ってるんだけど
ああもしかして>>616は結合律一般について言ってるのか？
それならアスペみたいなこと言って悪かった
いやまさか四則演算の結合律の便利さから
printFile file = readFile file >>= putStrLn
printFile == readFile file >>= putStrLn
になることの利点を理解しろという主張だとは思わなかったからさ・・・

**デフォルトの名無しさん** · 2019/10/24(木) 19:42:56.62

いやモナド則で語ることなんて結合律以外ないだろ。。
結合律を無条件で仮定できる状況がどれほど負担を減らすかって話なんだが
ここまでバカな絡まれ方するとは思わなかった。

**デフォルトの名無しさん** · 2019/10/24(木) 19:50:34.49

ああ、printFile file == readFile file >>= putStrLn だった
しかもそれも誤解しか生まない表現で
要はreadFile file >>= putStrLnをprintFileで置き換えても問題ないってことを言いたかったんだけど
いやほんと5ch向いてないね

**デフォルトの名無しさん** · 2019/10/24(木) 20:08:28.59

>>627
なんか、あんたは気持ち悪いね

**デフォルトの名無しさん** · 2019/10/24(木) 20:16:05.76

>>626
いやほんと頭が悪くて申し訳ない
「足し算の結合律って便利でしょ？モナド則も結合律だから便利なんだよ」
こんな糞みたいな主張をする人間が世の中にいることぐらいは分かっておくべきだった

**デフォルトの名無しさん** · 2019/10/24(木) 20:22:28.52

単位元を語ってもええんやで

**デフォルトの名無しさん** · 2019/10/25(金) 04:29:07.52

>>629
前提として「足し算の結合律って便利だね」
じゃ足りないの
何が不足なのかな
副作用をモナドの結合連鎖外に及ぼさない事による恩恵が主目的じゃないの？
とくにマルチスレッドコア環境だと色々有難いよね
モナド連鎖の組み合わせとか組み替えとかがスカッとできてイイ！とか
連鎖の中で起きたエラーのリカバリーとかはよくわからん

**デフォルトの名無しさん** · 2019/10/25(金) 08:07:43.53

>>631
モナドが実際の所どれぐらい便利なのかは分からないけど
(m >>= f) >>= g == m >>= (\x -> f x >>= g)
が言ってることは単純なんだよ
>>=が普通の関数呼び出しのように使えるというだけ
$(普通の関数呼び出しを演算子化したもの)の場合を考えれば分かりやすいかな
g $ (f $ x) == (\y -> g $ (f $ y)) $ x
関数と値の引数が$と>>=では逆だから両辺が逆向きになってるけど
要するに二つの関数を一つの関数まとめても構わないという
誰もが当たり前にやってることの理論的基盤を>>=にも要請してるというだけなんだよ
だから getLine >>= printFile と getLine >>= readFile >>= putStrLn
が同じだと言うためにはこの結合律を満たさなきゃならない
ちなみに二個以上の関数をまとめ上げる場合や多引数の場合もこれで証明できる

**デフォルトの名無しさん** · 2019/10/25(金) 08:33:13.53

>>632
モナドの条件が成立すると色々便利な事は認識している
端緒の認識はそれで問題ないと思ったけど
便利だよねって見解が
>こんな糞みたいな主張をする人間が世の中にいることぐらいは分かっておくべきだった
って言われて、え？え？何かマズイ理解なり認識があるのか??
何がマズいのかワカラン??って感想
単純に罵倒してマウント取りたかっただけなら問題ない

**デフォルトの名無しさん** · 2019/10/25(金) 09:19:09.32

>>624見たとき何言ってんだコイツと思ったが案の定ボコされてて安心した
論理的な思考ができない人間って怖いわ

**デフォルトの名無しさん** · 2019/10/25(金) 11:27:36.73

>>624
>浮動小数においては
>(a+b)+c != a+(b+c)
>なんだよ。
まるめ誤差を考慮すればだけど
浮動小数点を引き合いにだして!=だってやった事か

**デフォルトの名無しさん** · 2019/10/25(金) 18:07:06.47

>>633
そこは売り言葉に買い言葉だったんじゃねーの。
俺は雑な主張はアリだと思うし、それに対する善意の解説もいいと思うぞ

**デフォルトの名無しさん** · 2019/10/25(金) 18:15:13.95

>>633
三段論法的なのが糞だって言ってるだけでその部分は別に間違ってないよ
まあマウンティングするつもりはないんだが
曖昧なこと言っといてそれについて意見したら「バカに絡まれた」なんて
そりゃ感情的にもなるよ確かに大人げないけどさ