TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
Visual Studio 2017 Part7
知ってるとプログラミングに役立つ数学知識
C++相談室 part144
くだすれPython(超初心者用) その37
javaとpythonってどっちが初学に向いてる？
Java入門・初心者質問スレ Part.8
VRプログラム雑談【Unity/UnrealEngine】【HTC Vive/Oculus Rift/その他VR】
推薦図書/必読書のためのスレッド 82
Visual Studio 2008 Part 22
[RPA]PC自動化技術総合スレ[効率化] Part.6

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


1 ：2015/07/14 〜 最終レス ：
関数型プログラミング言語 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.sc/test/read.cgi/tech/1428535861/

2 ：
関連サイト
(英語)
Haskell - Wikibooks, open books for an open world (ページ内に内容をまとめたPDFあり)
http://en.wikibooks.org/wiki/Haskell

Learn You a Haskell for Great Good! (『すごいHaskellたのしく学ぼう!』の無料オンライン版)
http://learnyouahaskell.com/chapters

Real World Haskell (同名書籍の無料オンライン版)
http://book.realworldhaskell.org/read/

(以下、日本語)
Haskell入門 5ステップ - HaskellWiki (公式サイト内、日本語入門セクション)
https://wiki.haskell.org/Haskell%E5%85%A5%E9%96%80_5%E3%82%B9%E3%83%86%E3%83%83%E3%83%97

Haskell - Wikibooks (先述Wikibooksの日本語版。未編集の項目、多)
http://ja.wikibooks.org/wiki/Haskell

Programming in Haskell
http://www.sampou.org/cgi-bin/haskell.cgi

Haskell のお勉強
http://www.shido.info/hs/

Haskell Programming
http://www.geocities.jp/m_hiroi/func/haskell.html

本物のプログラマはHaskellを使う:ITpro
http://itpro.nikkeibp.co.jp/article/COLUMN/20060915/248215/

［入門］関数プログラミング―質の高いコードをすばやく直感的に書ける！
http://gihyo.jp/dev/feature/01/functional-prog

3 ：
過去スレ一覧
27) http://peace.2ch.sc/test/read.cgi/tech/1420718555/
26) http://peace.2ch.sc/test/read.cgi/tech/1406436392/
25) http://peace.2ch.sc/test/read.cgi/tech/1393313450/
24) http://toro.2ch.sc/test/read.cgi/tech/1382705669/
23) http://toro.2ch.sc/test/read.cgi/tech/1376111807/
22) http://toro.2ch.sc/test/read.cgi/tech/1364009659/
21) http://toro.2ch.sc/test/read.cgi/tech/1358702176/

4 ：
20) http://toro.2ch.sc/test/read.cgi/tech/1350428908/
19) http://toro.2ch.sc/test/read.cgi/tech/1340760070/
18) http://toro.2ch.sc/test/read.cgi/tech/1331902463/
17) http://toro.2ch.sc/test/read.cgi/tech/1325510368/
16) http://toro.2ch.sc/test/read.cgi/tech/1317958045/
15) http://hibari.2ch.sc/test/read.cgi/tech/1310199414/
14) http://hibari.2ch.sc/test/read.cgi/tech/1299385928/
13) http://hibari.2ch.sc/test/read.cgi/tech/1286706874/
12) http://hibari.2ch.sc/test/read.cgi/tech/1272536128/
11) http://pc12.2ch.sc/test/read.cgi/tech/1252382593/
10) http://pc12.2ch.sc/test/read.cgi/tech/1231861873/
09) http://pc11.2ch.sc/test/read.cgi/tech/1211010089/
08) http://pc11.2ch.sc/test/read.cgi/tech/1193743693/
07) http://pc11.2ch.sc/test/read.cgi/tech/1174211797/
06) http://pc11.2ch.sc/test/read.cgi/tech/1162902266/
05) http://pc8.2ch.sc/test/read.cgi/tech/1149263630/
04) http://pc8.2ch.sc/test/read.cgi/tech/1140717775/
03) http://pc8.2ch.sc/test/read.cgi/tech/1076418993/
02) http://pc2.2ch.sc/test/read.cgi/tech/1013846140/
01) http://pc.2ch.sc/tech/kako/996/996131288.html

5 ：
匿名掲示板に
「児童ポルノ単純所持で捕まったら無罪だったとしても社会的に終わるぞ」
という脅し文句を連呼してる人がいる

確か日本IBM会長が痴漢で捕まった時に騒いでたの２chの一部だけで
本当に痴漢で捕まったと思ってる人がほとんどいなかった記憶あるのだが

6 ：
AIZU ONLINE JUDGE　競技プログラミング
http://judge.u-aizu.ac.jp/onlinejudge/index.jsp

Haskellで書けるようになった

7 ：
>>6
うおおお！！朗報だありがとう！！！

8 ：
このスレが本スレだな。例のＡＡが無いと盛り上がらん。

9 ：
>>6
うおおお！やったぜ。

10 ：
命令型でないとrangeもmapも書けないのは海外では常識。
そのことは海外のサイト見れば明らか。権威のある人物ならみんな知ってる

11 ：
>>10
それはわからんのよ。
バイオコンピュータによって可能になるかもしれんしな。

ただ、今目の前にあるのはバイオコンピュータではないってことが大事なんだろうな。

バイオコンピュータが目の前に来てからHaskellを使おうと考えるのが普通の人だわな。
まあその時には、Haskellは無くなってるだろけどな。

12 ：
http://web.archive.org/web/20150715011113/http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b

13 ：
関数型言語におけるmapの定義：

https://www.haskell.org/tutorial/functions.html
A Gentle Introduction to Haskell（やさしいHaskell入門）

"The well-known map function"（よく知られたmap関数）

map :: (a->b) -> [a] -> [b]
map f [] = []
map f (x:xs) = f x : map f xs

基本中の基本です。

14 ：
UCLA卒業と、岡部健（kenokabe・毛の壁）を語ろう [転載禁止]©2ch.sc
http://hello.2ch.sc/test/read.cgi/joke/1436928203/

15 ：
>>14
もう許してやれよ

16 ：
岡部健がQiitaのコメント欄に出没してるぞ〜（歓喜）

http://qiita.com/nonstarter/items/2763f5d85f2b8df3b18b#comment-7d7a978d53ad17b911c5

今度の名前はqiitapostの模様

17 ：
とうとう荒らしに墜ちたか

18 ：
教育者の端くれなのに、やることが小さいね

19 ：
>>1にこんな品のないAAを貼り付けるのはよくない
こんなスレ、僕は認めないからな

20 ：
　　　　　　　　　,.-―:￣｀ー::::::::::､
　　　　　　　／::::::::::::.::::::::::::::::::::::::::::｀::､､
　　　　　　/::::::::::::::::::::::::::::::::::::::::::::::::::::::｀､
　　　　　 ｌ::::::::::::::::::::::::::::::::::::::::;':l:::::::::::＼::l
　　　 　 l:::::::::::::::::::::::::::::::::,,::::::::;-,:,::::::::::::::::l
　　　　 l::::::::::::::::,＿,.::::,';::::::;:::::: :: l ::::::::::::::l
　　　 　l::::::::::／-/:::/-ニ,.::::／=,.／::::::::::l
　　　　 ヽ::::　´､ひ> ;: 　l .<ひ>'　 ､::::::::/
　　　　ヽ:::::　　 ￣ .)::;　 l　￣　　　ｌ::::/ 　　　
　　　　　､:::::..　　 /:::;　.,-､　　　　 l:::/、
　　　　,―::::::::　　ゝヽ- ｰ' ､　　　 l::/,､ヽ
　　 　 l,､,､,,:､::　/ ,--､,-.､_ l　 　 /::::::,､,､l
　　　ｌ,､,､,､,､,､::､　｀ー￣-'　　　/:::::::::::,､,､l
　　　ｌ,､,､,､,､,､,､::ヽ　　　　　 ／::::::::､,､,､,､,ﾉ:＼

こんにちは。
私は現在、関数型プログラミングを勉強している者で、まさにこちらのスレで批評されている書籍を読んで、思考を切り替えるためのコツを分かり易く学べたと考えている者です。
様々な視点から学び、理解を深めたいと考えており、こちらのスレも目を通し、関心を持って注目しております。

21 ：
mapは命令型でしか書けない。

22 ：
おい、Codepadのようなものを「エミュレーター」と解釈できる、なんらかの要素があるとしたらどのあたりなんだ？

23 ：
モナドって一言で言うとなんなん？

24 ：
世界線

25 ：
>>23
class Monad m where
(>>=) :: m a -> (a -> m b) -> m b
return :: a -> m a

っていう関数が定義されていてモナド則を満たすもの

26 ：
>>25
なるほど
やっぱり岡部健の間違いか。

27 ：
foldでmapは書けるが、岡部健はその事と間違えてたんだろうな

28 ：
>>25
一言で言うとなんなん？言うてるやん
それともほんとは分かってないから言えないとか？

29 ：
なんやこら調子乗んなしばくど

30 ：
>>28
「一言」って、どれくらいの長さまで認めてくれるの？

31 ：
>>28
自己関手の圏におけるモノイド対象

32 ：
>>23,28
順次、反復、分岐のうち分岐を可能にする構造[1]
という説明であれば一般的なプログラマは理解できるはず

[1] http://d.hatena.ne.jp/kazu-yamamoto/20150128/1422413182

33 ：
一言で一言でって、一言で言えたら定義がそもそもそうなってるわ！
一言でいっちゃうと必ず嘘を含むので言葉尻をとらえる重箱の隅をつつく言葉遊び勢を気にしておいそれと一言で言えないんだよ
だから一言で言って欲しいなら、『厳密でなく細かな間違いを含んだ私見でいいので、大雑把で直感的に言い直すとどんな風にとらえておけば当たらずとも遠からずですか？』って訊けよな

34 ：
>>32
その説明、ずっと分からなかったんだけど、反復を実現するのはApplicativeなの？
単に関数を再帰的に定義すればいいんじゃないの？

35 ：
>>31　じゃなくて
>>32
そうそうこういうのがいいんだが、
モナドって、命令型でふつうにできてることを関数型の中でもやりたいってことでＯＫ？
そうすると、IOはいいけどMaybeやListが置いてけぼりになるんじゃないの？

36 ：
Maybe/Eitherならエラー時の処理、リストならリスト内包表記におけるフィルター処理が分岐にあたる
他のモナドだと直感的に「分岐」とはみなせないような例もあるかもしれないけど
そのモナドなりの意味で分岐を解釈できるはず

Functorを箱とみなすか文脈とみなすかみたいな話と同じで
一言で言おうとしたときに具体例を選べばどうしたって他で無理のある解釈が出てくるわけで
そこを突っ込みたかったら結局「定義にもどれ」ということになる

37 ：
>>36
ああそう、やっぱり>>32はあくまで初心者向けの通俗的解釈に過ぎないわけね。
また振り出しにもどったわｗ
> そこを突っ込みたかったら結局「定義にもどれ」ということになる
突っ込みたいわけじゃないんだが。。。
「定義にもどれ」ってのは、一見もっともに聞こえるがダメダメよｗ
「なんでそんな定義なの？」というのが大事なわけで。
それに定義というなら、『Monad は、単なる型クラスの一つで、それ以上でも
それ以下でもありません』でほんとおしまいなんだし

38 ：
皆様方
以降、スルーでよろしくおながいします

39 ：
モナド変換子が絡むと一気にむずかしくなるなぁ
StateTとIOの複合は頻出っぽいから頑張って身につけたい
なにか参考になるサンプルとかないでしょうか

40 ：
https://gist.github.com/anonymous/1944f34703bcb63131d8


これはどちらが正しいんだ？

41 ：
最初に無があった
無は有を生んだ
これが全ての真理

42 ：
>>40
ちゃんと見て無いけど、
どっちもどっちな感じ…

43 ：
＞・他方、worldcomponentライブラリを用いてunmount処理を書こうにも、ライブラリ自体が対応していないので、
＞状態を完全にリセットしてしまうか、ライブラリの実装の内部に立ち入らない限り、書けません。
＞（これはworldcomponentが、unmountされたコンポーネントに対してもforceUpdateを呼び出してしまうせいなので、
＞通常のライブラリであれば、そのような問題はありません。なお、基本的再確認ですが、
>Facebook Reactの公式マニュアル https://facebook.github.io/react/docs/component-api.html には "Normally you should try to avoid all uses of forceUpdate()"
＞すなわち「通常はforceUpdate()のいかなる使用も避けるべきである」とあります。）

どう考えてもkenokabeのコードが悪いと思うが。

44 ：
>>37
うんじゃぁ　これも通俗的な話だけど
(>>=) :: m a -> (a -> m b) -> m b
って関数が凄い便利なんだよ scalaだとflatMapなんていったりするけど
monadの力って (>>=) って関数が定義されてる mっていうデータ構造(文脈だの箱だの言われるが)
これをhaskellは副作用を扱うのに使ってるけど
副作用を普通に扱える言語でもmaybeやfutureみたいにエラー時の処理や非同期計算に便利なんだ
もちろん上は全然正確な話ではない

45 ：
>>43
これに関してはメモリリークの件でコード改竄を指摘されて
「お前らだってコード改竄してるじゃないか！」
って言いたいんだろうなぁと思う。

事実関係よりも心の平安を保てるかどうかで発言してるっぽいし。

46 ：
main = do
print "Hello"

これをghc hello.hsすると生成された実行ファイルのサイズが1MB超えるんですが
こんなものですか？
もっと大量のコードが書けるほどのレベルではないんですが、500行ぐらい書いたらサイズが1GB言っちゃうんじゃないかと心配になりました

47 ：
ランタイムの分がでかいからな、なんで線形に増加すると思ったのか

48 ：
qtライブラリを使えば、１ｍｂぐらい気にならなくなるじゃろ。

49 ：
>>46
jhcを使うとランタイムがないぶんそれだけ小さくなるというのを
岡部究(master_q)さんが一時期熱心に調べてたな。

50 ：
>>44 はかなり良い説明だと感じた。
一面を捉えた正確な説明だと思いますよ。

51 ：
>>44
> (>>=) :: m a -> (a -> m b) -> m b
うん、これは、たしかに
(a -> b) -> (m a -> mb)
m(a -> b) -> (ma -> mb)
に比べるとやや崩れているところな。そこが人間にとっていいってことか？
だが、IOからMaybeや非決定性まであまりに無節操に広く適用されるところが、
かえって、実はナンセンスなんじゃないの？と思ってしまうな

52 ：
取り敢えず初心者にモナドってなんなの？って訊かれたら、オレオレDSLのフレームワークって言っときゃ良いんでしょ？

53 ：
モノイド大将がボス

54 ：
>>52 その説明いつも全然意味不明

55 ：
>>51
まず最初に、モナドと全く関係のない言語が、副作用を無節操に広く適用した
そうして無節操に広がったIOの適用範囲の一部をIOではなくMaybe等で書き直している
Maybeが広くなった分だけIOが狭くなるのでモナド全体の広さは変わらない

56 ：
>>48
QtでもさすがにHello出力だけで1MB超えは無い。

57 ：
>>55
> まず最初に、・・・副作用を無節操に広く適用した
> IOの適用範囲の一部をIOではなくMaybe等で書き直している
> Maybeが広くなった分だけIOが狭くなる
上の3行の一つ一つが意味分からん。
もう少し補足してくれんか

58 ：
>>57
分からんなら後回しにして比較的分かりやすいところを先に解決すればいいと思う
分からんところに拘るのは効率が悪い

59 ：
>>58
例えば教科書に出てくるなにかの概念が分からんというようなことじゃなて、
あなたが>>55に書いている文が、あれじゃ意味不明と言ってるんだが。
副作用を無節操に広く適用ってどういうこと？
そしてIOとMaybeしか出てこんがモナドはこの二つだけじゃないし

60 ：
>>59
対案を出せばいいと思う

61 ：
>>51 のような疑問は、Applicative と Monad のパワーの違いとは？ということであり、
それについてはすごいHaskell に平易な解説があったと思う。

要するに>>= があるおかげで、 モナドから取り出した値を見て、次に行う副作用を作れるってことだ。

62 ：
>>60
対案出せと言われましても意味分からんからできません、なんよｗ　わからへん？

>>61
> 要するに>>= があるおかげで、 モナドから取り出した値を見て、次に行う副作用を作れる
それって、 (>>=) :: m a -> (a -> m b) -> m b　　言うてるだけやし

63 ：
実際monadとapplicativeどっちも使える状況なら
applicative使ったほうがいいよって言われてね？

64 ：
和書のどれかに載ってた床下配線が一言だと一番分かりやすいと思った

65 ：
>>61
取り出すところまでは同じだが、取り出した後でできることが違う
m a -> (a -> b) -> m b
m a -> (a -> m b) -> m b
-- 超えられない壁 --
m a -> (a -> b) -> b

66 ：
つか正直>>51が何言ってるかわからん

>>63
mapでできることをfoldや再帰でやらないってのと同じ発想だね

67 ：
>>64
箱やコンテナもそうだがそういう物理的比喩は所詮本物じゃない

>>65
超えられないのか？

68 ：
>>67
IOが超えられない
モナドクラスというのはIOと同じクラスになりたいやつが集まってるから

69 ：
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"
とやってもうまく取り出せません。。

70 ：
そりゃ型あわないんだから出来ないよそんなこと

71 ：
クソアマR


まさかとは思うが kenokabe先生(a.k.a qiitapost, chimetorch) は React.js を使いさえすればプログラムが FRP になると考えているのだろうか。
https://twitter.com/bolero_MURAKAMI/status/623057115456733184

72 ：
>>70
関数のオーバーロードみたいの使ってできるようにないませんかね？？

73 ：
モナドは型クラス。ある代数データ型に、
それに対応するfmap, ap, bind が揃っているだけ。

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

これが「モナドがDSLフレームワーク」ということの意味。

74 ：
>>69
>getData :: DataType -> a

なんでこの型付けがおかしいかわかれば
getDataが作れないことの諦めがつくよ。

75 ：
>>72
Haskellに関数のオーバーロードはない
型クラスを変に絡めればあるにはあるけど

どういう状況を想定してその関数がほしいと思ったのかを教えてもらえれば、アドバイスできるかもしれない
基本的にHaskellではそういう関数を必要とすることはないはず

76 ：
>>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"}

77 ：
>>76
確かに記述上できる事になるけど
意味ないなあー

78 ：
むしろ

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

みたいにしたらいけない理由が見当たらない。

79 ：
>>69
欲しいのは (Num a) => [a] のような型か
fromIntegralとかrealToFracのような
具体型をジェネリックな数に変換する関数だったりしないだろうか

80 ：
モナドは一度使えば最後までついて回るしがらみ

81 ：
なんだかんだ言っても、モナドって、結局、低級言語のデザインパターンなんだな
一言で言えばそういうことだった

82 ：
岡部健がQiitaで発狂続けてて大草原

83 ：
http://yomogi.2ch.sc/test/read.cgi/net/1437302243/
GitHub/Qiita/StackOverflowの臭い奴を観察1

84 ：
https://gist.github.com/anonymous/10622bea0d37cdd0f59f

85 ：
毛の壁の記事を探索するbotコンテストでも開催しろ

86 ：
>>82
Qiita荒らしにしか見えない。

87 ：
Monadでは
>>= :: ma -> (a -> mb) -> mb
となっているですが、これは、どうして
>>= :: ma -> (ma -> mb) -> mb（つまり普通のapply）
ではだめなのでしょうか？

88 ：
>>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 を吸収して
適用してくれる。だから、「モナドでラップされた値を取り出して適用してくれる」
みたいな言われ方をするけど、まあ、結果としてそう見えるようなうまい定義が
されてる。（例えばモナド則なんかがそんなうまい定義の背景にあって、そういうのを
どうやって思いついたか説明しようとすると圏論の話しになる。しらんでいい。）

89 ：
>>87

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

そういう場合、

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

みたいなのを「つなげたい」場合がある。これは入り口が違うので (>>=) は使えない。
だもんで、(>>) なんてのがある。

90 ：
>>88
>>= :: ma -> (a -> mb) -> mb
を用意する代わりに、
extract :: ma -> a
みたいなのがあれば、普通の関数適用だけでも同じことができるのではないのですか？

91 ：
>>90
「そういうのが作れるならば」あなたのおっしゃるとおり。

具体的に考えてみましょう。 m が Maybe の場合、　extract Nothing は何になりますか

92 ：
>>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 の値を返してる。
（つまりモナドの中から値を引っ張りだす、というような事は実際にはやってないわけ）。

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

そういううまいルールをどうやって設定するかみたいな話をするために圏論を借りてきてる。
正直、圏論だとかいってもこのレベルの話ならグラフ理論と難しさは変わらん。
（表示的意味論でも圏論を使うけど、そっちは数学がよほど好きでないと厳しい）。

93 ：
>>91
> extract Nothing は何になりますか
なるひどこれは困った。。。

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

>>= :: ma -> (a -> mb) -> mb　の中では、特に、
a -> mb　の部分がモナドにとって本質的なんだなと思えてきました

94 ：
>>92
> そういううまいルールをどうやって設定するかみたいな話をするために圏論を借りてきてる。
「そういううまいルール」とは、どこの事でしょうか？

95 ：
>>92
extract :: ma -> a
は存在しない場合があるようですが、
いつも存在しないのですか？
また、join :: m(ma) -> ma
は必ず存在するのですか？

96 ：
>>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
でやる流儀の両方が解説されてます。論理的にはどっちで考えても良い。）

97 ：
日本語でおすすめの入門サイトってありますか？

98 ：
Haskellの型システムは入門用ではない
静的型と動的型の高度な煽り合いの成果物だ

99 ：
>>96 ：デフォルトの名無しさん：2015/07/23(木) 14:03:17.98 ID:9NQb4Eqn
> そういう上手いルール、はモナド則です。
うまいというより、ふつうに定義すればモナド則は満たされるのではないですか？

> join :: M(M a) -> M a
> の存在は、モナドの構成要件の一つだと言って差し支えないと思います。
joinがそうであるのにextractがそうでないのはなぜでしょうか？
まあ、oinは不可欠だが、extractはなくても代わりがあるからだということなのでしょうが

100 ：
>>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 型の射をうまくつなげてどうにかしたい場合です。
それは「コモナド」と呼ばれてます。（これを積極的に考える場面もあるらしいのですが
私の勉強が追いついていないのでコモナドについてこれ以上語れることはありません。）

101 ：
>>100
空でないデータ構造に対して、その中のある（現在注目している）要素を特に指し示す
ある種のポインターを持った構造として使う、というのがよく知られた例ではないかと。

ストリームをチューリングマシンのテープに見立てた時のヘッドの現在位置とか。

102 ：
extract を要求しなくてもいろんなことができる、という程度におれは考えてるなぁ

103 ：
> たとえば　http://d.hatena.ne.jp/itto100pen/20090710　に、モナド則の一部が満たされない例があります。
ページ紹介ありがとうござます。
そこの return x = [x x] は、（私の思うｗ）「ふつうの」定義ではないので、
それがモナド則を満たさないのも尤もかなと思いました

104 ：
>>103
逆に言えば、あなたが直観的に思う「ふつう」を保証してくれるのがモナド則なのですわ。

105 ：
>>104
モナド則というのがそういうものだという説明ははじめて聞きました。本当ですか？

106 ：
まあ要はそれらは「自然」な振る舞いをするようにできているのです。

107 ：
そんな希望的観測は法則を知らなくてもできるから法則の意味がない
法則はもっと不吉な意味を持つべきなんだよ

「不自然にならないよう自然を保証してくれるので復旧シナリオは考えていない」
まさかこのパターンの意味がわからない難聴系主人公はいないよね

108 ：
>>107
> 「不自然にならないよう自然を保証してくれるので復旧シナリオは考えていない」
> まさかこのパターンの意味がわからない難聴系主人公はいないよね
ここよくわからない。少し説明を加えてくれませんか

109 ：
モナド則を満たさないモナドインスタンスは使用者が大いに困るだろう
上の　return x = [x x]
とか

110 ：
明らかにモナド則を満たさないモナドインスタンスの例はよく出てくるけど、
「ふつうの」FunctorやApplicative Functorであって
Monadでないものの具体例ってあるのかな

111 ：
>>110
ZipList
理由はこれ http://www.mail-archive.com/haskell-cafe@haskell.org/msg57217.html

112 ：
>>109
確かにロボットが困った顔してるように見える

113 ：
>>110
間違ってるかもしらんけど
関数はFunctorやApplicative Functorだけどmonadではなかったような

114 ：
>>113
関数は恒等モナドなのでしょう？

115 ：
とにかくモナド則ってモナドの本質とは全然関係ないですよね。
そのネーミングがよくないなｗ

116 ：
>>115
モナドの本質とは、Kleisli射が「合成できる」ことであって、モナド則は
そのような合成が well-defined であることを保証しているという意味では本質と
関係している。

117 ：
>>113
(->)型はモナド。
Readerモナドの正体は関数モナドそのもの。

118 ：
モナド則は情報量保存則のようなものだと思ってもよい
(>>=)やreturnでwrapするだけで元の情報が失われるような実装は禁止
後に続く関数に元の情報を全て渡す

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

("warning", x) >>= return = ("", x)

119 ：
>>111
なるほどZipListか
まだちゃんと読めてないんだけど、
> (可算無限も含めて)長さが固定のベクトルだったらその定義で上手く行くんだけどね、
> でも一般のリストに対する上手い定義ももしかしたらあるかもね
って感じの結論か
return (= pure) が無限リストを返すから
確かにモナド則を満たすのは容易ではなさそう

>>115
Haskellでは型さえ合っていればコンパイルできてしまうだけで
モナドがモナド則を満たすのはむしろ定義だと思う

120 ：
まあMonadLikeクラスでも作ってモナド則無しでやってみろよ
辛くなったら帰って来い

121 ：
>>116
> モナド則は...合成が well-defined であることを保証している
>>118
> モナド則は情報量保存則のようなものだと思ってもよい
>>119
> モナドがモナド則を満たすのはむしろ定義だと思う

えっ？　モナド則って単位元の存在と結合則ですから、モナドに限らないおよそ代数演算に
課される最低限の規則に過ぎないでしょう？

122 ：
>>121
その最低限の規則だって明示的に指定して置かなければ混乱するでしょ。
あなたにとって最低限のことは隣の誰かにとっては最低限の常識ではない。

123 ：
結合法則 (x + y) + z = x + (y + z)
交換法則 (+ z) . (x +) = (x +) . (+ z)
これらは数学的に同じ意味だから
結合法則は最低限だとか、交換法則は最低限じゃないとかいうのは
数学じゃなくて言葉遊びだよね

124 ：
結合法則を満たせば半群
群は交換法則を満たさなくてもよい，満たすものを特に可換群とよぶ

十分に数学的だ

