トップページ⇒tech
1002コメント372KB

関数型プログラミング言語Haskell Part29 [転載禁止]©5ch.io

■ このスレッドは過去ログ倉庫に格納されています
0001岡部メモリリーク健2015/07/14(火) 19:27:09.01ID:jJ1YDtNe
関数型プログラミング言語 Haskell について語るスレです。

　　　　　　　　　,.-―:￣｀ー::::::::::､
　　　　　　　／::::::::::::.::::::::::::::::::::::::::::｀::､､
　　　　　　/::::::::::::::::::::::::::::::::::::::::::::::::::::::｀､
　　　　　 ｌ::::::::::::::::::::::::::::::::::::::::;':l:::::::::::＼::l
　　　 　 l:::::::::::::::::::::::::::::::::,,::::::::;-,:,::::::::::::::::l
　　　　 l::::::::::::::::,＿,.::::,';::::::;:::::: :: l ::::::::::::::l
　　　 　l::::::::::／-/:::/-ニ,.::::／=,.／::::::::::l
　　　　 ヽ::::　´､ひ> ;: 　l .<ひ>'　 ､::::::::/
　　　　ヽ:::::　　 ￣ .)::;　 l　￣　　　ｌ::::/ 　　　＜　毛の壁（岡部健）の話は禁止な
　　　　　､:::::..　　 /:::;　.,-､　　　　 l:::/、
　　　　,―::::::::　　ゝヽ- ｰ' ､　　　 l::/,､ヽ
　　 　 l,､,､,,:､::　/ ,--､,-.､_ l　 　 /::::::,､,､l
　　　ｌ,､,､,､,､,､::､　｀ー￣-'　　　/:::::::::::,､,､l
　　　ｌ,､,､,､,､,､,､::ヽ　　　　　 ／::::::::､,､,､,､,ﾉ:＼

haskell.org (公式サイト)
http://www.haskell.org/

前スレ
関数型プログラミング言語Haskell Part28
http://peace.2ch.net/test/read.cgi/tech/1428535861/
0052デフォルトの名無しさん2015/07/19(日) 10:57:36.17ID:XE+dCI5P
取り敢えず初心者にモナドってなんなの？って訊かれたら、オレオレDSLのフレームワークって言っときゃ良いんでしょ？
0053デフォルトの名無しさん2015/07/19(日) 13:47:54.47ID:I4MCl2HA
モノイド大将がボス
0054デフォルトの名無しさん2015/07/19(日) 15:46:09.62ID:I1Wicbx/
>>52 その説明いつも全然意味不明
0055デフォルトの名無しさん2015/07/19(日) 16:48:46.04ID:OqblcV5w
>>51
まず最初に、モナドと全く関係のない言語が、副作用を無節操に広く適用した
そうして無節操に広がったIOの適用範囲の一部をIOではなくMaybe等で書き直している
Maybeが広くなった分だけIOが狭くなるのでモナド全体の広さは変わらない
0056デフォルトの名無しさん2015/07/19(日) 17:14:36.93ID:kvcDaKH1
>>48
QtでもさすがにHello出力だけで1MB超えは無い。
0057デフォルトの名無しさん2015/07/19(日) 18:26:20.48ID:ZQ+VxBJa
>>55
> まず最初に、・・・副作用を無節操に広く適用した
> IOの適用範囲の一部をIOではなくMaybe等で書き直している
> Maybeが広くなった分だけIOが狭くなる
上の3行の一つ一つが意味分からん。
もう少し補足してくれんか
0058デフォルトの名無しさん2015/07/19(日) 19:00:07.54ID:OqblcV5w
>>57
分からんなら後回しにして比較的分かりやすいところを先に解決すればいいと思う
分からんところに拘るのは効率が悪い
0059デフォルトの名無しさん2015/07/19(日) 19:13:47.34ID:ZQ+VxBJa
>>58
例えば教科書に出てくるなにかの概念が分からんというようなことじゃなて、
あなたが>>55に書いている文が、あれじゃ意味不明と言ってるんだが。
副作用を無節操に広く適用ってどういうこと？
そしてIOとMaybeしか出てこんがモナドはこの二つだけじゃないし
0060デフォルトの名無しさん2015/07/19(日) 19:32:23.42ID:OqblcV5w
>>59
対案を出せばいいと思う
0061デフォルトの名無しさん2015/07/19(日) 21:26:06.98ID:BgJ/88od
>>51 のような疑問は、Applicative と Monad のパワーの違いとは？ということであり、
それについてはすごいHaskell に平易な解説があったと思う。

