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

1 ：2012/10/17 〜 最終レス ：2012/11/06

haskell.org
ttp://www.haskell.org/
日本語サイト
ttp://www.sampou.org/cgi-bin/haskell.cgi
ttp://www.shido.info/hs/
過去ログ
関数型プログラミング言語Haskell
Part1 ttp://pc.2ch.net/tech/kako/996/996131288.html
Part2 ttp://pc2.2ch.net/test/read.cgi/tech/1013846140/
Part3 ttp://pc8.2ch.net/test/read.cgi/tech/1076418993/
Part4 ttp://pc8.2ch.net/test/read.cgi/tech/1140717775/
Part5 ttp://pc8.2ch.net/test/read.cgi/tech/1149263630/
Part6 ttp://pc11.2ch.net/test/read.cgi/tech/1162902266/
Part7 ttp://pc11.2ch.net/test/read.cgi/tech/1174211797/
Part8 ttp://pc11.2ch.net/test/read.cgi/tech/1193743693/
Part9 ttp://pc11.2ch.net/test/read.cgi/tech/1211010089/
Part10 ttp://pc12.2ch.net/test/read.cgi/tech/1231861873/
Part11 ttp://pc12.2ch.net/test/read.cgi/tech/1252382593/
Part12 ttp://hibari.2ch.net/test/read.cgi/tech/1272536128/
Part13 ttp://hibari.2ch.net/test/read.cgi/tech/1286706874/
Part14 ttp://hibari.2ch.net/test/read.cgi/tech/1299385928/
Part15 ttp://hibari.2ch.net/test/read.cgi/tech/1310199414/
Part16 ttp://toro.2ch.net/test/read.cgi/tech/1317958045/
Part17 ttp://toro.2ch.net/test/read.cgi/tech/1325510368/
Part18 ttp://toro.2ch.net/test/read.cgi/tech/1331902463/
Part19 ttp://toro.2ch.net/test/read.cgi/tech/1340760070/

2 ：

関連書籍
・Introduction to Functional Programming Using Haskell (2nd ed.)
　ttp://www.amazon.co.jp/exec/obidos/ASIN/0134843460/
・Haskell: The Craft of Functional Programming
　ttp://www.amazon.co.jp/exec/obidos/ASIN/0201342758/
・The Fun of Programming
　ttp://www.amazon.co.jp/exec/obidos/ASIN/0333992857/
・The Haskell School of Expression: Learning Functional Programming Through Multimedia
　ttp://www.amazon.co.jp/exec/obidos/ASIN/0521644089/
・入門Haskell
　ttp://www.amazon.co.jp/exec/obidos/ASIN/4839919623/
・ふつうのHaskellプログラミング
　ttp://item.rakuten.co.jp/book/4052963/
・Programming in Haskell
　ttp://www.amazon.co.jp/exec/obidos/ASIN/0521692695/
・Real World Haskell
　ttp://www.amazon.co.jp/exec/obidos/ASIN/0596514980
・関数プログラミングの楽しみ
　ttp://www.amazon.co.jp/exec/obidos/ASIN/4274068056
・すごいHaskellたのしく学ぼう!
　ttp://www.amazon.co.jp/dp/4274068854

3 ：

関連リンク
・GHC Wiki
　ttp://hackage.haskell.org/trac/ghc/wiki/TitleIndex
・A History of Haskell
　ttp://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/
・関数型関連の用語集
　ttp://sky.zero.ad.jp/~zaa54437/programming/concepts/
・本物のプログラマはHaskellを使う
　ttp://itpro.nikkeibp.co.jp/article/COLUMN/20060915/248215/?ST=ittrend
・Haskell API search Engine
　ttp://www.haskell.org/hoogle/
　【簡単な使い方】
　１．検索バーに関数名を入れて検索
　　例　map
　２．検索バーに型名を入れて検索
　　例　(a -> b) -> [a] -> [b]
・Real World Haskell
　ttp://book.realworldhaskell.org/read/
・Learn You a Haskell for Great Good!
　ttp://learnyouahaskell.com/chapters

4 ：

おつ

5 ：

前スレの流れで一言。
関数型の考え方はExcelのおかげで充分社会に浸透していると思う。
Excelシートを使って統計や簡単な計算が出来る人は大勢いるが、同じことを
同じような時間で手続き型言語で出来る人が同程度いるとは思えない。
よって、前スレの>>988に同意

6 ：

>>5
>>988には同意だが、年寄り向きではないね。記号を使い過ぎで忘れてしまう。
Smalltalk や Prolog とはちょっと違う。

7 ：