125 ：
非可換群なんかいくらでもあるのにね。

126 ：
Z上でのある演算(+)の結合法則から構成される構造を
別の台集合(+z)(x+)と合成（.）で構成される構造に等価だといったところで
もとの演算(+)の可換性について何も言ったことにはならないというだけのことよね

127 ：
>>122 >>123
強調点は「最低限」のところではなく「およそ（ふつうの）代数演算に共通」
というところにありました

128 ：
だから、モナドの特質を表すものじゃないと

129 ：
>>126
嘘を言ったのではなく何も言ってないのか
チャレンジよりゼロリスクを選んだ人間がどのような評価を受けるかという意味で面白い

130 ：
数学の話はいいからHaskellの話を

131 ：
trace :: ((B, D) -> (C, D)) -> B -> C
trace f b = let (c, d) = f(b, d) in c

としたとき、このtraceってwell-defined？

132 ：
型に特質があるから値の特質（モナド則？）はなくても良くね？
「選択と集中」とかいう言葉を信じるなら値に特質を持つことは寧ろ禁止した方が良い

133 ：
HackageDBである特定のパッケージに依存しているパッケージの一覧を得る
検索方法はないでしょうか。

たとえば、yesod が必要なパッケージの一覧など。

134 ：
>>132
その「選択と集中」というカルト宗教流行ってるの？　根拠もなんもないくせに
耳あたりだけいい言葉に騙されてない？

選択と集中でおもいっきり原子炉にぶっこんだ東芝はどうなった？　

135 ：
さすがにそこで原発でてくんのは謎

136 ：
マジレスするとモナド則を満たしてないモナドインスタンスはバグだ
利用者が困る

137 ：
色々な機能を全部まとめて売りつけようとする奴がいるから
欲しくないものまで買わされて損する場合がある
それよりは欲しいものだけを集中的に買って損する方がマシ

138 ：
モナド則満たしてないモナドインスタンスなんて欲しくないもの買わされたって状態だよ

139 ：
モナド則を満たしていることをコンパイル時に証明する機構がHaskellに望まれる

140 ：
完全な保証は無理でもQuickCheckあたりでなんとかならんかな

141 ：
選択と集中というのは、経済学の用語で比較優位の話だ。

なんでこんな所で選択と集中の話が出てくるの？

142 ：
よくわからないけどモジュールは疎結合が正義って話しかな？

143 ：
exportは天国、importは地獄
特に、間接的なimportを強制されたら最悪

144 ：
>>137
ジャック・ウェルチが言ってる「選択と集中」とは何の関係もないな

145 ：
なるほど
ジョブズのようなものがいるんだ

146 ：
プログラマも経営センスを求められるというお話？

147 ：
>>132
ジャック・ウェルチの「選択と集中」でもってあなたが何を言わんとしてるか
さっぱりわからないし、「型に特質がある」という言い方も意味不明。
モナド則は値の特質ではなくモナドでラップされた型がどのように振る舞うか
を決めてるのであって、このルールがあるからこそ do 記法を
安心して使える。とにかく地道に勉強しよう。

148 ：
Haskellってオワコンなんでは？
なんでJavaScript使わないのみなさん？
普及率も需要もこっちの方が上だし、国際的潮流かとおもうけど

149 ：
>>148
じゃあまずお前が国際的潮流に合わせて英語か中国語で書き込めよ

150 ：
Javascriptやってればいいじゃん
人のことはどーだってよくね？

151 ：
まるで何でスタバ行かないのって聞かれたような気分

152 ：
>>149
哦，可以用國語嗎？你看得到呢？

153 ：
>>152
日本語でOK

154 ：
我想喝啤酒！

155 ：
Haskellは無料で遊べちまうけど需要のあるJSは徹底的に課金するべき

156 ：
ビールといえば、資源ごみ捨てないと…

157 ：
ghcの新型出るんですか？

158 ：
毛の壁また来てるの？
さっさと2chから消えろ

159 ：
無理だよ、毛は10年前からナンパ書き込みしたりしてるから

160 ：
いつどこに誰が来たのかさっぱりわからないし意味不明。

161 ：
ヤングアニマル No.15
アンダーメンバー全員集合 16ページ お祭り騒ぎ

ベルセルク連載開始 + 別冊付録 直近4話分


皆、短パン・ランニングシャツ姿
堀・らりんのお股
ひめたんの胸

162 ：
そういや原発の長文書き込む荒らしがなりを潜めたと思ったら、入れ替わるように毛の壁ブームが起こったな

163 ：
1人しか敵視しない1bit脳が基本だから
客観的に1人いようが2人いようが主観的には1人しか視えない

164 ：
モナドの合成って難しいことなの？

165 ：
>>162
原発長文君は効率的な情報収集という意味では有用であった復活を拒絶しない

166 ：
きーたぽすととかいうけのかべが抹消されたようだ

167 ：
cabal-installでドキュメントも一緒にインストールする際のhtmlのリンクの質問です。

パッケージをインストールするとドキュメントも一緒にインストールされるように設定しましたが、
ドキュメントのルートのindex.html（.cabal/config ファイルの dic-index-file の項）が更新されるとき、
インストールしたパッケージが公開しているモジュールへのリンクが間違った場所を指しています。

.cabal/config ファイルのインストールディレクトリ関係の項はデフォルトで下記のようになっています（一部だけ抜粋）。

doc-index-file: $datadir/doc/$arch-$os-$compiler/index.html

install-dirs user
　prefix: /home/ユーザー名/.cabal
　datadir: $prefix/share
　docdir: $datadir/doc/$abi/$pkgid
　htmldir: $dicdir/html
　haddockdir: $htmldir

例えば今 hacolour-1.23 パッケージをインストールすると、ドキュメントは
/home/ユーザー名/.cabal/share/doc/x86_64-linux-ghc-7.10.1/hscolour-1.23/html/
以下にインストールされます。

しかし、doc-index-file の index.html ページの例えば Language.Haskell.HsColour のリンクは
/home/ユーザー名/.cabal/share/doc/x86_64-linux-ghc-7.10.1/Language-Haskell-HsColour.html
を指すように更新されてしまいます。
当然、そんな所に Language-Haskell-HsColour.html ファイルはありません。

この間違ったリンクを正しく
/home/ユーザー名/.cabal/share/doc/x86_64-linux-ghc-7.10.1/hscolour-1.23/html/Language-Haskell-HsColour.html
を指すように設定するには
.cabal/config ファイルのどこを直せば良いのでしょうか。

168 ：
>>167
>doc-index-file: $datadir/doc/$arch-$os-$compiler/index.html

普通に

doc-index-file: $datadir/doc/$arch-$os-$compiler/$pkgid/index.html

じゃいかんの？

169 ：
あ、 ....../$pkgid/html/index.html かな。パスの途中に "html" 入れ忘れた。

170 ：
ごめん見当違いだったわ。
総インデックスファイルは確かにそこになきゃダメだ。

171 ：
>>164
モナドは自己関手なんで、関手を合成することができるが、
そうしてできた合成関手は一般にはモナドにならない。

172 ：
>>171
合成関手はモナドになり得ると思うが。。。
モナドの合成は一般にはモナドにならないということね？
なぜそうなのか、まだよく分かってないのだが、
そもそも合成できないっていうのはモナドが圏的でないということね？
それって結構困ったことなのでは？

173 ：
>> 167
見当違いかもしれないけど、俺の手元の~/.cabal/configは
htmldir: $docdir/html
になってた。貴方のは
htmldir: $dicdir/html

174 ：
>>173
すいません、ただの書き間違えです。
私の方でも正しくは

htmldir: $docdir/html

です。

175 ：
>>172
モナドFとGについて、合成関手FGに対して適切なηとμを、
「一般には」構成できない。FとGがよほど相性が良い場合は別だけど。

176 ：
　　　　　　　　　,.-―:￣｀ー::::::::::､
　　　　　　　／::::::::::::.::::::::::::::::::::::::::::｀::､､
　　　　　　/::::::::::::::::::::::::::::::::::::::::::::::::::::::｀､
　　　　　 ｌ::::::::::::::::::::::::::::::::::::::::;':l:::::::::::＼::l
　　　 　 l:::::::::::::::::::::::::::::::::,,::::::::;-,:,::::::::::::::::l
　　　　 l::::::::::::::::,＿,.::::,';::::::;:::::: :: l ::::::::::::::l
　　　 　l::::::::::／-/:::/-ニ,.::::／=,.／::::::::::l
　　　　 ヽ::::　´､ひ> ;: 　l .<ひ>'　 ､::::::::/
　　　　ヽ:::::　　 ￣ .)::;　 l　￣　　　ｌ::::/ 　　　＜　排便ダン　きんもちい〜
　　　　　､:::::..　　 /:::;　.,-､　　　　 l:::/、
　　　　,―::::::::　　ゝヽ- ｰ' ､　　　 l::/,､ヽ
　　 　 l,､,､,,:､::　/ ,--､,-.､_ l　 　 /::::::,､,､l
　　　ｌ,､,､,､,､,､::､　｀ー￣-'　　　/:::::::::::,､,､l
　　　ｌ,､,､,､,､,､,､::ヽ　　　　　 ／::::::::､,､,､,､,ﾉ:＼
　　　 　 /⌒＼〆',　 ｀ ￣ ´　　ゝ/⌒＼
　　　　/　　ﾉつ＼　・　　　　・　 /⊂　　ヽ!
o0○ノ　 /　 3　　＼　(::::⌒ヽ　/　とノ＼　ヽ○0o
(　　　　/､＿ﾉ＼　　　Y　｀(_､_)　　　/　　＼´　　)ﾟ
　＼＿)　　　 ｀ヽ　　　: :;;*:;　　　: : : |　　　　(＿ノ
　　　　　　　　　人＿＿;；:；;､＿＿_ノ　　　　　　　　　　ヽヽ 　　　　　　　ヽヽ
　　　　　　　　　　　　　;:;；:;；:；,,　　　　　　　　　　　──┐　|　　| 　　──┐　|　　|
　　　　　　　　　　∬　;;:;::.;::.::;::..:;:..:　∬　　　　　　　　　　/ 　|　　| 　　　　　/. 　|　　|
　　　　　　・〜　　　;::;.:;:;:;:;:.:;:.:::.;:;:;.:.:.:　　　　　　　　　　ノ　　　　ノ　　┐　ノ　　　　ノ　　┐
　　　　　　　　　　∬;;;:::;;;:;:.:;:.::.:;;.:.;.:;.:; ∬　　　　　　　　　　　　　　 　 ┴ 　　 ヽヽ　　 　 ┴
　　　　　　　　　　　　　 :"

177 ：
もし敵の武器をコピーする能力があったら
意味不明すぎてコピーできない武器を使えばいい

178 ：
>>175
了解。
モナドが合成できないということは、代数的議論としてはそうだと言ってればいいんだろうが、
プログラミングとしては、致命的なのではないの？

179 ：
>>178
代数的な議論とか言ったって簡単に情報系の議論に移せるよ。

Fという文脈に、さらにGという文脈をつけたものは、先にG、それをFでかぶせたものとは
同一視できない。

もう少し具体的に言えば、Maybeと状態モナドStateを考えたとき、Maybe State s a と State s Maybe a
を何も制約つけずに同一視できるほうがプログラミングとしては致命的だよ。

180 ：
すいませんハスケル初級者で質問なのですが
ハスケルでは「=」は代入ではなく束縛だという事で

関数定義
func :: Int -> Int
func x = func (x - 1)　
それを使った式
func 100

と書いた場合無限に減算を繰り返す理由は
「=」は代入ではなく束縛だから
ハスケルがfunc xに該当する唯一の値を求めて処理を繰り返すという
仕組みになっているという理解でよろしいでしょうか。

181 ：
代入とか束縛とか関係ない

int func(int x) {
. return func(x-1);
}

int x = func(100);

Cでこう書いたって無限再帰

182 ：
>>179
可換でないといけないとは言っていない。
合成ができないのが致命的と言ったのだが

183 ：
素数と素数の積が素数でないのは致命的じゃないが
モナドとモナドの合成がモナドでないのは致命的か？

184 ：
>>180 それは
x = x - 1
とかの場合の話じゃない？

185 ：
>>182
なぜ致命的なのかさっぱりわからない

186 ：
>>183 >>185
> 素数と素数の積が素数でないのは致命的じゃないが
それは素数の本質からの帰結だが、モナドの場合はそうではない。
もし整数と整数の積が整数にならないとすると、それは整数概念にとってかなり致命的。
群とまでいわなくても圏すらなさない概念はふつう使い物にならない

187 ：
>>178
>モナドが合成できないということは、代数的議論としてはそうだと言ってればいいんだろうが、
>プログラミングとしては、致命的なのではないの？

そりゃモナドでプログラミングしたことなきゃわかんないよな

188 ：
>>186
よくわからんが仮に「モナド」が使い物にならないなら
「素関手」みたいな、素数に似た名前の新しい概念を提案すればいいんだろ？

189 ：
>>188
今は、素でないといけないと言ってるわけじゃないし（むしろ素しかないのは変だなと言ってる）
名前を問題にしてるわけでもないんだが

190 ：
ただ名前を提案するだけでも、何も提案しない奴よりマシになれるからね
コストは最小化した方が良いし

191 ：
ハスケルで実用的なプログラム組みたい
具体的にはエロ画像サイトのスクレイピングやりたい

192 ：
>>191
やったらいいじゃん

193 ：
>>181　>>184
すいません代入束縛関係なく無限再帰の構文でした。

無限再帰途中で停止するため基底部を
パターンマイッチングの設定で止めてみました。

func' :: Int -> Int
func' 0 = 0
func' x = func' (x - 1)

x = x - 1でもやってみます。

194 ：
x = x-1

はHaskellだと止まらないよ。

x = x-1 = (x-1)-1 = ((x-1)-1)-1) = ...

といつまでたっても書き換えが終わらないから。
ただこの例ではループの検出が容易なのでghciで

ghci> let x = x-1
ghci> x

を試すと *** Exception: <<loop>> となって中断される。
基底部のない再帰はそうならない。

195 ：
>>187
ほんとこれ。　モナドの積がモナドにならないことがなぜ致命的なのか、全然言えないんだよねこの人。

196 ：
あれこれ空論には饒舌でも結局コード書かない奴は何をやってもダメ

197 ：
でもまあ何をやってもダメな奴は
自分は何もやらず安く買って高く売るだけの能力に全振りしてるんじゃないか

198 ：
>>194
ありがとうございます。
試してみて止まらないのを確認しました。
xが無限ループに束縛される様な感じです。

199 ：
>>188
素関手ってのは、あらゆる関手がそれらから合成できるときに使う言葉だ。
モナドは全然そんなものじゃないだろ？

>>195 >>196 >>197
モナドっていうのは、ごく限られた単純局面でのみ使えるプログラミング技法だっていう自覚はないの？
その意味で、関手はもちろんメジャーだが、モナドはニッチなんだよ。
もっと実用の「コード書いて」いくとそれがわかってくると思うが

200 ：
>>199
御託はいいんだよ。モナドってのは自己関手が作り出す「文脈」を引き継いで
どんどん計算してく、そういう発想をカタチにしたものなわけ。そういう具体的な
思想と具体的な実装を持っていて、Wadlerが示したように do 記法を通じて
参照透明性を壊さずに命令型のプログラミングができることは示された。

んで君は、「モナドは合成できないじゃないか」と言ってるわけ。んなこたあ誰だって
知ってるんで、たとえばモナドをパラメトリックにして、モナドトランスフォーマなんかを
考えたらいいんじゃね？いや、それ一見いいように思えてモナドがタワー状に積み重なって
保守しづらいんだけどとかいろんな人がまだあれこれやってる最中。

なんか便利なものができたら、その「便利なもの」が切り開いた地平の先に新しい岩があるの。
それは「問題の解決がもたらした新しい問題」なので頭が痛いところだけど、そうやって新しい問題の
解決のために挑むのが「知性ある人間」のしごとなの。

「馬車は不便」を内燃機関による自動車が解決したけど、今度はその馬力と速度を人間が
制御しそこねて「走る棺桶」だと言われたり、自動車による死者が多すぎて「交通戦争」と
言われたりすることに対して、シートベルトが知性ある人間によって発明されたの。
シートベルトは中途半端な解決策だね、ということでエアバッグを発明したの。

なんかのアイデアが副次的にもたらす頭の痛い問題をとりあげる、それは大事。
でも、「こんな致命的な欠陥があるから問題外」という考えは知性の放棄なの。

「自動車事故で人がたくさん死ぬから自動車禁止な」←知性の放棄です。

経済的工学的制約があるから、自動車事故の問題だってまだ解決してない。でもそれを
解決しようと続けることが知性なの。

モナドの合成の話は頭が痛い問題で、まだ十分な解決策をだれも見いだせてない。でも
それで喚き散らして「欠陥品」と罵ってるのはバカでもできる。知性がある人間は君が喚き散らしてる
間も圏論の本を読みながら「いくらかマシなアイデア」をひねり出そうとしてるの。

201 ：
出るって

ttp://www.amazon.co.jp/圏論の歩き方-圏論の歩き方委員会/dp/4535787204

日本評論社 (2015/9/10)

202 ：
>>200
力のこもったコメントありがとう
> 御託はいいんだよ。
もっと冷静にｗ
> 参照透明性を壊さずに命令型のプログラミングができることは示された。
それは関数型にとって宿命的課題。だが、モナドはそのためのものでもないし、モナドだから解決できるわけでもない
> んなこたあ誰だって知ってるんで
もっと冷静に。合成できないことは知っててもその意味が分かっていない
>「馬車は不便」を内燃機関による自動車が解決した
その場合の自動車は、限界はあっても、本質的技術進歩なんだよ。
その他あまたのそもそも成立しない技術とは区別しないとな。
合成できないというのは成立し得ない兆候なのよ。
> でも、「こんな致命的な欠陥があるから問題外」という考えは知性の放棄なの。
いやいや、致命的な欠陥があればそれはもうそれでだめなのよｗ
> モナドの合成の話は頭が痛い問題で、まだ十分な解決策をだれも見いだせてない。
それが分かっているなら、少し救いだが
> 君が喚き散らしてる間も圏論の本を読みながら「いくらかマシなアイデア」をひねり出そうとしてるの。
圏論の本を読みながらｗ
そもそもモナドが圏論から形式的にひねり出したアイデアだから、プログラミングでは使えないんじゃないのかい？

203 ：
あれこれ空論には饒舌でも結局コード書かない奴は何をやってもダメ

204 ：
合成するならモナドじゃなくて、モナドに供する関数でやってくれってことかねぇ。

モナドでパイ生地宜しく抽象レイヤ重ね出したら、結局手続き型と同じ業を背負い込むんじゃねーの？
という素朴な疑問がある。

205 ：
手続き型言語がーってのは的外れだな
この流れなら普通は自然言語に疑問をもつ
自然言語なんて空論記述言語にすぎないんじゃねーかと

206 ：
>>205
意味不明ｗ
自然言語だからか？ｗ

207 ：
都合が悪いようだな
自然言語を理想とする理想主義が否定されれば高級言語や人工知能の大部分が崩れるから

208 ：
>>207
逆だよ。ラッセルのような論理主義は自然言語が曖昧性を持ち、真理を記述するのに不適格だと
考えて記号論理を推進した。そのラッセルが生み出した型理論を（大幅に）修正したものが
強い型を持つ言語の基盤になっている。

自然言語による真理記述に興味を持ち続けた学者もいるけど、少数派（間違いだといいたいわけじゃない）
で、今日のプログラミング言語には全く影響を与えていない。

209 ：
低級言語に曖昧性はない
高級言語は曖昧性がないことに加えて更に別の理想を追求している
おそらく一度あきらめた理想を取り戻そうとしている

210 ：
毛の壁みたいなこと言ってないでコード書けよ

211 ：
Haskellでまともなコードが書ける日本人なんていないでしょ

212 ：
あっそう（ﾊﾅﾎｼﾞｰ

213 ：
都合のいいサンプルを出してるだけだ

214 ：
>>200みたいな評論のことね

215 ：
ガラパゴスなおまえらには無理

216 ：
haskell なんて簡単だよ
ひたすら型を複雑にすれば勝手に精密なプログラムになってくれるんだぜ？
あんな楽な言語、他に無いよ

217 ：
仕事でも趣味でも普通に世界でバリバリHaskell書いてる日本人たくさんいるけどな

218 ：
理想の言語を選べ
1 自然言語 ←コード書かない
2 型を書くだけ ←コード書かない
3 短い (一行とか) ←コード書く

219 ：
>>217
日本人が普通に世界でバリバリHaskellで書いたアプリケーションをたくさん紹介してくれ

220 ：
>>218
この３つの中では
１しかないかな？
２と３は論理的にありえない

221 ：
>>219 外資金融系とか。

222 ：
>>221
金融屋だけどHaskellは実務ではあんまり使わないよ
金融業界で使われている有名なライブラリがOcamlで書かれてるから、Ocamlが多い
あとは、F#だっけ？なんか、Ocaml互換のプログラミング言語

223 ：
>>222 知らないんだったら黙っててね

224 ：
言語名間違えてる時点で完全にモグリ。

225 ：
>>223
普通に現職の俺より詳しいというなら、なにかそれらしい反論してみろって

>>224
OCamlだったか、すまん
特定のドメイン領域でしか使わないし、俺は普段使わないから間違えたの

226 ：
エアコーダーさんは黙ってね

227 ：
どうせ紹介してくれるのならオープンソースの方がいいな。
まともに動く Haskell アプリのソース全体が見れる機会ってなかなかないんだ。
日本人が書いたなんて意地悪なことはもう言わんから、紹介してくれないか。

github 漁っても、実験的なものやサンプル、ライブラリくらいしか見あたらん。
なんか小粒な Web アプリはやたら出てくるが、なんだろ。
流行ってるのか？

228 ：
Hskellは金融で使われているよ
まぁ下請けだったけどね
元受の会社は誰でも知ってる大会社
ヒントだけ書くと、ソー○ネク○ト

229 ：
金融ってMATLABで数値計算ガリガリというイメージだがな。

230 ：
cabal replのCtrl-Pがshellと違って連続で同じコマンド使ってても1つ前のコマンド出すから
間違える→Ctrl-Pの連打数が増える→間違えるの繰り返し辛い

231 ：
>>229
数値計算につかうわけじゃない
ADTで金融商品の記述のDSL作って使う

232 ：
おまえらは「机上の空論」の世界でしか生きられない、ガラパゴスエアコーダー。言語の一つも作ってみろ、卑怯者

233 ：
この場がいいのかどうか分かりませんが、もし分かれば教えてください。

Wadlerの"Theorems for free"に、
r: ∀X. List(X) -> List(X) ならば　a* o r-A = r-B o a*
　 ここで、a: A -> B, a*:　List(A) -> List(B),
　r-A: List(A) -> List(A), r-B: List(B) -> List(B)
という定理が出てきます。