要するに>>= があるおかげで、 モナドから取り出した値を見て、次に行う副作用を作れるってことだ。
0062デフォルトの名無しさん2015/07/19(日) 23:30:44.39ID:ZQ+VxBJa
>>60
対案出せと言われましても意味分からんからできません、なんよｗ　わからへん？

>>61
> 要するに>>= があるおかげで、 モナドから取り出した値を見て、次に行う副作用を作れる
それって、 (>>=) :: m a -> (a -> m b) -> m b　　言うてるだけやし
0063デフォルトの名無しさん2015/07/19(日) 23:34:09.77ID:bed99W+w
実際monadとapplicativeどっちも使える状況なら
applicative使ったほうがいいよって言われてね？
0064デフォルトの名無しさん2015/07/20(月) 00:20:18.66ID:0TG+/+/W
和書のどれかに載ってた床下配線が一言だと一番分かりやすいと思った
0065デフォルトの名無しさん2015/07/20(月) 00:27:41.08ID:wg3sT89+
>>61
取り出すところまでは同じだが、取り出した後でできることが違う
m a -> (a -> b) -> m b
m a -> (a -> m b) -> m b
-- 超えられない壁 --
m a -> (a -> b) -> b
0066デフォルトの名無しさん2015/07/20(月) 02:08:57.73ID:u/oPh9jr
つか正直>>51が何言ってるかわからん

>>63
mapでできることをfoldや再帰でやらないってのと同じ発想だね
0067デフォルトの名無しさん2015/07/20(月) 09:29:20.00ID:c+ACSEXZ
>>64
箱やコンテナもそうだがそういう物理的比喩は所詮本物じゃない

>>65
超えられないのか？
0068デフォルトの名無しさん2015/07/20(月) 09:57:42.74ID:wg3sT89+
>>67
IOが超えられない
モナドクラスというのはIOと同じクラスになりたいやつが集まってるから
0069デフォルトの名無しさん2015/07/20(月) 21:32:15.43ID:tLpP/4eq
data DataType = DataI [Int] | DataF [Float] | DataD [Double]
deriving (Eq, Show)
という型があるとします。
型構成子で包まれているリストを取得するにはどうしたらよいでしょうか？
getData :: DataType -> a
getData (DataI a) =a
getData (DataF a) =a
getData (DataD a) =a
getData _ = error "no"
とやってもうまく取り出せません。。
0070デフォルトの名無しさん2015/07/20(月) 21:52:25.58ID:WnNA5LDR
そりゃ型あわないんだから出来ないよそんなこと
0071デフォルトの名無しさん2015/07/20(月) 22:03:47.04ID:l2CykBu3
クソアマ死ね


まさかとは思うが kenokabe先生(a.k.a qiitapost, chimetorch) は React.js を使いさえすればプログラムが FRP になると考えているのだろうか。
https://twitter.com/bolero_MURAKAMI/status/623057115456733184
0072692015/07/20(月) 22:10:25.52ID:tLpP/4eq
>>70
関数のオーバーロードみたいの使ってできるようにないませんかね？？
0073デフォルトの名無しさん2015/07/20(月) 22:56:29.03ID:XuKvM2I+
モナドは型クラス。ある代数データ型に、
それに対応するfmap, ap, bind が揃っているだけ。

だが、その代数データ型の値をデータコンストラクタで出来上がった
構文木と見ると、代数データ型がBNFみたいに見えてくるはずだ。
そのBNFが表現する言語に、まさにfmap, ap, bindが制御構造を
もたらすものとして理解できる。