■ C
for( const char *s="12345"; *s; ++s ) if( '2'<*s&&*s<'5' ) printf( "%d", (*s-'0')*2 );
■ JavaScript
console.log([1,2,3,4,5].filter(function (i){ return i > 2 && i < 5 ; }).map(function(i){ return 2 * i; }));
■ Python
print(map(lambda x: x*2, filter(lambda x: x>2 and x<5, [1,2,3,4,5])))
■ Ruby
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2}
■ C#
new{}{ 1,2,3,4,5 }.Where(x => 2 < x && x < 5).Select(x => x*2);
■ Common Lisp
(print (loop for x in '(1 2 3 4 5) if (< 2 x 5) collect (* x 2)))
■ Haskell
print [x*2| x <-[1,2,3,4,5], x > 2, x < 5]
■ Perl
print map {$_*$_} grep {2<$_ and $_<5} 1..5;
■ Mathematica
{1,2,3,4,5}~Select~(2<#<5&) 2
■ MATLAB
x=[1 2 3 4 5]; x(2<x&x<5).*2
■ Scheme
(print (list-ec (: x 1 6) (if (< 2 x)) (if (< x 5)) (* x 2)))
■ Clojure
(for [x (range 1 6) :when (and (> x 2) (< x 5))] (* 2 x))

8 ：

てか、プログラミング学ぶときって、そんなに学校の勉強や日常生活のアナロジーで考えるかなあ
たしかにそういう入門書は多いけどさ

9 ：

それより学校の国語はふつうに宣言的だし日常で使う言葉も宣言的
宣言的な考え方は認識や言葉の基本。身近すぎて>>990が気づいてないだけでは

10 ：

宣言的、の意味を理解してないのかも

11 ：

c#だと
Enumrator.Range(1,5).Where(x => 2 < x && x < 5).Select(x => x*2);
だよ。
1から5までぐらいだったら文字数増えちゃうけどね。

12 ：

>>8
アナロジーで考えるという事ではなく、染みついた思考法・問題解決法

13 ：

>>9
宣言的の意味が違う。
出くわした問題や課題を解決しようとする時に、
素直に頭に思い浮かぶ解決方法としての宣言的な考え方の話。
問題や周辺環境を宣言的に表現して解を導く子どもはあまりいない。
たいていの子は問題解決への（直接の）手続き・手順を考える。

14 ：

新スレおめでとうございます:(；ﾞﾟ'ωﾟ'）:

15 ：

>>13
えーそんなことないでしょ。推論は宣言的な方法で問題解決してるじゃない
解決方法としての宣言的な考え方が日常的でないなんていうのはおかしい

16 ：

後出しの独自定義の相手すんなよ
「関数型言語は自然な人間の思考に反する」とか言うために
子供がどう考えるかとか話を拡げて泥沼化したいだけだろ
変な脳科学みたいに

17 ：

茂木は今関係ないだろ！

18 ：

宣言的ってMakefileのトップレベルの部分書くときみたいなのですか？

19 ：

>>16
「関数型言語は自然な人間の思考に反する」と言ったことは一度もない。
人間の思考は柔軟なので、訓練すれば誰でも色々な考え方が自然にできるようになる。
先のは問題や課題を解決しようとする時、かつ、子どもの話だ。
子どもは思考をする訓練をまだそれほど受けない。
大人に向けて成長していくうちに、授業や生活の中で自然に
宣言的な考え方をする訓練を徐々に受ける。
（教師側も宣言的な考え方を学ばせようと意図しているわけではない）
社会人になる頃には、たいていは宣言的な考え方も、
手続き的な考え方もやろうと思えば普通にできるようになってる。
しかし、意識してやっているわけではないので、
そのままでは Haskell でプログラムするのにたいして役には立たない。
問題や環境を意識して宣言的にとらえたり翻訳する練習を重ねないと、
プログラムは難しい。
ただ、考え方自体はすでに慣れているので、
宣言的な記述を見たときにそれを解釈するのはそれほど苦ではない。
また、そのために、問題を宣言的にとらえるのも、
ある問題で合点がいけば他の問題もスルスルと合点がいく事も起こり得る。
Haskell を初めた頃は難しかったが、
ある日突然視界が開けたという経験をする人が多いのは、
そのことも少なからず関係しているのではないかと私は思う。

20 ：

>>19
あなたが>>990なら、言っていることがずいぶん変わってるが。

21 ：

Haskell である日突然視界が開けるようになるためには型システムを理解しないとね。
宣言的とか関係ないんじゃね？

22 ：

>>21
型システムを理解しないとね、は自分も経験してるから簡単に同意できる。
宣言的とか関係ないんじゃね？ は、根拠を示してくれ。
関係ないと感じた経験がないから、じゃね？と言われても
このままでは同意も反対もできん。

23 ：

>>20
指摘はもっともだ。
>>990
> 静的な、宣言的な考え方なんて、手続き的な考え方に比べれば、
> 学校教育の現場でほとんど出くわすことはないだろう。
> たとえ出くわしても、意識しなければ素通りしていくだけで、身にならない。
これは言い過ぎた。
出くわすし、成長と供に授業の中でそれとなく訓練を受けてはいる。
しかし、いかんせん、そうだとは意識していないのだから、
そのままでは Haskell のプログラムをする事に関してはたいして役に立たない。
宣言的な考え方に触れた時にそれを理解できる体勢にはなるが、
そういう考え方を自分から進んでするまでには至らないだろう。
そして、自分から進んで宣言的に考える事に慣れなければ、
Haskell でのプログラムが C や Java より簡単とは思えないのではないだろうか。
自分で宣言的に考える事ができなければ
Haskell のプログラムはいつまで経ってもしっくりこないと思う。

24 ：

三行以内にまとめろ

25 ：

諸君、議論したまえ

26 ：

>>24
今回の件では3行以内でレスするのは今の私には無理だ。
どうしても3行以内にしてほしいのなら、
もうレスをやめざるを得ない。

27 ：

>>25
議題なに?

28 ：

本日の議題: 「宣言的」とはどういう意味か

29 ：

>>26
3行とか関係なしに、もうレスやめていいよ

30 ：

>>29
了解した

31 ：

やると言ったらやるのが宣言的
できるならやる、できないならやらない、は宣言的ではない
何ができるかよりも何をするべきかを重視する

32 ：

たとえば連立方程式の解を求めよ、という問題に対して
どう解くのが宣言的なのよ？

33 ：

>>32
宣言的には解けない

34 ：

とにかく解いたと仮定する
矛盾するまで仮定するのをやめない

35 ：

こういうのは宣言的っぽいと思うんだが、どう？
囲碁を例に極簡単に示すと
iterateF :: a -> [a -> a] -> [a]
iterateF = scanl (flip ($))
-- ゲームの進行状態とは、初期状態から交互に着手したものである
progressStatuses = iterateF initialStatus (cycle [blackMove, whiteMove])
-- 終局状態とは、ゲームの進行中に投了するか、着手できなくなるか、千日手になった時である
eventualStatus = find (isResigned || isFinished || isRepeated) progressStatuses

ほぼ自己説明的だから本当はコメントなんて要らんと思うが一応書いておいた。
***Status 系は今の盤の状態の他に、一つ前の盤の状態とか、
終局理由の情報も含まれてる代数データ型。
あと、ユーザー入力はどうすんの？ とかいう話はとりあえず無し。

36 ：

囲碁では千日手は簡単に作れる
これは宣言じゃなくて発見

37 ：

…？

38 ：

もしかしたら最新の GHC では取り除かれているかも知れませんが、
下記のようにパターンの中で簡単な計算をするのは
どういう名前の言語拡張でしたっけ？
f :: Int -> Int -> Int
f (n + 1) x = ・・・

39 ：

宣言：その分野のプロでも知らない用語を定義する
発見：定義しなくてもそのうちわかる

40 ：

>>34
つまり、アルゴリズムというものは、宣言的ではあり得ない？

41 ：

例えば、宣言してもしなくてもアルゴリズムが存在する場合
それは宣言とは全く関係ないから宣言的ではない
黙っていても存在感があるものは宣言的ではない
言い続けなければ消えてしまいそうなものは宣言的

42 ：

ワロタｗｗ

43 ：

Haskellで実用的なもの作ってみろよ
ほかの言語でもできるから

44 ：

>>40
「アルゴリズムとはチューリングマシンの計算表のことだと考えよう！」

45 ：

宣言的っていうのやめて静的っていえばいいんじゃね
現に宣言的型とはいわないだろ 静的型だろ

46 ：

終動負荷的な静的筋力トレーニング

47 ：

今ここで議論の真似事をしている間だけの限定でいいから、
宣言的という言葉の意味をはっきり定義してくれ
じゃないとまじめな議論にならんだろ

48 ：

A とは B のことだ。
というような文言の羅列になるのが宣言的なのでは。

49 ：

オブジェクトなどの羅列ではなく文言の羅列なのか

50 ：

>>49
この文脈で言うオブジェクトってなにを指す？

51 ：

>>50
メモリ領域などを抽象化したものかな

52 ：

メモリ領域などを抽象化ものの羅列って、意味が分からん
ちなみに、Haskell の変数は特定のメモリ領域に付けられたラベル（名前）じゃないよね

53 ：

>第1の定義によれば、ある出力を得るにあたってそれを作成する方法ではなく、出力の性質を記述することを「宣言型」と称する。
>別の定義では、純粋関数型言語/論理プログラミング言語/制約プログラミング言語で書かれたプログラムを「宣言型」と称する。

54 ：

>>52
そうだよね
特定したくないから抽象化したんだよね

55 ：

>>54
特定したくないから抽象化したって、何か勘違いしてないか？
Haskell の変数は、値が格納されたメモリ領域に付けられたラベルではなく、
「値に付けられたラベル」だぞ。
let a = 17
というのは、17 という値の別名が a ということだ

56 ：

>>53
これはPrologの簡単なプログラムですが、
http://nojiriko.asia/prolog/olympic.html
A とは B のことだ。ではなく例えば、
1888とアテネは夏期オリンピック関係にある。
という文言に相当するものの羅列と見做すことができる。
これも全体として宣言的と言える。

57 ：

>>55
特定の値ではなく抽象的な値にラベルをつけるよ
まだ値がわからない段階でもラベルをつける

58 ：

おー、ごめん。
夏期オリンピック(1996,アテネ).
1988ではなくて、1996だった。さっきjavaの宿題スレにも
同じテーマのことを書き込んでその時点から勘違いをしていた。

59 ：

さらに間違い。1996年ではなくて、1896年です。すみません。

60 ：

>>52 は「変数は特定のメモリ領域に付けられたラベルではない」と言ってる
>>54 は「そうだよね｝と同意し「特定したくないから抽象化したんだよね」と言ってる
>>54 の言う「特定したくない」というのは、メモリ領域を特定したくないから、
と読み取れないか？

61 ：

もっとオリンピックに詳しい人に聞けばいいのに
プログラマーがオリンピックを宣言するのはなぜなのか

62 ：

>>61 この問題の解答の一部を切り取っただけだから。
http://nojiriko.asia/prolog/j72_387.html

63 ：

RWH 読んでて型構成子って何かと思ったら、型コンストラクタかよ。

64 ：

>>38
n+kパターンはHaskell98の仕様にあったが、Haskell2010で取り除かれた。
GHCのフラグには (No)NPlusKPatterns がそれかね。

65 ：

GHC 7.6.1 を使っています。
Graphics.UI.GLUT モジュールをインポートしたファイルを
ghci 上でロードするまではできました。
しかし、そのモジュール内の関数を評価しようとすると、
下記のエラーメッセージが出力されます（改行は適当に入れました）。
Loading package OpenGLRaw-1.2.0.0 ... linking ... <interactive>:
C:\Users\＊＊＊\AppData\Roaming\cabal\OpenGLRaw-1.2.0.0\ghc-7.6.1\HSOpenGLRaw-1.2.0.0.o:
unknown symbol `__imp_wglGetProcAddress'
ghc.exe: unable to load package `OpenGLRaw-1.2.0.0'
ネット上で調べてみました。
同じような環境で同じエラーが出た方の書き込みがいくつかありましたが、
私が見た限りでは、解決策、あるいは解決に繋がるような情報はありませんでした。
このようなエラーに関して何か心当たりはないでしょうか。
ちなみに、ghc でのコンパイルは問題なく行われ、実行ファイルも起動できます。
ghci 上でのみ問題が起きます。
[環境]
Windows7 64bit
GHC 7.6.1
GLUT-2.3.0.0 パッケージ（他の依存パッケージも cabal で自動インストール）
glut-3.7.6-bin_x64（GLUT 本体）
[コマンド]
ghci -lglut32

66 ：

単相性制限はその後どうなりましたか？
望まれない子の将来が気になります

67 ：

>>64
ありがとうございます。

68 ：

RWH、Maybe の箇所、唐突に Just 使って、しかも結局 Just の説明皆無かよ。

69 ：

RWHって文章の構成悪いよね
説明なしにいきなり初出の単語が出てくるし話はあっちこっちに逸れまくり
Haskellとかコンピュータとかの枠に限らず一般的な書籍としてかなり悪いほうだと思う

70 ：

でも他の書籍やネットで基礎をしっかり学んでおけば、
それほど苦にならないと思うが

71 ：

これから学ぶ範囲の知識について他で学習しておかないと理解に苦しむような本だったら
学習のための本としての役割を果たしていないと思うけどね

72 ：

「理解に苦しむ」って、今回の件ってそれほど大げさなことかな。
あれ？ 何だろ？ って思ったら、まずは調べてみればいいいじゃん。
Just なんてその本にしか載っていない特別に物でもないんだし。
他の本でもそういうの色々あるよ。
とくに説明もなく新しい単語や概念が出てくるのなんてしょっちゅうだ。
そんなところでいちいち躓いて憤ってたらきりがないよ。
それに改善点を指摘するなら、ここにじゃなくて、出版社や著者にでしょ。

73 ：

Haskellを本格的に使いこなそうと思ったらRWHのレベルまでは知っておく必要があるからね
他の入門書はとりあえずHaskellを知る程度のものでしかない
RWHに代わるものが現れるまではとりあえず必要なものだ

74 ：

GHC 7.6.1 って、もしかして32bitアプリは作れない？

75 ：

>>66
何も変わってないよ。Haskell2010に入ってる
ただしGHC 7.8からghciではデフォルトで外されることになった
http://hackage.haskell.org/trac/ghc/ticket/3202

76 ：

>>75
遂に白河の清きに魚の住み兼ねて
元の濁りの田沼に戻るのですね！

77 ：

MonomorphismRestrictionのどのへんに白河の清き要素があるのか気になる

78 ：

どなたか！　この中にMonomorphismRestrictionを擁護してくださる方はいらっしゃいませんか！？

79 ：

型システムわからん
良かれと思って型宣言したらコンパイル通らなくなる
rigid type variable bound by 云々言い出して
俺の善意を踏みにじりやがる

80 ：

>>79
どんなコードでそのエラーが出た？
そのエラーには「Could not deduce 〜」というのもあった？

ちなみに型は、元々コンパイルが通っていたコードに
良かれと思って後から書き加えるものではないよ。
テスト駆動がまずテストを書くのと同じように、まず型を書くんだよ。
それから本体を「型に合わせて」書くんだ。

81 ：

>>79
もしかしてローカル変数に多相型の宣言付けてエラーもらってる？
それなら、ローカル変数の型宣言の中では、外の型変数を(ScopedTypeVariable拡張なしでは)
使えないということを覚えておけばいいよ

82 ：

>>80
>テスト駆動がまずテストを書くのと同じように、まず型を書くんだよ。
そんなの場合によるだろ。糞どうでもいい

83 ：

>>82
どのような場合に先の型を書き、
どのような場合に後に型を書くと良いのでしょうか？
何か簡単な事例を挙げていただけると助かります。

84 ：

どんな場合によるのか興味ある

85 ：

じゃあ俺も興味ある

86 ：

me too

87 ：

母さんビール

88 ：

>>87 ← 意味判らない

89 ：

haskellには（式以外の）文がない・・・って嘘じゃね？

90 ：

>>89
そう思う根拠は？

91 ：

>>87
そう思う根拠は？

92 ：

ifも式、letも式。ではwhereは式？

93 ：

そもそも式以外の文がないってどこ情報よー

94 ：

>>83
ただちに書かなくていいことは後で書く
テスト駆動も、制約に合わせて書くというより
関係ないコードを書かないことで間違いを減らしている気がする

95 ：

>>83
好きにすればいいと思うけど、俺の基準を挙げるなら、
トップレベルの定義は先に思い付いた方から書く
・普通は型の方が簡単なので型から書くことが多い
-- | 標準正規分布に従う乱数を生成する
randomNormal :: StdGen -> (Double, StdGen)
・定義が頭にあるのに型がすぐに思い付かないor面倒なら定義から
forceTell x = rnf x `seq` tell x
forceTell :: (MonadWriter w m, NFData w) => w -> m ()
ローカル変数は定義から書く。型は必要なときだけ後から書く

96 ：

>>92
そもそも、「式」とは何？
それをはっきり定義しないと、where が式なのかどうか判断できないだろ

97 ：

Haskell Reportの言葉遣いに従うなら簡単
・whereは式じゃない。宣言やcase選択肢の一部
・Haskellに「文」は存在する。do式の中に並んでいるのがそれ

98 ：

俺はグローバルでもローカルでも型から先に考えるな。
書くかどうかは気分（ローカルで型推論がうまく働かなきゃ書く）。
>>80 の型から先に書くというのは、そういう意味で俺は無意識に拡大解釈したけど、
例に出したテスト駆動の方は実際に書かなきゃ意味ないなぁ、どうなんだろ。
（テスト駆動の方も、コードの内容よりテストから先に「考える」と言えばそうだろうが）

99 ：

where は節

SQLなら

100 ：

tail は確かに List にも Vector にもあるから Ambiguous かも知らんけどさ
渡してるのが Vector なんだから Vector の方の tail だって推測してくれても良いんじゃないの？
分からず屋！

101 ：

実行時間計測用コマンド作ってみた
良かったら使ってください
(ネットで都合良く使えそうな関数見つけて、Cで良いのに意地になって作っちゃった)
import Data.Time
import System.Process
import System.Environment
import System.IO
main = getCurrentTime >>=
(\start -> getArgs >>=
(\commands ->
runInteractiveProcess (head commands) (tail commands) Nothing Nothing >>=
(\(_,stdout,_,_) -> hGetContents stdout >>= putStrLn >>
getCurrentTime >>=
(\end -> print $ diffUTCTime end start))))

102 ：

日記

103 ：

>>100
その機能をうまく(型推論の便利さをあまり犠牲にしないで)実装できたらすごい
俺は尊敬するし、論文も書ける

104 ：

MSがはやく　Visual　Haskel／CLI　出してくれればいいのに

105 ：

関数型はF#とpythonが既にあるからねぇ。

106 ：

MSRにGHCメイン開発者いるけど学者としての活躍が使命でMS製品に反映させなくていい人たちだったとおもうので、
IronPythonみたいに外部か開発部署に物好きがいないとむずかしいかもね。
どちらかというとF#の人たちがどういうポジションなのか気になる。

107 ：

これ、買いですか？
関数プログラミング入門 Haskellで学ぶ原理と技法｜Ohmsha
http://ssl.ohmsha.co.jp/cgi-bin/menu.cgi?ISBN=978-4-274-06896-6

108 ：

>>103
どうしてだよ！
手続き型言語によくあるオーバーロードだろ
できないのかよ！

109 ：

>>107
特徴
・コンピュータサイエンスっぽいノリ。関数型プログラミングを
　数学の一分野として位置づけて証明をつけたりするような議論がある。
　副題に「原理と技法」とあるのは適切だと思う。Haskellってリスト内包表記で
　無限リストがあっさり扱えたりする反面、自分が書いたコードが本当に効率が良いのか
　わかりにくいところがある。この本では、コードの効率を手で分析してみせてる箇所があり、
　そのような議論を丁寧に追って自らの血肉にできれば有益だと思われる。
・モナドの説明は想像していたよりあっさりしていた。
　コンピュータサイエンス寄りの本とは言え、突如領域理論や圏論で読者を打ちのめす心配は一切ない。
・Haskellという言語自体の入門書にもなっているが、この本をHaskell入門書として紹介するのは
　SICPをScheme入門書として紹介するのと同じぐらいには間違っていると思う。
・すでに訳出されている fun of programming (関数プログラミングの楽しみ)　はこのBirdの本の
　「続編」という位置づけであり、その本の中でIFPHでは〜のような言及がしばしばあるので
　「関数プログラミングの楽しみ」を楽しむためにはこの本も持っていたほうが良い。
まとめ
　「関数プログラミング入門　Haskellで学ぶ原理と技法」はHaskellをとりあえず使ってみたいという
　人には向かない。そのような向きには「すごいHaskell〜」を勧める。この本は、ある程度Haskellで
　自分が書きたい関数を書けるようになり、効率の問題に直面しはじめた人にこそ向いていると思う。
　どのようにデータ構造を工夫し、アルゴリズムを解析し、改良するかについての実例が載っており、
　これらの技法を身につければ --- 簡単ではないだろうが --- より整然とした、そして効率の良い
　Haskellコーディングができるようになるだろう。

110 ：

自分もその本、気になってた。くわしい解説ありがとう！
「関数プログラミングの楽しみ」の前に読むといいのか、なるほど

111 ：

以前原著買おうとしたけどいいお値段しててやめちゃったな
オーム社さんいい仕事してくれるぜまったく

112 ：

大武者

113 ：

pdfで出してくれー

114 ：

http://tanakh.jp/pub/fp-tudoi-2012/tudoi.html
すごい本のPRスライドがあった。

115 ：

みんなhaskellでなにかいてるの？

116 ：

続編を買って読んでいて、前編を欲してる人に是非おすすめ、という感じか

117 ：

なんせ「関数プログラミングの楽しみ」ではモナドの話はIFPHの11章を見てもらうことにしてここではArrowの説明するぜ！
というノリだからね。
続編というか、IFPHを前提というかそういう感じかな。

118 ：

こういう本ってすぐ絶版になったりするから
すぐ読まないにしても確保しといたほうが良さそうだな

119 ：

>>118
そsそうなの!?
関数プログラミングの楽しみとセットですぐ買おうかな

120 ：

ghc 7.6.1 で foreign import stdcall 使うと警告が出る。
the 'stdcall' calling convention is unsupported on this platform,
treating as ccall
これはどういう事？
ccall が実際にどういう規約なのかよく分からんけど、
もし ccall == cdecl なら、ccall /= stdcall だよね。

121 ：

>>107って目次を見ると、どっかで読んだような話ばっかだよな
もうこの手の本はお腹いっぱいだわ

122 ：

>>120
これじゃね
> When compiling for the x64 architecture in a Windows context (whether using
> Microsoft or non-Microsoft tools), there is only one calling convention ? the
> one described here, so that stdcall, thiscall, cdecl, fastcall, etc., are now all one and the same.
http://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions

123 ：

>>122
なるほど。
x64 & Windows では呼び出し規約は1種類に統一されたのか。
外部ライブラリを呼ぶ時も、呼び出し規約は何だろうと
ヘッダファイルを調べたりする必要がなくなるわけだ。
こりゃ便利。
ありがと。

124 ：

>>109
�d
すごく参考になった。

125 ：

IFPHは完全にコンピュータサイエンスの本だから、プログラミングの本だと思って買うとがっかりするぞ

126 ：

SICPをScheme入門書として紹介するのと同じぐらい〜って表現がぴったりだな

127 ：

Vectorの変更不可の方は
sliceなんかするとC++でいうところの参照のベクタになるってことでいいすか？
中身のコピーはしないんですよね？

128 ：

>>127
vector パッケージのドキュメントには、
Data.Vector.slice の項に次のように書かれています。
O(1) Yield a slice of the vector without copying it.
The vector must contain at least i+n elements.
もしコピーされているようなら、それはバグですね。

129 ：

http://pbh.jp/wiz/
↑
これ解けないやつは真骨頂にクズ
ハッカーをを名乗る価値無し
海外からNinjaレベルと言われるほどの者なら簡単に解くことができる
解いてみてみ？
合ってるか確認してやるから
SHA-1とか総当りとかほざいてるようじゃ脳味噌足りてないよ
ホワイトハット気取りのお前らクズじゃJarlsbergすら解けないんだろうな

130 ：

>>128
ですおね＾＾

131 ：

政治学習

132 ：

噂の『関数プログラミング入門』を買った
カバーデザインがポップでありながら品があって良い
組版もプログラミングHaskellと同じものなのですっきりしていて気が散らない
Haskellのコードに使われる等幅フォントが縦長窮屈でなく読みやすい
製本は流行りのlay-flatタイプの綴じ込みでこのへんもぬかりない
なかみはむつかしくてよくわからなかった

133 ：

>>132
> なかみはむつかしくてよくわからなかった
一番感じなところだが・・・

134 ：

肝心なところ

135 ：

カバーデザインが非常に洗練されている「関数プログラミングの楽しみ」の前編に相当するとのことなので、
やはりデザインはいいんだな

136 ：

この本開きやすいよな
フルフラット製本って言うらしいけど

137 ：

フルスロットル製本に空目した

138 ：

RWHより簡単かどうかだけ知りたい

139 ：

諸君、議論がお留守だ

140 ：

>>7
ほんとにｊｓやpythonってそんなひどいん？

141 ：

>>7
■Objective-C
for (id num in @[@1,@2,@3,@4,@5]) printf("%d\n", [num intValue]);
または
for (id num in @[@1,@2,@3,@4,@5]) NSLog(@"%@", num);

142 ：

Pythonでリスト内包表記使ってないのは不公平だな
■Python
[x*2 for x in range(1,6) if 2<x<5]

143 ：

>>7て一番酷いのはHaskellだろ
こんな阿呆なコード書くやつ居ないよ

144 ：

畜生、Vectorにnub無いのかよ

145 ：

nub って何？

146 ：

>>7って [1, 2, 3, 4, 5] みたいなリストを用意するのがルールじゃないの？
range とか 1..5 はだめだろ

147 ：

Conal Elliott のブログの写真って、最近変わった？
つい最近まで正面を見てなかったっけ
まぁ、どうでもいいが
この素敵なおっさん、いつになったらブログ更新するんだろ

148 ：

>>138
RWHは泥臭く実例を追う実用主義。BirdのIFPHは、理論的な側面を強調している。
無限リストの挙動がなんでそーなるの的な数学的原理なんかはIFPHが優れてるし
画像を扱ってバーコードリーダー作るぜ⇒大量のボイラープレート⇒それモナドでまとめられるよ
なんて話はRWHの優れたところだ。
コンピュータサイエンス（数学寄り）の素養があるならIFPHが簡単だろうし
CとかPerlは実戦でつかえるけど理論には興味ないしそれでも関数型使ってみたいならRWHが向いてる。

149 ：

モナド変換子を解説してる日本語書籍がRWHしか無くないかね？
現実的にHaskellを使いこなすにはモナド変換子の理解が必須だと思うのだけど

150 ：

>>149
IFPHの10.4でモナド変換子の説明が載ってますぞ〜　
例外の複合、状態の複合を例として説明し、最後にそれらを応用してますぞ〜

151 ：

それならちょっとIFPH立ち読みしてくるかなあ
よさそうなら関数プログラミングの楽しみと一緒に買ってしまうか
関数プログラミングの楽しみの方は、いつかじっくり読みたいなとは思ってたんだ

152 ：

丁度昨日IFPHと関数プログラミングの楽しみ併せて買ってきたわ
読みたい時に手に入らないとかありがちだからなー

153 ：

>>145
リストの重複要素を省く

154 ：

>>153
ありがと

155 ：

モナドって、IO、継続、Stateなどの副作用系から、LISTや冪集合などの
数学系に至るまで、適用範囲がすごく幅広いのだが、これはどうしてだろうか？
これだけ幅広くても、モナドとは何かを言えるものだろうか？

156 ：

またモンゴロイドが疑問を抱いてるようです

157 ：

>>155
関数ほどは幅広くはないよ
でも関数とは何かを言えるものだろうかなんて誰も疑問に思わないな

158 ：

>>157
関数。たしかにそうだけどね。
モナドは中途半端に幅広い、と言うとどうかな。
関数の場合は、モナドのような分類（IO、State、．．．）はしないよね。
しかもこの分類はアドホックな分類にも見えるし。

159 ：

＞146
＞７のClojureはrange使ってるよ

160 ：

>>155
Prologは副作用系と数学系を区別してなかったのだが
Haskellはいったん副作用系と数学系を対立させ、再び統一するためにモナドを発明した

161 ：

>>160
うん。そのとき、たとえば、IO a とList a における IOとListには、
どちらも型構成子であるという共通性はあるが、それ以外の共通性は
感じ取れないんだ。さらにいうと、List aの方はaの自然な拡張だと
すんなり納得できるが、IO aの方は、aとIOの強引な組合せとしか
見えないんだ。

162 ：

>>159
前スレのテンプレを見てもらえばわかるがrangeとか1..5とか使ってないのよ
だから元々そういう縛りがあったんだろう

163 ：

あれはテンプレじゃなく前スレで勝手にぶっこまれただぞ

164 ：

>>163
それは失敬
でもテンプレ化するならそれなりにルールを決めないとだめだよね

165 ：

>>161
お前には感じ取れなくてもListとIOには共通性があって
その共通性に基づいてるのがモナドなんだな

166 ：

え聞こえないとかありがちだからなー

167 ：

「感じる」とはまた曖昧で主観的な・・・

168 ：

>>165
>ListとIOには共通性があって
どういう共通性？

169 ：

モナドとは、モナド則を満たすような(>>=)とreturnを定義できる型構築子のこと
逆に、ある型構築子に対してモナド則を満たすような(>>=)とreturnを定義できるならそれはモナド

170 ：

IOとかListとかが実際に果たす役割はどうでもよくて、共通する構造によって表現可能ってことだから 関数よりむしろモナドのほうが広いとも言える

171 ：

>>169
むしろ、IOとListとが同類にみえるようなモナド則は実はナンセンスなのじゃ
ないかという疑問なのだが？
>>170
さすがにそんなことはないだろう。

172 ：

>>169
そのような性質を持つものにモナドという名前を与えた背景の方が興味あるな

173 ：

>>171
モナド則なんてなくても、Prologでは副作用と非決定性は同類に見えていた

174 ：

>>172
お察しの通り、モノイドとの類似性から
>>173
非決定性が副作用の一部というなら分かるが、同類というのは分からん。
Prologの何のことを言ってる？

175 ：

非決定性と副作用を同類に扱う手法のひとつがモナドだよね？Prologには何かそれに代わる物がある？

176 ：

>>171
ナンセンスとか言っても現実にリストとIOは同じモナドの概念でまとめられるので、
まとめられる以上それを別のものにする理由が無い

177 ：

IOはRealWorldを状態に持つStateモナドのようなものだってことは理解してる？

178 ：

Prolog:
非決定性は副作用の一部 (>>174)
Haskell:
非決定性はモナドの一部 + 副作用はモナドの一部

179 ：

まとめられるから、というだけでモナドにまとめている訳でもなさそうだけどな
まとめられるのに、諸事情でまとまっていないものもあるし

180 ：

でも、非決定性、状態、継続、例外、入出力等、
かなり多くのものがまとめられるからモナドを選んだんじゃないのかね？

181 ：

色々やってるうちに便利なことに気付いたって印象だな
IOとか昔はモナドじゃなかったんでしょ

182 ：

流体は非粘性(粘度効果は無視できる)、ポリトロープな状態方程式で記述される熱的な理想気体とし、断熱過程の下で作用する。

183 ：

応用範囲が広くて便利なものを「ナンセンス」と言う意味が分からんな
独自の言葉の使い方をしてるならちゃんと最初に定義してくれ

184 ：

>>155
Moggiの論文に説明があるよ。でもまあ確かに判ってる人が
判ってる人向けに書いてる感がある。

185 ：

>>171
さすがにそんなことはないだろう、なんてことはないのだ。
恒等関手もモナドなのでモナドによって定まるKleisli圏の中に元の圏も
含まれている。形式的な話ではあるが。勿論モナドごとに一つのKleisli圏があり、異なる
モナドをつなぐためにはめんどうな事をしないといけないが
（この辺は自分もまだ未把握。モナドトランスファーが関係してるのかなぁ）

186 ：

コアンダ効果を通常の翼の速度分布の説明に使うのは不適切であると

187 ：

駄目だ！　このスレ頭良い人達でいっぱいだ！

188 ：

>>185
そういう言いかたなら、関数は射なのだから，やっぱりそんなことはないのだ。

189 ：

>>188
射は関数とは限らないから、それは反論になってないよ（ただ185の議論が強引なのは確か）

190 ：

プログラムとは関数では無くKleisli圏の射のことなので、
関数よりモナドの方が広いと言うのはある意味正しい

191 ：

>>185
いまここではそもそもそのKleisli圏がどれだけ意味があるのかを聞かれているんじゃないかな

192 ：

>>190
米田の補題より、関数＝射。
190より、モナド⊂プログラム＝Kleisli圏の射⊂射。
したがって、モナド⊂関数。
これでOK?

193 ：

諸君、議論しているね

194 ：

>>192
＞米田の補題より、関数＝射。
ちょっと意味が解らないんだけど、
米田の補題からどうやって関数＝射（ここで言うイコールって何？）が導かれるのか説明してくれない？

195 ：

むしろ、カルテジアン閉のような気がする

196 ：

>>189
強引？
間違ってるっていうんだよｗ

197 ：

Q. 何でIOと[]の共通部分をわざわざ括り出して名前を付けるの？
A. 便利だから
で済む話だろ

198 ：

Moggiの論文読めば済む話なのに、何をごちゃごちゃ言ってるのんだよ

199 ：

英語を読んだら死ぬという噂だし…

200 ：

>>197
IOをモナドで扱うのが便利なのは分かるが、
リストまで同じようにモナドで扱うのが便利な理由がいまいち分からん

201 ：

>>198
だからあMoggi論文が納得できないって言ってるんだろ
それはそれでありだな

202 ：

>>200
内包表記便利じゃん
あれってモナドだからだよ

203 ：

>>195
:(；ﾞﾟ'ωﾟ'）:カルテジアンなの？　カルテシアンだと思ってた

204 ：

コードも書かずにモナドがどうやら大して理解もしてない圏論がどうやら、
実にHaskellerらしいスレですね

205 ：

圏論を深く理解したHaskellerでもなさそうなあなた様が
このような場末に何の御用で

206 ：

>>200
リストモナドは総当たり(深さ優先探索)するときに使う
問題によってはStateT s []がすごく便利

207 ：

>>202
リスト以外で内包表記が役に立つ（適している）シーンが思い浮かばない
リストもモナドで括る利点が内包表記ができるってだけなら、
内包表記はリスト専用構文でもいいような気がするのだが

208 ：

>>206
すまん、総当たり(深さ優先探索)する簡単な具体例は何か無いだろうか
（俺、ここでいう総当たりの意味がよく分かっていない）
リストがモナドになっていない他の言語と比較してみたい

209 ：

つうかモナド内包表記っていつのまにか復活してたのか

210 ：

Listモナドが何なのかもわかってなくて煽ってたのかこいつは
Listの各要素に関数を適用するmap程度のものだとか思ってたのか？

211 ：

いろんな書き方が出来て楽しいのう
do { x <- xs; y <- ys; return $ x + y }
[x + y | x <- xs, y <- ys]
(+) <$> xs <*> ys

212 ：

>>211
一番下の知的な書き方に憧れます

213 ：

>>210
それ以外に効果的だと感じる内包表記の使い方を見たことがない

214 ：

わかってるじゃないか
お前が見たことないだけだよ

215 ：

>>211みたいなの見てるとリストの要素から別のひとつの要素作ってるだけだから、
あんま効果的に見えないんだな
リストモナドの場合、
要素からリストをつくる操作(リストが入れ子になるわけじゃないよ)とか
要素を排除する操作とか(途中ですべての要素が排除されたら処理は止まる)を混ぜることができて、
最終的に結果をひとつのリストとして得ることができる

216 ：

総当りというかバックトラックの例だが。
nQueen :: Int -> [[(Int,Int)]]
nQueen n = nQueen_ 1 [[]]
　where nQueen_ m ans
　　　| m > n = ans
　　　| otherwise = nQueen_ (m + 1) [(m, x) : xs |
　　　　　　　　　　　　　　　　　　　　　　　xs <- ans,
　　　　　　　　　　　　　　　　　　　　　　　x <- [1..n],
　　　　　　　　　　　　　　　　　　　　　　　all (\ (i, j) -> x /= j && abs (m - i) /= abs (x - j)) xs]

217 ：

4つの4で0..100を作るパズル
import Data.List
import Control.Monad
main = putStr $ unlines $ map (intercalate ", " . take 2 . fourFours) [0..100]
fourFours :: Int -> [String]
fourFours target = do
  (val, str) <- msum $ map makeWith [[4,4,4,4], [44,4,4], [4,44,4], [4,4,44], [444,4], [4,444], [4444]]
  guard $ val == fromIntegral target
  return str
makeWith :: [Int] -> [(Rational, String)]
makeWith [x] = return (fromIntegral x, show x)
makeWith xs = do
  (left@(_:_), right@(_:_)) <- zip (inits xs) (tails xs) -- xsを二つに分ける
  leftVal <- makeWith left -- 左部分式を作る
  rightVal <- makeWith right -- 右部分式を作る
  combine leftVal rightVal -- 演算して組み合わせる
combine :: (Rational, String) -> (Rational, String) -> [(Rational, String)]
combine left right = do
  op <- [add, sub, mul, div] -- 演算を選ぶ
  op left right
  where
    add a b = return $ op2 (+) "+" a b
    sub a b = return $ op2 (-) "-" a b
    mul a b = return $ op2 (*) "*" a b
    div a b = do
      guard $ fst b /= 0
      return $ op2 (/) "/" a b
    op2 valOp strOp (v0, s0) (v1, s1) = (valOp v0 v1, "(" ++ s0 ++ ")" ++ strOp ++ "(" ++ s1 ++ ")")

218 ：

君らがやってるのはトイプログラムとか頭の体操の類いだけじゃん
たとえばゲーム製作の＊＊の部分での利用とか、
会計ソフト製作での＊＊の部分での利用とか、
Webサービス製作での＊＊の部分での利用とか
そういう実用的な部分での使い方はねーの？

219 ：

いつからそんな話になったんだよｗｗ

220 ：

jQueryなんかはListモナド的なものをうまく活用してるいい例かね
Listモナドのアルゴリズムはわりと広範囲に応用可能だと思う
状態モナド的なものと比べて

221 ：

>>218
なんで総当たりの実演をするのにそんな分野依存の知識を要求する例が欲しいんだ？
リストモナドは総当たりが必要な時にはいつでも使える、ということさえ知ってれば
プログラマなら応用できるだろ

222 ：

まあでもはっきり言えばリストモナドは実用上そこまで重要じゃないと思う
Maybeの方が10000倍大事

223 ：

カードをプレイするためのコストが比較的複雑なTCGで、
手札のカードが場に出せるかどうかを判定するのにStateT a [] bを使ったような記憶はある

224 ：

>>219
いや、だってさ
実用的なシーンではたいして使えない仕組みなんて、
あっても意味は無くないか？
何のためにプログラムしてるかと言えば、
アプリを作るためにしてる、というのが
まぁ一般の大半のプログラマの意見だと思うし

225 ：

あと、俺の言う仕組みって、リスト以外のモナド内包表記のことね

226 ：

>>224
いや、>>208に答えてリストモナドがどんな感じで動くかという話をしてるんであって、
リストモナドの存在意義を示すための例じゃないよ

227 ：

>>225
お前は誰だよｗ文脈依存な書き込みするならコテつけろｗ

228 ：

モナドの出番だな

229 ：

>>226
だったらアンカーを適切に付けろ
こっちはモナドを勉強中なんだから何に対しての何の意見なのか全く分かんねーよ
で本題だが、すいませんでした、>>216 は参考になります
これから他の言語と比較して理解を深めようと思います

230 ：

リストがモナドである意味が分からないのか、
内包表記がリスト以外のモナドで使える意味が分からないのか、
それとも他に難癖付けてるのか
レスが錯綜してて分からん

231 ：

非リストのモナド内包表記の活用例というのは俺も見てみたい
実際使ったことがない

232 ：

>>230
> リストがモナドである意味が分からないのか、
これはとても難しい問題だと直感したから、ひとまず置いておく。
> 内包表記がリスト以外のモナドで使える意味が分からないのか、
まずはこれを知りたい。
しかも、意味は難しいそうだから、まずは例を。
遊びにしか使えない例なら、そんなもので意味を探るのは無理だから、要らない。

233 ：

>>222
>Maybeの方が10000倍大事
Maybeが？ほんまかいな

234 ：

> ほんまかいな
メイビー（ｷﾘｯ

235 ：

センスNothing

236 ：

好きな書き方で書けば良いよ
if y /= 0 then Just (x / y) else Nothing
do { guard (y /= 0); return (x / y) }
guard (y /= 0) >> return (x / y)
[x / y | y /= 0]

237 ：

いろんなライブラリ内で Maybe が使われているのを見るが、
[x / y | y /= 0] のような書き方を見ないのは何故だ？

238 ：

モナド内包表記が復活したのって最近でしょ？

239 ：

可読性もありそう

240 ：

そんなキモい書き方するのなんてゴルファー（）ぐらいたろ

241 ：

モナドのインターフェースを持ってるから、>>211みたいに
do形式や内包表記さらにはアプリカティブファンクターの式なんかの好きな書き方ができるんだよね

242 ：

>238
復活といっても GHC の言語拡張ですよ。

if y /= 0 then Just (x / y) else Nothing
[x / y | y /= 0]
どちらがプログラムの意味を理解しやすいかは読み手の経験によるでしょうが、
私は前者の方を使いたいですね。

243 ：

内包表記をリスト以外に使うのがキモいのなら
> 内包表記がリスト以外のモナドで使える意味が分からないのか
なんて訊くまでもないよね。
だって使えるかどうかに関わらずキモいから使わないんでしょ？

244 ：

>>243
>>323
> 遊びにしか使えない例なら、そんなもので意味を探るのは無理だから、要らない。
[x / y | y /= 0] これが遊びでないと言うのなら、>>237 はどう説明する？
なぜ書籍ではこのような書き方が紹介されない？

俺は内包表記がリスト以外のモナドで使えるのは、意味なんて何も無いと思う。
最初は、モナドだとどんなものでも内包表記ができちゃう事を発見したから、
プログラマがなんか役立つ使い方をしてくれるだろうという安直な考えで、
リスト以外にも使えるモナド内包表記が作られたんじゃないかな。
設計者自身に明確な目的なんてきっと無いでしょ。
その後、たいして上手い使い方も無いまま復活した理由が不明だが。

245 ：

結論ありきなら議論する意味なんて無いってだけだよ。
ていうか、書籍に書いてあるかどうかで判断したいなら
こんなとこで他人に聞く必要もないだろ？

246 ：

>>244
なんでリストで内包表記が使えるのは意味があるの？
do構文があれば要らないよね？

247 ：

>なぜ書籍ではこのような書き方が紹介されない？
そりゃ自分で書いてる通り、最近復活したからでしょ
そのうちリスト以外でもイディオムが生まれてくるよ

248 ：

>>236
:(；ﾞﾟ'ωﾟ'）:内包表記って[と]で括られてるからリスト専用だと思ってた……
　　　　　　　今までは偽りの人生だった……

249 ：

本に書いてあって現場で使われているものにしか興味ないなら
スレ間違えてるよな

250 ：

エロゲの攻略法わかんなくてゲームの意義を問う
というかZIPでくれと言い出す奴

251 ：

サワーグレープセオリー

252 ：

ghciだと:set -XMonadComprehensionsでモナド内包表記が有効になるのか
これはなかなかおもしろいな

253 ：

>>252
詳しい解説サンクス
それならPerl忍者が荒らすのも分かる気がする(´・ω・｀)

254 ：

>>249
じゃあ、本は無しにしようか。
現場に限ってもいいし、
何なら HackageDB に登録されているライブラリ内に限定してもいいが、
それでもスレ違いか？
プログラム言語において機能を実装するというのは、
使うことによってメリットがあると想定されるからだろう。
Haskell は実用もしっかりできる関数型言語を目指して生まれたのだから、
なおさらだ。
Haskell98 で言語仕様から消えたモナド内包表記が、
最近になってGHCの言語拡張として復活したのは、どういう意図があって？
モナド内包表記が欲しいと思っていた人たちは、
どういうシーンでそれが活用できると考えていたの？
その辺りが知りたい。
正直言って、>>236 の例では恩恵が実感できない。
「好きな書き方で書けば良い」という理由だけで復活したとも思えん。
それでは Perl みたいじゃないか。

255 ：

内包表記なんて長いコードに使うもんじゃない
（長くなるならmapなりfilterなりdoなり使うべき）
だから短いコードだから内包表記で書く意義が
分からないってワケじゃないだろう
ってことは、こっちは>>254様が納得する理由をエスパーしてやらなきゃ
ダメってことなワケだが、なんでそんなことしてやる必要あるの？

256 ：

>>254
>>247

257 ：

>>254
http://hackage.haskell.org/trac/ghc/ticket/4370
http://hackage.haskell.org/trac/ghc/wiki/MonadComprehensions

258 ：

サーセン
Data.Vectorで組んで動いたコードをData.Vector.Unboxedに切り替えようと思ったんすよ
そしたら急にVectorはファンクタじゃないからfmap使えないよ Probable fix 云々ってクレーム来たんすけど
どゆことっすか？ファンクタでしょ？

259 ：

>>258
メッセージ全文うｐらないのは甘え

260 ：

>>257
ありがと。
前者は単にモナド内包表記と同等の do 表記をいくつか例示してるだけじゃん。
誤解を恐れずに言えば、モナド内包表記の操作的意味論っぽいものを示してるだけ。
ただ、そのページに論文「Bringing Back Monad Comprehensions」へのリンクがあった。
こっちはざっと見たところ「現実的な問題提起 --> モナド内包表記による解決」
という感じで語っているような気がするから、実用的なことが書かれていそうだ。
これからじっくり読んでみるよ。
後者の方はこの論文と同名なんだが、同じもの？
至る所に訂正の跡があるのだが、最新版ってことかな？
どちらにしても、「Bringing Back Monad Comprehensions」
こういう情報が欲しかったんだ。

261 ：

>>258
unboxed vectorは関手じゃないよ(腹が立つのは分かる)
関手なら fmap :: (a -> b) -> Vector a -> Vector b
が定義できなきゃならんけど、unboxed vectorだとb=Integerとかにできない
(Unbox制約を満たさないといけないから)

262 ：

最近流行ってる関手って、そもそも何？

263 ：

http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.0/Prelude.html#t:Functor
Haskellでいう関手はこれ
圏論の関手は他を当たってね！

264 ：

>>261
マジすか
複雑な事情っすね
実践よりもHaskell型システムの理解に的を絞ったサイトないっすか？

265 ：

>>262
map を関手の一つと考えると、関手から自然変換まで簡単に理解できる
簡単に理解できる　＝　毎日30分定義とにらめっこして1週間ぐらい悩むと分かる

266 ：

>>263
Functor クラスが関手のことなら、なにも漢字で書かなくてもよくない？
unboxed vector は Functor クラスのインスタンスじゃないから、
と言う方がはるかに分かりやすいというか、ストレートだと思うんだが
と感じるのは私だけ？

267 ：

知らんがな

268 ：

>>266
定着してる訳語があるのに横文字や片仮名を使うのは宗教上の理由でできんのです、ごめんなさい

269 ：

>>268
ギャグとしてはあまり面白くない

270 ：

女だ！　このスレに女が紛れ込んでるぞぉーっ！
魔女を焼き払えーっ！

271 ：

一人称を私にすると賢そうに見えるの法則

272 ：

ん？
Functor クラスそのものは関手なの？
Functor クラスがたまたま持つ性質（種数やfmap関数など）を持つものが関手なの？
たとえば Applicative なども関手？
Functor クラス自身とそのインスタンスのみが関手？
Functor クラスそのもののみが関手で、そのインスタンスは集合の要素みたいなもの？
わけが分からなくなった・・・

>>271
一人称「私」なんて誰でも使うから、賢そうに見える要素にならないでしょ

273 ：

>>272
二番目が一番近いと思う

274 ：

>>273
そうだとすると、>>268 の言う「定着してる訳語」っておかしくないか？
>>268 の言い方だと Functor の日本語訳が関手である、
と言っているように聞こえる

275 ：

>>274
圏論でFunctorの訳語が関手だから、それ以外に訳しようがない

276 ：

圏論でFunctorと、haskellのFunctorクラスは同じもの？

277 ：

わかった
今後Haskellのファンクタの意味で関手といいたい場合
いわゆる関手
と書くことにしよう

278 ：

>>276
HaskellのFunctorクラスのインスタンスはある種の(圏論的な意味の)関手(の対象部分)になってる
具体的にはHask圏からHask圏への関手
逆に、ある型構築子が(圏論的な意味の)関手になっていてもFunctorのインスタンスとは限らない
たとえば>>258のunboxed vectorがそう

279 ：

>>278
じゃあ、HaskellのFunctorクラスを安易に関手と言うのは、
文脈によっては危険じゃないか？
どの文脈だと危険か正しく理解してる奴しか使えない訳語な感じがするが

280 ：

>>279
もちろん混乱の原因になることはあるけど、
*Functorのインスタンスを関手と呼ぶ
のをその論法で禁止したら、
*Monadのインスタンスをモナドと呼ぶ
*Monoidのインスタンスをモノイドと呼ぶ
*Numのインスタンスを数値型と呼ぶ
あたりも言えなくなって不便じゃないか

281 ：

単位元と結合律を保存する高階関数は関手
という理解は正しいでしょうか？

282 ：

>>281
「恒等関数と関数結合を保存する高階関数」と言った方が良さそう

283 ：

関手はFunctorではなくfmapじゃないのん？

284 ：

>>280
なるほど、そう言われると、たしかに不便だな。
Haskell の話をしていると判りきっている時には
Monad のインスタンスはモナドと言いたい。
（個人的にはFunctorのインスタンスはファンクタと言いたいが）
でも、Haskell の話をしてるときに、いきなり圏論が姿を現し、
そのまま議論が進んでいくと、ややこしくならない？
そういうシーンをこのスレでよく見かける

285 ：

271 名前：デフォルトの名無しさん[sage] 投稿日：2012/11/05(月) 20:04:44.17
一人称を私にすると賢そうに見えるの法則

賢くみられたいからHaskellやるという法則

286 ：

賢く見られたいからHaskellって・・・
賢く見られたいんならMITで博士号取るだろ普通

287 ：

>>286
ギャグとしてはあまりおもしろくない

288 ：

>>287
一度目はいいけど、二度やると冷める
もう止めた方がいいと思うよ

289 ：

GHC 7.6.1 の ghci 上で Conduit が動かない
ghci 上で Data.Conduit系モジュールがロード処理されると、
エラーが出る。
Loading package conduit-0.5.2.7 ... linking ... <interactive>: internal error: R
_X86_64_PC32: High bits are set in 7fefb411866 for _close
(GHC version 7.6.1 for x86_64_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
これはバグ？
俺英語書けなくてバグ報告できないんだが、詰んだかな

290 ：

あ、ちなみに ghc でコンパイルすれば問題なく実行できるから、詰んではないか
でも色々実験して勉強しようと思ってたんだが、ghci 使えないとなると、
かなり面倒になるなぁ・・・

291 ：

>>281-283
関手とはある圏の対象と射をもう一つの圏(自己関手の場合は同じ圏)に移すものだから、
Functorのインスタンスとfmapセットで関手と言うのが一番近い

292 ：

>>286=こいつ図星
こいつ>>285のレスに図星しすぎれレスしてやがる
だいたいのやつは必死に悔しくても反応したら負けっていう考え持ってるから食いつかない
こいつは食いついた正直者

293 ：

>>290
たぶんWindows固有の問題
LinuxかMacを使うとか、Windowsなら仮想マシン上でLinux使えば、問題が出ない可能性が高い
この手の開発はUnix系メインでやっててWindowsはオマケのことが多いから、
細かいとこで目の行き届かない不具合があったりする

294 ：

俺、Haskellぐらいしかまともに書ける言語ないんだが、
正直それはそれで非常に恥ずかしい思いをしている

295 ：

○○をしたら負けとか偉いやつが言ったらすぐ真似をして
○○をしなくなるのが情弱
Matzみたいなのが「これから来る言語」　Haskellとか言ったら
すぐ真似して
Haskellしだすやつが情弱
>>286=こいつ最高に図星

296 ：

Haskellの話しようぜ

297 ：

>>293
ありがと
とりあえず勉強だけなら処理速度は要らないから、
vm player に linux 入れて、そっちでやってみるよ

298 ：

実用度外視なんだから、偉いやつが言ったことをすぐ真似してHaskellやるのが正解
どうせネットで偉い人のマネする以上の教育課程が揃ってないんだから

299 ：

教育してもらわなきゃプログラミングすら出来ないアホは
まったく向いてないからリアル土方に転向したほうが良いよ？

300 ：

侮辱がただの賛意表明になっているような
元からそのつもりだったのか？
いや、そういう文体には見えないなあ
要するに>>299はアホなんだろう

301 ：

え？まじで教育が必要なの？
大学でも別にプログラミングなんて独学だっただろ？
え？大学行ってないの？

302 ：

俺が言いたいのは>>298と>>299って同じ主張じゃね？
ってこと
ほんとに大学行ってるの？

303 ：

>>298は「教育環境揃ってない = 実用度外視」
と書いてるようにしか読めんのだが
教育されなきゃ実用的なプログラミングも出来ないアホは向いてないよ

304 ：

話通じてないなあ・・・
自分の発言にあとから留保つけちゃってるし
まあ俺は>>298じゃないからいいんだけどさ

305 ：

アホが偉い人のマネすべきってのはその通りだな
自分で考える脳みそ無いし

306 ：

GHCはRuby以下の安定性

307 ：

　　　∧＿∧
　　 （　´Д｀） ＜みなさーん、お茶が入りましたよ〜
　　／　　　 ＼
　　|　l　　 　l　| 　　　 ..,. ., .,
　　|　|　　　 | _|｡.:_:：゜｡-.;.:゜｡:.:;。
　　ヽ ＼_　.｡'ﾟ/　　　`｡:､｀；゜:;.::.｡:.:。
　　 /＼_ﾝ∩ｿ＼　　　 ::..゜:: ﾟ｡:.:.::.。.｡:.
.　 /　 /`ｰ'ｰ'＼ ＼　　゜: ::..゜:: ﾟ｡:.:.:，｡:.:.
　〈 　く　　　　　/　/　::..゜:: ﾟ｡:.:.:，.:.:.:｡:.:，
.　 ＼　L　　　./　/　＿::..゜:: ﾟ｡:.:.:，.:.:，.:.:.:，
　 　　〉　）　 （　.::旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦.
　　 （_,ノ　　　 .`ー'旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦旦.

308 ：

298 名前：デフォルトの名無しさん[sage] 投稿日：2012/11/06(火) 00:53:45.21
実用度外視なんだから、偉いやつが言ったことをすぐ真似してHaskellやるのが正解
どうせネットで偉い人のマネする以上の教育課程が揃ってないんだから
305 名前：デフォルトの名無しさん[sage] 投稿日：2012/11/06(火) 07:44:55.65
アホが偉い人のマネすべきってのはその通りだな
自分で考える脳みそ無いし

309 ：

Matzってそれほど「偉いやつ」だっけ

310 ：

Perl忍者最近見ないな

311 ：

>>261
じゃあfmap的なことはどう実現したらいいんですか！？

312 ：

>>311
Data.Vector.Unboxed.map

313 ：

>>312
(////)

314 ：

(////) ::

315 ：2012/11/06

(////) :: Answer -> Shame