しかし、ここのrやaをたとえば
　r = { ["a", "b"] |-> ["a", "b", "b"],
[1, 2] |-> [2, 1],
........... }
a = { "a" |-> 1, "
"b" |-> 2,
............}
のようにとった場合、
　a* (r-Char(["a", "b"]) = a* (["a", "b", "b"])
= [1, 2, 2]
r-Int (a* (["a", "b"]) = r-Int ([1, 2])
= [2, 1]
となってしまい、明らかに
この定理は成り立たないと思うのですが、どこか誤解があるでしょうか？

234 ：
ヘアKしか出来ない卑怯者がブンブンうるさいね

235 ：
>>233 rの型が違う

236 ：
>>235
> rの型が違う
どう違うのでしょうか？ 気が付きません

237 ：
>>236 HaskellかMLのプログラム書いたことある？

238 ：
どこが違うかを直接指摘してくれるとありがたいです

239 ：
232の謎の言語のコンパイラはどこにあるんだろう
もしかしてコンパイラがなくても型が見える人なのかな

Haskellも自分が使うためじゃなくて型が見えない人のために作っただけ
そう考えるとHaskellでアプリを作っている気配がないのも辻褄が合う

240 ：
>>233
Wadlerの論文のどこの話をしてるの？

241 ：
岡部健さんこんにちは

242 ：
>>240
http://ttic.uchicago.edu/~dreyer/course/papers/wadler.pdf の
Introductionの話だと思う

>>233が何を言いたいのかは分からないけど

243 ：
>>242
ありがとう。そんな最初のところだったのか。
こりゃ単に r はパラメトリック多相な関数じゃなきゃいかんて話だな。

>>233みたいに型ごと値ごとにアド・ホックな対応を付けて
r を構成することはできない（任意の型のリストの任意の値を
取らなきゃいけないんで計算可能にならない）。

244 ：
>>240 >>242
そこです。
そこにある例では、odds関数の説明がよく分かりません。
「これは（定理の）反例にはならない。なぜなら、oddsの型が∀X. List(X) -> List(X)
ではなく、より特定的な List(Int) -> List(Int)であるので」と言うのですが、
oddsの型が∀X. List(X) -> List(X) になっていないとなぜ言えるのでしょうか？
φ(A)であってさらに∀X.φ(X) でもあることはあり得ることではないのですか？

245 ：
>>242

"odds"はIntについてしか定義できないだろ。
他の型についてどうやって定義すんだ？

というわけで、どんな型のリストにも適用できる関数は
特定の型の値を具体的に見て処理できないので
リストの構造を弄ることしかできない、ということよ

246 ：
あ、アンカー間違えた。>>242じゃなくて>>244

247 ：
>>243
> 型ごと値ごとにアド・ホックな対応を付けて
> r を構成することはできない（任意の型のリストの任意の値を
> 取らなきゃいけないんで計算可能にならない）。
その条件が明記されているのはあまり見たことがないのですが、
暗黙の常識なのですか？

248 ：
>>247
この文脈での「関数」が計算可能関数じゃなきゃいけないのは常識。

249 ：
>>245　>>248
すれ違いすみません。
> "odds"はIntについてしか定義できないだろ。
> 他の型についてどうやって定義すんだ？
Int以外についてはidにする、とかすればいいのではないですか？
そうしたときには
> この文脈での「関数」が計算可能関数じゃなきゃいけないのは常識。
計算可能でもあると思うのですが？
それに「この文脈」というのは今のような場面では少しいい加減な感じがしますが

250 ：
まあ、こりゃアド・ホック多相の話をしてない、ってだけだな。

251 ：
>>250
「アド・ホック多相」という概念があって、
ここでは「ただしアド・ホック多相でないこと」という条件が暗黙に付いている
ということですか？

252 ：
原文読んでみたけども、最初からパラメトリック多相の文脈で話してるし
問題の部分のちょっと前で暗黙どころか明確に否定している気が…

> The intuitive expIanation of this result is that r must work on lists of X
> for any type X. Since r is provided with no operations on values of type X,
> all it can do is rearrange such lists, independent of the values containedin them.
> Thus applying a to each element of a list and then rearranging yields
> the same result as rearranging and then applying a to each element.

253 ：
>>252
> 問題の部分のちょっと前で暗黙どころか明確に否定している気が…

特に以下の部分のことでしょうか？
>> Since r is provided with no operations on values of type X,
>> all it can do is rearrange such lists, independent of the values containedin them.

そういう意図なのだろうと思うのですが、
「r: ∀X. List(X) -> List(X)」だけではその意図を正確に形式化できていないのではないか？
と疑問なのですが。。。

254 ：
ML多相はad hoc多相ではないし、プログラミング言語理論でpolymorphismと言ったらデフォルトでparametric polymorphism。Cardelliのチュートリアルから読み直せ。

255 ：
ついでに、∀でad hoc多相表すほうが稀だから。

256 ：
形式化はイントロ以外の本論か、普通の型理論の入門書を読み直そう。

257 ：
associated data type は日本語では何と言うのが通例でしょうか。

258 ：
どっかの大学のレポート課題？

259 ：
>>258
私（>>257）への質問でしょうか。
勘違いでしたらすいません。

普通の社会人です。

type family を調べていたら出てきましたが、type family は型族という訳があるのに
associated data type は訳がネット上に見当たらないので質問しました。

単純に「関連データ型」でググっても associated data type に関連する記事は見当たりませんでした。

260 ：
VBAでもやってろよ

261 ：
ある程度以上のプログラミングを日本語で勉強しようというのが無理なので英語のままで検索することをおすすめする

262 ：
>>261
誤解させてしまったようです。
勉強のために日本語訳を訊いたのではなく、
単に日本語ならなんて言うのだろうかと思っただけです。

263 ：
結局、「r: ∀X. List(X) -> List(X)」という定式化ではパラメトリック多相性の意図を
正確に形式化できていないのではないか？という疑いは解けていないまま。。。

264 ：
どのように書かれていたら ID:6CToalvRは「正確に形式化できている」と判断するのだろうか

265 ：
俺が悪いんじゃない、Wadlerの書き方が悪いんだ、と言いたいのかもな

266 ：
∀型の意味はSystem Fとして厳密に形式化されている。「型システム入門」にも書いてある初歩。

267 ：
Wadlerの論文でも4節のFigure 2でちゃんと定式化の復習してるじゃねーか。読まずに書くなよ

268 ：
>>263

論文や入門書どころか2chのレスすら読めないのか？

0255 デフォルトの名無しさん 2015/08/10 19:27:08
形式化はイントロ以外の本論か、普通の型理論の入門書を読み直そう。
ID:xfbTbnyl(1)

269 ：
パラメータ多相はtemplateのようなものに型名を渡すだけで実体化する

アドホック多相は実体化する前に
["a", "b"] |-> ["a", "b", "b"],
[1, 2] |-> [2, 1]
のような単相のコードを仕込んでおかないと実体化できない
つまり型名だけでなくコードとか色々な情報を注入している

270 ：
パラメータ多相とかアドホック多相とかいろいろ出てるが
それらに共通の「多相」って何か言ってみろよ

271 ：
>>270
君はなぜ自分より知識や教養が上の相手にタメ口なんだ

272 ：
>>271
答えられないのか？
ところで君はこのスレをご主人と崇める番犬なんだな？ｗ

273 ：
基本的用語の検索もできない自称プログラマって生きてて恥ずかしくないの？
https://en.wikipedia.org/wiki/Polymorphism_(computer_science)

274 ：
大学1年生か2年生の課題とかじゃない？

275 ：
多相を分かりやすく言うと「単相ではない」という意味です
単相は昔からみんな知ってたやつなので分かりやすい

276 ：
>>272
おまえみたいなダメ学生のレポート代筆を誰が手伝うかってことです。

277 ：
田舎の秀才というか、狭い世界で褒められてるうちに
自我が肥大してしまっていつしか
「わからなくてもコツコツ勉強するのは大事」
「世の中わからんこともある」
「わからんのは、教え方が悪いからとは限らず、自分の知力の限界かもしれない」
というようなことを認めようとしないまま中途半端な歳まで来ちゃうと限りなくアウトに
近い。

妙に肥大した自我と釣り合いを取るために、「わたしには
知性も教養も欠けてるのでどうか憐れむと思って教えてください」
の一言が出せずに煽ることしかできない、そういう喧嘩腰が
いつまでも通じると思ってる時点で社会知性が低すぎてダメ。
コンビニのバイトですら務まらないレベル。


狭いサークルで褒められまくっていたせいか、妙な自信と
プライドだけは高いんだが中身はスッカスカ。


たまに親切な誰かが丁寧に教えてやっても礼の一言も述べず
「ふーん、なんか結局モナドって合成できないからプログラミングにとって致命的じゃん」
とか、言ってる本人にも意味不明なワードサラダめいたポエムを投げることしかできない。

278 ：
>>277
君どうしちゃったんだ？ｗ
本題についてだけ静かに語ればいいんだよ

279 ：
>>278
まあそんなに落ち込むな。

280 ：
自演して一人盛り上がってるアホを見た

281 ：
長文自己紹介とか草

282 ：
>>277
毛の壁宛なんだろうが、なんとなく流れ弾に中った感がある

283 ：
体育会系がルールにこだわるのは
ルールがなければ勝ち目のない相手にもルールを守らせれば勝てるからなんだよな

284 ：
そんなことってあるか？

285 ：
常識でしょ
「勝ちたいのならルールを作る側になれ」てよく言うじゃん
そういう意味で体育会系を束ねるのは楽だけどな

286 ：
「常識でしょ」

287 ：
「選択と集中」だとか「勝ちたいのならルールを作る側になれ」とか
カモリーマン相手の自称ベテランコンサルタントが言いそうな言葉っすね。

そういうゴミみたいな言葉を頭に突っ込むとゴミみたいな考えしか出てこないゴミ頭になります。

288 ：
別に俺俺型クラス作ってもいいんやで

289 ：
うおおお いつの間にかhackageにあるソースコードがリッチになってる！
http://hackage.haskell.org/package/base-4.8.1.0/docs/src/GHC.Base.html#local-1627391929
どうやって作るんだこれ…

290 ：
仕様を作る側って素人でもなれるんだろ
プロは他人が作る仕様 (変更) を予知するべき

291 ：
ちょっと何言ってるか判らない

292 ：
ﾜﾛﾀ
すげぇなw

https://dl.dropboxusercontent.com/u/7687891/join_to_Monad/join_to_Monad.html

293 ：
>>292
若干長いけど良い記事だよね。

294 ：
>>292 >>293
とても素直な気持ちのいい記事だね

295 ：
いろいろHaskellが変わったらしいけど
今だとHaskellの入門書としてお勧めってどれになるんです？

296 ：
>>295
いろいろとか言っても Monad が Applicative になったとかそんな程度じゃないの？

297 ：
ねえ

Monad m => m (m a, m b) -> (m a, m b)
ってできるっけ？

298 ：
失礼。自己解決しました。
join . liftA (uncurry (liftA2 (,)))

299 ：
writer関数ってタプルの順番間違ってないか？

> (++) <$> (Sum (42::Int), "apple"::String) <*> (Sum 13,"banana")
(Sum {getSum = 55},"applebanana")

> let flipP (a,b) = (b,a)

> (++) <$> (writer $ flipP (Sum (42::Int), "apple"::String)) <*> (writer $ flipP (Sum 13,"banana")) :: Writer (Sum Int) String
WriterT (Identity ("applebanana",Sum {getSum = 55}))

--
現状、
writer :: Monad m => (a, w) -> WriterT w m a
になってるが、
writer :: Monad m => (w, a) -> WriterT w m a
だったら上記の例のflipPが要らない。

300 ：
人には右利きと左利きがあって、左利きは「間違ってないか？」とよく言われるが
その問いに正解はない

301 ：
リトルエンディアン: しばしばビッグエンディアンより優れているとされる
ビッグエンディアン: しばしばリトルエンディアンより優れているとされる

302 ：
なんか、すごいの来たー！！！
ttp://www.amazon.co.jp/圏論-原著第2版-Steve-Awodey/dp/432011115X/

あとこれも、
ttp://www.amazon.co.jp/圏論の歩き方-圏論の歩き方委員会/dp/4535787204/
以前の数学セミナー（だっけ？）の連載のまとめだと思うけど。

303 ：
Wikipediaのエンディアンの項目を見ていて一番ばからしいと思ったのは、
エンディアンを切り替えられるバイエンディアンプロセッサ。

304 ：
なんか、すごいの来たー！！！
ttp://www.amazon.co.jp/圏論-原著第2版-Steve-Awodey/dp/432011115X/

あとこれも、
ttp://www.amazon.co.jp/圏論の歩き方-圏論の歩き方委員会/dp/4535787204/
以前の数学セミナー（だっけ？）の連載のまとめだと思うけど。

{- 間違えて sc の方に書き込んだら、まるっきり反応がなかった。 -}
{- で、.net で再投稿 -}

305 ：
Wikipedia
＞圏論を初期の学部生に教授することは強い反対にあっている。

にわかに圏論の勉強を始めない方が良い？

306 ：
買うわ

307 ：
>>305
一言で言うと、Haskellのモナドや多相型の関数の概念を理解し使いこなす、つまり関数プログラミングの実務に圏論は全く必要ないし
知っていても何の役にも立たない、つまりは圏論はそのキーワードをひけらかしていい恰好したいだけの単なるファッションの飾りに過ぎない

他方、本当に計算の理論（例えば表示的意味論を展開する数学的構造な枠組みとしてのScottらの領域理論など）を
勉強して理解し将来的にはその分野で学術誌か国際会議に論文の１つでも通したいのならば、圏論の勉強は不可欠
（Scott理論の古典的で基礎的な部分の学習だけならば別に圏論を知らなくとも一応はできるけれどね）

308 ：
>>307
その説明もなんか変なんだよな
いい恰好したいなら金持ちか政治家になればいいのに
なんで批判する側もされる側も学者を標的にするのかさっぱりわからない

309 ：
一言で言うと、自動車を運転するために熱力学や内燃機関について知る必要は全くないし
知っていても何の訳にもたたない。つまり熱力学だとかカルノーサイクルを勉強してるやつは
カッコつけたいだけのファッションバカにすぎない。

ブレーキは踏めば止まる、エンジンはなんかガソリン入れときゃ動く、ラジエーターだとか
よくわからんものはガソリンスタンドでチェックしてもらえばいいし、タイヤの空気圧が下がってる
事の意味もガソリンスタンドの人が注意してくれるし、物事が動く原理というのは
全く知る必要がない。

原理厨はなにかとあれこれ勉強しないとわからん言って脅してくるけど、俺達は反知性主義の
旗を掲げて徹底抗戦だ。

310 ：
例えがまるで的外れだ

311 ：
「一言で言うと」で始まる長文を書いてる時点で

312 ：
反知性主義自体には共鳴してくれるでしょ。圏論要らない。

313 ：
「全く〜ない」
とか
「〜だけ」
とか
「〜にすぎない」
が多用されてる文章は確かに反知性主義的な感じがする。

314 ：
要らないというのはミニマリストの言葉なんです
ミニマリストが反知性の手口を学べばそっくりそのまま応用できる可能性が高い

315 ：
>>304
宣伝乙(良い意味で)

316 ：
Haskell分かっても圏論が分かったことにはならないの？
どこで違いが出てくるの？

317 ：
>>316
Haskは圏のなかでもやや特殊。型付のラムダ計算なんかを抽象化して得られる
圏と近い。例えば、Hask圏では A, B という対象に対して A->B という対象を作れるが、
このような性質は「一般の圏」にはない。

318 ：
まぁhaskellの学習に圏論必要ないってのはほんま

319 ：
圏論ワードに外来語的なニーズがあるというコンセンサス

320 ：
Haskellの学習に圏論は必要ないし、そもそもプログラミングを学ぶ必要すらない。
俺達先進国の人間はベトナムの優秀なIT技術者を時給50円で死ぬまで使えば良いからだ。
そもそも何かを学ぶということは人間の自然に反する。言語を捨て、文明を捨て、原始に回帰すること
こそ人類の究極の目標である。

321 ：
知識がどうとかは、個人ベースの話なので、まったくどうでもいいし、着眼点がずれている
個人の人生のテーマなんぞは、本人にしか関係ないし、他人からしたらどうでもいいこと
お前が知識が要らないと考えるなら、そうすればいいし、俺らには関係ない、お好きにどうぞ

機能性を追及することが、人類の永遠のテーマなのです
分かりやすく言えば、100人の人間が集まって、その100人で、どういう機能を果たすか、ということ
昨今コミュニケーション能力が高らかに叫ばれるのは、そういうこと
ここで、知識は手段に過ぎず、目的になりえない

322 ：
100人がコミュニケーションすると80人が嘘をつき合計マイナス60人になる場合もある
マイナス60人は1人よりも小さい

323 ：
そうならないようにするのが、人類のテーマなんです

324 ：
ワクテカ
http://haskellformac.com

325 ：
mac 用IDE がもうすぐリリース

326 ：
すまん、かぶった

327 ：
>>320 建設会社でも行ってこい、

328 ：
>>327
圏論厨を滅ぼすまではダメです

329 ：
>>328 ワロタ、あれは生き残るパターンや。プログラミングの機械化がすすむ以上、おまいらが将来つかうことになるからな

330 ：
そもそも真の圏論厨はlispで独自実装しそうなもんだが

331 ：
Lispと圏論は全然関係ないからやめろよ
C++使えよ
マクロじゃなくてテンプレートを使うんだぞ

332 ：
>>317
それはむしろHaskellをやればCCCがすぐ分かるということだ
Haskellをやっても圏論は分からないという例はないの？

>>318
いやその逆で、圏論の学習の替わりにhaskellが使えるか？ということなんだが

333 ：
例というか、PerlのOOPが異端視されるのと同じ
Perlをいくら完璧に学習しても「OOPを正しく理解していない」と見做される

334 ：
OOPと圏論を同列に並べるのはいかがなものか
OOPは茫漠とした思想みたいなもんだが圏論は違うだろ？

335 ：
違うだろ？ってみんなで答え合わせしないと確信を持てない時点でかなり怪しい
みんなで共有する知識はそういう怪しいものばかり
なので個人で頑張る

336 ：
>>335
Haskellの話に圏論絡めてくる奴は皆殺しにしろとか言い出す
僕みたいな反知性主義者が「答え合わせ」に参加すると結論が歪む。

337 ：
>>336 とりあえず通報しときました。

338 ：
>>337
つうほうせんといてや〜

339 ：
圏論やるより型クラス勉強してモナド使うほうがhaskellの勉強になるから

340 ：
>>339
そうやな！圏論いらんわ。
だいたいあいつらちょっと数学が得意だからって調子こいてるよな。

341 ：
いらんってことはないけどな。
圏論だと思って使わなくても圏論の概念は使うことになるし。
逆に言えばわざわざ圏論を学ばんでもどうせ触れるっつー話でもある。

俺ら日本語の文法をわざわざ学んでから喋っとるわけちゃうみたいに、
実用から入っていけばなんとなく自然な使い方もわかるようになるで。
まあ、どっちから入門してもかまへん。
ただ、圏論から入っていくやつをあえてディスるんはやめよで。

342 ：
私は関西人ではないのですが、『やめよで』は『やめような』という意味の関西弁として正統なのでしょうか？

343 ：
圏論は頭の体操にもなるし論文書いたり新しい技法を開発するレベルまでやりたいなら止めはしないが、
haskellのモナドを人に教えるときに圏論の話を絡める奴は全く信用できん、という程度の話。

344 ：
>>339
>>340
>>341
君たち、
「Haskellやモナドを使うのに圏論を知っておく必要は全然ない」てのはよく聞くけど
それって、「そんなの知らなくてもできる仕事は一杯あるからね、下流底辺に。
上流の仕事は圏論が分かる層がやるから気にしなくていいよ。」ってニュアンス？

345 ：
>>344
「最初からハードル上げるな」という話。
Haskell でプログラミングするだけなら圏論を意識することはない。

圏論で言ってることというのは意識せずとも使える程度のものでしかないんだよ。
ただ、そこに明確な定義を与えて名前を付けたのが圏論という学問領域になってるだけ。
言うなれば数学界のデザインパターンが圏論。

先に Haskell を実用している人が圏論みても、
あ〜このパターンってこういう名前がついてんのね〜、ってくらいの感想だろうよ。

346 ：
デザインパターンの中には知らなかった (しかし知っていると有用な) パターンだってあるだろうし、
それを学ぶことを無意味と切り捨てることはできない。
圏論として学ばなくても誰かのコードを読んでいるときに知るということもあるだろうから、
圏論という形で学ぶ必要は必ずしも無いけど、
まあほどほどに Haskell を使えるようになった頃に一度くらい斜め読みしてもいいんじゃないのかねとも思う。

上手く使えるようになったつもりでもさー、全然知らなかった概念が頭の中に湧いて出てくるってことはないんだよ。
たとえ話で言えば、字を早く書きたくてペンの性能を目いっぱい追求して満足な結果が出るとするじゃん？
そしたら世の中には実はタイプライターがありました、ワードプロセッサがありました、っていう感じ。

347 ：
目的や目標とするレベルが各人バラバラだから話が噛み合わない

348 ：
参考文献を書く義務とそれを読む自由と読まない自由があるけど
342のように自由というニュアンスを理解できない人が多い
で、自由ってよくわからんから全部義務にしようということで圏論まで強制されてしまう

349 ：
高度なことをしようと思えば高度な知識が必要だし、
ほどほどでいいならほどほどの知識でいいっていう当たり前の話だよな。

文章にきちんとまとめて発表しようとすると使う言葉が圏論の世界のものに
なってしまうからどうしてもそういう言葉を目にしてしまうだけで。

350 ：
数学界のデザパタの前にHaskellのデザパタを知りたい

351 ：
モナドだろ

352 ：
>>348
自由とか義務とかの問題じゃないだろｗ
能力の問題
>>349
やっぱりHaskellより圏論の方が高度ｗってことね

353 ：
反知性主義者を代表して言わせてもらうが

「俺は圏論をまったく知らないが、モナドを自由に使えてる。だから圏論は必要ない」

以上です。

354 ：
>>353
反知性主義者か。ええなあ。がんばってや

355 ：
>>353
その圏論を知らずにモナドを自由に使えているあなたが仮に圏論を学べば、
モナドを人に上手く教えたりもっと
自在にモナドを操れるようになるのかも知れないね。

356 ：
必要に足りてるならそれはそれでいいよ。

357 ：
>>355
その例を一つ二つ挙げてみてよ

358 ：
べつにチューリング完全な言語を超えるような未知の能力を研究してるわけじゃないから
ただ型推論を使って動的型付け言語のレベルに追いつけるかどうかの問題

359 ：
何言ってんだこいつ？

360 ：
難聴乙

361 ：
静的型付け言語がまるで動的型付け言語に劣っているかのような誤解を招く書き方ですね

362 ：
チューリング完全の枠を出ないと、超一般的な前提を言いながら、
ffiで各々が呼びだせば解決する程度の話をする頭の悪さ

363 ：
頭の良さってほんのわずかの差で一喜一憂するところが放射能に似ているよね

364 ：
動的型つき言語は、再帰型のある静的型付き言語のサブセットだぞ

365 ：
>>363
すまんが放射能語ではなくて日本語で頼む

366 ：
haskellにどんなモナドがあって、どういう使い方をすればいいのかは圏論を学んでも分からんよ。
Freeモナドが、Stateが、Parsec.ParsecTが、あるいはXMonad.Core.Xがどういうモナドなのか、圏論が教えてくれることはない。

VisitorとSingletonとIteratorと各々を学ばなきゃ使えないのに、デザインパターンという言葉の意味にだけ耽溺する奴とよく似ている。
よっぽど学術的なことをしたいか、さもなければ馬鹿だ。
俺は「純粋関数型言語で副作用はどう書けばいいのか」という初学者の質問に「IOモナドがー」と馬鹿な答を書く馬鹿がこのスレにいたのをよく覚えている。
ttp://blog.jle.im/entry/io-monad-considered-harmful
スノッブ共からモナドや圏論の言葉を取り戻さないといけない。

367 ：
Stateモナドとかスタック作るまでのチュートリアルがほとんどで
結局どう使うかはほとんど説明されてなかったり

368 ：
>>367
実際あんまり使わないからだと思う。
それに、本当に状態操作が欲しいなら素直にSTモナド使うほうがいい。

369 ：
>>366
どういうモナドかは当然それぞれの性質があるんだろうけど、
共通する性質があってそれをモナドというパターンに当てはめてるんだから、
モナドがどういうものかは知らんと話にならんだろう。

デザインパターンに過剰にこだわるのが害悪の場合はあるが、説明に使う言葉に何を使えばいいっていうんだ？
っていうか、基礎的な質問ならキーワードとなる言葉を与えてウェブ検索させるってのは普通のことだろう。
共通認識できる「名前」が重要で、それが圏論由来のものであろうがそうでなかろうが重要じゃない。
既についている名前があるなら新しい言葉を発明することにどれだけ意味があるっていうんだ？

370 ：
http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf
Monads for functional programming
Philip Wadler, University of Glasgow
No knowledge of category theory is required to read these notes.

371 ：
>>366
うんうん、それもまた反知性主義だね！

反知性主義者たちがどんどん集まってきてうれしい。
Haskell界で声がでかい人で圏論にハッキリ嫌悪感を示してる人って山本センセぐらいしか
いないんで、貴重な同士だわ〜

372 ：
>>370
なんか糖衣にくるんで圏論に誘導しようとしてるような感じがして嫌だな。
参考文献に悪名高いMoggi（こいつのせいで調子こいて圏論言うやつが計算機科学に入ってきた）
が挙がってるし、ろくなもんじゃないだろ。

そもそも反知性主義者である俺は英語論文を読むなどというスノビズムに染まった行動には断固として反対なのだ。
日本男児なら日本語で語れ！

373 ：
dg非jドアsポあjふぃおs打kｓｇふぁ： 打sjgdｌ：ｓ
ｄｓｃじょぎｋｄさｋｊｇｄｓｋげｊ子ｒイオｄｓｇｋあｄ祖ｇｓだ

ｊ御ｋ自ソアｄｇｊポｄｓｊｇぴおｄｓあぽｇだぽあ

374 ：
>>368
まあStateモナドは確かにそうなんだけど
そういう意味じゃなくてSTモナドも含めてきっちり実用面まで含めて状態計算関連の説明してる所ってほとんどないよね、ってことが言いたかった
ソース読めって言われればそれまでだけど

375 ：
だいたいね、

``It is doubtful that the structuring methods presented here would have been
discovered without the insight afforded by category theory.''

とか言い出してるあたりで、「あーこいつ自分が圏論を知ってますアピールしとるな」
と分かるじゃん。心の底では「Moggiくらいお前ら読めよ」とか思ってるわけ。
自分では圏論信者なんだけどそれは小乗の教えだとか密教だと思ってるわけ。
それで、大乗というか大衆バージョンの教えとして「ほら経典なんか勉強しなくても
この車輪を手で回すだけで救われますよ」とか大衆をバカにした布教をしてるんだよね。

そういう態度がいちいち鼻につくからね、圏論厨はキモいんですよ。

376 ：
じゃあどうするっていうんだ？
圏論的背景があるのはどうしたって動かせないだろう。
真髄を理解したければ圏論は必要じゃないか。

真髄は必要ない、ただ使えればいいっていう人向けの情報が嫌なら
もう Haskelｌ 使うなよとしか言いようがないよ。

377 ：
>>374
STモナドはIOモナド理解してればそのまま使えるよね？
そして、IOモナド・STモナドの仕組みは原理としては別に難しくない

378 ：
逆にわたくし、haskellしばらく勉強してきまして
そろそろ裏でどういう理論づけがあるのかなーみたいなことを知りたくなってきたのですが、
何かしらおすすめのルートはございますか（普通に圏論に入門してみればいいの？）

379 ：
反知性とかそういうのじゃなくてな、haskell初学者を惑わせるだけの圏論の話なんて必要無いってだけなんだ。
初心者が聞く「モナドって何？」っていう質問に圏論的な説明はじめるのは迂遠過ぎてhaskell難しいっていう印象しか残せない。

単に「中の値を直接取り出せないようなコンテナ型であっても、その中身を(安全に)操作、合成するための技法」の1つであると言えばいいのに、
それを「何故モナドという名前なのか」という意味に曲解し、そこだけ説明したり訂正したりする奴がいるから、haskellの真髄は圏論であると勘違いする人が出てくる。

圏論じゃなくて型付けラムダ計算あるいはSystemFがhaskellの基礎でしょ。
Control.MonadやControl.Categoryはあくまでも利便性を高めるためにあるもの。無くても不便なりに使える。
>>378 なので、haskellのコアな部分というなら型理論を学べば良い。ライブラリの中には圏論をベースにしたものがあるから、そっちの理論的背景を学びたいなら圏論を学べば良い。
圏論は間違ってもマクレーンの本からはじめない方がええ。最近ならもっといい(例が数学的過ぎない)文書がネット上にもある。
日本語だったら前スレにも出てた↓とか。
http://nineties.github.io/category-seminar/#/

380 ：
>>379
自分は反知性主義を掲げて圏論厨を批判してるけど、「なぜモナドという名前なのか」とか言い出す
圏論厨は見たことない。

マクレーンが隠れ哲学厨だったんで範疇論から名を借りてcategory とつけた分野に、
ついでにライプニッツの単子論から名前を借りて（こっちはもう本当に名前を借りただけ）
monad と呼んだだけで意味とか全くないし。

それまでは triple と呼ばれてたんでまともな複合語が作れないという問題があったから
モナドと呼ぶほうがマシじゃんぐらいの意味しかない。

ほらね、圏論ってのは意味がないんです。やめましょう。

381 ：
Haskellの真髄は(->)
型クラスがなくても(->)は存在する
(->)がなければMonadもCategoryもない

382 ：
>>378
圏論はやらんほうが人生を有効に使えると思いますが、人生を無駄にしたいというなら

Benjamin C. Pierce "Basic Category Theory for Computer Scientists"

あたりはお勧めできます。ただしモナドは載ってません。とはいうものの索引まで入れて100ｐなので
圏論がどんなものか概観するにはちょうど良いでしょう。100ｐもあんのかよ、というツッコミもあるでしょうが
ラムダ計算の領域理論のための議論も含まれてるので、Hask圏をゆるっと理解したい程度なら
領域理論の準備の箇所を飛ばせばいいと思います。

他に、もうすぐ共立から邦訳が出ますが

Steve Awody "Category Theory", 2nd ed.

あたりも好評のようです。非常に丁寧に書かれてる本ですが、丁寧ということは長ったらしいという
ことでもあり、いちいち説明が大仰だったりする感もないではないです。

みなさんも仰ってるとおり圏論なんてのは言葉づかいにすぎないわけで、日常会話程度なら
大げさな本で勉強せずともよろしいという人は、圏論の教科書ではありませんが

J. L. Bell "Toposes and Local Set Theories"　←Doverなのでそこそこ安い

の最初（一章）の20ｐぐらいまでを眺めるとよいでしょう。モナドは載ってませんが米田ぐらいまで一気に話が進みます。

Pierce とかBellをざっと眺めるぐらいの理解をしておけば

ttps://ja.wikibooks.org/wiki/Haskell/圏論

の議論は簡単に理解できるでしょう。理解したからといってHakellのコーディング能力は一ミリも伸びないと思うけど、
とりあえず「return,join でモナド実装するのがスッキリしてわかりやすいと思うな」とか言い出した奴に
ドヤ顔で「うんうん、圏論で言う eta, mu だね」と返せるようになります。

383 ：
>>363 その前に頭の良さの定義を頼むw

384 ：
>>382
反知性主義者というので期待してたが
結構知ってるよ的なので、ガッカリしたｗ

385 ：
お前ら人間なめんなよ、子供の算数を集合論ではじめときゃいいんだよ。

386 ：
>>366
> VisitorとSingletonとIterator
これらデザパタはクソなのだが、モナドも同類なのか？
>「純粋関数型言語で副作用はどう書けばいいのか」という初学者の質問に「IOモナドがー」
Moggiはじめ皆そう言ってきてるんだが違うの？
> ttp://blog.jle.im/entry/io-monad-considered-harmful
これモナドを全否定してるかと思ったらそうでもないので期待外れ

>>379
> 圏論じゃなくて型付けラムダ計算あるいはSystemFがhaskellの基礎でしょ。
圏論は後者とどう違うという認識？

387 ：
>>379 >>382
ありがとうございます。
なんかある程度勉強してからだと「あ、そういうことね」っていうふうになれそう
というのに最近出会ってちょっと悔しかったので、やってみます

388 ：
tapl

389 ：
>>388
Benjamin C. Pierce "Types and Programming Languages" 　ですね。 "Basic Category Theory for Computer Scientists"
のようなコンサイスな本を書いた人がなぜこんな風に長ったらしく書いたのか不思議ですが丁寧な本ですね。
もう少し読者の数学的マチュリティを信頼して書いてくれたら簡潔になっただろうにと思うとそこんとこ残念ですが。

>>386
圏論と型付ラムダ計算との関係については、J. Lambek and P. J. Scott "Introduction to Higher Order Categorical Logic"
なんかを見ると良いと思います。

390 ：
圏論ねえ。数学的興味からHaskelltoha関係なく勉強したのだが、
Haskellに関する限り、Ekmettが何してるのか理解したい時に
少し役に立つ程度だと思う。

391 ：
Haskellと圏論の関わりなんて、IOを無矛盾に扱うために言語に追加導入できる最良の道具だったってだけのことで、
ラムダ計算とLisp・一階述語論理とPrologのような、その生い立ちに根源的に関っているもんじゃないからね
オナニーの道具としては最高なんだろう

392 ：
普通andとorとnotしか使わないから述語論理も要らないな

393 ：
鹿児島県の伊藤祐一郎知事に言わせれば
「高校教育で女の子にサイン、コサイン、タンジェントを教えて何になるのか」
「社会の事象とか、植物の花とか草の名前を教えた方がいい」
ということになる。

394 ：
>>392
普通∀や∃も使うだろう

395 ：
>>393
関数の名前は知ってるけど内容は知らないんだろ
植物の名前でも同じことだ
名前ばっかり宣伝するのは本当に無意味だからやめればいい

396 ：
ひゃっほーう　stack 環境下でエディタの補完が効くようになったぜ！

397 ：
圏論とHaskellとモナド。。。。。
ちょっと話が面白くなってる気がするな
反知性主義者や山本さんやらが出てきて。
勿論知性主義者が出てきてもいいよ
あれを読めとか何かを教えてやったとかつまらんこと言わずに
自分の見解を言ってくれ

398 ：
圏論なんてそんなに構えて勉強する、なんてスゴイものじゃないよ
おれはバカンス先のホテルで2冊も読んだらだいたい分かったよ

399 ：
>>398
「スゴイ」とか「分かった」という語句を使う点がなんだかなと思うが。。。
すぐに分かったと言うあなたとなかなか分からん奴とは何が違うと思うか語ってみてくれないか

400 ：
「C++完全に理解した」

401 ：
cabal について質問です。

.cabal/config ファイルの documentation の項を True に設定すれば
cabal でインストールしたパッケージのドキュメントが追加され、
ドキュメントルート内にある index.html ファイルが更新されますが、
その際に index.html ファイルの更新のされ方を指定する方法はあるでしょうか。

具体的には、index.html に張ってあるリンクの URL をデフォルトから変えたいです。
たとえば、ただいま index.html 内の Data.List へのリンクの URL は、
最後 Data-List.html で終わっています。
これを base-4.8.0.0/Data-List.html のように文字列を加えたいのです。

.cabal/config ファイルにはパッケージのインストール先を指定する項目はありますが、
このようにドキュメントのリンクの URL を指定する項目は見あたらないようです。

不可能なのでしょうか。

402 ：
>> 399
たぶん、haddockセクションの html-location の項がそれ。

403 ：
>>402
そこに文字列を入れ、いろいろなパッケージをインストールしてみましたが、
何も変わりませんでした。

404 ：
ひょっとして、コメントアウトを外してない、なんてことはないかい？

-- html-location:
を
html-location: hoge
にしないといけないよ。

405 ：
>>404
もちろん、コメントは外しています。

406 ：
>>405
ちなみに、cabal install --haddock-html-location='・・・' で直接指定しても何も変わりませんでした。

407 ：
>>406
以前似たような質問をしてた方と同じ人ですか？　
前回ともども、ろくすっぽ調べもせずテキトウに答えちゃってごめん。

いろいろ試してみたんだけど、どうやら無理っぽい。
html-locationはその時にインストールしたパッケージの内部のドキュメントのリンク先を変えるものらしい。
haddockにある別のオプションを変えることで、ドキュメント右上のContentsや、Indexの参照先を変えることはできた。
でも、ご所望の、パッケージが依存している別のパッケージのドキュメントへのリンクは、書き換えられないみたいだ。

すべてのパッケージのドキュメント位置の情報は、ghc-pkg が握ってる。

$ ghc-pkg field '*' haddock-html
...
haddock-html: /usr/local/Cellar/ghc/7.10.2/share/doc/ghc/html/libraries/array-0.5.1.0
haddock-html: /usr/local/Cellar/ghc/7.10.2/share/doc/ghc/html/libraries/base-4.8.1.0
haddock-html: /usr/local/Cellar/ghc/7.10.2/share/doc/ghc/html/libraries/bin-package-db-0.0.0.0
haddock-html: /usr/local/Cellar/ghc/7.10.2/share/doc/ghc/html/libraries/binary-0.7.5.0
...

これらの情報を参照して、haddockはパッケージのリンク先を書くんだと思う。
だから、やりたいことを実現するには、そもそもの依存パッケージの位置を変えるしかない。
(cabalを通して呼ばれるhaddockにだけその情報を渡す方法があるのかもしれないが、俺の調査ではわからなかった。
cabal installへのフラグ--haddock-option=--optghc=-package-db=hoge/.../package.conf.dなどを試したけど何も変わらず)

408 ：
>>407
こちらでは ghc-pkg field '*' haddock-html 出力と、
ドキュメントの index.html 内の各リンクの URL とが異なっています。

たとえば、ghc-pkg field '*' haddock-html の出力では
　　　/usr/share/doc/ghc/html/libraries/array-0.5.1.0
　　　/home/.../.cabal/share/doc/x86_64-linux-ghc-7.10.1/random-1.1/html
となっています。
前者は ghc インストール時にデフォルトで入っているパッケージ、
後者は cabal でインストールしたパッケージです。

ところが、/home/.../.cabal/share/doc/x86_64-linux-ghc-7.10.1/index.html では、
Data.Array へのリンクは /home/.../.cabal/share/doc/x86_64-linux-ghc-7.10.1/Data-Array.html
System.Random へのリンクは /home/.../.cabal/share/doc/x86_64-linux-ghc-7.10.1/System-Random.html
になっています。

.cabal/config がデフォルトの状態でこのようになります。


ちなみに、frames.html や doc-index-A.html などの中にあるリンクは正しいです。
また、各モジュール個別のページ内にある他モジュールへのリンクも正しいです。
トップの index.html 内のリンクだけがおかしいのです。


もう少しアプローチを変えて調べてみます。
ありがとうございました。

409 ：
ああ、もし、sandbox使ってるんだったら、

$ ghc-pkg field '*' haddock-html
ではなく、
$ cabal sandbox hc-pkg field '*' haddock-html
を呼んでください。

あと、405の時点では「haddockがghc-pkgを内部で呼ぶ」と思ってたんだけど、実は「cabal が haddock に依存先パッケージのドキュメントの位置を渡す」ということがわかった。
cabal install に --verbose=3 を渡して、haddockに渡っているオプションを見て気づいた。
cabal の --package-db オプションの値が、haddockへ --read-interface オプションとして渡されるらしい(ただし、sandboxにいるときは cabal install に直接package-dbを指示しても無視されるみたい)。

410 ：
>>409
問題が解決しました。

結論から言うと、最新版の GHC をインストールしたら治りました（7.10.1 --> 7.10.2）。

ここに私と似たような質問がありました。

http://comments.gmane.org/gmane.comp.lang.haskell.arch-linux/2119

要約すると、これはインストール時の設定などではなくもっと上流で起きている問題であり、
以前はオンラインドキュメントでも同じ問題が起きていて、GHC 10.7.2 で治ったそうです。

つまり、私は問題の根本が分からず、とりあえず config ファイルの設定によって URL を変えて一時しのぎをしようと思い、
その方法をここで質問しましたが、最新版で問題が解決され、質問の意味がなくなったということです。

私は ArchLinux を使用しており、GHC も cabal-install も ArchLinux のパッケージシステムを使用してインストールしていましたが、
ArchLinux のパッケージでは GHC の最新版はまだ 7.10.1 のままでした（ArchLinuxは最新版の提供が比較的早いはずなのですが・・・）。
そこで GHC の公式サイトから 7.10.2 をDLしインストールしたところ、デフォルトのライブラリドキュメントも、
その後で cabal でインストールしたライブラリドキュメントも、index.html が正しいリンクを張ってくれるようになりました。

実際のところは、ArchLinux のパッケージだったからまずかったのか、7.10.1 だったからまずかったのか分かりませんが。


cabal の挙動について詳しく解析していただいたのに活用できなくて申し訳ありません。
ただ、その解析方法や情報についてはとても勉強になりました。

ありがとうございました。

411 ：
おめでとう。
haddockのバグだったのか(cabalではなく)。
haskellのツール周りは色々混み合っててよくわかんないなあ。

412 ：
型クラスのメソッドにデフォルトの定義を与えることができますが、
そのデフォルトの定義をインスタンス定義の側から呼ぶことはできるでしょうか。

例えば下記のようなことがしたいです。

class Umai a where
　level :: a -> Int
　level _ = 3

data Nasu = Nasu

instance Umai Nasu where
　level x = Umai.level x * 100

これは最後の Umai.level でコンパイルエラーが出ますが、ニュアンスは伝わると思います。

他にも、デフォルトと同じ挙動をさせたいが、Debug.Trace.trace 関数を仕込んで調査したい時とか。

413 ：
instance Umai () where {}
newtype X10 a = X10 a
nasu = X10 (X10 ())

class Oldtype a where { oldtype :: a b -> b }
instance Oldtype X10 where { oldtype (X10 o) = o }
instance Umai a => Umai (X10 a) where { level x = level (oldtype x) * 10 }

414 ：
()もいいけど、型をラベルみたいにして情報載せるのは、ファントムタイプの出番ですよ。
data Umai a = Umai { defaultLevel :: Int,
season :: Season}
data Season = Spring | Summer | Autumn | Winter deriving Eq

data Nasu
data Tomato

class Level a where level :: a -> Int

instance Level (Umai Nasu) where level = defaultLevel * 100
instance Level (Umai Tomato) where level = defaultLevel * (liftA (== Summer) season ?) 200 100
{--
> level (Umai 1 Summer :: Umai Nasu)
100
> level (Umai 1 Summer :: Umai Tomato)
200
> level (Umai 2 Summer :: Umai Tomato)
400
--}

415 ：
ちな
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE FlexibleInstances,TypeFamilies #-}

module Main where
import Control.Applicative

(412の中身)
instance Num n => Num (a -> n) where
(+)= liftA2 (+)
(-) = liftA2 (-)
(*) = liftA2 (*)
abs = liftA abs
signum = liftA signum
fromInteger = const . fromInteger

class Conditional q a where
type ConditionalExec q a
(?) :: q -> ConditionalExec q a -> ConditionalExec q a -> ConditionalExec q a
infixr 1 ?

instance Conditional Bool a where
type ConditionalExec Bool a = a
(?) b x y = if b then x else y

instance Conditional (a -> Bool) b where
type ConditionalExec (a -> Bool) b = a -> b
(?) = liftA3 (?)

main :: IO ()
main = print $ level (Umai 1 Spring :: Umai Tomato)

416 ：
>>413 >>414
ありがとうございます。
そのままでは使えないのですが、考え方を参考にさせていただき、応用してみます。


ちなみに、さすがに Umai 型クラスにも、Nasu データ型にも手を加えずに実現する方法はないですよね。

417 ：
それならデフォルトの実装は別の場所に書いた方がよさそう
手を加えてはならない場所に書くのはリスクが大きすぎる

418 ：
>>417
すいません、そういう意味ではなくて、
Umai 型クラスに相当するものがライブラリで提供されていて、
こちらでは手が加えられないのです。

もし方法がないなら、ライブラリのソースはあるので、
アドバイスを参考に改変しようかと思います。

419 ：
質問。infix pattern synonym の結合性って弄れないの？

420 ：
>>397
なんで君はいつも上目線なんだ

421 ：
謙虚月間です。皆さん九月は、他人の落ち度より自分の異常を優先して疑い、相手を尊重しましょう

422 ：
GHC が出力する実行バイナリがえらいデカいんやけど、これどうにかならんの？

423 ：
atomの端末から起動しないとghc-mod使えない不具合辛い

424 ：
>>422


対策

１．諦める

２．共有ライブラリを使う

from : ttp://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/using-shared-libs.html

＞4.13.1. Building programs that use shared libraries
＞
＞To build a simple program and have it use shared libraries for the runtime system and the base libraries use the -dynamic flag:
＞
＞ghc --make -dynamic Main.hs

425 ：
中置関数の部分適用について理解できないところがあるので、質問です。

まず下記の関数を定義しました。
siplus :: String ->Int -> Int
siplus str num = read(str) + num

普通に使うと次のように動作します。
> siplus "1" 2
> 3

最初のStringを部分適用したものの型を調べると、こうなります。
> :t siplus "1"
> siplus "1" :: Int -> Int

ここで最初のStringではなく、2つ目のIntを部分適用したいと思った時、
例えばこんな書き方はできません。
> :t siplus _ 2
> エラー

しかしこれを中置関数として扱った場合、2つ目のIntのみを部分適用した
関数を作ることができてしまいます。
> :t (`siplus` 2)
> (`siplus` 2) :: String -> Int

これは一体どういうことなのでしょうか？
String -> Int -> Intの関数への部分適用でString -> Intの関数を作り出せてしまうのは、
カリー化の考え方から見て矛盾があると思います。
どういう理屈でこれは成り立っているのでしょうか？

426 ：
中置演算子の部分適用は、適用する引数をどちらからも選べる特殊な機能で、
普通の部分適用と区別して「セクション」と呼ばれている。
いずれにせよ、実体は (¥str -> siplus str 2) のようなラムダ式作るのと変わらん。

427 ：
>>426
なるほど、つまり中置記法の右側に値を置いたものは、
カリー化とは無関係で単にラムダの糖衣構文ってことなんですね。

428 ：
まあ、(flip siplus) 2 の糖衣だと思うんでもいいと思うけどな。

429 ：
二項演算子は後置演算子とみつけたり

430 ：
Haskellは二項演算子を愛し過ぎてる
1+が綺麗に書けるけど、そんなにこだわる機能じゃないと思う
むしろ二項演算子無くして前置に統一したほうがよく無いかな？

431 ：
>>430

a * x + b

なんてのをまともに書けない言語はアカンでしょ

432 ：
>>431
＞a * x + b
つ (+ (* a x) b)

433 ：
>>432
そういうのが好きならLisp使えばいいじゃん。。。

434 ：
>>429
それは嘘です
後置演算子の直後の二項演算子はセーフ x! * y
二項演算子の直後の二項演算子はアウト x + * y

>>421
「本当か嘘か」を優先して考え「謙虚か傲慢か」などという雑念は捨てました

435 ：
煽ってるのをオマエラじゃんｗ

436 ：
>>434
うーん、その例と「二項演算子は結合強度最弱の単項後置演算子とみなせる」
がどう矛盾するのかよくわからないです。

437 ：
>>436
結合強度を変えてもsyntax errorを覆すことはできません

438 ：
>>437

x + * y　

によってあなたが何を例示したのか正直まったく理解できないのです。


元ネタは外国のブログ記事だった気がするけど見つからないので自己流解説すると、
なんか二項演算子（算術に限らない。ここでは (#) とする。）があって、そのシグネチャは

(#) :: X -> Y -> Z

だとしますね。そうすると x : X に対して作られるセクション x # は Y -> Z という型を持つわけですね。
そうすると、結局「あたかも」

postfix #
(#) :: X -> (Y->Z)

と定義されていた「かのごとく」見れますねという話をしてるつもりです。
（Haskellでは自前の後置演算子は作れないので上のは嘘コードですが）。

439 ：
カリー化ですべての関数が単項演算になるはずだったのですね
ところが構文解析を見ると二項演算が存在する証拠が出てきたので理解できないと

440 ：
概念の話をしてるのに実装の話をされても困りますね
ちょっと上のレスに出てるように二項演算子だと
# x
っていうように後ろの引数だけ適用もできることになってるからこれは後置単項演算子とは別物だよね

441 ：
素直に実装の話をされて困ることなんてないよ
実装の話じゃないから困らないよな？と言われて困ることはある
{-# LANGUAGE #-} とか

442 ：
二項演算子は単項後置演算子みなせるよね
に対して
構文解析では二項演算子が分けてあるんだよ
と言われても　はあそうですか　としかならないがな
なぜ構文解析上分けてあるかの理由まで示されると納得しそうだが

443 ：
>>438
Applicativeスタイルを使うときに出てくる「途中の式」はそうやって考えるとわかりやすいね。

444 ：
>単項後置演算子
今日はじめて知ったんだが、実は出来るぜ。
{-# LANGUAGE PostfixOperators #-}

data Currency = Yen Int deriving Show

(￥) :: Int -> Currency
(￥) = Yen

main = print (105 ￥)
{--
> :main
Yen 105
--}

445 ：
>>442
それが後置演算子だとすると
(2 +)と(+ 2) で(+)が別の演算子だということになってしまう。
数式の構文解析で(-)が単項演算子と二項演算子の両方に使われるせいで
BNFが無駄に複雑化するの知ってるでしょ？
同じことが(-)だけでなく二項演算子一般について大規模に生じてイヤなわけ。

446 ：
>>442
構文は理由より人気を優先した方がいい
どんな理由を示してもおそらくライバルの1.05倍くらいのメリットしか出てこない
一方、理屈抜きで人気投票すれば1000倍とか差がつく可能性がある

447 ：
「モナドは値を箱の中に入れるので外からは見えない、だから安全だ」
っていう話をよく聞くけど、納得いかない。

例えばMaybeモナドの中に値を入れても、fromJustで簡単に取り出せるし、
入れる時もJustで簡単に入るじゃん。

こんなユルユルの箱に入れたところで何が安全なの？

448 ：
入れたままで扱えるから便利なんだよ。
(IO は別)

449 ：
>>447
箱の喩えでいうなら、その箱から中身を取り出したままでいられる仕組みは
モナドの範疇ではないよ。

Monad 型クラスのインスタンスであるその型に付随された
モナドとは何の関係もない機能だ。

450 ：
>>447
>「モナドは値を箱の中に入れるので外からは見えない、だから安全だ」
>っていう話をよく聞くけど、

そんな話を聞いた覚えがないのだが……

451 ：
自分も聞いたことないな
安全だって言ってる文献を教えて欲しい

452 ：
>>449
でも取り出す機能を簡単に付けられるのであれば、箱としての堅牢性は無いに等しいじゃん。
一回入れたらもう出せない！ってのならわかるけど。

>>450-451
IOモナドなんかそんな風に言われるじゃん。
でもIOモナドに入れた値だってfromJustで取り出せる。

453 ：
>>452
>IOモナドなんかそんな風に言われるじゃん。
>でもIOモナドに入れた値だってfromJustで取り出せる。

？？？
まず前半、聞いたことがない。そういうこと言ってる実例挙げられる？
後半、意味がわからない。

454 ：
もしかしてMaybeなどのモナドを使うことで付く分岐による安全性を
「モナドは外からは見えないから安全」という話に思い込んだんじゃ？

455 ：
出直してきます

456 ：
どうやら根本から勘違いしてただけだったか・・・

457 ：
まあ気持ちはわかるわ。俺もはじめの頃は、Maybeモナドは腑に落ちんかった。
パターンマッチでいつでも値取り出せるじゃん。って。

モナドはデストラクタを隠蔽するのが肝なんだよな。
だからparsecとかIOとかをみて、初めてありがたみがわかった。

458 ：
>>457
>モナドはデストラクタを隠蔽するのが肝なんだよな。

データ構築子のこと？
runXX の形でモナドの実体を取り出せるモナドは珍しくないし、
IOモナドもそこは変わらないよ？
IO aの実体をWorld -> (a, World)として取り出してもありがたくないだけで

>だからparsecとかIOとかをみて、初めてありがたみがわかった。

うーん、その感覚はさっぱり
隠蔽云々とは関係なくリストモナドだろうがIOモナドだろうがありがたいけどなあ

459 ：
Maybeモナドの場合なら、return (つまりJust)に突っ込んで得られない
Maybe a の値、つまりNothingによって集合aを拡大していることになるわけで、
この拡大された集合a+上の計算を、元々のaの計算から自然に与えることが
できるようなそういう拡大の仕方とその構造のことをモナドというわけ。
Maybeほどストレートではないけど、他のモナドも基本は一緒。

これはデータ構築子が公開されててパターンマッチできるかどうか、とか
或いはそれと等価な関数が公開されてるかどうか、とかとは関係のない話。

460 ：
関数型言語ってのは
要するに
OOPでクラス関数で主に記述するってことと同じでしょ？
メンバ関数・変数をなるべく使わずに

何がすごいのかさっぱりわからない

461 ：
あなたがそう思うならそれでいいんじゃないの
誰が関数型言語使えと頼むじゃなし使わないと死ぬわけでもなし

462 ：
荒くれ者のC++erがHaskellやると
バグめっちゃ減るんすよｗｗｗｗ
その代わりコンパイル通りににくくなるんで慣れるまでめっちゃ苛々するんすけど
実行時にヘマするくらいならコンパイル失敗した方がマシだってことを学ぶんすよｗｗｗ

もうC++は体力続かない
三ヶ月前のコードとか読みたくないでしょ
歳取ったらHaskellが良いって解りますよ
Haskellなら三ヶ月前のコード、また読んでみてもいいかなって、それはとっても嬉しいなって

463 ：
>> 457
なんていうか上手く言えないんだけど、例えば、
データ構築子がreturnとbindしか無くて、一方分解子、runの類いがたくさん提供されてるデータを考えてくれ。
どうだいそれって滅茶苦茶役に立たないだろ？

464 ：
>>463
>データ構築子がreturnとbindしか無くて、一方分解子、runの類いがたくさん提供されてるデータを考えてくれ。

なにが言いたいのか理解できないが、いずれにせよreturn とbind があれば
他のはそれから定義できるんだからなにも問題ない
runXXの類がたくさん提供されてる、というのもよくわからんが、
それで有用性が損なわれるとはちっとも思えない

465 ：
あと、データ構築子とreturn/bindは違うものなんでそこのところ宜しく
もし、returnでしか当該データ型の値が作れないならrunXX云々以前にそりゃ役には立たない
m a 型の計算が実質的に a 型の計算そのものに崩壊するからな

466 ：
そうそう。そんな感じ。
だからモナドにするならreturn以外にカスタムコンストラクタをたくさん提供するべき。
逆にコモナドなら、コンストラクタは少なくていい。けど、デストラクタはextractだけじゃだめ。

(俺は_ -> Hoge のヤツをHogeのコンストラクタ、Hoge -> _ をデストラクタって呼んでる。異端かもしれんが)

467 ：
>>466
>だからモナドにするならreturn以外にカスタムコンストラクタをたくさん提供するべき。

いやまったくもって意味不明なんだけど
普通に型定義のデータ構築子がある以上、それを使えばいいんだし、
それらのデータ構築子から構成できないようなものもあり得ない

しかもなんで「べき」なわけ？
Maybe型が役に立たなかったことなんかないだろう
あと、勝手な自分用語振り回されても理解できない（するきになれない）

468 ：
オレオレ用語で分かりにくくて、すまんかった。共通の言葉遣いは大事だよね。データ構築子はdata Hoge a = Hoge ... の奴でいいよね？

ところでさ、ライブラリを作っていて、データの内部表現を公開したくない時があるじゃない？
あとでチューニングしたいときとか。そういう時にデータがモナドなら主に ... -> Hoge a を、コモナドなら Hoge a -> ... を提供する。
return / extract に加えて。

理由は、えー…　逆だと使いづらいから。
(たとえばMaybeなら、fromJustってあんまり使わないでしょ？)

469 ：
なんか変な主張と独自用語のレスが続くね…
荒らしかな

470 ：
あ゛ーそのつもりはないんだけど…　スレ汚してスマンね。

理由が弱いので、もう少し考えると、
例えば、doの途中でrunして値を取り出して、その値で分岐して別のモナディックアクションにつなぐのは、計算量が無駄。
それを避けるためにモナド（手続きの抽象）がある、と俺は理解している。

471 ：
データ構築子を公開したくない、というのはわかる
パターンマッチで実体取り出されたくないとき
（実体に依存した利用をされたくないとき）、というのはあるからな

だが、「return に加えて」は意味不明だ

作ろうとするモナドが恒等モナド以上の何かであろうとする限り、
returnでは作れないようなモナド値を構成する方法を提供しなければならない
これは内部表現の隠蔽云々とは何の関係もない
そうしないと使いづらいからではなく、そうしないと恒等モナド以上の
機能を有し得ないから、だ

fromJustを使わない（データ構築子 Just のパターンマッチも使わない）、
というなら、コード全体がモナディックになってしまう
（もちろんnon-monadicなコードは恒等モナドによってまったく等価な
　monadicなコードとして書けるが、普通はそんなことはしない）

はっきりいって、何が言いたいのか本当にわからない……

472 ：
>>470
こっちもすまん、>>468見る前に書き込んだから

473 ：
>>470
>例えば、doの途中でrunして値を取り出して、その値で分岐して別のモナディックアクションにつなぐのは、計算量が無駄。
>それを避けるためにモナド（手続きの抽象）がある、と俺は理解している。

計算量（？）はほぼ変わらず、コードが見やすくなるだけだ
むしろ、コードの煩雑さを苦にしないならば
最初からモナドの実体を直接操作する方が余計な関数呼び出しと
そこでいう意味の「計算量」は減る

-- オーダー以外の意味で「計算量」を使われるのも違和感があるが

474 ：
>>470
>例えば、doの途中でrunして値を取り出して、その値で分岐して
>別のモナディックアクションにつなぐのは、計算量が無駄。
>それを避けるためにモナド（手続きの抽象）がある、と俺は理解している。
別のモナディックアクションにつなぐのが計算量の無駄というのが、
わからんのだけど
よく言われるように、用途の文脈を明確にしたい場合に使ってる事が多いし

475 ：
>>474
Reader モナドで、逐一runReaderを使い r->a 型関数に戻すのが手間だ、
くらいの意味だろう。そりゃモナドの中で計算を合成できる方がいいしが、
指摘の通り、手間や関数適用コストの僅かな定数的増大よりは、文脈を切らずに
連続させることの利益が目的でdo 記法を使うはずだ、と私も思う。

476 ：
読み直したけど主張が纏まってないのと、レスが補強になってない
少し落ち着いて

>>475
それで意味がわかりましたが、自分も正に>>473と同じ事を思いました
モナド無くていいじゃん、と

477 ：
>>469
「計算は論理の物質化である」

478 ：
>>460
OOPがわかってもC++がさっぱりわからないのと同じ

C++がわかればstaticメンバが何の役に立つのかわかる

479 ：
なんでMonadはApplicativeのインスタンスじゃないの？

480 ：
いまはApplicativeだよ

481 ：
Monadにはできない（或いは非効率）だけど、Functorよりは強い構造を
持ってる有用なデータ型が多いことがHaskellでのプログラミングの進展に
よって後になってから判明したから

後付で用意されたんで、元からあるMonadの定義には手を付けなかった

482 ：
>>447
藁人形を殴るのやめろ

483 ：
RTS上のデータ域に直接的にアクセスできるらしいな
unboxedが最速かと思ったがもう一つ隠し玉があるのか

484 ：
<*> <*>

485 ：
FFIのためにCに揃えてメモリ剥き出しでデータ配置してる場合のことでしょ

486 ：
StateはStateT Identityとして定義されてるのに、なぜMaybeはMaybeTを使って定義されていないのでしょう？

487 ：
>>486
Stateは、状態をあとづけでつける場合に使われるからモナド変換子なのかなぁ。。。？

488 ：
MaybeはEitherを使って定義されなかったという前例がある

489 ：
そらそうだろ、という気もするのだが、

Maybe a = Either () a
Just x = Right x
Nothing = Left ()

みたいな話？

490 ：
unitはidentityに似てるからいいんじゃね

491 ：
よく頭のおかしいバカが「スケーラビリティ」とほざくが
大抵それは「前例のない規模で前例を踏襲する」ことだ

492 ：
>>491
「前例のある規模で前例を踏襲することができない」よりはいいんじゃね

493 ：
そんなになんでも簡単にスケールしてもらってはエンジニアがご飯が食べれなくなるので困る
軽トラをCADで拡大して4tトラックになるんだったら仕事なくなる
実際には現実世界の各種係数があって、そっちはスケールしないので無理なわけだが
CAD内でデータを拡大しても、重力やら鉄の剛性やら法律やらetcの
現実世界まで一緒に拡大されるわけではないからな、不整合が起こる

494 ：
不整合そのものを認識できないバカは少ない
拡大できない現実が悪いか、拡大できると言う虚言癖が悪いかを判断できないバカが多い

495 ：
えー

496 ：
○○されると仕事がなくなるというのは現実的にあるとしても、
だから○○は止めろとグチを言って前へ進まないのはただの甘えです。


ところで、GCがゴミを回収するタイミングを制御する方法はあるでしょうか。
たとえば、ある関数を評価しようとしないとGCが動かないようにできる、みたいな。

ステージクリア型のゲームを作っていると、ステージプレイ中はGCを止めて、
クリアしたりミスしたタイミングで一気にゴミ回収したいことってありませんか？
他にも、3DCGツールを作っていて、レンダリング中ではなく完了後にゴミを回収したい、とか。

497 ：
>>496
GC止めるのはできないはず
System.Mem以下の関数で明示的に起動することはできる

RTSオプションの -I フラグ辺りを見るといいのかもしれない

498 ：
>>496
あるある
入力待ちに入る瞬間に軽くGCしといて欲しいとか考える

499 ：
>>497
ユーザーガイドを見てみました。

なるほど、そのオプションでアイドルになってから
GCが自動起動するまでの時間を指定できるのですね。
この値を非現実的な大きな値にすれば、結果的にperformGC関数で
意図したタイミングでGCを起動できることにならないか、と。

試してみます。
ありがとうございました。

500 ：
近頃ホットなライブラリは？

501 ：
tanakahってネトウヨなのか

502 ：
そんなことはない。彼は六年前に衆議院総選挙で民主党に投票した過去がある。よほど懲りたとみえる

503 ：
民主に騙されてアホウヨになってしまったんだね

504 ：
どんな嘘に騙されたのか知らんが
騙されたというならもっとこう、嘘を絶対に許さない的な理念があるべきじゃないのか
人を分類して煽り合うだけでは嘘は無くならないだろう

505 ：
Haskellでこの世から嘘をなくせるのか？
プログラミングの話をしてくれ

506 ：
嘘を見抜くソフトを開発すればいい

うまい嘘をつくためにも使えちゃうか

507 ：
tanakahがおかしいのは昔からだ

508 ：
任意の要素数の集合（順序など特別な構造はない）に対する置換が与えられた時、
その置換と同等な巡回置換のリストを得る関数 cperms :: ([a], [a]) -> [[a]] を作りたいのですが、泥臭くなってしまいます。

例えば、集合 {x, y, z, w} に対して置換 {x, y, z, w}-->{x, w, y, z} があるとします。
（本来ならば置換は上下に並べて表記したいところですが、これで勘弁してください）。
この置換は2つの巡回置換に分けられ、ひとつは x を x に置換するの巡回置換 [x]、
もうひとつは y を w に、 w を z に、z を y に置換する巡回置換 [y, w, z] です。
なので、cperms ([x, y, z, w], [x, w, y, z]) = [[x], [y, w, z]] となります。

私の考え方は下記のような単純なものです。

引数のタプルの第1要素を置換前リスト、第2要素を置換後リストとします。
置換前リストの先頭要素から次のように順にスキャンします。

0. 置換前リストの先頭要素を a1 とする。
1. 置換前リストの a1 と同じ位置にある置換後リストの要素を a2 とする。
2. 置換前リストの a2 と同じ位置にある置換後リストの要素を a3 とする。
・・・
n. 置換前リストの an と同じ位置にある置換後リストの要素を a[n+1] とする。

a1 == a[n+1] ならば [a1, a2, ..., an] を巡回置換のリストとする。
置換前・置換後の各リストから辿った要素を取り除いた新たな2つのリストを作りタプルにする。
そのタプルに対して再び cperms 関数を適用し、結果を先ほど作った巡回置換のリストと concat する。

泥臭く感じるのは2点。
ひとつは、a1 を覚えておいたり、構築中の巡回置換リストを保存するなどのために
いくつものアキュムレータを付けた再帰関数を作っている事。
もうひとつは、置換前リストや置換後リストから要素を探すときにいちいち先頭から順に探している事。

宣言的とはとても言えないコードになってしまうなですが、良い方法はないでしょうか。

509 ：
Hideyuki Tanaka ‏@tanakh
憲法守れ！検閲反対！憲法守れ！検閲反対！

検閲する側の人間を支持していてこれか
脳みそ入ってないでしょ

510 ：
ここはHaskellのプログラミングについて語るスレです。プログラマ個人について語るスレではありません

511 ：
とりあえず連想リストの検索と削除を同時にするけどアキュムレータを使わない方法

f :: Eq a => a -> [(a,b)] -> Maybe (b, [(a,b)])
f _ [] = Nothing
f x (y:ys) = if x == fst y then Just (snd y, ys) else fmap(id***(y:))(f x ys)
-- (***) a b (c, d) = (a c, b d)

512 ：
めっちゃ素朴で雑談的な疑問: 長い函数合成書く時に、ついAしてBして…っていうふうに考えてしまって
右から順に書いてしまう (極端には filter even 書いてからその左に length . って書き加える）
んですが、これは慣れてもそういうもの？
それともそのうち「最終的に欲しいのはこれだから」みたいに左から書くようになる？

513 ：
自分も同じ疑問感じるわ
今はタイプするのが楽だから左から書いてるけど
一度右からの流れを思い浮かべてから逆順をたどるように書くみたいにしかできてない
左から考えられるようになるものなのか？そもそもなるべきなのか？どうなんだろう

514 ：
>>512
右から左に思考の順番通り書くので何の問題もない。
カーソルの戻りがイヤで左から右にしたいなら

(>>>) ：関数合成演算子( . )の引数が逆になった演算子（Control.Category）

とか

(&)　：関数適用演算子($)の引数が逆になった演算子（Data.Function）

とかを使えばいいよ。

簡単な短いものはボトムアップで考えて関数合成の連鎖で直接書いてしまうし、
複雑な関数は「欲しいのはこれだから」みたいにトップダウンで定義を考えて
（where節がどんどん入れ子になる感じで）書いていく。

515 ：
左に書き加えるとかはHaskellではなくVimの話題のような気がする

516 ：
田中さん完全にネトウヨなんだな

517 ：
>>511
レスが遅くなってすいません。

その関数 f の意図が今一分からないのですが、
例えば f 2 [(2, 4), (3, 2), (1, 1), (4, 3)] とやってみると結果は
Just (4, [(3, 2), (1, 1), (4, 4)]) となるのですが、
これは意図通りの結果でしょうか？

518 ：
>>517

>>511
間違えました。

> 例えば f 2 [(2, 4), (3, 2), (1, 1), (4, 3)] とやってみると結果は
> Just (4, [(3, 2), (1, 1), (4, 4)]) となるのですが、

結果は Just (4, [(3, 2), (1, 1), (4, 3)]) になります。

519 ：
>>518
[(2, 4), (3, 2), (1, 1), (4, 3)]の先頭の(2, 4)はfを使わなくても処理できるので
そこでfを使う意図はありません
次の段階でf 4 [(3, 2), (1, 1), (4, 3)]のような使い方を意図しています

520 ：
脳みそ入ってるか入ってないか判らないときはMaybeモナドに包んで処理って習った

521 ：
>>508でやりたいのっていわゆる強連結成分分解じゃないの
ググればしっくりくる解き方があるんじゃないかな

522 ：
宣言的なコードをあきらめればいい

523 ：
シンプルに総当りしてマッチしたものを返せばいい

524 ：
>>519
すいません、やはり意味がよく分かりません。

関数 f の各引数と戻り値の意味を教えていただけないでしょうか。

525 ：
>>521
恥ずかしながら初めて聞いた名称だったので調べてみました。
確かに、置換を有向グラフとみなせば、強連結成分分解で解けますね。
今、そのアルゴリズムの詳細を調べているところです。

ただ、私の問題の方が制限がきついので、実際はもう少し特化した方法がとれると思います。
グラフと見なしたとき、全てのノードについて出る辺と入る辺はちょうど1つずつです。
なので極大もなにも一通りにしか分解できませんし、探索中に戻る必要もありません。


>>523
総当たりというのが具体的にどのような処理を指しているのか分かりませんが、
それは結局 >>508 になるのではありませんか？

526 ：
>>508
多少は手続き的っぽくない感じで定義してみた
計算量のことなんも考えてないので泥臭さでは全く負けてないけどｗ
置換は[0..(n-1)]に対する任意の置換を[Int]で与えるものとする

import Data.List (nub, nubBy, sort, transpose)
cperms :: [Int] -> [[Int]]
cperms ns = nubBy unique . (map nub) . transpose . (take n)
　 $ iterate (map (ns!!)) [0..(n-1)]
　 where n = length ns
　　 unique xs ys = (sort xs) == (sort ys)

-- cperms [0,3,1,2] => [[0], [1,3,2]]

長さnの一般の置換に対して、[0..(n-1)]の各要素をn回、順に置換していって、
軌道に分けて(transpose)、無駄な重複を削除して結果を得る
unique関数では「2つの巡回置換が本質的に等しい」を判定したいんだけど
毎回ソート2回やるより速い方法が絶対あると思う(メモ化するとか)

527 ：
みんなもう買ったか？

文芸誌「新潮」４千部増刷　筒井康隆さんの長編小説掲載
http://www.asahi.com/articles/ASH9K61F1H9KUCVL01X.html

新潮社は１７日、文芸誌「新潮」１０月号（初版８９００部）の４千部の増刷を決めた。
同号には筒井康隆さんの長編小説「モナドの領域」が掲載され、本人がツイッターで「わが最高傑作にして、おそらくは最後の長篇（ちょうへん）」とつぶやくなど話題となっていた。

528 ：
import Data.Graph (buildG,scc)
import Data.Tree (flatten)
cperms (a,b) = map flatten $ scc $ buildG (minimum a,maximum a) $ zip a b

cperms ([1,2,3,4],[1,4,2,3])　-> [[2,4,3],[1]]

529 ：
>>511のつづき

g (x, ys) = maybe ([], ys) (((x:) *** id) . g) (f x ys)
h [] = []
h ((x,x'):ys) = uncurry (:) . ((x:) *** h) . g $ (x', ys)
cperms (xs, xs') = h (zip xs xs')

530 ：
>>526
グラフで言えば、n個の各ノードから1歩ずつ辿ってスタート地点に戻りn個の輪っかを作る。
最後に本質的に同じ輪っかを1つとみなして輪っかを集める感じですか。
分かりやすいですし、発想が面白いですね。

2つの巡回置換が本質的に等しいことを判定する部分（unique）は、
ys ++ ys の中に xs にマッチする部分があるかどうかを、
xs を先頭から1要素ずつずらしながら調べれば O(n) の計算量でいけますね。

しかしそれ以前に、O(n^2) の nub を n+1 回行っているので、
要素数が増えてくると焼け石に水かもしれませんが・・・


>>528
調べてみたのですが、強連結成分分解の計算量は O(|V| + |E|) なんですね。
（実際にこのライブラリの実装がそうなっているかは未調査のため分かりませんが）

巡回置換への分解が強連結成分分解の特殊バージョンだと分かっていれば、
このコードはとてもシンプルで、何をやっているかも一目で分かるので良いと思います。


ただ、>>526 も >>528 も、集合が整数の連続した列と一対一に対応できること前提なのですね。
まぁ、集合をリストで表現できる時点で要素に番号付けは可能なので、
テーブルか何かでも作っておけば、理論上は整数の巡回置換のリストから元の要素へ戻せますが、
手間と処理時間は少しだけ増えそうです。

531 ：
>>529
h (zip xs xs') の簡約をノートに書いていって、処理がやっと理解できました。

結果的に、ひとつの巡回置換の先頭 2 要素のうちの最初のひとつを h で、
次の要素を g で取り出しているのがやや気になります。

あと、1 要素から成る巡回置換を作ることになる場合、
(x, x) :: [...] というパターンから処理を始めますが、
最初の x を h で取り出して、次の x を g で取り出してから、
残りのリスト [...] から g で取り出した x があるかを調べますよね。
そこも少し気になるところです（そこには無いと分かっているから）。

以上の部分をもう少しシンプルにできそうな気がするので考えてみます。


みなさん、いろいろな方法でアドバイスくださり、ありがとうございました。
参考にします。

532 ：
>>526
冷静に考えてみれば、いろいろ最適化できそうですね。

たとえば、unique は >>530 よりもっとシンプルになります。
巡回置換リストは、元の集合（を表したリスト）を類別します。
つまり、巡回置換リストのある要素リスト内の任意の要素は、
巡回置換リストの他の要素リスト内には存在しません。
よって、unique xs ys は elem (head xs) ys と同値です。

map nub では、nub は要らないです。
この部分の nub で要素が消えるのは、要素が繰り返し循環している部分です。
たとえば、nub [2, 3, 2, 3] = [2, 3] という感じに。
これ以外にここの nub で要素が消えるパターンはありません。
なので nub xs は、ここに限れば takeWhile (/= head xs) xs と同値です。

これで、O(n^3) から O(n^2) になりました。
せっかくなので、ひとつ残った nub をどうにかしたいところですね・・・

533 ：
>>532
と思ったのですが、iterate (map (ns !!)) [0 .. n-1] の部分で O(n^3) でしたね。

連投失礼しました。

534 ：
>>516
(´･_･`)自分が思ったことを素直に表明してるだけで、特段ネトウヨに加担してるつもりはないと思うよ

535 ：
デマによる誹謗中傷
レッテル張り
相手を馬鹿にした言動
完全に田中はネトウヨでしょ

536 ：
レッテル貼りは一回だけならほとんど問題ない
同じことを何回も言うのはそれがレッテルであろうがなかろうが問題がある
レッテルを貼ることが問題だというのは多分嘘だろう
本当の問題は連呼すること

537 ：
田中はもう何年もずっとだろ

538 ：
(´･_･`)他人の意見を鵜呑みにするより自分で考えてるだけでネトウヨというレッテルを貼られるなんて辛すぎでしょ。

539 ：
>>538
>他人の意見を鵜呑みにするより自分で考えてるだけでネトウヨ

いや、まさに他人の意見を鵜呑みにしてるだろw

540 ：
関プロ実入の194Pの図4.1の一番右側にあるtarai、間違ってませんかね？

541 ：
毛の壁に触ったがために田中さんも災難だなぁ

542 ：
taraiは2ヴァージョンある

543 ：
>>512
fmapとかnewtypeコンストラクタとかは最終的に欲しいものというよりむしろ
欲しくないものを検出するために書いてるだけだから
慣れないと感じるのは順序とは別の問題かもしれない
欲しいものの記述のみに集中できる言語があればいいんじゃないか

544 ：
>fmapとかnewtypeコンストラクタとかは最終的に欲しいものというよりむしろ
>欲しくないものを検出するために書いてるだけだから

545 ：
(´･_･`)民主党政権時代より今の自民の政治がマシだと思っただけでネトウヨ扱いなんですかねえ

546 ：
すみません。
反復関数系でフラクタル図形等に応用される
サンプルがあったので研究してみたのですが

値構築子の関数に固有の法則を持たせて
値構築子のタプルの値を使って演算する様ですが
構築子の値に関数をCONSで繋げるという手法が理解できず
何か参考になる文献を知っていましたら教えて下さい。

data Decision = (Int, Double) :-> DecFun
type DecFun = Int -> [Int]

d1 :: Decision
d1 = (1, 0.25) :-> \f -> []
dList = [d1,d2.....]（このリストを処理する関数内でDecFunを匿名関数にして処理）

547 ：
田中さん実質実効為替レートとか知らなさそう

548 ：
毛の壁本当うぜーな
関係ない話は自分のブログでやってろボケ

549 ：
実名と自然言語がうぜーから無名関数プログラミング

550 ：
>>546
元のサンプルplz

551 ：
思っているだけじゃなくてレッテル貼り、中傷、デマ
色々やってんじゃん

552 ：
Haskellの話して。それがHaskellとどう関係あるの？

553 ：
マ板でtanakhスレでも立ててそっちでやれ

554 ：
>>550
すみません。反復関数系のソースは以下です。
import System.Random
type Length = Rational
data ABCTerm = A | B | C
data DP = DP {len :: Length, state :: State, key :: Int}
data State = S1 | S2 | S3 | S4
data Term a b = NnT (a,b) | Mod String (Sentence a b) (Sentence a b) | Par String
type Sentence a b = [Term a b]
type Prb = Double
data Direction a b = (a, Prb) :-> DirFunc a b
type DirFunc a b = b -> Sentence a b
--grammar
abcDir :: [Direction ABCTerm DP]
abcDir = [
(A, 0.5) :-> \p -> [NnT (A, p)],
(A, 0.5) :-> \p -> [NnT (A, h p), NnT (A, h p)],
(B, 0.5) :-> \p -> [NnT (B, p)],
(B, 0.5) :-> \p -> [NnT (B, h p), NnT (B, h p)],
(C, 0.5) :-> \p -> [NnT (C, p)],
(C, 0.5) :-> \p -> [NnT (C, h p), NnT (C, h p)]
]
rFact x p = p{len = len p * x}
h = rFact 0.5
q = rFact 0.25

applyDir :: (Eq a) => [Direction a b] -> StdGen -> (a,b) -> (StdGen, Sentence a b)
applyDir dirs g (c,d) =
let ds = filter (\((c',p) :-> df) -> c'==c) dirs
(p,g') = randomR (0.0::Double, 1.0) g
in (g, [NnT (c,d)])

555 ：
一人二人見かけてそれを全体として語っちゃうような感じ

556 ：
(非終端記号, 確率) :-> (意味値 -> [終端記号または非終端記号])
こうですか？わかりません

557 ：
右寄りのマスコミまで左寄りに見える極右脳
もう産経くらいしか見れるものがない

558 ：
なんでソースの全体示さないで、一部分だけ貼り付けてんの？

559 ：
確率的構文ツリー生成なんかな

560 ：
宗教上の理由でオープンソースを認めたくない人もいるかもしれない

561 ：
エントロピーの計算って p log p とか p log p/q とかいっぱい足し合わせるからpやqの大きさに依ってあり得ない数値になることがあります
合計値が非負であることが数学的に証明済みの計算結果が負になることもあります
困りました

562 ：
>>561
Haskell関係ないよね。どっちかというと数値計算の話題だと思う。

563 ：
>>562
Haskellにそういの巧いことやってくれるライブラリありませんか？

564 ：
>>556 >>558 >>559
どうもありがとうございます。
もっとハスケル学習してから解読してみます。
パタンマッチ用に記号を鰓が出ない範囲で構成しただけなのかもしれません。

565 ：
>>563
Haskell万能だと思いすぎじゃね？

566 ：
ぼく「Haskellに夢を見過ぎた」

567 ：
Haskellやりすぎるとネトウヨになる
彼女もできない

568 ：
>>563
君がそのライブラリを作ればいい。（ﾄﾞﾔｯ）

569 ：
>>563
浮動小数点使わずに計算を進めて最後の最後に浮動小数点にすればいい。
data Logarithm = Log Ratio
みたいな型と、Logarithmに関する計算法則を関数で定義してやればいいだけ。
後はインターフェースを使いやすくしてライブラリとして公開だ！

570 ：
>>569
logsumexp みたいな問題ってそれだけで解決するんだろうか（疑問）

571 ：
今 yesod-1.4.2 パッケージがインストールされている状態です。

ここに、persistent-sqlite-2.2 をインストールしようしてもできません。
以下が cabal install persistent-sqlite コマンドの出力です。

Resolving dependencies...
In order, the following would be installed:
persistent-2.2 (reinstall) changes: aeson-0.9.0.1 -> 0.10.0.0
persistent-sqlite-2.2 (new package)
cabal: The following packages are likely to be broken by the reinstalls:
yesod-persistent-1.4.0.3
yesod-form-1.4.4.1
yesod-auth-1.4.6.1
yesod-1.4.2
persistent-template-2.1.3.4
Use --force-reinstalls if you want to install anyway.

試しに cabal install --force-reinstalls persistent-sqlite をしてみましたが、
警告通り yesod 関係のパッケージが壊れ、Yesod モジュールが import できなくなりました。
しかたがないので、今は yesod を --force-reinstalls して（表面上は）元の状態に戻しています。

どのようにすれば、yesod と persistent-sqlite が両立できるでしょうか。

572 ：
stack new、もう少し便利になるといいな。
ライセンスファイルまで作ってくれるのはいいけど、テンプレートいじらないとBSD固定だし。

573 ：
テンプレートを一度弄るだけで済むなら十分便利だと思うが……

574 ：
>>571 ですが、今の状態のままだと解決策は見あたらないので、
一度全て綺麗さっぱりとアンインストールして stack を入れてみたところ、
yesod も persistent-sqlite も問題なくインストールできました。

しかし、今度はライブラリ ドキュメント関係で問題が発生しました。

まず ghc-7.10.2 をインストールし、それから stack（ArchLinux なので haskell-stack）をインストールしました。
stack を使って ghc をインストールしても良かったのですが、今回はこの順でやりました。

それから、stack haddock コマンドでライブラリ ドキュメントをインストールすると、
~/.stack/snapshots/x76_64-linux/lts-3.7/7.10.2/doc/index.html
からドキュメントが見られるのですが、stack で入れたライブラリのドキュメントしか一覧にありません。

初めに ghc をインストールした時に付随していたライブラリ、
例えば Data.List や System.IO などのモジュールのドキュメントが同じ所には見当たりません。

cabal install --enable-documentation コマンドでインストールした時は、
上記のモジュールも、新しく入れたモジュールも、全てのモジュールが、
ライブラリ ドキュメントのトップページに載っていました。

今の stack ではそのような事はしてくれないのでしょうか。

575 ：
stackでghc入れないからそうなる

576 ：
>>575
今の状態からはもう直せないのでしょうか。

577 ：
自分でいれたghcをpathから外して、stack setup

578 ：
すればstackからghcいれられるけど、望む結果になるかはわからん。

579 ：
main = do
[x,y] <- span (\i -> i < 3) [1 2 3 4 5]
print y

みたいに、spanの結果を束縛したいんだけど、型が合わない。
doの中で、モナドじゃない普通の関数の戻り値を束縛する方法を教えて下さい。
<$>とか<*>で頑張ればできるんでしょうか？

580 ：
>>579
letを使えばよい
span :: (a -> Bool) -> [a] -> ([a], [a]) に注意

main = do
let (x, y) = span (\i -> i < 3) [1, 2, 3, 4, 5]
print y

581 ：
あとwhere、インデントは適当にあわせくれ

main = do
print y
where
(x, y) = span (\i -> i < 3) [1..5]

582 ：
プログラマーの朝は早い。

583 ：
> 578
> 579
そうか、無理にIO ([a],[a])にしようとしないでletを使えばよかったのか・・・。

早朝から回答ありがとうございました。
そして書き込み直後に寝落ちしてごめんなさい。

584 ：
span :: (a -> Bool) -> [a] -> ([a], [a]) に注意
の意味がやっとわかりました。
タプルだったんですね。

main = do
　(x,y) <- (span (\i -> i < 3)) <$> return [1..5]
　print y
でできました。

585 ：
>>584

純粋な値をわざわざ return して <- で束縛（正確には違うけど）するのはよくない。
純粋な値の束縛にはlet を使おう（whereでもいい）。

あと、細かいことだが

¥i -> i < 3

とは書かずに

(< 3)

と書く（中置演算子のセクション記法による部分適用）。

586 ：
何故do中のletにはinが不要なのですか？

587 ：
>>586
do 構文というものはそうだからとしか言いようがない。
Haskell Language Report とかちゃんと見てる？

588 ：
>>586
let ... in を使いたければ do 構文に先行して書く必要がある。
というか、do 構文中に出現するletは do構文に先行するlet ... in の糖衣構文。
なんでそうなってるのかというと、大雑把にはdo構文の解糖を簡単にするため。

# where派より

589 ：
whereは好きじゃない。当方はlet派です。
F#由来の　|>　演算子もいいと思う。

590 ：
F#の |> ってなんだろうと、ググろうとしたけど、記号がググれない。Hoogle的なものはないのか、F#よ。

591 ：
forward pipe operatorだよ

592 ：
tanakhネトウヨオフ会やるでー

593 ：
データ宣言に型クラス制約つけると、そういう制約のかかってないクラスのインスタンスになれません。

{-# LANGUAGE GADTs #-}

data Foo a where {
Foo :: (Integral a) => a -> Foo a
}

-- ↓これはエラーになる！
instance Functor Foo where {
fmap f (Foo x) = Foo (f x)
}

--- ↓これはOK
class IntegralFunctor f where {
ifmap :: (Integral a, Integral b) => (a->b) -> (f a) -> (f b);
}

instance IntegralFunctor Foo where {
ifmap f (Foo x) = Foo (f x)
}

しかし制約のついた型をファンクタやらモナドやらの枠組みで扱いたいことってあるんですけど、
どうにかしてうまいことすりぬける技とかってないですかね。

594 ：
データ宣言に型クラス制約つけるのって非推奨ないし禁止されてなかったっけ

595 ：
それは知ってるんですけど、でもどうしても制約つけたいときあるじゃないですか。
やっぱりなじまないから非推奨扱いなんですかね。

596 ：
もともと人間のミスを探すためにつけた制約だからエラーになったら人間のミスでしょ
人間ではなくシステムの工夫が足りないと言い出したらなんのための制約かわからない

597 ：
代替手段ないの？ どうしてもどうしてもどうしてもそれやりたいの？

598 ：
Windowsでタスクトレイに常駐するタイプのプログラムを作ろうと思ったらgtk2ksでいいの？

599 ：
×gtk2ks
○gtk2hs

600 ：
Michael Barr, Charles Wells, "Category Theory for Computing Science"って誰か読んだことある人いる？
http://www.math.mcgill.ca/triples/Barr-Wells-ctcs.pdf
良い本ならタダだし読みたいんだけど

601 ：
> でもどうしても制約つけたいときあるじゃないですか。

俺も以前はあるような気がしていたし、Haskellの設計者たちもそうだったんだろう
でもよく考えると、ありそうでないんだよなぁ。だから非推奨になった
データ型での制約は無意味、関数で制約をつければ十分

602 ：
パラメータ多相はダックタイピングに肯定的な雰囲気
アドホック多相は否定的な差別意識のようなものを助長する

603 ：
1要素のリストを作るとき、[x]ではなく[] xのような書き方を
したいときがあります。(\x' -> [x']) x とか　return x　は気に入らないです。
この対策となる手短な演算子、関数あります？

604 ：
>>603
return

605 ：
すまぬ、「return x　は気に入らないです」を見落とした

606 ：
>>603
(:[]) x ダメ？

パクッと食べる感じで私は好きですが

607 ：
ていうか感情論じゃなくて客観的な動機を設定してほしい

608 ：
>>606
いいね。採用です。

>>607
(\x' -> [x']) x 見た目に冗長　（でも、ついさっきまで使っていた）
return は、多目的に利用されていて、
特に「IOモナドにいれる」という雰囲気が強い。
単要素リストのために使いたくないです。

609 ：
モナドがIO専用になったら型クラスにする意味がない
演算子はいくらでも作れるから演算子オーバーロードの需要も少ない

610 ：
Applicativeのpureがreturnよりはいい名前だと思うが
この目的なら>>606の書き方が一番クールに見える

611 ：
というか、普通は>>606で書くもんだろ。
非決定性計算の話をしてる時はreturnに決まってるが

612 ：
>>611
そういう事は初めはなかなか気づけないものなんですよ。

慣れた人にとっては普通すぎて何故その発想が出てこないのか不思議なことでも、
本人にとってはその思考回路がまだできていないのだから仕方がない。

でも、大抵そういう事は一度教えれば納得してもらえるから、
クドクドと言わなくてもいいんじゃないでしょうか。


あと、このタイミングで「非決定性計算」という単語を出しても、
return に対して IO モナドと強く結びついた印象を持っている話し相手には、
たぶん何のことだか分からないと思いますよ。
この単語を出すのなら、もう少し噛み砕いて言わないと。

613 ：
リストをリストとして扱うか、モナドとして扱うかの違いですか

614 ：
とりあえず***演算子を使ってみてほしい
Arrowとして扱わないから使わないなんてもったいない

615 ：
(>>>)はともかく(***)の出番なんてそんなあるか？？

616 ：
>>148
ただ賢くなりたいってためにやってるんだと思うよ
筋トレと同じ
目的がなくただプログラミングが詳しくなりたいって人がやってるだけ
だから使えない知識なんだよ

617 ：
目的は人それぞれ
これを知らない人は同調圧力をかけて計画経済をやろうとするので
そういう意味でとても重要な知識だよ

618 ：
>>585
>純粋な値をわざわざ return して <- で束縛（正確には違うけど）するのはよくない。
>純粋な値の束縛にはlet を使おう（whereでもいい）。

これはコンパイルエラーのメッセージが分かりづらくなるから？
それとも遅くなる？

正直Haskellのコードがどういうアセンブラにコンパイルされるのか全然イメージできてない。

619 ：
確かに関数適用分のコストは生ずるが、そういう問題じゃない。
モナドじゃないものをわざわざモナドの中に突っ込むとわかりにくくなる。

620 ：
あ、あとラムダ式のネストが一段深くなるのものコストか。
だが、コストの問題よりは意味の問題。

621 ：
1. モナドから中身を取り出して
2. なんか純粋な計算をして
3. モナドに戻す
これらを疎結合的に書けるのに、純粋な値をreturnでラップして繋げちゃうと
密結合になっちゃってよくない、という話だと理解していた

622 ：
Haskell使ってる時点でC++より遅いのは今更なこと
低バグ、３ヶ月後に読んでうんざりしないコードが書きたくてHaskellを使うのだろう？

623 ：
低バグはいいが、３ヶ月後に読んでうんざりしないは保証しかねるかな
意外と冗長なほうが読みやすいこともある

624 ：
可読性を最大化する言語を決めてから一つの言語で書き続ける
これはウォーターフォール的なやり方

どんな言語が与えられてもまあまあ読めるような書き方を覚えてから言語を適当に選ぶ
というやり方があってもいいと思う

625 ：
３ヶ月後に仕様が変わっていて大幅書き直しを要求されることも…
言語拡張なんていうクソほども信用できないものを使った自業自得だが、これには参ったです

626 ：
目的のためなら互換性を犠牲にする言語と、目的も犠牲もない言語を使い分ける

627 ：
Tカードやマイナンバーの
定期的に番号変えても行動パターンが同じだったら結局同定されてしまう問題って

関手から隠されているはずの対象の性質がわかっちゃうんだよって
圏論的に秘匿性に限界があるってことを指摘できちゃうんじゃないの？
役人馬鹿なの？

628 ：
ヤケクソワロタ

629 ：
>>627
>Tカードやマイナンバーの定期的に番号変えても行動パターンが同じだったら
>結局同定されてしまう問題って

行動パターン？

公開鍵暗号方式で公開鍵を規則的に変えると秘密鍵も同じ規則でかわるの？

630 ：
線形に変化すると特定されるので非線形の暗号アルゴリズムを使用しなければならない

631 ：
最近ホットなライブラリは？

632 ：
wai パッケージのライブラリの使い方について質問です。

Web アプリにおけるストリーム レスポンスがどのように働くのか調べているのですが、
挙動がいまいちよく分かりません。

import Blaze.ByteString.Builder (Builder, fromByteString)
import Control.Concurrent (threadDelay)
import Network.HTTP.Types (status200)
import Network.Wai (Application, responseStream)
import Network.Wai.Handler.Warp (run)

main = run 3000 app

app _ sendResponce = sendResponse $ responseStream
　status200
　[("content-Type", "text/plain")]
　content

content = send frush = do
　send $ fromByteString "A\n"
　flush
　threadDelay 5000000
　send $ fromByteString "B\n"

これを runhaskell で実行して firefox でアクセスしてみました。

私の期待通りなら、ブラウザ画面に A が表示されてから 5 秒後に B が表示されるはずですが、
実際は画面が空白のまま 5 描画が経過した後に A と B が表示されます。

この挙動を見てストリーミングの意味がよく分からなくなったのですが、こういうものですか？

633 ：
>>632
すいません、コードが変で、余計なものもありました。

import Blaze.ByteString.Builder (fromByteString)
import Control.Concurrent (threadDelay)
import Network.HTTP.Types (status200)
import Network.Wai (responseStream)
import Network.Wai.Handler.Warp (run)

main = run 3000 app

app _ sendResponce = sendResponse $ responseStream
　status200
　[("content-Type", "text/plain")]
　content

content send frush = do
　send $ fromByteString "A\n"
　flush
　threadDelay 5000000
　send $ fromByteString "B\n"

これが >>632 のように期待通りになりません。
「期待」の方が間違っているでしょうか？

634 ：
sbvって実行時証命？ コンパイル時証命してくれる機能はないの？

635 ：
Data.ListとData.Array.Repaをimportとするのに困っています
・Repaをfull importする -> map，zipWithが衝突する
・Repaをqualifiedにする -> :. も修飾しろと言われる
両方qualifiedにするしか回避方法がないのでしょうか？

636 ：
import Data.Array.Repa (:.)
import qualified Data.Array.Repa as R

637 ：
或いは

import Data.Array.Repa as R

とRepaをqualifiedせずにいったんフルに開いてしまい、
衝突するmapやzipWith は R.map R.zipWith とする。

638 ：
>>636
同じモジュールを2回importしてもいいんですね

import Data.Array.Repa ((:.)(..))
import qualified Data.Array.Repa as R

これで思っていた感じになりました
ありがとうございました

639 ：
いまだに forall がよく分からん。

f :: T1 a => T2 a
g :: forall a. T1 a => T2 a

関数 f と g の違いって何？

640 ：
ライブラリのサンプルでラムダ式の4重ネストとか見かけるけどそういう書き方って普通なの？
jsのコールバック地獄と何一つ変わらない気がするんだけど

641 ：
>>639
なにも違わない

642 ：
>>641

=> は型制約？
それとも -> という関数型データ構築子の誤記？

data ShowAny = forall a. Show a => SA a

みたいなデータ型を定義すると、この型を使って

heteroList :: [ShowAny]
heteroList = [SA 7, SA "Hello!", SA [1,2,3], SA ()]

みたいなリストを作って、

map show heteroList

メソッドディスパッチ的な多相みたいなことができるようになる。
forall を書くことでデータ型宣言の右側に量化を及ぼせるようになるのが
forall（とExistentialQuantification拡張）の意義だよ。

643 ：
>>641
>>642
誤記じゃないよ。

いや、Wikibooks の「Hskell/存在量化された型」などを見て forall の基本は理解したつもりになっていたけど、
書籍「Developing Web Apps with Haskell and Yesod」に、

type ChatHandler a =
　　forall master. YesodChat master =>
　　HandlerT Chat (HandlerT master IO) a

という型シノニムが載っていて、よく分からなくなった。
（これ、ライブラリが用意した型じゃなく、こういうのを自作しましょうと言ってる）

わざわざ forall を付てるのはどういう意図なんだろ。
>>641 の言うように特に意味はないの？

意図はともかく、この場合の forall の役割も記事の文脈が分からないと何とも言えないかな。

644 ：
>>639
Haskellが今どうなってるか知らないが一般的にトップレベルのforallは省略できる
局所的なforallは省略できない
例 (forall a. (b -> a) -> a) -> b

645 ：
モナドの別名を作りたいです。型におけるnewtypeのように、専用のモナドにして、
既存のモナドと混ざらないようにしたいです。

具体的には、Writerモナドを特化したいと考えています。

WriterT　のエラーログ専用版、 ErrorLogTを作り、
エラーログは関数tellではなく、専用関数tellErrorを使うようにしたいです。

同様に、警告ログ用はWarningLogTとtellWarningとしたいです。

作る方法あります？

646 ：
>>643
それはmasterが局所的な量化になってるんじゃないの？
ChatHandlerの型にはmasterがどういう型かが現れてないでしょ

647 ：
>>645

newtype MyMonad a = MyMonad { runMyMonad :: SomeMonad SomeType a }
deriving (Functor, Applicative, Monad)

とかすれば？

648 ：
定義としては、こんな感じかな。。
モナド変換子の扱いが厄介だと思ったが、あっさり成功しました。
まだ使ってない・・。

{-# LANGUAGE GeneralizedNewtypeDeriving #-}

newtype ErrorLogT m a = ErrorLogT { runErrorLogT :: WriterT [String] m a }
deriving (Functor, Applicative, Monad)

649 ：
>>644
>>646
試しに forall master. をコメントアウトしてコンパイルしてみたら、下記の warning が出た。

Variable ‘master’ is implicitly quantified due to a context
Use explicit forall syntax instead.
This will become an error in GHC 7.12.
In the type ‘YesodChat master => HandlerT Chat (HandlerT master IO) a’
In the declaration for type synonym ‘ChatHandler’

出たのは warning だけで、コンパイル自体はできる。
ということは、局所的な forall ではないよね。
もしそうならエラーでコンパイルできないはず。

つまり、今のところは「この場合の forall の有無による意味の違いは無い」と解釈して問題ない、よね？ まずいかな？


書籍ではたぶん、将来エラー扱いになる（し、今でも警告が出る）から今のうちに forall を明示的に書いておいたのだと思う。
だが、なんで将来エラー扱いになるのかが分からんな。
明示しないとどんな不都合が起こるんだろ。

650 ：
>>649
んー、確かめたら局所量化じゃなさそうだね。
= の右に左に出てこない型変数をforallなしで書くなってことなんだろうけど
でもこれデータ型宣言じゃなくて型シノニムだもんね。

651 ：
>>640
>ライブラリのサンプルでラムダ式の4重ネストとか見かけるけどそういう書き方って普通なの？
>jsのコールバック地獄と何一つ変わらない気がするんだけど

よくわからん。

¥x1 x2 x3 -> zzzzzzz と書くのを律儀に
¥x1 -> ¥x2 -> ¥x3 -> zzzzzzzzz と書いてたって話じゃないのか？

それなら単に複数引数のλを周りくどい表記で書いてるってだけだ。
或いはdo構文をdesugarした形で明示的に書いてるとかかな。
いずれにせよ関数定義内で局所的に変数を定義するのと同じなんで地獄とも思えない。

652 ：
もしhaskellじゃなかったらごめんなさい
うろ覚えだけどabcマシン？なるマシン語を下地になんか作る本があったきがするんだけど
何の本かわかります？

653 ：
すみませんhaskell学習のためにIDE使おうと思い試しに
intellijにhaskforceプラグイン入れて
winghci向けにテキストエディタで作っていた物を実行した所
cabalのhackageライブラリへの接続設定が上手くいかないみたいで
エラー連発となったのですが
どなたかintellij活用していて解る方いましたら教えて下さい。

参考URL
https://carymrobbins.github.io/intellij-haskforce/

654 ：
すみません.cabalファイルの
build-depends設定が必要でした。
お騒がせしました。

655 ：
>>652
わからん。
Haskellはcmmで書かれてるらしい。

656 ：
abcマシンってこの人が記事にしてるやつ？

http://d.hatena.ne.jp/lethevert/20060424/p2

657 ：
察するにHaskellじゃなくConcurrent Cleanなる関数型言語がABCマシンからなるVMを使っているようだが

658 ：
昔は2chにConcurent Cleanのスレがあったらしい

http://d.hatena.ne.jp/quox/20080809/p4

659 ：
いまは単にCleanという。Concurrentの部分は黒歴史認定された。

660 ：
cleanかー。確かに昔cleanのpdfファイルを読んだ覚えがある。cleanのスレもたまに見てた
haskellじゃなかったのね、ありがとう

661 ：
import Data.Array
import Data.Map

f :: Array Int Int -> Int -> Int
f a i = a ! i

これ、(!) がどっちのモジュール由来かわからんってエラーが出るんだが、
なんで推論しないんだろうな。

もし (!) が、Array と Map がともにインスタンスになっている共通のクラスのメソッドなら、
ちゃんとどっちの型のものか推論してくれるのに。

662 ：
>>661
>これ、(!) がどっちのモジュール由来かわからんってエラーが出るんだが、
>なんで推論しないんだろうな。
>
>もし (!) が、Array と Map がともにインスタンスになっている共通のクラスのメソッドなら、
>ちゃんとどっちの型のものか推論してくれるのに。

まさに殆ど自分で答えを書いてると思うが、(!)は多相関数じゃないから
推論もヘッタクレもなく、単純に名前が衝突する。

ほぼ同じ状況のレコードのフィールドは
列多相にする拡張がGHC 8.0でついに入るようだ。

663 ：
多相な関数ってのとたまたま同じ名前がついた関数が複数あるってのは条件が違うんだな。

664 ：
>>662
名前が衝突してたって、a と i の型で (!) がどっちのものか特定できるじゃん。

なんで分からないなんて言うの、って話。

クラスメソッドなら同じく a と i の型から推測するわけだから、
同じように推測すればいいのに。

665 ：
>>664
多相性抜きだと (!) に型がつかないから。
あと、同じ型シグネチャを持った複数の(!)があったらいずれにせよ解決できない。
おとなしく最初からモジュール名で修飾して特定できるようにしとけ、というのは理にかなった方針。

666 ：
>>665
うーん、正直なところまだ納得できん。

これだけ教えてくれ。
>>661 の状況で (!) が Data.Array モジュールで定義されたものだと特定するのは、理論的に不可能なのか？
それとも、たまたま今の ghc に特定する仕組みが備わっていないだけなのか？

667 ：
>>666
理屈としては可能なんじゃないかな。効率がわるいから
やらんだけで。

668 ：
>>666
観点による。現在の環境にある(!)という名前の全部をテーブルから探してきて、
引数位置の型に合うヴァージョンを同定するということ自体はもちろんできる。

だが、(!)を多相にする仕組みを用意しないと(!)に型が付かないので
型安全性の観点からは不可能だということになる。
試しに自分が期待するように振る舞う(!)の型を書いてみればいい。

察するに構造的部分型が欲しいのかもしれないが、Haskellにはない（OCamlにはある）。

669 ：
具体的に考えるんだ
x の型が一意に決まらないとき show x はどうなるかとか

670 ：
>>669
どうなるの？

671 ：
A型またはB型を意味するABクラスを考える
x :: AB a => a
show :: Show a => a -> String
show x :: (AB a, Show a) => String
形式上ABクラスとShowクラスの関係は宣言していない (できない) から両者は無関係

だがABクラスがなくなればAとShowの関係やBとShowの関係を無視できない

672 ：
13:00
〜21:00
チャンネル 関数型ストリーム処理勉強会

lv241026970

673 ：
free monadのfreeってどういう意味？
自由とか解放とか、鉛フリーとかのフリー？
monad以外にも何とかフリーってあるの？

674 ：
>>673
由来は数学だね。数学のなかで、なんかの理論（たとえば群論や線形空間論）があったとして、
「なんでもない集合S」を土台にして「群」や「線型空間」を作りたい場合があるわけ。
普通の群はなんか色々元同士に絡みあった複雑な関係があったりするけど、Sから簡単に作った
群はそういう「複雑な関係から自由」だと思えるわけ。そんなわけで、そうやって作ったのを「Sの
上の自由群」と呼んだりする。

線形空間もそう。Sの元をベクトル空間の基底だと思って、無理にベクトル空間にするわけ。
S＝｛きゅうり、なす、みかん｝　だとすると、これらを基底とするベクトルは

　αきゅうり+βなす＋γみかん

みたいになる、、、とか言うと大理不尽パンチを食らった感じがするかもしれんけど、
学習理論で言う特徴空間なんてそんな感じだよ。

　α特徴１＋β特徴２ + γ特徴３

みたいに表して、その空間がどうなってるかを調べたりするわけ。そういう意味で、一見
理不尽というか、「数学的な対象はコネコネして作れない」という神話的プラトニズムからは
受け入れがたいだろうけど、こうして作った空間は「数学」と「現実」を結んで議論するのに役に立つよ。

「現実と数学」の理論を結んでくれるこのような働きそのものを圏論ではシミュレートできるわけ。
「なんたら」という理論に対して「自由なんたら」を考えることができる。こういうとゆるっとしてふわっとした
話のようだけど、一般性という意味でのゆるさを保ちつつ、議論が宙に浮かない程度にはリゴラスな
議論ができるのが圏論の旨味です。

気分的な解説をこれ以上続けても仕方ないので、興味があったら圏論の本の「随伴」あたりを勉強されたし。
たまに「Wikipedia見てもわからなかった」とか言ってる人がいるけど、Wikipediaは記事によって記述の濃淡が
ばらつき過ぎていて、あれで勉強するというのは全くオススメしないよ。

675 ：
>>674
ありがと。

圏論 原著第2版 の第9章のタイトルが随伴だそうだから読んでみるわ。
圏論入門者がそこまで到達（理解）するのにどれだけ時間がかかるか分からんが。

676 ：
モナドって離散信号を一回連続に直してからフーリエ変換して離散に戻すみたいな感じですか

677 ：
モナドは自己関手なので離散から連続に直すみたいな感じではありません

678 ：
>>676
床下配線でどうたら、という解説から想像をたくましくしてはいけない

679 ：
あえて抽象的な喩えで言うなら、
「モナドは文脈」という考え方が私はわかりやすかった。

ある関数を使うときに文脈によって意味 (戻り値) がかわることもあるし、
文脈にそぐわない関数を使うことは出来ないように型で制約されている感じは、
まさに文脈って感じがする。

680 ：
つまりモナドを説明する前に多相型を説明しろってことだ
多相型は文脈によって意味がかわる

681 ：
>>680
そういう意味での文脈、じゃないよ。

たとえばMaybeは「中に何も入ってないかも知んない文脈」だし
リストは「なんか値が複数にバラけてるっぽい（し何もないかもしれない）文脈」なんだよ。
具体的にはFunctorでラップされてる型ならなんでもそのFunctorに応じた文脈だと言える。

Functorを考えるとき、

X -> F Y と Y -> F Z を合成したい場合がある。
（しなくても済む場合もありますが）

そういう「合成」がうまくいくためには FY と Y->FZ を受け取ってFZを
返してくれる演算があると便利だなぁということになる。それが (>>=)だね。
そういう演算が「うまく行く」ことを保証するのがモナド則。

682 ：
「文脈」なんて言わずにおとなしく「計算効果」といっておけばよかったんだよ

非モナディックな値を単純にreturnでモナドに投入するだけでは作れないような
モナディックな値がその計算効果の意味を表現している
MaybeならNothingだし、Listならシングルトン以外の全てのリスト、
IOなら実行しても定数しか返さないようなもの以外の全てのIOアクション

そういう計算効果を、do構文の中にいるときのようにある種自然に
取り扱えるようにするのが、モナドの持つ構造つまりモナド則。

683 ：
モナドがない言語にもListはあります
モナドがなくてもListの計算効果はあります
Listを知らない人にモナドを教えるのは早すぎるし
知っている人に計算効果を教えるのは遅すぎる

684 ：
昔、継承がなければポリモーフィズムもないと思ってたんだが
ダックタイピングすれば継承がなくてもポリモーフィズムがあると気付いて
継承を理解するには静的型付けを知るべきだと思った

モナドも同じだと思う
静的型付けを知らなければモナドの本当の意味は分からない

685 ：
>>684
>昔、継承がなければポリモーフィズムもないと思ってたんだが
>ダックタイピングすれば継承がなくてもポリモーフィズムがあると気付いて
>継承を理解するには静的型付けを知るべきだと思った

意味がわからん。
継承と多相が関係ないのはそりゃ当然だが
ダックタイピングがどうというのも関係がない

>モナドも同じだと思う
>静的型付けを知らなければモナドの本当の意味は分からない

いや普通にリストモナドとかLispで実装して使うから。
そういうLisperは既に静的型付けを知っている！みたいな話なのかもしれんけど。

686 ：
>>685
リストモナドというけど、Haskellと全く同じ仕様をLispで実装したとは思えないから
モナドの定義が微妙に違うんだろうな
オブジェクト指向の定義が何通りもあるのと同じようにね

687 ：
「モナドの定義が微妙に違う」＃とは

ふつうにreturn, fmap, bind (or join) を用意して
do構文に似せたマクロにするだけなんだが……

688 ：
ID:UTL+VBaFが何言ってんのかさっぱり分からん

689 ：
嘘を言うよりよっぽど安全だが
まあどんな小さなリスクも見逃さない努力が必要ってことか

690 ：
そもそも継承と部分型関係は関係ないからな。
ID:UTL+VBaF (>>689もかな？) の言ってることは尽く意味不明。

691 ：
>>683
(>>=)のような組み合わせ方法を議論のビルディングブロックに
もってきたのがHaskellの（というかワドラーの）偉さなんだけど、
この「偉さ」は静的な型がしっかりした世界でのみ意味を持つのであって
そういう意味では他の言語では（所謂関数型言語の仲間であっても）
モナドを論じる意味は全くない。

692 ：
>>691
>この「偉さ」は静的な型がしっかりした世界でのみ意味を持つのであって

まったく勘違いしてる
計算効果は型付けの静的動的とはなんの関係もない

693 ：
自分が書いたものでも他人が書いたものでも、
ぱっと見これは宣言的じゃないなと感じるコードってあるよね。

俺は自分で無計画に思いつくままにプログラミングしてて、
let や where でやたら数珠繋ぎに値が加工されているときに、
こりゃアカンわと思うんだが。
where
　(x, y) = f a
　z = g x
　w = h y z


おまえらはどう？
どういうコードを見たときに非宣言的だと感じる？

694 ：
let や where の変数の値は実行時まで分からないことが多い
分からないことは宣言できない
余計な変数を作らないようにして分からないことを目立たなくすることはできる

695 ：
>let や where の変数の値は実行時まで分からないことが多い
>分からないことは宣言できない
>余計な変数を作らないようにして分からないことを目立たなくすることはできる

意味不明過ぎる。
局所定義でなくトップレベルに書いたらいいとでも？

696 ：
宣言的ってナニ？

697 ：
Excelは宣言的だと聞いたことがある

698 ：
囲碁やソリティア、大戦略などのような2次元の広がりのある升目型ボードゲームを作る場合、
ボードのデータ構造は Haskell でもやはり Data.Array 系でしょうか。

699 ：
>>698
immutableでやるんならData.Mapでもさほど問題はないよ。数百要素程度だし。
mutableで行くとシンプルに割りきってMArrayを使ってもいいんじゃないかな。
もし盤面を行列と見た計算が必要ならRepaを使う。

700 ：
副作用使わない自慢よりは静的型付け自慢の方が無難

701 ：
>>699
ありがとうございます。
参考にさせていただきます。

702 ：
>>692
私が言ったのは (>>=)を議論のビルディングブロックに持ってくることが
ピンと来るのは静的な型がしっかりしているからだ、と言うことだ。

別にLispやJavascriptやらJavaで (>>=)に該当するものを作っても構わんが
Haskellが受けるのと同じ恩恵は受けられない。

ホゲホゲという言語でモナド作ってみたとかいう記事は腐るほど出てくるが
Haskellっぽい言語以外では「作ってみた」以上の進展はない。
考えることは出来ても(>>=)を議論のビルディングブロックにする旨味が
その導入コストを下回るからだ。

703 ：
宣言的なコードと非宣言的なコードの違いが分からないどれがどれ？

A: https://paiza.io/projects/PJqKw4d6Bm6slQXPq2bZ0A
B: https://paiza.io/projects/3G2kGBhaUdr9AgLqz9WQMA
C: https://paiza.io/projects/lGZzjjrbxOuGjF60NgMpzQ
D: https://paiza.io/projects/MW0pDwWuXHb0G_P0jDrx_w
E: https://paiza.io/projects/46HCc6YRllxPA3_fhOA5aQ
F: https://paiza.io/projects/UM0hOXFZUbPnzUX_rTEx7A

704 ：
declarativeと何を対比したいんだ？

宣言的/式志向的

を区別したいなら
https://wiki.haskell.org/Declaration_vs._expression_style

を読むだろJK

705 ：
>>703
・宣言的/非宣言的に分けられるという信念はだれに吹きこまれたのか
・宣言的/非宣言的を判定する基準は存在すると思うか。思うとしたら何故か
・そもそも宣言的（ｒｙ

706 ：
よく知らないけど、宣言的と手続き的って矛盾しないの？
対比させてる人が多いけど

707 ：
手続きは機械でできるから人間の仕事は宣言だけになるという噂だよな
手続き的な宣言が存在しないとは言っていない

708 ：
モナドすら知らない人からするとdo文は手続きに見える

709 ：
>>708
というかそれでいいんだよ。
純粋な関数型の枠組みの内部で手続き的な構造をもたらすことが
モナドを導入する意図の重要なひとつなんだから。

710 ：
手続き的な構造を目的にして do 構文を使っちゃいかん。
ソースが見苦しくなる。

手続き的な構造の構築機能としては、
Haskell の do 構文は C 言語などに比べて遥かに不自由なのだから。

711 ：
main :: IO ()　の場合がまさにそうだけど、モナドM に対して M なんちゃらって
値を一つのリテラルで書くのが難しい場合に手続き的に do で
構成するような使い方にとどめておいたほうが良いのであって
手続き的にかけるぞやったーとか言ってると全体がIOモナドに
なちゃーうよ。

712 ：
>>709
> 純粋な関数型の枠組みの内部で手続き的な構造をもたらすことが
> モナドを導入する意図の重要なひとつ
それってどのくらい信用していい？
それじゃあ、モナドを導入する意図のうち重要なものをすべて挙げることができる？
あるいは、モナドを導入する意図全体を簡潔に言える？

713 ：
>>712
重要な理由の一つを挙げただけの人にどうして
「モナドを導入する意図のうち重要なものをすべて挙げることができる？」
と聞くのかさっぱりわからん。

というか「信じるかどうか」気にする前に君が読むべき論文は

Wadler Monad

でググれば一発目に出てくると思うんだが。あとはその論文でも
引用されてる Moggi 1989 とか。 Moggi 1989 はアイデアの宝庫だよ。
状態や継続が「モナドで表現した計算効果」とみなせることは
Moggiのアイデアだよ。

714 ：
ttp://www.amazon.co.jp/圏論の技法-中岡-宏行/dp/4535786674
発売日 2015/12/14

こんなの今日見つけたんだけど、圏論、今年、流行ってるの？

日本人が書いてるから、言葉的に読みやすいと嬉しいけど。

715 ：
>>713
> 重要な理由の一つを挙げただけの人にどうして
> 「モナドを導入する意図のうち重要なものをすべて挙げることができる？」
> と聞くのかさっぱりわからん。
めんどくさい人だね。一つ挙げた人が残りすべてを挙げることができるかもしらんし、
できんかもしらんじゃないか。なんで「と聞くのかさっぱりわからん」のかさっぱりわからん。
出来ないはずだがね、あなたにも

> Wadler Monad
> Moggi 1989 はアイデアの宝庫だよ
それはあなたたちの買いかぶりだよ

716 ：
↑なんでハスケルスレってこんな人ばっか湧くの？

717 ：
>>709
よく分からんのだが、その構造というのは表現と同義？

単に手続き型言語のプログラムと似たような見た目にできるよって話なのか、
それとももっと深い意味(意義)があるのか。

718 ：
>>716
しかもこういうのに限ってまともに勉強したことない感じなんだよなあ

Moggi1989をきちんと読んで理解した人間人が
>>712みたいな間抜けな質問をするはずもなく。

719 ：
>>717
モナドを使って計算効果の表示意味論を与えようという話なんで、
見た目がどうとかじゃなくて、まさに「意味」の話よ。

720 ：
>>716 >>718
腐るほど居る単なる文献学習生の一人（二人？）なのね？ｗ
しかも今や相当古い文献

721 ：
うわあイタい

722 ：
>>719
計算効果の表示的意味論を「何に対して」与えるの？
手続き的な構造をもたらす対象は「何」？

両者の「何」は同じもの？
つまり、その「何か」はモナドによって計算効果の表示的意味論を与えられると、
構造が手続き的になるの？

構造の意味もいまいち分からんが・・・

723 ：
質問が多くなるのは最初の質問がおかしいんだよ
おそらく質問の答えを知りたいのではなく論破して否定したいだけ
それなら単刀直入に否定から入る方が早い

否定から入るのを避けるのは非効率
明らかに生産性が下がっている

724 ：
関数型言語ってモジュール間の依存性高すぎない？

725 ：
大雑把な書き方をするねぇ

726 ：
F#とC#のような言語非依存のモジュールシステムがあったらいいね

727 ：
C言語出来るだけの素人がhaskell修めるまでどんくらい時間かかりますか？

728 ：
修めるだけならチュートリアル読むだけなんだからまったく時間かからんだろ。
マスターする、という意味なら一般にそんな時間の見積もりは不可能だろ。

729 ：
>>719 >>728
もっとちゃんと答えられんのか

730 ：
>>729
「ちゃんと」答えてるじゃないか。
むしろ根拠もないのにこれ以上に具体的な答えを返す方がおかしいわ。

731 ：
>>730
それは無能ってことよ

732 ：
有能なら未来予測ができるのか

733 ：
>>729
きみ、このスレに頻繁に書き込んでるけど、なんでHaskellに執着してるの？

親でも殺されたの？

734 ：
>>731
はいはい。お前さんが答えてやりゃよかろ。無能じゃないんだったらな。

735 ：
haskellでnumpyのようなライブラリーありますか？

736 ：
>>731
あれ、返事待ってたんだけどな…
ほらー有能なんでしょ君？　早く答えてくれないと！
かなり待ってるんだけどなぁ。俺が
死ぬまでにちゃんと答えてくれるんだよね？
ねー早くスマートでクールな答えをよろしく頼むよ！

737 ：
Jカーブ底打ってからあと2年

738 ：
>>735
bindings-gsl　じゃだめですか

739 ：
semantic versioningを厳密に順守するパッケージ間なら、ビルド後の依存関係を緩くしても良さそうなもんだけどな。
base_foo-1.0.0を利用するプログラムは、base_fooがsemantic versioningを満たす限り、
base_fooのバージョンが2未満ならバイナリレベルで互換性があると言えるはず。

740 ：
厳密に維持しているかどうかってのはどう判断するんや。
維持しているつもりが維持できてないってこともよくある話で、
そんなのをアテにするのが土台無理なんだってば。

741 ：
semanticsとなんの関係もないのになんでsemantic versioningっていうんだろう

742 ：
ソースの意味が分かってないと順守できないし順守されているかどうか判断できないから

743 ：
パッケージのインストールってなんでファイルを置くだけでOKにできないの

744 ：
>>743
？どういう意味だろう

745 ：
Ambiguous！

746 ：
諸君、議論したまえ

747 ：
>>746
またおまえか

748 ：
conduit と persist を連携させ、例えば上流から String 型のデータを受けて、
「persistを使って」データベースへデータを挿入する Sink を作るとする。
次のようにコネクションプールを使って簡単な例を作ってみたんだが、
この方法はやっぱりスジが悪いかな？
連携方法について他に良い案があれば教えてほしい。

share [mkPersist sqlSettings, mkMigrate "migrateAll"] [persistLowerCase|
Ingredient
　name String
|]

sinkInsertion :: Sink String (ResourceT IO) ()
sinkInsertion = bracketP createPool deletePool insertRecord

createPool :: IO ConnectionPool
createPool = runNoLoggingT $ createMySQLPool 省略 1

deletePool :: ConnectionPool -> IO ()
deletePool = destroyAllResources

insertRecord :: ConnectionPool -> Sink String (ResourceT IO) ()
insertRecord pool = do
　liftIO $ runResourceT $ runSqlPool (runMigration migrateAll) pool
　let loop = do
　　　　mname <- await
　　　　case mname of
　　　　　Nothing　-> return ()
　　　　　Just name -> (liftIO $ runResourceT $ runSqlPool (insert_ (Ingredient name)) pool) >> loop
　loop

main = runResourceT $ sourceList ["nasu", "tomato"] $$ sinkInsertion

749 ：
template haskell つかってるひとはじめてみた

750 ：
そんなこというひとはじめてみた
実用だと使うよね？yesod某とかfile-embedとか

>>748
むしろpersistとconduitの連携とか勉強になった
すっきりしていいと思う

751 ：
file-embedは便利だけどyesodとかhakyllとかそんな使うかなあ。
まあでもlensでお目にかかってるはずだとは思うけど。

752 ：
lens はいろんなチュートリアルみてもなにやってるか
わからなくて使ってない

753 ：
Haskellをベースに創られたElmとかいうAltJS言語の話題はここでいいですか？

754 ：
簡単な文法の話以外ならElmスレ立てたほうがいいと思う

755 ：
>>713
これ読んでみるわ、サンキューモッギ

756 ：
Monadクラスの中で特に汎用性の高いインスタンスを一つ選び
そのインスタンスだけでほぼ何でもできる、という方向に行かないのは何故なのかな
そうすれば苦労してMonadクラスを理解する必要もなくなるのに

757 ：
>>756
きみがMonadクラスを理解するのに苦労した原因は
それぞれのインスタンスが個々の機能に特化ているからなの？

インスタンスが特化しているとクラスが理解しにくいのは何で？

意味が分からん

758 ：
特化しすぎたら価値を理解するのに苦労するのは当たり前じゃないか
例えばアフリカのある国でしか使えない通貨とか

759 ：
>>758
きみにとってアフリカの通貨（インスタンス）の価値は分からなくても
通貨（クラス）の価値は分かるよね

760 ：
モナドは単なる、今のところなかなかの成功を納めているデザインパターンの一つに過ぎないとこのスレで教わった

761 ：
あと、月を指せば指を認むって諺をさっきTwitterから学んだ

762 ：
>>756
>Monadクラスの中で特に汎用性の高いインスタンスを一つ選び
>そのインスタンスだけでほぼ何でもできる、という方向に行かないのは何故なのかな

なんでわざわざそんなモジュール性がクソになるようなことしなきゃいかんのw

763 ：
So you can think of lists as promises that
the next element will be delivered once it really has to be, and along with
it, the promise of the element after it.
読めないので翻訳お願いします

764 ：
>>762
特化してもモジュールが単純化される保証はない
ポイントカードのように特化して複雑化したモジュールが大量に作られる可能性がある

765 ：
promiseを日本語で理解してくると読めるようになると思う

766 ：
すごいhaskell楽しく学ぼう持ってる人教えてください
205ページに日本語訳が載ってると思います
お願いします

767 ：
モナド則をチェックする機能はなぜ作れないのか

768 ：
>>767
一般に与えられた2つの値の等価性を決定する手段がないから（たとえば関数）

769 ：
そういうのはチェックではなく証明しないとだめだ。もちろんその証明は人間が書くのだが。

770 ：
既存のインスタンスは証明済みだよな
既存のに制約を加えただけのインスタンスも証明不要

771 ：
mtlのListTがモナドではないと気付かれるまでに少し掛かったので油断は禁物だ

772 ：
なんだと？ 発案者は何らかの責任を取ったのか？

773 ：
GHC 7.10.3 リリースおめ
[ANNOUNCE] Glasgow Haskell Compiler version 7.10.3
https://mail.haskell.org/pipermail/ghc-devs/2015-December/010736.html

次は 8.0.1?

774 ：
>>772
Cのクソ品質の乱数だって誰も責任とっとらんがな

775 ：
returnの命名者誰なんだろ

776 ：
たとえば「絶対に儲かる」乱数だとか品質に言及していたら責任問題になるだろうが
作者が何も言ってない値札もついてないものは質が低くても別にいいんじゃないか

777 ：
名前なんて適当に別名つけたったらええやん。

778 ：
標準を軽視すれば他人に読みにくい糞コードの濫発を招くのではないか

779 ：
Haskell のコードなんて言語内 DSL の乱発じゃん。 別名くらいイマサラ

780 ：
不満があるなら自分で言語を作ればいい
それもできないなら黙ってる事をお勧めする

781 ：
>>779
それは言い得て妙だな。俺も使わせてもらおう。

782 ：
本当の初心者には

IOモナドは型を合わせるパズルさえ解けたらそのご褒美に
純粋性を保ちながら入出力を許してくれる仕組みだと思え

って言ってる。
合わせ慣れるとほっといても意味がわかってくるんだよね

783 ：
近くにHaskellに興味を持ってくれる初心者がいるなんて羨ましい

784 ：
>>782
どうも理解が全く違ったようだな。撤回するわ。やめとく。

785 ：
ハスケルって白鳥になりたいペンギンみたいな言語だな

786 ：
Haskellは、海底から見上げたらペンギンも飛べることになるって言語

787 ：
Haskellを何かに例える奴はろくにHaskell使ってないだろw

788 ：
初心者に分かりやすい例えと熟練者に分かりやすい例えは違うし

789 ：
>>785
>>786
これらの喩えは初心者に分かりやすいのですか？
それとも熟練者に分かりやすいのですか？

私には意味が分からないです。

790 ：
>>789
間を取って初心者にも熟練者にも意味不明な喩えにしてみました。
どちらにも「同じくらい」納得していただくことを目指した結果なので
何卒ご了承ください。

791 ：
例え話の目的は、元ネタを知ってる奴なら言わなくても分かることを省略することだな
省略しても何も分かりやすくならない
ただ短くなるだけ

792 ：
haskell勉強中です
H本にfoldlが無限リストに対して動作しないと書いてあるのですがfoldrで扱えてfoldlで扱えないとはどういうことですか

793 ：
後のページを読めばわかるようになる

794 ：
>>792
遅延評価だから

795 ：
读书百遍、其意自见。

796 ：
>>793-794
続き読みました
foldl(&&)True(repeat False)だと((&&) ((&&) ((&&) True False)False)False)のように展開され、
foldr(&&)True(repeat False)だと((&&)False ((&&)False ((&&) False True)))のように展開されるので
(&&)の実装通り、"False _ = False"ということでfoldrではFalseが得られるということでした
頭から適用するかケツから適用するかで展開方法が違うからこんなことになってるんですね
ありがとうございました。

797 ：
「選択と集中」で原発事業に盛大にぶっこんだ挙句不運にも
原発事故の風評被害ｗをうけて業績超悪化したのを「チャレンジ」で
切り抜けようとしてドブに沈んでいるけど、ハイリスク・ハイリターンてのは
そういうことだよね。

おつかれさん

798 ：
プログラマはMacを使ってるってマジ？
http://hayabusa3.2ch.sc/test/read.cgi/news/1450395043

799 ：
すごいわかりにくいが、型に集中して値のことを忘れるって話をしてるんだよな
静的型でリスクが減ることはあっても増えることはないってのは本当か？という話

800 ：
金が遊んでたのでゲームを買う代わりに型システム入門 −プログラミング言語と型の理論−

を買ってみたのですが、これ読むとHaskell力増しますかね？

801 ：
>>800
Haskell力の低い人と高い人で決定的に違うのは何でしょうか。

802 ：
動的型で嬉しいことがあるとすれば（返り値の？）型の違う関数を許す事になるが果たして…

803 ：
コード弄りながら設計を考えていくタイプの物は動的型の方が楽かな

804 ：
>>801
Haskell力が低い人
「読んだ方が良いか？」

Haskell力が高い人
「『ママッ子』なんだよ>>800！
　ビビったんだ…。甘ったれてんだ！ わかるか？ え？オレの言ってる事。
　『型』のせいじゃあねえ。心の奥のところでオメーにはビビリがあんだよ！
　オレたち強いHaskellerはな！
　そこら辺のナンパJavascripterや仲よしクラブで『読んだ方が良いか？』『読んだ方が良いか？』
　って訊いて回って仲間と心をなぐさめあってるような負け犬どもとはわけが違うんだからな。
『読んだ方が良いか？』…そんな言葉は使う必要がねーんだ。
　なぜならオレや、オレたちの仲間はその言葉を頭に思い浮かべた時には！
　実際に本を読んじまってもうすでに 終わってるからだッ！
　だから 使った事がねェ〜〜〜ッ。
　>>800
　オマエもそうなるよなァ〜〜〜〜〜〜〜〜
　オレたちの仲間なら…わかるか？ オレの言ってる事… え？
『読み終わった』なら 使ってもいいッ！」

805 ：
>>804
ほんこれ

806 ：
bottomって何だお

807 ：
あらゆる部分関数を全関数にするための魔法のこと

808 ：
和の単位元bottom
積の単位元unit

809 ：
C から int 型の配列を Haskell に渡して
たとえば Haskell ですべての要素に 1 を足して
足された配列を C に返すってのをやりたいんだけど
いいサンプル知らない？

配列じゃなくて単独の int とか double とかはできるんだけどな

810 ：
Cでやればよくない？

811 ：
そりゃ業務だったらそうするけどさ

できたら楽しいなって、それだけだよ

812 ：
>>809
FFIしたいということですか

813 ：
本物のプログラマはHaskellを使う 日経ソフトウエア
第58回　Cの配列をHaskellで利用する 2013/08/07
http://itpro.nikkeibp.co.jp/article/COLUMN/20130806/496825/

814 ：
>>812
そういうことですね

>>813
情報ありがとうです

とりあえず力技ではできたけど、あんまりスマートじゃないなー
俺の Haskell レベルだと、どうやってリストにすればいいか解らないｗ
http://pastebin.com/v9q509Pr

815 ：
ghc 7.10.3 の ghci 上での :sprint について

Prelude> let x = 1
Prelude> :sprint x
x = _
Prelude> x
1
Prelude> :sprint x
x = _

こうなるんだが、これが正常なの？
最後、x = 1 と表示されるのを期待したんだが。

816 ：
>>815
http://d.hatena.ne.jp/kazu-yamamoto/20151217

817 ：
>>816
なるほど

ありがと、助かったよ

818 ：
>>786
どこかで見たネタだと思ったらゆゆ式だった。

819 ：
諸君、議論したまえ。

820 ：
>>819
すっこんでろ

821 ：
H本でbracketOnErrorのとこまで読みました。
bracketとbracketOnErrorの使い分けどうやってますか？
onerrorの方が効率は良さそうですが。

822 ：
Ｈ本なんて固有名詞ネーヨカス

823 ：
>>822
あなたがわからないだけでしょ

824 ：
キチガイだな。　放置でヨロｗｗｗ

825 ：
>>824
あんたキチガイだからNGしとくわｗ
さいならー

826 ：
＞819 名前：デフォルトの名無しさん[sage] 投稿日：2015/12/29(火) 10:07:19.04 ID:zZSzcFIy [1/3]
＞H本でbracketOnErrorのとこまで読みました。
＞bracketとbracketOnErrorの使い分けどうやってますか？
＞onerrorの方が効率は良さそうですが。

どっちがキチガイなんだろうかｗｗｗｗ

827 ：
>>821
その本でどのように説明されているのか私は知りませんので、
的外れなレスでしたらごめんなさい。

bracket と bracketOnError はそもそも役割が異なり、
その処理効率によって比較するものではありません。

bracket は第3引数のIOアクションの実行時に例外が発生しようがしまいが、
第2引数のIOアクションは実行されます。

一方、bracketOnError は第3引数のIOアクション実行時に例外が発生した場合のみ、
第2引数のIOアクションが実行されます。
(どちらの説明もライブラリドキュメントに書かれています)

なので、確保したリソースの第3引数のIOアクション後の解放を保証したいのならば、
bracketOnError は使えません。
例外が発生しなければ第2引数のIOアクションは実行されないので。


ちなみに、この2つの関数、中身はほとんど同じです。
http://hackage.haskell.org/package/base-4.8.1.0/docs/Control-Exception.html
ここの各関数のシグネチャの右端にソースへのリンク(Sourse)があるので、見てみてください。
どうでしょう、効率に差があるように見えるでしょうか。

828 ：
>>827
ありがとうございます。
すみません。まだ初歩の学習中でbracketのソースは読めそうにないです…
bracketOnErrorでも第三引数に第二引数と同等のリソース開放のコードを書くことでこの2つの関数は代替可能だと思ったのですが間違っているでしょうか？
onerrorの方が効率が良いと思ったのは例外が発生しない場合第二引数の関数を呼び出すコストがかからないからと考えましたが大したコストじゃなさそうですね

829 ：
>>828
たしかに bracketOnError の第2引数は、第3引数で例外が発生しない限り実行されません。
その意味では「例外の無い通常運転では第2引数を実行するコストはかからない」のでその分効率的でしょうね。

ただ問題は、そのような処理の流れで本当に大丈夫なの？ と言うことです。
あなたが実現させたい処理の流れに合っているかどうか、それが最も大事です。
bracket と bracketOnError のどちらを使っても実現させたい処理に適合するのなら、
より効率的な方を選ぶのも手です(効率の他に、ソースがより読みやすい方を選ぶのも手)。

効率よりもまずは合っているかどうかを考えた方が良いと思います。
>>827 で「役割が違う、効率で比較するものではない」と言ったのはそういう意味です。
合わないものを工夫して合わせるのはバグの元なので、
そういう工夫はそれしか手段がない場合のみやるべきだと私は思います。

もし bracketOnError の第3引数にリソース解法処理を「必ず行うように」書くのなら、
あなたがメリットだと感じている「例外がなければ第2引数を実行するコストがかからない」
というのは無くなり、処理的には bracket と「ほぼ」同等になりますが、
それなら bracket を使うべきだと私は思います。
同じ処理を実現するなら、手間がかかる bracketOnError より楽に bracket です。

830 ：
bracketOnError の第一引数が例外となったらどうなりますか？

bracket AB共通後始末 $ bracketOnError planBwith後始末forB＼AB共通後始末 planAwith後始末forA＼AB共通後始末
こう書けばいいです？

831 ：
教えて君にエサをやるからこうなる。　だからあれほどスルーといったのにな。

832 ：
>>830
bracketOnError の第1引数で例外が発生すれば、
その例外はそのまま bracketOnError の外に伝わります。

このことは、>>827 で挙げたソースが読めなくても、
自分で実験して確認できます。
実際に第1引数で適当なが例外を発生させてみれば良いです。

「こう書けばいいです？」の部分は何を言いたいのかよく分かりません。
まずは落ち着いてください。
全角のバックスラッシュは何を意味するのわかりませんし、
そもそも btrcket や bracketInError の第1引数は第3引数よりも先に実行されます。
そこに後始末処理を書いてはいけません。

何を言いたいのかは分かりませんが、しかしこれも実験で簡単に確認できるはずです。
どちらの関数も引数はすべて IO モナドなので、print を適当に挟んで実行順などを調べられます。

質問の前に、まずは自分でやってみてください。

833 ：
>>829
結論としてbracketOnErrorとbracketは代替可能ですよね。

ちなみ>>830は私じゃないのでｗ

834 ：
>>833
おそらく、あなたの期待している処理に関してだけ言えば、両者は代替可能だと言ってしまっても、
実用上それほど間違っていはないと思われます。

歯切れが悪い言い方で申し訳ないです。
というのも、正確に言えば両者は代替できない(と思う)からです。
>>829 でも同等性に関して「ほぼ」と断りました。

私が今ぱっと思いつく限りでは2つの異なる点があります。

ひとつは、bracketOnError の第3引数に（わざわざ）書いた開放処理の中で例外が起きれば、
その時点で bracketOnError の第2引数が実行されます。
第2引数でも開放処理が書かれていれば中途半端に二重に実行されます。
どう代替しますか？

もうひとつは外部例外への対処の仕方です(以後、簡単のため正確さは犠牲にします)。

両者の第1引数と第2引数では、外部例外がマスクされます。
一方、第3引数では外部例外のマスクが一時的に開放されます。
外部例外というのは他スレッドから現スレッドに投げられる例外の事だと今は思ってください。
これがマスクされているという事は、外部例外が投げられても処理を最後までやり切る、という事です。

したがって、bracket の第2引数に書いた開放処理と、bracketOnError の第3引数に書いた開放処理は、
外部例外への対応という点に関して異なります。
mask_ という関数を使って外部例外をマスクできますが、それで開放処理を書くのなら、
もうほとんど bracket の第2引数で開放処理を書くのと同義で、代替できると呼べるかどうか。


そもそも、代替できるかどうかに拘る理由が分かりません。
普通、bracketOnError を見たプログラマは、例外が発生しなければ第2引数は実行されない、
という前提でプログラムソースを読むはずです(ドキュメントにそう書かれているので)。
なので、第3引数に開放処理が書かれていれば混乱を生むだけだと思うのですが・・・

835 ：
>>833
すいません、>>834 で外部例外と言いましたが、言葉が間違っていました。

正しくは「非同期例外」です。

836 ：
persistent-sqlite パッケージの接続用関数のどれを使っても、
データベース名にURIが使えないんだが、なんで？

たとえば、withSqliteConn "file:test.db?mode=memory" とやっても、
この名前そのままのファイルがカレントディレクトリに作られてしまう。
withSqliteConn "file:///tmp/test.db" とやったらオープンできないと言われる。

ちなみに、sqlite-simple パッケージの接続用関数を試してみたら、
こちらではちゃんと前者はインメモリで名前付きデータベースが作られたし、
後者もちゃんと /tmp/test.db が作られた。

これは、persistent-sqlite パッケージのバグか仕様？　それとも俺のやり方が悪い？

[環境]
OS : ArchLinux
ghc : 7.10.3
persistent-sqlite-2.2

837 ：
質問の仕方が悪い
バグだからお前は悪くないか、仕様だからお前が悪いの二択

838 ：
これが関数型界隈の人間は冷たいの正体か…

839 ：
「名前そのままのファイル」が作られるんだから仕様だろ
URIを解釈せずにそのままファイル名にする、というのは
きちんと意味のある方針

840 ：
Sqliteの仕様としてURIが使え、インメモリで名前が使えるよ。
SqliteのC言語ライブラリでも、それをラップした他言語ライブラリでも、
Haskell の sqluie-simple でも問題なく仕様通りの使い方ができる。

だから、persistent-sqlite で使えないのが不思議なんだよ。

で、単に persistent-sqlite のバグなのか、
このライブラリに限りSqliteの仕様に反することが明文化されているのか、
それとも俺の使い方が悪い（どこかで設定できる？）のか、
と質問したんだが、どうだろうか。


>>839
それがドキュメントに書かれていれば、なるほどと思う。
一応俺なりにドキュメントを精読したつもりなんだが、見当たらない。

841 ：
関数型の切り口で語る奴はだいたいKだと思ってる

842 ：
そもそもDatabase.Persist.Sql (withSqlConn) がそういう動作をする

persistentのバックエンドのひとつとしてsqliteが使えるというだけで、
sqliteの機能をまるのまま提供する義理があるわけじゃないからな
sqlite特有の仕様は全部切り捨ててるんじゃね

843 ：
じゃあ、Sqlite の大きな特徴のひとつであるインメモリはなんで使えるんだ？

withSqliteConn ":memory:" は普通に使えてるんだが。

844 ：
毛の壁うざいな

845 ：
もうブームは去った感じだけど、まだ元気にどこかで妄言吐き散らかしてるんだろうか

846 ：
>>838
これ質問されてんじゃなくてURI使わせろって命令されてるだけだから
命令を無視されても冷たいとはいえない

847 ：
誰も知らないようだから、GitHub yessodweb/persistent の issues にあげてみるよ。

848 ：
C言語ライブラリでも the URI filename capability is disabled by default
って書いてあるね

849 ：
>>848
そう、俺も GitHub の issues に投稿してから気づいた。
自分で Sqlite のサイトのリンクまで載せておきながらね。

すぐにゴメンナサイをしたけど、かなり恥ずかしいヤツになってしまった。
みんなにもゴメン、完全に俺の早とちりだった。

ただ、URI解釈機能の追加には作者も乗ってくれたみたい。

850 ：
sqlite-simple は direct-sqlite に依存する
direct-sqlite.cabal の cc-options の所には -DSQLITE_USE_URI と書いてある

persistent-sqlite.cabal の cc-options にはそれがない

851 ：
年始早々お邪魔します。
stylish haskellをインストールしてみたのですが
IDEの表示動作には何ら変化が無く
これを導入する事によって何が嬉しいのか解りません。
もし解説してるサイト等を知ってましたら教えて下さい。

852 ：
cabal test の結果を色分け表示するツールって無いかな？

853 ：
>>851
前Vimから使ってたけど単なるコードの整形ツールだよ？そういうことではなく？

854 ：
>>851
ありがとうございます。
単なるコードの整形ツールねのですね。
ハスケルはlet式の中で改行された名前の先頭位置によって
鰓が出たりするので重宝できるかもしれません。

855 ：
使い方どころか何のためのツールかも知らないでインストールしたのか
このスレに質問しにくる奴は総じてどこかおかしいな
まあ、まともな人間ならStack OverflowやTwitterで答えてもらってるからそれもそうか

856 ：
総じてどこかおかしい奴用Haskell質問スレ設立の機運が高まる

857 ：
総じてっていうか英語読めない/読まない人たちだな

858 ：
2chに書けばお人好しが教えてくれると思っている

859 ：
ていうか、おかしいと批判することと隔離することを混同するなよ
批判は自由だが、隔離は自由ではないぞ

860 ：
『ママッ子（マンモーニ）』なんだよペッシ！
　ビビったんだ…。甘ったれてんだ！ わかるか？ え？オレの言ってる事。

861 ：
口語的に書かれても意味が分かりかねますので
もう一度正しい文章構成で書いてもらえますか

862 ：
>>861
意思疎通する気があるなら安価ぐらい付けたらどうかな

863 ：
>>862
意思疎通する気は全くありませんでした
謹んでお詫び申し上げます

864 ：
>>863
年始早々お邪魔しにきたわけだ、なるほど

865 ：
『話せば分かる』なんて大ウソ!
正解は『離せば分かつ』
毛の壁

朦朧健

866 ：
>>864
こちらの意図も伝わっていなかったようですが
それも含めて意思疎通する気が無い故仕方がないことと考えております
年始の戯れにお付き合いいただきありがとうございます

867 ：
AdventCalender書いてない奴が居るせいでHaskellがランキングから外れてて草
総ストック数はそこそこあったのに

868 ：
ghc のコンパイルエラーの文って、いつも最初の数行しか役に立たないんだけど、
後ろの方の文が役に立った人っている？

たとえば、適当なファイルに次の2行を書いて、

import Control.Exception
main = try (return 0) >>= print

ghc-7.10.3 でコンパイルすると、エラーが２つ出る。
ひとつは try 関数のところで Exception e0 の e0 の型が曖昧だというエラー。
もうひとつは print のところでその型 e0 が Show のインスタンスではないというエラー。

どちらも、エラーの本質はエラー文の初めの2行で分かる。
その直後の Note: there are several potential instances: の提案が
極希に役立ったことがあったかもしれん。
だけど、最後の　In the first argument of ‘(>>=)’, namely ‘try undefined’
の辺りが役に立ったことなんて一度もない。

型が合わないタイプのエラーも同じ。
expected な型と actual な型の情報は重要だけど、残りの情報は役に立たん。

でも、ghc の作者はそういった情報も役に立つと思ってるから出力してるんだと思う。
が、俺にはさっぱりわからん、どういう意図なんだろ。

869 ：
総じてではなく丁寧語で書いてる奴約1名が本当に頭のおかしい奴ってだけだね
>>821と同じ奴っぽいけど一瞬でサイコパスだと見ぬいた>>822何者なんだ…

870 ：
>>868
まあとりあえず言葉通りの意味がわかれば十分じゃないか
逆に何を言われても物足りないと思えば、言葉が何の役にも立たないのは当然だ

871 ：
諸君、議論したまえ

872 ：
保守

873 ：
それはHaskellのコードをまともに書いたことがないからというだけでは……
似たような型の関数を長大に連鎖してる箇所でそれがなかったら手間もいいとこ

874 ：
あ、しばしば予想外の箇所が示されるってのはあるけどな。
型推論が最終的に失敗した箇所とエンバグした箇所が違うことはわりとある

875 ：
>>873
まともかどうかは分からんが、
確かに似たような型の関数を長大に連鎖するのは意図的に避けてる。
やっぱ、そこから逃げてちゃマズいか。

それがなかったらの「それ」が何を指しているのか曖昧だが、
最後の In the first argument of の件か？
それなら、エラーが検出された場所（行と列）が最初に示されるだろ。
それで分かるよね。

876 ：
ghcの仕事は辻褄が合わないコードを探すことだ
役に立たないコードを探すことではない
役に立つなんて下手に断言して辻褄が合わなくなるより何も言わない方がましだ

877 ：
毛の壁みたいな奴いるな

878 ：
ghcをメイクするにはghcが要るんですか？

879 ：
>>878
要ります
CコンパイラがCで書かれてるのと一緒です

880 ：
バグったghcを直すためにバグったghcを使うんだよな…

881 ：
そういう場合、バグっていなかった最後のバージョンを特定して、それの次のバージョンのソースコード見直してリメイクして次のバージョンをリメイクしてって辿り直すんですか？

882 ：
もしIDE使ったらエディタのバグやビルドツールのバグも不可避になるのかな

883 ：
Haskellは関数型言語ですから、コンパイルが通った時にはバグが無いことを保証されています。
従ってバグを持つghcは原理的に存在しません。

884 ：
でもHaskellコンパイラ第一号はC/C++なんかで書かれたんでしょ？
そこで埋め込まれた可能性がある

885 ：
保証されてるのは型の整合性だけだろ

886 ：
>>881
大抵は新規の拡張とか高度な最適化に関するエンバグなので
それを用いていないGHCを-O1程度でコンパイルするぶんには無問題

887 ：
あ、よく考えたらそうでもないか。隣家廻りとかもよく壊れてる気がしてきた。
だが、まあ別にGHC自身を普通にセルフコンパイルするのに支障はない。

888 ：
>>884
Lazy MLという純粋かつ遅延評価なML方言で
GHCのプロトタイプが書かれて、それを使って
ブートストラップしたということらしい。

889 ：
コンパイルの最終ラインはCでしょ、なあに少しくらいバグが入っていた方が気付けになる

890 ：
Haskellは関数型言語なので並列性が最強です。
メニーコアの時代には全てのソフトウェアがHaskellで書かれるでしょう。

891 ：
せやろか

892 ：
なるわけない、適材適所だよ
Haskell は強力な原語だけど万能でもなんでもない

893 ：
>>890
rtsがcmmみたいなクソ言語つこうとる間は移植性皆無だし
Haskellがメニーコア時代を制するとか全くの寝言。

894 ：
シングルコア、メニー言語の時代がずっと続いたから
なんでも反対する人に未来を予想させたらメニーコア単一言語になる

895 ：
cmmの移植性が皆無＃とは

ともあれもうLLVM化がほぼ完了してるんでなあ

896 ：
メニーコア時代のプロセッサはHaskellのために作られます。
従って移植性は必要ありません。
また、Haskellに対して最大の最適化がかけられるので、ただでさえ世界最高速のHaskellが
更に速くなります。

897 ：
スーパーコンピューター京は、当初Cで書かれたジョブを投入していましたが、
あまりにも遅く実力を発揮できなかったそうです。
たまたまHaskellで書かれたコードを実行したところ素直にスケールし、同等のCプログラムに比べて
一万倍以上の速度をたたき出したそうです。
今では、京で実行されるプログラムの8割以上がHaskellで書かれるそうです。
この話を聞いた時、私はメニーコア時代にはHaskell以外すべて淘汰されると確信しました。

898 ：
＠各位　触るな

899 ：
しれっとフォートラン無視されてて草

900 ：
メモリさえあれば無限に近い桁数の計算ができるCOBOLがさいつよだって銀行の資料室窓際のおじいちゃんが泣きながらいってた

901 ：
sparc向けのコード吐けるhaskellコンパイラって存在するの？

902 ：
>>901
つくればあるよ

903 ：
さすがにその回答はないわ

904 ：
GHCのサイトになければないに決まってるんだし、
こういうしょうもないレスを期待されてたとしか思えないんだよね。

905 ：
>>901は反語だろ多分

906 ：
SourceForgeやgithub、適当なコミュニティにあるかもしれないんだけどな
10年前なら公式サイト or SFにないなら諦める、だったけど今はどこで作られてるか分かったもんじゃない

907 ：
sparcマシン上でソースからコンパイラメイクすればよくね？

908 ：
ターゲット上でコンパイルすればそのターゲット向け実行ファイルが作られるすばらしいコンパイラのソースをお持ちの方がいるようです

909 ：
Cを吐くjhcとか使えばいいよ

910 ：
sparcってアーキテクチャとしてどこが違うんだっけ？

911 ：
Haskellのレベルでもまだ機械語が透けて見える奴と見えない奴がいるね

912 ：
Haskellなんてそれこそ透け見えちゃいけない言語だしな
元の話だが、sparcクロスコンパイルもダメなんだけか？
今どき少ないがWSの並列のためにありそうなもんだが

913 ：
京でhaskellなんていう妄言に対するただのヤジだったのに、思いの外盛り上がってし待っている

914 ：
京はやっぱりfortranですかね

915 ：
>>909
あれはもう死んだでしょ

916 ：
>>913
質問の契機が思いの外しょうもなかった

HaskellでもFortranでもどっちでも良いが京では数学者が最適化しやすい方が良いんだろうな
どっちがいいかはプログラマ上がりじゃわかんねーや

917 ：
>>915
別に死んでないよ
ajhcがコンパイルできなくなってるのは
単にApplicativeがMonadの上に追加されたのに
追従してないだけなんで簡単に直せるよ

918 ：
死んでるじゃん

919 ：
心室細動だよ。まだ死んでない

920 ：
その程度も自分で直せずに「死んでるじゃん」とか言ってるの……？

921 ：
その程度の改修も公式に入らないほどにメンテが滞っているのならプロジェクトとしては死んでる、ってことだろ

922 ：
所詮研究のためのおもちゃなんだなあ

923 ：
じゃあ研究じゃなくて練習といえばいいだけ
練習もせずにぶっつけ本番なんてとんでもない

924 ：
>>920
Monadがどうこう以前に、GCに関連した処理がどこか
おかしくて、しかもMさんが見てもFixできなかったアレ。

（Mさんも本業の片手間だったかもしれないので
本当はがんばればFixできる可能性はあるけど、
どうも boxing - unboxing の処理が非常に込み入ってるらしく
jhcにちょろっとスケッチしてある程度の事だけを
ヒントにやらないといけないらしく、結局中断してる）

925 ：
研究職以外はオモチャとしてしか扱えんわな
純粋関数の可能性を追求したり、副作用のない環境での理論証明ツールだったり
そんな学術以外への転用がベストではない言語、普通のPGには使う意味ないもの

926 ：
科学技術用ってFortran？

927 ：
fortranスレで聞け

928 ：
研究職は基本fortran,Mathematica,mapleから選ぶ感じ

929 ：
数理ではHaskell便利なのになぁ

930 ：
一部のアルゴリズムの実装が簡単

931 ：
局所的なアルゴリズムじゃなくて、もっと全体を支配するような仕組み
静的型付けとかデザインパターンとか
デザインパターンはたとえば非決定性やイテレータやモナドや非同期のようなもの

932 ：
JavaとHaskellどっちが実行速いの？

933 ：
jhcの話してんのにHaskell=おもちゃと読み取ったアホがいるらしい

934 ：
言語は二つ以上覚えるとよい
そのうち一つは玩具といわれても腹の立たない言語
C++, Java, Haskellから二つ選ぶなら重複の少ないものがよいからJavaは選ばない

935 ：
>>931含め何を言ってるのかサッパリ分からないのは関数型脳じゃないからなのか
誰か日本語で訳してくれい

936 ：
誰かS式に訳して

937 ：
そうなんですよ。
Haskellを初めとする関数型言語は数学者にとって超絶便利。
しかしながら数学がわからない者にとっては難解なだけです。
まあ言ってみれば馬鹿には無理ってことなんですよ。
選ばれた天才が使ってこそ意味のある言語なんです。

938 ：
K定期

939 ：
デザパタが難しいのは、コードの中にパターン名が明記されている保証がないから
明記しないから正式名称が統一されている保証もない

940 ：
>>938
なるー、翻訳thx

941 ：
安全工学の知見？

942 ：
>>994
makiが馬鹿にしてる「安倍首相」って現世にいる安倍首相とは別の人間なんじゃないか、って思うときがある。
なんか自分が妄想してる間抜けの具現した影を殴り倒してはしゃいでる、みたいな。
奴が書き込んでるコメントを見てると根本的な事すら理解してないことが結構ある。

943 ：
スマン。誤爆したorz

944 ：
バトルプログラマー☆マキの話ならココで合ってるぜ。

945 ：
HDBCのexecute関数ってどこで実装されているのでしょうか？
Statement.hsの34行目に型宣言は見つかったのですが、実態が見つかりません。
よろしくお願いします！

946 ：
x実態
o実体

947 ：
>>945
Haskellは停止の必要無しにネットワークのむこう側にでさえコードを移動できるのです。
計算の途中で性能の不足を感じたら、性能の高いマシンへイメージを転送し、実行を継続します。
ですから、実装がどこにあるかは問題ではないのです。
Haskellであること、そしてHaskellを使えることが重要なのです。
Haskell使いであることに誇りを持ちましょう。

948 ：
すみません、意味がわかりません。
僕が知りたいのはどのソースのどの行にexecuteの実装があるかです。
よろしくお願いします。

949 ：
>>945 >>948
Javaで言うところのInterfaceみたいなもんだから
各データベース管理システムごとに実装が作られてる
sqlite3ならHDBC-sqlite3に
PostgreSQLならHDBC-postgresqlに

950 ：
>>947
こんなのに騙される奴がいるのか？
前向きな事を言っているから建設的な議論なんだろうみたいな考えの奴しか騙せないだろ

Haskellはおもちゃという批判の方がまだマシだ

951 ：
>>947
OCamlスレに帰りたまへ

952 ：
>>949
なるほど！ありがとうございます！

953 ：
このスレ、まだ関数型言語ブーム時のあれこれを引きずってて笑う

954 ：
引きずってるのは変な虫だけですから

955 ：
一部の奴が胡乱な書き込みをしているだけで、９割が現実を見ているよ

956 ：
ジエネレーティブプログラミングみたいな表現力で考えると、スキャフォルドやテンプレートか、lispのマクロか、全てがs式(データ)か、haskellの遅延評価みたいな選択肢があって、
得手不得手含めて、どれが好きか勝手に選べみたいな感じ。
って、書いてて全く意味が分からないが。

957 ：
型の表現力は考慮してなかった。

958 ：
>Javaで言うところのInterfaceみたいなもんだから

こマ？

959 ：
>>958
ざっくりしすぎだけどまあ、気持ちとしては近いんじゃね

960 ：
わしも昔はHaskellerとして名を馳せたのじゃったがライブラリにArrowを受けてしまってな

961 ：
後から実装できるのがinterfaceとは違う

962 ：
templateを教えたらHaskell並みに難しいのがバレるからinterfaceしか教えない現実

963 ：
重箱の隅をつついてどうでもいいことに華を咲かせるなぁ
言語違うんだから完全一致の概念にはならんだろ
ざっくりした気持ちで受け止めとけ

964 ：
このスレにたどり着いたHaskell初心者が誤解してしまう恐れを取り除かないと

965 ：
２ちゃんやってる段階で加齢臭漂うジジイしかいないこと確定なんで、意識高い（笑）Haskellワナビは
こんな痰壺のぞきに来ないやろ彡(ﾟ)(ﾟ)

966 ：
3日に1回しか本気出さない怠け者でも通常の3倍以上生きてるだけでわりと有能だからね
若者に嫉妬されるのも仕方ない

967 ：
すごいハスでさえなかなか読み切らない
できる人はあれ一日でおｋなん？

968 ：
>>967
読み切るだけなら1日か、長くても数日でできるでしょう。

でも、理解して、納得して、自分の言葉で説明できるまでには
そうとう時間かかると思います。
１ヶ月やそこらでは無理な人は多いです。

がんばってください。

969 ：
少しでも批判的な立場から見れば、全部読み切る必要がないのは明らかだけど
批判を封じると無駄が増えていく

970 ：
鈍感力とかいってた頃は鈍感だからいくら批判されてもOKだったけど今は批判NGなのかな

971 ：
また胡乱な書き込みが増えてきた
コードをさらせ

972 ：
じゃあ、コードを晒そうか。

聞いてくれ、さっき遅延評価の凄さを目の当たりにしたんだ。

無限リスト [[a], [a,a], [a,a,a], ・・・] を作る関数
stepup x = iterate (x:) [x]

リストから最左の指定要素を取り除く関数
remove xs x = xs \\ [x]

ここまで準備したところで、下記の計算をしてみる。
let xs = repeat 'a'
in head $ foldl remove (stepup 'a') [xs, xs, xs]

結果は、無限ループに陥ることなく "a" だ。

すごくね？

973 ：
>>972
うんそうだね。

でも遅延評価ってのが何物なのかわかってくるとあんま驚かない。

974 ：
yieldある言語だと無限要素の実現は容易だけど
それをリスト構造として扱えるって点では便利かもね

975 ：
遅延評価は並列処理をしようとすると驚き最小の原則を破る

976 ：
遅延評価はノンプリエンプティブマルチタスクの親戚
タスクを遅延している

もしプリエンプティブならタスクが勝手に動き出すので無限ループを止められない
メニーコアとかも無限ループを止められない

977 ：
遅延のおかげでメモリ不足になってエラーになった

978 ：
ここから遅延評価の悪口を言っていこう

979 ：
どんなに素晴らしいプログラミング言語だろうと
コーディングする人間の質が悪ければ何の意味も価値もなさない

http://ideone.com/880zvK

980 ：
https://paiza.io/projects/6tuAv6EyXxyMfm4QkzUopg

まあこの程度のものを>>979みたいに書かれたらそりゃたまらんよな

981 ：
ワンラインシェルスクリプトの俺スゲーみたいだな
悪いわけじゃないが、他者の可読性ってどうなんだ？

982 ：
>>979
酷すぎて乾いた笑いが出るな
Sラン級糞コーダーに解答例書かせるとかPaiza大丈夫か

983 ：
このスレ、書いてないことまで透視能力使って読んでる奴いっぱいいるじゃん
それに比べたら書いてあることの可読性がどうなろうと透視するのは簡単だろ

984 ：
検索してみたらただの2chの回答者じゃん
流石に一般人晒すのはマズイよ

985 ：
instance Functor Tree where
fmap f EmptyTree = EmptyTree
fmap f (Node x left right) = Node (f x) (fmap f left) (fmap f right)

このコードで最初は(f x)なのに、あとの2つは(fmap f left)とfmapが先頭につくのはどうしてですか？

986 ：
>>985

１．つかないと型が合わないだろ

２．そもそも再帰的定義

「ある木に fmap f した結果は、根にfを適用し、葉の部分木にfmap fした木である」

が理解出来てるか？

987 ：
>>986
>２．そもそも再帰的定義
>
>「ある木に fmap f した結果は、根にfを適用し、葉の部分木にfmap fした木である」
>
>が理解出来てるか？

すみません、理解できていないです。
なぜ葉は直接fを適用できないのでしょうか？

988 ：
>>987
たとえば整数の二分木（Tree Int）に
整数の偶奇性を判定する関数 even を fmap して
同じ形をしたブール値の二分木(Tree Bool)を得る場合を考えろ。

整数の（空でない）二分木は、根に値 x が収納され葉として部分木 left と right を持つので

Node x left right

という形をしている。
x の型は整数 Int で、 left と right の型は整数の二分木 Tree Int だ。
他方で、even の型は Int -> Bool なのだから、
even left とか even right という式は意味を成さない。

989 ：
Haskellは無限ループに陥りません。
だからこそコンパイルが通ればバグが無いことを保証できるのです。

990 ：
バグの定義からはじめようか

991 ：
>>987
1. fが受け取るのは[xの型] (xは[Tree型]じゃない)
2. left と rightは[Tree型]
3. [Tree型]とfの仲介がfmap

おわかり？

992 ：
ideoneでhaskellのサンプルコードが無限ループじゃなかったっけ？

993 ：
Androidでお手軽にHaskellできるアプリ誰か頼む。C4droid並の品質で。ソースコードはAndroidのVimTouchで書くからIDEは要らないや

994 ：
>>988, 989
理解できました！
わかりやすい説明ありがとうございます！

995 ：
タブレットでコーディングする需要があるのか…

996 ：
arm向けのコード吐けるhaskellコンパイラって存在するの？
と言ってみる

997 ：
ARMをターゲットにしたクロスコンパイラなGHCは普通に存在する

そのGHCでGHC自体をARM向けにコンパイルすれば
ARM計算機上でHaskell使った開発ができるはず

998 ：
むしろプラットフォームに依存しないようなソフトしか書けないやろ

999 ：
>>901に被せただけで特に意味はなかったが、クロスコンパイル環境は普通にあるのな
Androidなら誰か暇人が作ってそうだけど、あっても古くてメンテされてないかな

>>998
そのコメントは流石に的が外れすぎてる

1000 ：
というかそもそもGHCはLLVMに対応してるからな

1001 ：
>>995
キッズが空き時間にスマホにBluetoothキーボード繋いでCodeForcesやるだろ

AI　AI　って夢見すぎてない？
Microsoft Silverlight その9
1行ずつC言語を書いてくスレ（目標なし）
２ｃｈの荒らし報告の書式対応のプログラム
ふらっと C#,C♯,C＃（初心者用） Part138
C++相談室 part144
推薦図書/必読書のためのスレッド 83
テストしにくいコードをテストする方法教えて下さい
【糞.NET】裏切り者には死を【アンチゲイツ】
D言語 Part34
--------------------
2020年44th新戦隊の予想&ネタバレ待ちスレ7
オーディオケーブル市場 2本目
東海気象情報 No.241
おねしょ・夜尿症に悩める保護者 　2晩目
【MHW】モンスターハンター：ワールド HR963
【不思議な話｜謎の話】【鳥取市のリコー事件】
【福島】ネット空間も飾った防護服アート「サン・チャイルド」　風評被害につながると撤去に「放射能をめぐる分断にみんな疲れています」
瓦そば
結婚に向け最後の出会い
アーティスト潰しの集団ストーカーに気をつけて
【国労】JR内労働労組について語ろう【JR総連】
くのいちのおへそ
【テレビ】＜玉川徹氏＞森田知事の「プライベート視察」「仕事よりも私的なことを一番大変な時に優先していたことは間違いないこと」
白鵬は史上最高の八百長力士 決まり手42手はドルジ41手 舞の海33手よりも多いのはその証拠
みんなのオセロ避難所
男のVIO脱毛★7【デリケートゾーン】
【ワウマ！】au Wowma! part210【auユーザー専用】
JOAQUIN JOE CLAUSSELL
茜屋日海夏 Part3
☆★専門学校じゃないと取れない素晴らしい資格★☆
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