これが「モナドがDSLフレームワーク」ということの意味。
0074デフォルトの名無しさん2015/07/20(月) 23:06:18.94ID:XuKvM2I+
>>69
>getData :: DataType -> a

なんでこの型付けがおかしいかわかれば
getDataが作れないことの諦めがつくよ。
0075デフォルトの名無しさん2015/07/20(月) 23:52:10.07ID:WnNA5LDR
>>72
Haskellに関数のオーバーロードはない
型クラスを変に絡めればあるにはあるけど

どういう状況を想定してその関数がほしいと思ったのかを教えてもらえれば、アドバイスできるかもしれない
基本的にHaskellではそういう関数を必要とすることはないはず
0076デフォルトの名無しさん2015/07/21(火) 00:28:11.79ID:2lFdT9I+
>>69
class IorForD a where {getData :: DataType -> [a]}
instance IorForD Int where {getData (DataI xs) = xs; getData _ = error "no"}
instance IorForD Float where {getData (DataF xs) = xs; getData _ = error "no"}
instance IorForD Double where {getData (DataD xs) = xs; getData _ = error "no"}
0077デフォルトの名無しさん2015/07/21(火) 00:39:13.17ID:xbZldfZG
>>76
確かに記述上できる事になるけど
意味ないなあー
0078デフォルトの名無しさん2015/07/21(火) 01:37:31.91ID:XB/uoEzx
むしろ

Num a => DataType a
getData :: DataType a -> [a]

みたいにしたらいけない理由が見当たらない。
0079デフォルトの名無しさん2015/07/21(火) 01:57:25.58ID:iDhKY9Vq
>>69
欲しいのは (Num a) => [a] のような型か
fromIntegralとかrealToFracのような
具体型をジェネリックな数に変換する関数だったりしないだろうか
0080デフォルトの名無しさん2015/07/21(火) 13:15:45.21ID:Dco/MENI
モナドは一度使えば最後までついて回るしがらみ
0081デフォルトの名無しさん2015/07/21(火) 13:21:44.03ID:/2Z49al6
なんだかんだ言っても、モナドって、結局、低級言語のデザインパターンなんだな
一言で言えばそういうことだった
0082デフォルトの名無しさん2015/07/21(火) 13:22:20.40ID:B0LBt+ac
岡部健がQiitaで発狂続けてて大草原
0083デフォルトの名無しさん2015/07/21(火) 13:32:51.80ID:aaCdXzrq
http://yomogi.2ch.net/test/read.cgi/net/1437302243/
GitHub/Qiita/StackOverflowの臭い奴を観察1
0084デフォルトの名無しさん2015/07/21(火) 19:49:21.60ID:LwXUVlfX
https://gist.github.com/anonymous/10622bea0d37cdd0f59f
0085デフォルトの名無しさん2015/07/21(火) 22:58:37.09ID:eRnXfzMM
毛の壁の記事を探索するbotコンテストでも開催しろ
0086デフォルトの名無しさん2015/07/23(木) 08:07:45.47ID:Hd8z6Qav
>>82
Qiita荒らしにしか見えない。
0087デフォルトの名無しさん2015/07/23(木) 09:38:20.27ID:UOPnVIxG
Monadでは
>>= :: ma -> (a -> mb) -> mb
となっているですが、これは、どうして
>>= :: ma -> (ma -> mb) -> mb（つまり普通のapply）
ではだめなのでしょうか？
0088デフォルトの名無しさん2015/07/23(木) 10:23:45.67ID:9NQb4Eqn
>>87

X -> m Y というタイプの関数をたくさん繋げたいという気持ちがあるわけ。mがモナドだとするとき
m でラップされた型、たとえば m Int だとか m () だとかを「mという文脈を付与された型」だと思う
ことにします。m としては IO や Maybe を考えれば考えやすい。

f :: X -> m Y
g :: Y -> m Z

みたいなのがあったとき、ｆの結果の文脈を引き継いでｇを計算したいわけ。たとえば m が
Maybeならば、ｆの結果は Nothing かもしれないわけ。IOだったら、実行時環境からIOで
ラップされた値を受け取ってるかもしれない。そういうのを受けて g を計算したいわけ。

このとき、>>= があるおかげで

(f x) >>= g

というのが計算できるわけ。「ｆのあとにｇ」というのを素朴に、思いついたままにやろうとすると

g ( f x) -- 型が合ってないので illegal

だけど、これは m 一個分型がずれてるからダメ。>>= は、一個分の m を吸収して
適用してくれる。だから、「モナドでラップされた値を取り出して適用してくれる」
みたいな言われ方をするけど、まあ、結果としてそう見えるようなうまい定義が
されてる。（例えばモナド則なんかがそんなうまい定義の背景にあって、そういうのを
どうやって思いついたか説明しようとすると圏論の話しになる。しらんでいい。）
0089デフォルトの名無しさん2015/07/23(木) 10:30:27.22ID:9NQb4Eqn
>>87

ついで。　IO () みたいに、「中身がない」というか、文脈を持ってるという以外に
意味がないモナド値ってのもある。もっと広く言うと状態系のモナドね。

そういう場合、

f :: X -> m ()
g :: Y -> m ()
h :: Z -> m ()

みたいなのを「つなげたい」場合がある。これは入り口が違うので (>>=) は使えない。
だもんで、(>>) なんてのがある。
0090デフォルトの名無しさん2015/07/23(木) 10:46:01.13ID:UOPnVIxG
>>88
>>= :: ma -> (a -> mb) -> mb
を用意する代わりに、
extract :: ma -> a
みたいなのがあれば、普通の関数適用だけでも同じことができるのではないのですか？
0091デフォルトの名無しさん2015/07/23(木) 11:47:48.09ID:9NQb4Eqn
>>90
「そういうのが作れるならば」あなたのおっしゃるとおり。

具体的に考えてみましょう。 m が Maybe の場合、　extract Nothing は何になりますか
0092デフォルトの名無しさん2015/07/23(木) 11:59:35.34ID:9NQb4Eqn
>>90
よくいろいろなところで、(>>=) は「モナドから値を取り出して関数に適用する」
と言われたりするけど、unit と join を基礎にしてモナドを作ると、このトリックは
理解しやすい。

参考：　ttps://ja.wikibooks.org/wiki/Haskell/%E5%9C%8F%E8%AB%96

要するにMがモナドだとして

unit :: a -> M a

join :: M (M a) -> M a

があったとき

(>>=) :: M a -> (a -> M b) -> M b
x' >>= f = join ( (fmap f) x' )

となって、実際には fmap f を適用して、ダブった M を一枚剥がして M b の値を返してる。
（つまりモナドの中から値を引っ張りだす、というような事は実際にはやってないわけ）。

実際にはモナドのなかから値を引っ張りだしてないにも関わらず、引っ張りだして
適用したと「プログラマの心の中で」みなしていても整合してるように書けてしまう。

そういううまいルールをどうやって設定するかみたいな話をするために圏論を借りてきてる。
正直、圏論だとかいってもこのレベルの話ならグラフ理論と難しさは変わらん。
（表示的意味論でも圏論を使うけど、そっちは数学がよほど好きでないと厳しい）。
0093デフォルトの名無しさん2015/07/23(木) 13:06:35.41ID:UOPnVIxG
>>91
> extract Nothing は何になりますか
なるひどこれは困った。。。

>>92
たしかに、fmap と join を基礎にすれば、 >>=　はその一手ですね

>>= :: ma -> (a -> mb) -> mb　の中では、特に、
a -> mb　の部分がモナドにとって本質的なんだなと思えてきました
0094デフォルトの名無しさん2015/07/23(木) 13:35:05.00ID:UOPnVIxG
>>92
> そういううまいルールをどうやって設定するかみたいな話をするために圏論を借りてきてる。
「そういううまいルール」とは、どこの事でしょうか？
0095デフォルトの名無しさん2015/07/23(木) 13:41:38.62ID:UOPnVIxG
>>92
extract :: ma -> a
は存在しない場合があるようですが、
いつも存在しないのですか？
また、join :: m(ma) -> ma
は必ず存在するのですか？
0096デフォルトの名無しさん2015/07/23(木) 14:03:17.98ID:9NQb4Eqn
>>94
そういう上手いルール、はモナド則です。（Functor則と合わせて機能する）。

>>95
たとえば identity モナドなら extract は存在します。大事なのは「一般には、モナド M
に対して extract :: M a -> a が定義できない」ということ。 extract の存在を仮定してると
モナドの一般論にはならないわけです。

join :: M(M a) -> M a

の存在は、モナドの構成要件の一つだと言って差し支えないと思います。
Mがモナドであるかぎり必ず存在する。

参考：ttp://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Monad.html#v:join

（さっき挙げたWikibooksのページには、unit + join でやる流儀と unit + bind
でやる流儀の両方が解説されてます。論理的にはどっちで考えても良い。）
0097デフォルトの名無しさん2015/07/23(木) 18:38:39.92ID:KEVSaEFA
日本語でおすすめの入門サイトってありますか？
0098デフォルトの名無しさん2015/07/23(木) 21:02:13.38ID:hAeb0KoI
Haskellの型システムは入門用ではない
静的型と動的型の高度な煽り合いの成果物だ
0099デフォルトの名無しさん2015/07/23(木) 21:31:05.23ID:UOPnVIxG
>>96 ：デフォルトの名無しさん：2015/07/23(木) 14:03:17.98 ID:9NQb4Eqn
> そういう上手いルール、はモナド則です。
うまいというより、ふつうに定義すればモナド則は満たされるのではないですか？

> join :: M(M a) -> M a
> の存在は、モナドの構成要件の一つだと言って差し支えないと思います。
joinがそうであるのにextractがそうでないのはなぜでしょうか？
まあ、oinは不可欠だが、extractはなくても代わりがあるからだということなのでしょうが
0100デフォルトの名無しさん2015/07/23(木) 21:46:55.16ID:9NQb4Eqn
>>99
たとえば　http://d.hatena.ne.jp/itto100pen/20090710　に、モナド則の一部が満たされない例があります。
「普通に定義すれば」モナド則は満たされるというのは、経験的には確かにそういう場面が多いかもしれませんが、
状況が込み入ってくれば、いつか「普通にモナドっぽいものを作ったつもり」なのにモナド則を満たさないものに
遭遇するかもしれません。

>joinがそうであるのにextractがそうでないのはなぜでしょうか？
モナドというものがそういうものだからとしか言いようがないですね。

>>93 であなたは
>a -> mb　の部分がモナドにとって本質的なんだなと思えてきました

と書いていましたが、この X -> m Y 型の射をつなげてどうにかするための仕組みが
備わっているものをモナドと呼ぶわけです。うまくこのタイプの射をつなげるためには、
ダブったmをうまく剥がしてくれるものが必要で、それが join なわけです。

さっき挙げたWikibooksのページに、join を使って bind を作ったり、bind を使って join を作る
話が載ってますので、参考になさってください。

一方、あなたが書いてる extract :: M a -> a に相当する仕組みを考える場面は
一応あります。それは、 m X -> Y 型の射をうまくつなげてどうにかしたい場合です。
それは「コモナド」と呼ばれてます。（これを積極的に考える場面もあるらしいのですが
私の勉強が追いついていないのでコモナドについてこれ以上語れることはありません。）
0101デフォルトの名無しさん2015/07/23(木) 21:58:48.06ID:GSXYPmA+
>>100
空でないデータ構造に対して、その中のある（現在注目している）要素を特に指し示す
ある種のポインターを持った構造として使う、というのがよく知られた例ではないかと。

ストリームをチューリングマシンのテープに見立てた時のヘッドの現在位置とか。
0102デフォルトの名無しさん2015/07/23(木) 22:28:56.93ID:ul3W6A8M
extract を要求しなくてもいろんなことができる、という程度におれは考えてるなぁ
0103デフォルトの名無しさん2015/07/23(木) 23:19:05.16ID:UOPnVIxG
> たとえば　http://d.hatena.ne.jp/itto100pen/20090710　に、モナド則の一部が満たされない例があります。
ページ紹介ありがとうござます。
そこの return x = [x x] は、（私の思うｗ）「ふつうの」定義ではないので、
それがモナド則を満たさないのも尤もかなと思いました
0104デフォルトの名無しさん2015/07/23(木) 23:32:47.82ID:GSXYPmA+
>>103
逆に言えば、あなたが直観的に思う「ふつう」を保証してくれるのがモナド則なのですわ。
0105デフォルトの名無しさん2015/07/23(木) 23:45:33.49ID:UOPnVIxG
>>104
モナド則というのがそういうものだという説明ははじめて聞きました。本当ですか？
0106デフォルトの名無しさん2015/07/24(金) 00:04:12.32ID:E+4NqHJH
まあ要はそれらは「自然」な振る舞いをするようにできているのです。
0107デフォルトの名無しさん2015/07/24(金) 06:20:03.70ID:SOLi30hJ
そんな希望的観測は法則を知らなくてもできるから法則の意味がない
法則はもっと不吉な意味を持つべきなんだよ

「不自然にならないよう自然を保証してくれるので復旧シナリオは考えていない」
まさかこのパターンの意味がわからない難聴系主人公はいないよね
0108デフォルトの名無しさん2015/07/24(金) 08:17:51.80ID:ZflfUkEE
>>107
> 「不自然にならないよう自然を保証してくれるので復旧シナリオは考えていない」
> まさかこのパターンの意味がわからない難聴系主人公はいないよね
ここよくわからない。少し説明を加えてくれませんか
0109デフォルトの名無しさん2015/07/24(金) 08:31:24.73ID:sUR4TL+C
モナド則を満たさないモナドインスタンスは使用者が大いに困るだろう
上の　return x = [x x]
とか
0110デフォルトの名無しさん2015/07/24(金) 09:47:25.11ID:+b/Jkmb9
明らかにモナド則を満たさないモナドインスタンスの例はよく出てくるけど、
「ふつうの」FunctorやApplicative Functorであって
Monadでないものの具体例ってあるのかな
0111デフォルトの名無しさん2015/07/24(金) 10:31:52.55ID:qo8KZeeD
>>110
ZipList
理由はこれ http://www.mail-archive.com/[email protected]/msg57217.html
0112デフォルトの名無しさん2015/07/24(金) 12:24:32.99ID:mRGyPSzK
>>109
確かにロボットが困った顔してるように見える
0113デフォルトの名無しさん2015/07/24(金) 16:30:09.13ID:sUR4TL+C
>>110
間違ってるかもしらんけど
関数はFunctorやApplicative Functorだけどmonadではなかったような
0114デフォルトの名無しさん2015/07/24(金) 18:21:56.53ID:ZflfUkEE
>>113
関数は恒等モナドなのでしょう？
0115デフォルトの名無しさん2015/07/24(金) 20:30:46.83ID:ZflfUkEE
とにかくモナド則ってモナドの本質とは全然関係ないですよね。
そのネーミングがよくないなｗ
0116デフォルトの名無しさん2015/07/24(金) 22:02:00.45ID:UUB1Rdtf
>>115
モナドの本質とは、Kleisli射が「合成できる」ことであって、モナド則は
そのような合成が well-defined であることを保証しているという意味では本質と
関係している。
0117デフォルトの名無しさん2015/07/24(金) 22:15:15.51ID:E+4NqHJH
>>113
(->)型はモナド。
Readerモナドの正体は関数モナドそのもの。
0118デフォルトの名無しさん2015/07/24(金) 22:26:30.02ID:XFwmWe1A
モナド則は情報量保存則のようなものだと思ってもよい
(>>=)やreturnでwrapするだけで元の情報が失われるような実装は禁止
後に続く関数に元の情報を全て渡す

つまりわざと情報を捨てればモナド則を満たさない例を作れる
return x = ("", x)
(_, x) >>= f = f x

("warning", x) >>= return = ("", x)
0119デフォルトの名無しさん2015/07/24(金) 22:29:22.04ID:+b/Jkmb9
>>111
なるほどZipListか
まだちゃんと読めてないんだけど、
> (可算無限も含めて)長さが固定のベクトルだったらその定義で上手く行くんだけどね、
> でも一般のリストに対する上手い定義ももしかしたらあるかもね
って感じの結論か
return (= pure) が無限リストを返すから
確かにモナド則を満たすのは容易ではなさそう

>>115
Haskellでは型さえ合っていればコンパイルできてしまうだけで
モナドがモナド則を満たすのはむしろ定義だと思う
0120デフォルトの名無しさん2015/07/24(金) 22:52:20.29ID:jOlzxqLq
まあMonadLikeクラスでも作ってモナド則無しでやってみろよ
辛くなったら帰って来い
0121デフォルトの名無しさん2015/07/24(金) 23:04:31.56ID:ZflfUkEE
>>116
> モナド則は...合成が well-defined であることを保証している
>>118
> モナド則は情報量保存則のようなものだと思ってもよい
>>119
> モナドがモナド則を満たすのはむしろ定義だと思う

えっ？　モナド則って単位元の存在と結合則ですから、モナドに限らないおよそ代数演算に
課される最低限の規則に過ぎないでしょう？
0122デフォルトの名無しさん2015/07/24(金) 23:18:40.52ID:UUB1Rdtf
>>121
その最低限の規則だって明示的に指定して置かなければ混乱するでしょ。
あなたにとって最低限のことは隣の誰かにとっては最低限の常識ではない。
0123デフォルトの名無しさん2015/07/24(金) 23:40:04.07ID:XFwmWe1A
結合法則 (x + y) + z = x + (y + z)
交換法則 (+ z) . (x +) = (x +) . (+ z)
これらは数学的に同じ意味だから
結合法則は最低限だとか、交換法則は最低限じゃないとかいうのは
数学じゃなくて言葉遊びだよね
0124デフォルトの名無しさん2015/07/25(土) 07:47:47.08ID:6zkZTkly
結合法則を満たせば半群
群は交換法則を満たさなくてもよい，満たすものを特に可換群とよぶ

十分に数学的だ
0125デフォルトの名無しさん2015/07/25(土) 07:57:27.29ID:Jr3WK49j
非可換群なんかいくらでもあるのにね。
0126デフォルトの名無しさん2015/07/25(土) 08:09:08.78ID:Jr3WK49j
Z上でのある演算(+)の結合法則から構成される構造を
別の台集合(+z)(x+)と合成（.）で構成される構造に等価だといったところで
もとの演算(+)の可換性について何も言ったことにはならないというだけのことよね
01271212015/07/25(土) 08:44:38.00ID:Bvjhkxqq
>>122 >>123
強調点は「最低限」のところではなく「およそ（ふつうの）代数演算に共通」
というところにありました
01281212015/07/25(土) 08:46:08.24ID:Bvjhkxqq
だから、モナドの特質を表すものじゃないと
0129デフォルトの名無しさん2015/07/25(土) 08:55:06.98ID:gZG0Y+YD
>>126
嘘を言ったのではなく何も言ってないのか
チャレンジよりゼロリスクを選んだ人間がどのような評価を受けるかという意味で面白い
0130デフォルトの名無しさん2015/07/25(土) 09:14:59.38ID:bPfkCbEC
数学の話はいいからHaskellの話を
0131デフォルトの名無しさん2015/07/25(土) 09:34:33.91ID:Bvjhkxqq
trace :: ((B, D) -> (C, D)) -> B -> C
trace f b = let (c, d) = f(b, d) in c

としたとき、このtraceってwell-defined？
0132デフォルトの名無しさん2015/07/26(日) 10:00:37.02ID:dkr9+eHq
型に特質があるから値の特質（モナド則？）はなくても良くね？
「選択と集中」とかいう言葉を信じるなら値に特質を持つことは寧ろ禁止した方が良い
0133デフォルトの名無しさん2015/07/26(日) 11:46:33.95ID:rsm1cXgs
HackageDBである特定のパッケージに依存しているパッケージの一覧を得る
検索方法はないでしょうか。

たとえば、yesod が必要なパッケージの一覧など。
0134デフォルトの名無しさん2015/07/26(日) 14:06:20.87ID:ihM0rggd
>>132
その「選択と集中」というカルト宗教流行ってるの？　根拠もなんもないくせに
耳あたりだけいい言葉に騙されてない？

選択と集中でおもいっきり原子炉にぶっこんだ東芝はどうなった？　
0135デフォルトの名無しさん2015/07/26(日) 20:37:01.68ID:vJ1KGCO5
さすがにそこで原発でてくんのは謎
0136デフォルトの名無しさん2015/07/26(日) 20:44:23.44ID:vJ1KGCO5
マジレスするとモナド則を満たしてないモナドインスタンスはバグだ
利用者が困る
0137デフォルトの名無しさん2015/07/26(日) 20:52:18.39ID:dkr9+eHq
色々な機能を全部まとめて売りつけようとする奴がいるから
欲しくないものまで買わされて損する場合がある
それよりは欲しいものだけを集中的に買って損する方がマシ
0138デフォルトの名無しさん2015/07/26(日) 21:02:49.59ID:vJ1KGCO5
モナド則満たしてないモナドインスタンスなんて欲しくないもの買わされたって状態だよ
0139デフォルトの名無しさん2015/07/26(日) 21:02:55.04ID:PdaEJy2y
モナド則を満たしていることをコンパイル時に証明する機構がHaskellに望まれる
0140デフォルトの名無しさん2015/07/26(日) 23:01:02.42ID:ooP+OwHf
完全な保証は無理でもQuickCheckあたりでなんとかならんかな
0141デフォルトの名無しさん2015/07/27(月) 03:43:19.54ID:+mQx9Q9E
選択と集中というのは、経済学の用語で比較優位の話だ。

なんでこんな所で選択と集中の話が出てくるの？
0142デフォルトの名無しさん2015/07/27(月) 06:11:57.70ID:3edBlaSG
よくわからないけどモジュールは疎結合が正義って話しかな？
0143デフォルトの名無しさん2015/07/27(月) 11:31:50.70ID:pQHi2myk
exportは天国、importは地獄
特に、間接的なimportを強制されたら最悪
0144デフォルトの名無しさん2015/07/27(月) 22:21:38.16ID:+pmDbRz6
>>137
ジャック・ウェルチが言ってる「選択と集中」とは何の関係もないな
0145デフォルトの名無しさん2015/07/28(火) 05:08:55.87ID:XoUEQPXj
なるほど
ジョブズのようなものがいるんだ
0146デフォルトの名無しさん2015/07/28(火) 11:57:02.42ID:RBpFIWq5
プログラマも経営センスを求められるというお話？
0147デフォルトの名無しさん2015/07/28(火) 13:39:01.53ID:d4M8qnVV
>>132
ジャック・ウェルチの「選択と集中」でもってあなたが何を言わんとしてるか
さっぱりわからないし、「型に特質がある」という言い方も意味不明。
モナド則は値の特質ではなくモナドでラップされた型がどのように振る舞うか
を決めてるのであって、このルールがあるからこそ do 記法を
安心して使える。とにかく地道に勉強しよう。
0148coolio2015/07/28(火) 16:34:52.05ID:n3cGSoaV
Haskellってオワコンなんでは？
なんでJavaScript使わないのみなさん？
普及率も需要もこっちの方が上だし、国際的潮流かとおもうけど
0149デフォルトの名無しさん2015/07/28(火) 17:47:57.77ID:d4M8qnVV
>>148
じゃあまずお前が国際的潮流に合わせて英語か中国語で書き込めよ
0150デフォルトの名無しさん2015/07/28(火) 17:50:36.54ID:Ni9zj/4A
Javascriptやってればいいじゃん
人のことはどーだってよくね？
0151デフォルトの名無しさん2015/07/28(火) 21:05:55.89ID:ROVV0dd8
まるで何でスタバ行かないのって聞かれたような気分
■ このスレッドは過去ログ倉庫に格納されています