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

1 ：デフォルトの名無しさん：2013/01/21(月) 02:16:16.07

2 ：デフォルトの名無しさん：2013/01/21(月) 02:17:12.49

関連書籍
・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 ：デフォルトの名無しさん：2013/01/21(月) 02:18:09.04

関連リンク
・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 ：デフォルトの名無しさん：2013/01/21(月) 02:24:30.26

Haskell初心者ですが、RealWorldHaskell読んでいて、状態モナドもどきを自作してみようと思って

newtype State s a = StateMonad { stateFunc :: s -> (a,s) }

とやってみて

somefunc :: (a -> b) -> State s a -> State s b
somefunc f (StateMonad g) = StateMonad( \s-> (f(fst(g s)), snd(g s)))

は通るのに

instance Functor (State s) where
fmap :: (a -> b) -> State s a -> State s b
fmap f (StateMonad g) = StateMonad( \s-> (f(fst(g s)), snd(g s)))

が通らないのがわからなくて困っています。

★質問： fmap をどのように宣言するのが正解なのでしょうか？
（fmap :: (a -> b) -> State s a -> State s b　の一行を消しても型推論で通りますが、それは気持ち悪いのです）。

5 ：デフォルトの名無しさん：2013/01/21(月) 13:10:15.17

1(ﾟдﾟ )乙　これは乙じゃなくてポニーテールなんたらかんたら

自分も基礎的質問で申し訳ないが
Free Monadがらみの記事にあった
data Fix f = Fix (f (Fix f))
はどういう意味になるんでしょう?
data Fix f = FixC (f (Fix f))でもいいものだと思いますが、コンストラクタ引数のf (Fix f)がわからんとです。FixCに2つの引数を渡す?
でもそれだとdata Fix f = FixC f (Fix f)となるんでしたでしょうか？
二つの型を型引数としてもつ型を渡すという意味?
http://www.haskellforall.com/2012/06/you-could-have-invented-free-monads.html

6 ：デフォルトの名無しさん：2013/01/21(月) 14:48:42.62

>>5
data Fix f =Fix (f (Fix f))
とすると、値コンストラクタFixは、ひとつの f (Fix f) 型の引数をとる

Fixはkindが (*->*)->*
fはkindが *ｰ>*
つまり、f自体が何かひとつの型引数をとるということ

fを[]とすれば
Fix::[Fix []] ｰ> Fix []

fをMaybeとすれば
Fix::Maybe (Fix Maybe) -> Fix Maybe

fを(,) a とすれば
Fix::(a, Fix ( (,) a ) ) -> Fix ( (,) a )

7 ：4：2013/01/21(月) 19:10:00.99

教わって解決しましたマン
Functorインスタンスはfmap の型宣言書いちゃいけないんですね

8 ：デフォルトの名無しさん：2013/01/22(火) 10:22:35.99

>>6
重ねてですまんが"ｆ（Fix f)"の意味が分からんです・・・
Fix fの値を受け取るコンストラクタを持つfという型って意味でよい？

9 ：デフォルトの名無しさん：2013/01/22(火) 10:50:24.22

f (Fix f)は型引数としてFix fをとる型
[Fix f]とかMaybe (Fix f)とかIO (Fix f)

10 ：デフォルトの名無しさん：2013/01/22(火) 11:51:18.90

了解です。ありー
ちょっと咀嚼してきまふ(´・ω・｀)

11 ：デフォルトの名無しさん：2013/01/23(水) 14:56:26.88

新スレおめでとうございます＾＾

12 ：デフォルトの名無しさん：2013/01/23(水) 23:19:59.21

>>4
標準だと、instance宣言の中ではメソッドの型は宣言できない
書くまでもなく型は決まってるし

13 ：デフォルトの名無しさん：2013/01/24(木) 05:02:59.40

エラーメッセージでそのこと言及してくれよコンパイラ

14 ：デフォルトの名無しさん：2013/01/24(木) 23:44:07.74

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

15 ：デフォルトの名無しさん：2013/01/25(金) 16:21:32.33

haskellで書いたプラグインを動的に読み込む仕組みってないですか？

16 ：デフォルトの名無しさん：2013/01/25(金) 17:17:33.46

xmonad方式はどう?

17 ：デフォルトの名無しさん：2013/01/26(土) 01:40:13.71

>>16
言語処理系を作ってるので、ユーザー側で他の処理系(ghc)が必要っていうのは避けたいんですよね
ファイルをディレクトリに置いたら読み込めるっていうのが理想なんですが
やっぱりffiで共有ライブラリを読み込むしかないんですかね

18 ：デフォルトの名無しさん：2013/01/28(月) 14:21:16.47

function sum(a, b){
return a + b;
}

sum("こんにちは");

これをhaskellで書くとどうかけますか？

19 ：デフォルトの名無しさん：2013/01/28(月) 15:07:14.40

わけがわからないよ

20 ：デフォルトの名無しさん：2013/01/28(月) 17:43:39.13

>>18

sum' x y = x + y

main = let
hello = sum' "こんにちは"
in putStrLn "Hello"

コンパイルエラーになるけど

21 ：デフォルトの名無しさん：2013/01/28(月) 17:46:56.34

>>20
オブジェクト指向しかやってないからさっぱりわからないです
関数型ってむずかしいですね

22 ：デフォルトの名無しさん：2013/01/28(月) 18:10:06.26

わけがわからないよ…

23 ：デフォルトの名無しさん：2013/01/28(月) 18:10:14.38

>>18は何言語でどういう動作を期待してるの？

24 ：デフォルトの名無しさん：2013/01/28(月) 18:13:36.33

>>21
自分も勉強中なのだけど、「入門Haskell」や
「すごいHaskellたのしく学ぼう!」　（>>2を参照）
あたりを通読するのを勧める。C++知ってる人がPerlを学ぶとか
Pythonを学ぶのとかなり違った難しさがある。

英語がさほど苦手ではないなら「すごいHaskellたのしく学ぼう!」
の原書は
ttp://learnyouahaskell.com/chapters
で読めるよ。

25 ：デフォルトの名無しさん：2013/01/28(月) 18:14:06.91

サム「こんにちは」

26 ：デフォルトの名無しさん：2013/01/28(月) 18:48:19.34

プログラミングhaskell読んでるけど7章あたりで頭が追いつかなくなってきたわ。。。

27 ：デフォルトの名無しさん：2013/01/28(月) 19:11:36.20

dataのあたりで今詰まってる。ShapeとかCircleで説明してるやつ。
オブジェクト指向とちょうど逆になってるのかな。
何が逆かはうまく説明できないけど、なんかそんな感覚。

28 ：デフォルトの名無しさん：2013/01/28(月) 20:00:44.19

オブジェクト指向って何やってんの
そうまで他の言語を難しく考えることもないと思うんだけど

29 ：デフォルトの名無しさん：2013/01/28(月) 20:46:02.21

オブジェクト指向的にインタフェースと多態で書くと、
・データの種類(クラス)の追加は簡単
・処理(メソッド)の追加は面倒
代数的データ型で書くと、
・データの種類(構築子)の追加は面倒
・処理(パターンマッチする関数)の追加は簡単

30 ：デフォルトの名無しさん：2013/01/28(月) 21:20:37.19

データの種類で最も重要なのは
・null
・null以外
の二種類
nullという種類の追加が面倒という性質は
静的型付けの存在理由に関わる重要な性質だ

31 ：デフォルトの名無しさん：2013/01/28(月) 23:18:48.92

オブジェクト指向的な多態とnullは関係ないだろ
Haskellにだって、nullよりある意味厄介な⊥というのがあるし

32 ：デフォルトの名無しさん：2013/01/29(火) 00:08:17.73

lazyは厄介だ
実行時よりもコンパイル時という考え方に反する

33 ：デフォルトの名無しさん：2013/01/29(火) 00:12:58.10

bottomを厄介者扱いとかバチあたりな

34 ：デフォルトの名無しさん：2013/01/30(水) 17:17:32.64

リストをたくさん結合すると非効率というのがいまいちわからない
実際どういう状況で非効率になるの？

35 ：デフォルトの名無しさん：2013/01/30(水) 17:43:29.80

たくさんが問題じゃなくて ++ が問題。
後半のリストは共有できるにしても、前半のリストは複製しなきゃなんない。

36 ：デフォルトの名無しさん：2013/01/30(水) 23:43:24.50

>>29
オブジェクト脳の俺にもう少し（もうだいぶ）詳しく教えてくれないか ?

ちなみに上の人とは別でこのすれ初かきこです

37 ：デフォルトの名無しさん：2013/01/31(木) 00:16:55.85

>>34
配列ならスペースを多めに取ってnullを入れておく状況とか

仕様を正確に知っている人でも、必要なスペースは予測できない
仕様書には知っていることだけ書けばいいが
コードには予測できないことまで書かないと上手く動かない

38 ：デフォルトの名無しさん：2013/01/31(木) 01:27:57.49

関係ないが、講議で、ソフトウェア科学における最悪の発明が「NULL」という話を聞いた

39 ：デフォルトの名無しさん：2013/01/31(木) 12:12:36.80

発明した人と批判した人の両方が賞をもらえるという話をどこかで聞いたような気がする

40 ：デフォルトの名無しさん：2013/01/31(木) 17:04:09.49

>>38
UNKNOWN先生がアップを始めたようです

41 ：デフォルトの名無しさん：2013/01/31(木) 19:36:37.05

最高の発明だよ

42 ：デフォルトの名無しさん：2013/02/01(金) 02:09:57.58

NULLはビリオンダラーミステイク by Tony Hoare

43 ：デフォルトの名無しさん：2013/02/01(金) 08:45:26.97

言語を選んだ時点で失敗が確定するというのは
時期尚早な最適化の話と内容が180度違うから困る

44 ：デフォルトの名無しさん：2013/02/01(金) 19:43:14.96

'こんにちはundefined'
許すまじundefined

45 ：デフォルトの名無しさん：2013/02/02(土) 12:14:09.96

⊥が現れるのは再帰がある場所に限定される
が評価されるタイミングは限定されない

46 ：デフォルトの名無しさん：2013/02/06(水) 21:22:00.54

いちおうMaybeモナドすげEEEEEEってのはわかったつもりなんだけどさ

モナド使うとなんでIOの副作用が分離されるの ?
IOってところに環境のいろんなところが入っているから
それをひきずり回しているからIOじゃないところは純粋であるって説明
どっかで読んだんだけど、具体的にはどうやってるの ?

おしえてキボンヌ

47 ：デフォルトの名無しさん：2013/02/06(水) 21:34:07.28

指定したN番目の値を返す関数を作りたいのですが、上手く出来ません。
例えば、nthElementIs [1,2,3,4] 3 > 3見たいにしたいです。

isTrue :: Int -> Bool
isTrue number
| number > 0= False
| otherwise= True

nthElementIs :: [a] -> Int -> a
nthElementIs list number = case (list) of
[] -> case (number) of
0 -> []
otherwise -> error"okh"
(x:[]) -> case (number) of
1 -> x
otherwise -> error"z"
(x:xs) -> case (number) of
isTrue -> error"df"
otherwise -> nthElementIs xs (number - 1)

48 ：デフォルトの名無しさん：2013/02/06(水) 21:36:19.56

>>46
どうやってという疑問は比較的簡単で
Stateモナドで状態を引きずり回しているのと同じように
RealWorldを引きずり回しているのが IO

49 ：デフォルトの名無しさん：2013/02/06(水) 21:39:03.05

無限リストなの？

50 ：デフォルトの名無しさん：2013/02/06(水) 22:10:30.55

>>47
よーしパパそれほどHaskellerじゃないけど調子に乗って習作書いちゃうぞー

nthElementIs :: [a] -> Int -> a
nthElementIs (x:xs) num | num == 1 = x
. | num > 1 = nthElementIs xs (num - 1)

これじゃいかんの ?

不適なデータが来ても何とかするなら

nthElementIs :: [a] -> Int -> Maybe a

nthElementIs [] _ = Nothing
nthElementIs (x:xs) num | num < 1 = Nothing
. | num == 1 = Just x
. | num > 1 = nthElementIs xs (num - 1)

とか

51 ：デフォルトの名無しさん：2013/02/06(水) 22:20:12.67

>>50
ありがとうございます。
コードがすっきり分かり易いです。
エラー書くよりはMaybe使った方がやはりいいのでしょうか？
後、ガードとcaseの使い分けはあるのでしょうか？
聞いてばっかですいません。

52 ：デフォルトの名無しさん：2013/02/06(水) 22:23:54.11

>>50はものすごく教科書的でいいね。

nthElementIs xs num = last . take num $ xs

俺ならこの質問されたらめんどくさいから一行でこう書くわ
駄目な大人になってしまった

53 ：デフォルトの名無しさん：2013/02/06(水) 22:37:16.96

nthElementIs xs n = xs!!(n-1)

54 ：デフォルトの名無しさん：2013/02/06(水) 22:41:13.31

>>53でFA
これ以外の正解はない

55 ：デフォルトの名無しさん：2013/02/06(水) 22:46:36.68

明らかに学習目的なのに既存の関数を使って正解って…

あとインデックスは0から開始するように習慣づけるべきだと誰も指摘しないことに驚いた

56 ：デフォルトの名無しさん：2013/02/06(水) 22:52:17.68

>>46
分離したというけど、無関係ではないよね
IOの中では関数を適用できるが、関数の中ではIOを実行できない、という関係
コールバック関数を自分でコールできないみたいな状況に似ている

57 ：デフォルトの名無しさん：2013/02/06(水) 22:56:07.24

既存の関数使わないでどう答えろと
(==)も(<)も(>)も(!!)も、全部既存の関数だぞ

58 ：デフォルトの名無しさん：2013/02/06(水) 23:20:28.47

monadだから分離されているというべきなのか。
IOの型修飾を外すには、(>>=)するしか無いから分離されているというか、、、

59 ：50：2013/02/06(水) 23:51:46.77

>>51
> エラー書くよりはMaybe使った方がやはりいいのでしょうか？
> 後、ガードとcaseの使い分けはあるのでしょうか？

すまん。自分も習いはじめでよくわからんとです。

>>52
教科書読んだばかりですから !!
一流のHaskellerになると関数合成ばしばし使うのですね。
自分、関数合成にまだ発想が行きません。

便乗質問ですが、ピリオドとダラーの使い分けなんですけど、
nthElementIs xs num = last . take num $ xs
も
nthElementIs xs num = last $ take num $ xs
も
nthElementIs xs num = last $ take num xs
も結果は同じなのですがどう使い分けてます ?

本来なら(引数の順番さ000え逆だったら、nthElementIs num xsだったら)
nthElementIs num = last . take num
って書きたかったのでしょうけど

>>55
> あとインデックスは0から開始するように習慣づけるべきだと誰も指摘しないことに驚いた

そうしなければいけない何らかの事情があるのかと思ってた
（(!!)を使うといけないのもエラー処理のためとか今後の拡張とかの理由かと思ってた）

60 ：デフォルトの名無しさん：2013/02/06(水) 23:55:00.06

>>57
「既存の（ほぼ答えそのものの）関数を使って…」って書いたら満足だったか？

ていうか、よく見たら思った以上に酷い回答ばっかだった

まず、「is」が付く名前は慣習的にBoolを返すものだから、「nthElement」か単に「nth」とすべき。

>>52はありえない
>>50は
(nthElement [] n)　がNothingを返すのはいいが、
(nthElement [1,2,3,4] -1) などは明らかにプログラミングエラーなのだからエラーにするべき。
（他の言語なら最後の要素を返すのも考えられるが）
そうしないと潜在的なバグがコードに紛れ込み、かえって品質を落とすことになる。

入門書の最初の方に出てくるような例なんだから、これくらいまともに回答してくれよ

61 ：デフォルトの名無しさん：2013/02/07(木) 00:37:35.34

人に文句言ってばかりで自分では何もしないカスがいるみたいだから、
俺が代わりにPreludeに載ってる!!の例から丸写ししてやる。

nthElement :: [a] -> Int -> a
nthElement xs n | n < 1 = error "nthElement: negative index"
nthElement [] _ = error "nthElement: index too large"
nthElement (x:_) 1 = x
nthElement (_:xs) n = nthElement xs (n - 1)

62 ：デフォルトの名無しさん：2013/02/07(木) 00:52:21.07

丸写しして気づいたけど、2chでの回答としては>>53が一番の正解で間違いないね
ほぼ答えそのものの関数があるならそれを示せばいいだけだ。わざわざ転記する必要ねーじゃん

63 ：デフォルトの名無しさん：2013/02/07(木) 01:08:02.48

>>61
酷いと言われて悔しかったのはわかるが、実際にいちばんまともなコメントをしているのは自分だと思うぞ。
名前から「Is」を削ったのは納得したからじゃないの？
（インデックスをわざわざ1から開始にするのは意味がわからないが…）

>>62
それなら答えは(!!)を使えということだろ。
あるいはソースへのリンクを貼るか
http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1/src/GHC-List.html#%21%21

64 ：デフォルトの名無しさん：2013/02/07(木) 01:17:45.78

病院池

65 ：デフォルトの名無しさん：2013/02/07(木) 01:27:36.33

>実際にいちばんまともなコメントをしているのは自分だと思う
実際に一番まともなコメントは>>63以外にないと思うぞ。マジで。
名前は突っ込まれたから変えたけど正直問題の本質と関係ないからどうでもいいし

>インデックスをわざわざ1から開始にするのは意味がわからない
問題読み直したら？

>それなら答えは(!!)を使えということだろ。
だからそれが>>63で既出だって話。ぐだぐだ書いてる俺らより余程簡潔にまとめてるし、
ソースのリンクなんか貼らなくてもPreludeのソースなんてド素人でも見つけられる。

66 ：デフォルトの名無しさん：2013/02/07(木) 01:28:48.39

安価ミス。>>63じゃなくて>>53ね

×実際に一番まともなコメントは>>63以外にないと思うぞ。
○実際に一番まともなコメントは>>53以外にないと思うぞ。

×だからそれが>>63で既出だって話。ぐだぐだ書いてる俺らより余程簡潔にまとめてるし、
○だからそれが>>53で既出だって話。ぐだぐだ書いてる俺らより余程簡潔にまとめてるし、

67 ：デフォルトの名無しさん：2013/02/07(木) 01:31:57.55

>>62
あなたがそれを一番の正解と判断するに至った価値基準は？
それはあなた以外の人も持っていて当然のもの？
それ以外の価値基準が存在しうることは理解してる？

68 ：デフォルトの名無しさん：2013/02/07(木) 06:04:09.76

なんかここ怖い

69 ：デフォルトの名無しさん：2013/02/07(木) 07:11:57.30

基地外隔離スレだから仕方ない

70 ：デフォルトの名無しさん：2013/02/07(木) 07:26:24.38

>>65,66
なんでそんなに切れてるわけ？
>>47を見れば初学者なのは一目瞭然なんだから、インデックスは0から始めるものだと教えてやるのは当然だし、
どう考えても争うような本質的な問題じゃないだろ？

> ソースのリンクなんか貼らなくてもPreludeのソースなんてド素人でも見つけられる。
リンクを貼るの難しそうだしね。無理言って悪かったよ。

71 ：デフォルトの名無しさん：2013/02/07(木) 07:26:39.08

Haskell怖いです(震え声)

72 ：デフォルトの名無しさん：2013/02/07(木) 07:30:47.90

Haskellは怖くないよ
>>47とかたぶんFizzBuzz並に簡単な問題
それさえもできない人が何故か回答してるからおかしくなってるだけで

73 ：デフォルトの名無しさん：2013/02/07(木) 07:55:12.22

nth elementの取り出しなんて、preludeのソース詠めばいいだろ

74 ：デフォルトの名無しさん：2013/02/07(木) 08:30:01.16

どうみても頭がおかしいのは>>60ひとり

75 ：デフォルトの名無しさん：2013/02/07(木) 10:25:36.22

入門書読んだ後は、!!とか自作して遊んでたな。。。(遠い目)

76 ：デフォルトの名無しさん：2013/02/07(木) 18:35:12.00

プログラミングhaskell
8章まで来たけど、いよいよ全く意味がわからなくなって挫折しそうボスケテ！

77 ：デフォルトの名無しさん：2013/02/07(木) 19:13:34.93

８章は載ってるコードじゃ動かないし、その後の章の知識が必要だから初見で理解するのはたぶん無理だろう
理解できると一番面白い章だけど、最初は適当に読み流した方がいい

78 ：デフォルトの名無しさん：2013/02/07(木) 20:39:42.42

8章から難易度がスコーンと上がるからな
すごいHの方に浮気するのもアリだと思う

79 ：デフォルトの名無しさん：2013/02/07(木) 21:16:21.92

個人的にはすごいHaskellの方が難しいと思う
とくに序盤は

80 ：デフォルトの名無しさん：2013/02/08(金) 01:55:53.33

RWHで挫折してまたRWHに戻ってくるまでが勉強です

81 ：デフォルトの名無しさん：2013/02/08(金) 13:22:59.19

dammy

82 ：デフォルトの名無しさん：2013/02/09(土) 12:25:40.88

>>77
８章はPreludeのdo,returnとかが邪魔してコード通り動かないよなｗ
とりあえずdo表記を使わず、Preludeにある関数は名前を変えて
なんとか練習問題まで終わらせたけど・・・。

９章の電卓も期待した動きと違う。主に遅延評価のせいだと思うけど。
入力した式が評価されるまでputStrの実行も遅延させられるみたいで、
電卓のテンキー（飾り）が表示されない・・・。

俺は練習問題に関してはここで心が折れたｗ

本文は、１０章まで読んだけど、１１章からは応用問題みたいだから
後でいいやと読むのを止めたｗ

83 ：デフォルトの名無しさん：2013/02/09(土) 18:22:47.83

Haskellの最初の挫折ポイントはモナド
次の挫折ポイントが値の直接変更はSTモナド内で引きこもってやるということ

次の挫折ポイントがモナド変換

84 ：デフォルトの名無しさん：2013/02/09(土) 19:15:19.99

モナドって、"最初の"挫折ポイントか？
私は、まだモナド山に入山してさえいない。その前でちょっと挫折気味。

今、プログラミングHaskell 13章を読んでいる最中。

すごいHaskellはアダプティブファンクターのところで止まっている。

プログラミングHaskell を読み終わったら、すごいHaskellのアダプティブファンクター
～モナドのところに進んでみる。

85 ：デフォルトの名無しさん：2013/02/09(土) 19:19:40.65

adaptive functor!

86 ：デフォルトの名無しさん：2013/02/09(土) 20:58:26.45

>アダプティブファンクター
挫折した感がものすごく良く伝わってくる

87 ：デフォルトの名無しさん：2013/02/09(土) 21:32:25.92

挫折ポイントはいっぱいある。
型クラス、型構築子、データ構築子などの独特な型の世界が
行く手を阻んでいる。
ついでに型でエラーが出まくって慣れないと
何のエラーかよくわからんのがなぁ。

88 ：デフォルトの名無しさん：2013/02/10(日) 06:36:10.45

走り出してからエラーになるくらいならコンパイル通らない方が正義

89 ：デフォルトの名無しさん：2013/02/10(日) 08:50:54.19

俺も正義だと思うが、それとエラーメッセージが分かりづらいのは別の話

90 ：デフォルトの名無しさん：2013/02/11(月) 01:41:11.39

コンパイラがプログラマの意図を読めない限り
ありのままに起こった事を言うしかない
何を言ってるか分からないと思うが

91 ：デフォルトの名無しさん：2013/02/11(月) 03:00:26.98

それとエラーメッセージが分かりづらいのは別の話

92 ：デフォルトの名無しさん：2013/02/11(月) 09:28:40.81

Haskell（GHC）で最も意味不明のエラー in 俺

＊ is a rigid type variable bound by ～

93 ：デフォルトの名無しさん：2013/02/11(月) 10:59:30.81

data Day = Mon | Tue | Wed | Thu | Fri | Sat | Sun
deriving (Eq, Show)
fromDayToNum :: Day -> Int
fromDayToNum day = case (day) of
Mon-> 0
Tue -> 1
Wed -> 2
Thu -> 3
Fri -> 4
Sat -> 5
Sun -> 6
fromNumToDay :: Int -> Day
fromNumToDay number = case (number) of
0 -> Mon
1 -> Tue
2 -> Wed
3 -> Thu
4 -> Fri
5 -> Sat
6 -> Sun

isWorkDay :: Day -> Bool
isWorkDay day
| (fromDayToNum day >= 0 && fromDayToNum day <= 4) = True
| otherwise = False

isWorkDay' :: Day -> Bool
isWorkDay' day = case (day) of
(fromDayToNum day >= 0 && fromDayToNum day <= 4)-> True
_-> False
何故、isWorkDay'　はfromDayToNumを使えないのでしょうか？

94 ：デフォルトの名無しさん：2013/02/11(月) 11:26:59.76

>>93
case 中の -> の左側はパターンしか書けない
関数適用はパターンではないので、そういう使い方はできない

パターンは例をたくさん見ると理解がはやいと思う
直感的には構造で分岐する

95 ：デフォルトの名無しさん：2013/02/11(月) 12:02:11.43

例を見るもなにも、パターンマッチには基本的にコンストラクタしか使えないってだけじゃないの？
一応例外的にリストは[]が使えるけど

96 ：デフォルトの名無しさん：2013/02/11(月) 12:48:36.09

基本的にリテラルも使える

97 ：デフォルトの名無しさん：2013/02/11(月) 13:58:43.34

[]が例外的？　意味ワカンネ

98 ：デフォルトの名無しさん：2013/02/11(月) 14:03:16.68

基本的にn+kは消えた

99 ：デフォルトの名無しさん：2013/02/11(月) 14:06:21.42

束縛した変数を使えるという思い込みがたまに発生してデバッグに時間がかかる

100 ：デフォルトの名無しさん：2013/02/11(月) 14:30:09.01

>>97
空リストじゃなくて[]を使ったパターンのことね
[a, b]みたいなパターンも使えるけど、これはコンストラクタじゃないでしょ？

101 ：デフォルトの名無しさん：2013/02/11(月) 14:33:49.34

Haskellはあくまで静的型付けなんだという事が
コンパイル時のストレスと
実行時のパフォーマンスをもたらす

102 ：デフォルトの名無しさん：2013/02/11(月) 14:49:47.60

次の2つは同じだから、セマンティクス上はコンストラクタでパターンマッチさせて要素を変数にバインドしてる

f x = case x of
[a,b] -> b

g x = case x of
((:) a ((:) b [])) -> b

http://www.sampou.org/haskell/report-revised-j/exps.html#lists
http://www.sampou.org/haskell/report-revised-j/basic.html#basic-lists

103 ：デフォルトの名無しさん：2013/02/11(月) 19:02:29.99

> ((:) a ((:) b [])) -> b

( ´;ﾟ;ё;ﾟ;)　←これに見えた

104 ：デフォルトの名無しさん：2013/02/11(月) 20:05:23.50

なるほど、つまり関数適用はガードで。
それ以外はcaseで良いと？

riverse :: String -> String
riverse list = case (list) of
[] -> []
(x:xs) -> riverse xs ++ [x]
xRiverse :: String -> String -> Bool
xRiverse list rlist = case (list) of
[] -> if (rlist == [])
then True
else False
(x:xs) -> if (list == (riverse rlist))
then True
else False

では何故xRiverseの(list == (riverse rlist))は使えるのでしょうか？

105 ：デフォルトの名無しさん：2013/02/11(月) 20:27:57.97

なぜも糞もねーだろ
もう一回入門書読み直してこい

106 ：デフォルトの名無しさん：2013/02/11(月) 20:28:33.77

>>104
if e1 then e2 else e3
という形のとき e1 はBool の式なら何でもいい
list == (riverse rlist) は Bool の式なので使える
式っていうのは、どんどん計算することができて、途中に関数適用があったら実際に適応して計算を継続していく
そして、どんどん計算した結果、(Boolの式なので)TrueかFalseになる
もしTrueならif全体が e2 に、Falseなら e3 になる

107 ：デフォルトの名無しさん：2013/02/11(月) 20:31:24.19

ポインタ同値性を判定する方法ってなんかない？

108 ：デフォルトの名無しさん：2013/02/11(月) 20:45:26.08

ポインタアナリシス

109 ：デフォルトの名無しさん：2013/02/11(月) 20:54:35.49

>>105~106
丁寧な説明ありがとうございます。
今ちょうど入門書を読んでいる所だったので。
ありがとうございました。

110 ：デフォルトの名無しさん：2013/02/12(火) 06:54:40.32

>>107
おまえが入門者なら、答えは「ない」
そうでないなら、ポインタ同値性で何をやりたいかによる

111 ：デフォルトの名無しさん：2013/02/12(火) 06:56:54.59

引数を１つ取って、引数の型シノニムを文字列として返す関数ってどういう風にやればいいの？

112 ：デフォルトの名無しさん：2013/02/12(火) 07:00:32.14

>引数の型シノニム
って何？
引数の型を文字列として返したいなら、

import Data.Typeable

typeName :: (Typeable a) => a -> String
typeName = show . typeOf

113 ：デフォルトの名無しさん：2013/02/12(火) 07:19:50.40

>>112
引数の型を返して欲しいけど、型に別名つけたときに別名が返って欲しいという意味で型シノニムと言ってみた。

型が返るだけでも十分だ。ありがとう。

114 ：デフォルトの名無しさん：2013/02/12(火) 17:59:38.15

JavaやC#のインターフェースはクラスにある約束事(メソッドなど)の実装を強いることにより、その約束事を前提にロジックを書くことができると思いますが、
同時に、その約束事を実装しているものであれば実行時にそのロジックにどんなオブジェクトでも渡せるという仕組みでもあると思います。例えばUIの何らかのコントロールが渡されてきてDrawメソッドが呼ばれるような。

Haskellの型クラスはある約束事を想定するという意味では似ていると思いますが、コンパイル時に呼ばれるものが解決されて実行時にその約束事を守るどんなものでも渡せるというものではないですよね？

Haskellの場合は上にあげたような何らかのコントロールを渡して何らかの処理をするような処理というのはどんなふうに書くもんでしょうか?

115 ：デフォルトの名無しさん：2013/02/12(火) 19:13:43.92

何言ってるんだかわからん

116 ：デフォルトの名無しさん：2013/02/12(火) 19:40:23.91

>>114
例えば (>>) :: Monad m => m a -> m b -> m b。
これは、Monad 型クラスのインスタンス型であれば
どのような型の値でも被演算子になれる（引数として適用できる）のだが、
このようなものでは不満か？

ただ、この場合は m a 型引数と m b 型引数は
Monad 型クラスの同じインスタンス型でなければならないがな。

f :: (Monad m, Monad n) => m a -> n b -> m a
とかなら Monad 型クラスの違うインスタンス型の値が引数になれる。

> Haskellの場合は上にあげたような何らかのコントロールを渡して何らかの処理をするような処理というのはどんなふうに書くもんでしょうか?

何らかの型クラスのインスタンス型の値を渡したり、関数を渡したり、
関数内でパースされ解釈・計算される何らかの値（計算式を表したツリーとか）を渡す、など。

117 ：デフォルトの名無しさん：2013/02/12(火) 20:18:33.90

>>114
ExistentialQuantification拡張を使えば、型クラスをOOPのインターフェースのように使ってオブジェクト指向の多態っぽいことが出来る
ttp://www.haskell.org/haskellwiki/Existential_type

118 ：デフォルトの名無しさん：2013/02/12(火) 22:25:36.74

プログラミングHaskellなんとか読み終わった。
「本物のプログラマはHaskellを使う」の３章～４章あたりを読んでいる最中。
モナドはまだ‥わけわからんが、とりあえず式を追うことまでは可になった。

119 ：デフォルトの名無しさん：2013/02/13(水) 00:24:00.07

Haskell本って突然"->"とか説明もなく記号が出てくるの何とかならないのかって思う
初めて読んだとき->って何だよって本投げたわ

120 ：デフォルトの名無しさん：2013/02/13(水) 00:45:42.76

説明は必要になるまで遅延されます

121 ：デフォルトの名無しさん：2013/02/13(水) 07:14:39.41

質問です。
reverseList :: [a] -> [a]
reverseList list = case (list) of
[]-> []
(x:xs)-> reverseList xs ++ [x]

isPalindrome :: (Eq a) => [a] -> Bool
isPalindrome list
| (list == (reverseList list))= True
| otherwise= False
のisPalindromeは(Eq a)=>を入れないと（＝＝）のテストが出来ないことが分かりました。しかし、
isSum :: [a] -> Int
isSum [] = 0
isSum (x:xs) = 1 + isSum xs　　　　は (Num a) =>が無しでも動きます。
どう言う時に"()=>"を使用すればいいのしょうか？また、全ての関数にこの"()=>"を付けた方がよりいいのでしょうか？

122 ：デフォルトの名無しさん：2013/02/13(水) 07:40:19.86

>>117
その2.2-2.3辺りの事ですね。
んーとこれはコンパイラのスイッチでこういう書き方を許容出来る様に出来るけどデフォルトでは出来ないってことですかね。デフォルトではその辺どうするんでしょう？
ray tracerの例で言ってるようなrendableであるヘテロジニアスなリストとして扱って、時にはその中でballのものだけごにょごにょするような。
通常は代数的データ型でやるんでしょうが、例えばUIフレームワークみたいなものを作るとしたらどうしても後からフレームワーク外で後から定義されたものも同じ様に扱うニーズが有るので代数的データ型は使えないだろうと。

>>116 自分が言いたかったのは>>117に有る様なヘテロジニアスなリストを元にdynamic dispatchするにはとなると思います。
書き方が足らなくてすいませんでした。

123 ：デフォルトの名無しさん：2013/02/13(水) 08:36:54.73

型は良い事をするための物ではなく、悪い事を防ぐための免疫だよ
悪いやつが出てきてないのに何かしようとするのはアレルギーと同じ
アレルギーをなおすには型を弱くすればいいよ

124 ：デフォルトの名無しさん：2013/02/13(水) 09:13:34.03

>>121
isSum 内の + は型 a に関して足してるわけじゃないので (Num a) => という a に関する制約は不要
a にかかわらず要素の数を足している

コンパイルエラーになった時のように、必要なときに必要なだけ書けばいいと思うよ

125 ：デフォルトの名無しさん：2013/02/13(水) 13:37:37.02

ありがとうございます。
きっちり型が制限されてないときだけ（）＝＞を使います。

けど、どう言うときに「型がきっちり制限されている」のか分かるのでしょうか？[a]がElemとかShowとかが必要な時？
持ってる本（introduction to functional programming language using haskell）では良く分からなかったので。

126 ：デフォルトの名無しさん：2013/02/13(水) 15:10:06.26

単相性制限ってまだ生きてる？

127 ：デフォルトの名無しさん：2013/02/13(水) 18:42:19.23

windowsにhaskellをインストールしたら1GBも容量食った
何でこんなにでかいの？でかすぎやしないか？

128 ：デフォルトの名無しさん：2013/02/13(水) 20:08:54.01

>>127
> 何でこんなにでかいの？

サブフォルダ一つ一つの容量を調べてみれば、
何が容量を食っているのか分かるだろ。
その「何が」が分かれば、「どうしてか」も
今よりはもっと良く推測できるだろ。

何故そんな簡単な努力を怠って質問してくる？

129 ：デフォルトの名無しさん：2013/02/13(水) 20:13:01.85

それは簡単な努力じゃないだろ

130 ：デフォルトの名無しさん：2013/02/13(水) 20:25:07.57

プロHaskeller様にとっては簡単なんだろ

131 ：デフォルトの名無しさん：2013/02/13(水) 20:28:34.53

普通にエクスプローラーを開いてフォルダのプロパティを見れば良いだけだが

もちろん、フォルダのサイズを一覧できる Haskell プログラムを書いても良いが、
そこまでしなくても分かるだろ

132 ：デフォルトの名無しさん：2013/02/13(水) 20:46:23.62

なんで食い下がるんだよｗ
さしたる瑕疵のない質問に対して恫喝的な態度を取ったのを非難されてるんだろ

133 ：デフォルトの名無しさん：2013/02/13(水) 20:51:08.42

>>128
ハア？そんなの調べてどうすんの？アホなの？

134 ：デフォルトの名無しさん：2013/02/13(水) 20:56:47.87

では、簡単な努力もしない教えて君には、
どのような態度をとれば良かったんだ？

俺は努力して調べろと言った。
調べる方法も示した。

これ以上の適切なレスはそうそう無いだろう。

>>133
調べれば、「何でこんなにでかいの？」という質問に対する答えを、
「自分で」より推測しやすくなる。

135 ：デフォルトの名無しさん：2013/02/13(水) 20:58:47.41

>>134
だからさ、それを調べたところで何になるの？

136 ：デフォルトの名無しさん：2013/02/13(水) 21:02:24.41

>>135
疑問を自分で解消するための糸口が得られる。

137 ：デフォルトの名無しさん：2013/02/13(水) 21:03:33.46

いいぞもっとやれ

138 ：デフォルトの名無しさん：2013/02/13(水) 21:05:12.84

>>137
何を？何故？

139 ：デフォルトの名無しさん：2013/02/13(水) 21:08:36.06

>>136
だからサイズが大きいファイルなどを調べてどうすんの？
開発者にもっと軽量してくださいってお願いするの？
さっきから的外れな話してんじゃねえよ

140 ：デフォルトの名無しさん：2013/02/13(水) 21:15:40.81

>>139

>>127 が質問しているのはインストールしたHaskellの容量が1GBもある「理由」。
何に容量を食われているのか分かれば、そこから理由が推測できる。

（でかすぎやしないか？というのは、もっと小さくできないのかという思いを
疑問系で発言しただけのことだろうから無視）

もし >>127 が単なる愚痴であるなら、そもそも、そんなものはチラ裏にでも書いておけ

141 ：デフォルトの名無しさん：2013/02/13(水) 21:21:54.04

これから数スレ以内に "アスペ" が含まれる確率80%

142 ：デフォルトの名無しさん：2013/02/13(水) 21:25:17.78

http://stackoverflow.com/questions/4858585/why-is-ghc-so-large-big

143 ：デフォルトの名無しさん：2013/02/13(水) 21:40:48.01

イイからとっととファイルの階層を容量やフォルダ名、フォルダの中身をZipper的に辿れるもんサクッと作れや( ´Д`)y━･~~

144 ：デフォルトの名無しさん：2013/02/13(水) 22:01:35.75

なんでこんなにでかいの？
↓
フォルダ見てみればいいじゃん
↓
はあ？なんでそんなことしなきゃいけないんだよ

145 ：デフォルトの名無しさん：2013/02/13(水) 22:16:34.62

>>144
悪意を感じるな。
意図的に省略したか？

なんでこんなにでかいの？
↓
フォルダのサイズを見れば「何が」でかいのか分かる
「何が」が分かれば「どうしてか」は今よりもより良く推測できる
↓
はあ？なんでそんなことしなきゃいけないんだよ

だろうが。

単に、なんででかいんだよ、と言うだけで思考停止してるんじゃなくて、
自分でできるところまでまず調べろ。
容量をでかくしている主犯を調べるのはそのとっかかりだ。
その主犯がHaskellにどう関係してくるのか、
そいつは何故そんなにもでかいのか、
容量をでかくしているのはそいつだけなのか、これらを考えるのはその後だ。

146 ：デフォルトの名無しさん：2013/02/13(水) 23:27:22.65

>>125
とりあえず、
isSum ['a', 'b', 'c']
が
3になるのはよろしいでしょうか ?

mySum [] = 0
mySum (x:xs) = x + mySum xs
の場合(Num a) => aという制約が必要になります。

なぜなら、+の部分を型で書くと a + Intとなります。
aがNumのインスタンス?でなければならないので
Num a => aという制約が必要になります。

isNumの場合そのようなものはなく+の両辺の型は
1 (<= Numのインスタンス?) + Intであり、aに関する制約はまったく必要ないので
制約に関する記述は必要なくなります。

これでいいのかな?
添削して

インスタンスって表現でいいんだっけ ?

147 ：デフォルトの名無しさん：2013/02/13(水) 23:55:55.60

>>146
0 :: Num a => a
(+) :: Num a => a -> a -> a
やな
Intに限らない

148 ：デフォルトの名無しさん：2013/02/14(木) 03:51:26.44

最近血痰と喘息の気があるな
アスペルギルスかな

149 ：デフォルトの名無しさん：2013/02/14(木) 10:58:17.65

>>146
つまり、>>121のisPalindromeは相等性を持つ型（値が明確）と認識されなかったからダメだった。
だから、その式ではa==aがInt == Int、Bool == Bool、String==String　なのか解らないが為に()=>の制約が必要？
制約って関数の型をもっと強めることも出きるような物って感じがします。

150 ：デフォルトの名無しさん：2013/02/14(木) 13:13:38.62

型変数a, b, ...は制約ではなく写像って感じ
型変数に具体的な型を入れると何かが出てくる
入れる際に制約がもしあれば型クラスを指定する

151 ：146：2013/02/15(金) 00:48:04.33

>>149
ところでHaskellってList同士の比較も素でできるのすごいなぁ

で、
(==) [] lst = lst == []
(==) (x:xs) (y:ys) = (x == y) && (xs == ys)
だとして
x == yの部分が(Eq a) => a -> a -> Boolであるので
xの型は(Eq a) => aである必要があります。

IntもBoolもStringもEqのインスタンスなのですが、例えば
add1 x = x + 1
のadd1の型は(Num a => a -> a)(aをとりaを返す*関数*)となり
Eqのインスタンスではなく(==)の引数にすることができません。
（add1 == add1はエラーになる)

isPalindromeで(==)を使っている以上aはEqのインスタンスである
必要がある以上、引数がEqのインスタンスであることを要求する意味で
（Eqのインスタンスでない型の引数を拒絶する意味で）
Eq a => a
の制約が必要となります。

こんな感じ ?

152 ：デフォルトの名無しさん：2013/02/15(金) 01:30:24.34

素ではできんよ。==を使いたかったら[a]型の型変数aはEq型クラスのインスタンスである必要がある。

153 ：デフォルトの名無しさん：2013/02/15(金) 01:32:33.49

遅レスだけど

>>100
それは単なるシンタックスシュガーだろ
a:b:[]と同じなんだから実質コンストラクタ:を使ってる

154 ：デフォルトの名無しさん：2013/02/15(金) 19:22:36.98

>>153
>>102

155 ：デフォルトの名無しさん：2013/02/16(土) 19:47:16.54

Haskellで用いられるモナドと、ライプニッツが主張したモナド、
何か関係ありますか？

156 ：デフォルトの名無しさん：2013/02/16(土) 20:06:57.83

ありません。次どうぞ

157 ：デフォルトの名無しさん：2013/02/16(土) 20:17:13.44

同じ名前なのは偶然ですか？

根底の概念の部分で共通性があるとか、とういう事も無いのですか？

158 ：デフォルトの名無しさん：2013/02/16(土) 20:30:32.69

黙れ

159 ：デフォルトの名無しさん：2013/02/16(土) 20:50:39.64

QtでGUIが構築できるようになるパッケージって無いですか

160 ：デフォルトの名無しさん：2013/02/17(日) 03:51:51.74

>>158
↑
この人怖い！

161 ：デフォルトの名無しさん：2013/02/17(日) 11:15:41.97

>>160
いや、言われて当然だろう。

ライプニッツがモナドを提唱していた事を知っていたのなら、
「モナドライプニッツ haskell」でググれば、
それぞれのモナドが無関係なことは直ぐ分かる。
それもしないで食い下がってくれば言いたくもなるぞ。

最近、簡単な調査を怠ってくだらない質問してくる奴多いな。

162 ：デフォルトの名無しさん：2013/02/17(日) 16:35:21.08

haskellスレは今日も殺伐

163 ：デフォルトの名無しさん：2013/02/17(日) 17:52:26.05

>>161
まだ根に持ってるの？ｗ

164 ：デフォルトの名無しさん：2013/02/17(日) 21:02:56.91

Foldableはあるのに
Filterableってクラスはないのかしら

165 ：デフォルトの名無しさん：2013/02/17(日) 21:30:23.43

標準ライブラリには無いね。

Filterableクラスは、具体的にはどんな関数を持ったクラス？
どのようなケースで必要になる？あるいは、どのようなケースであると便利？

166 ：デフォルトの名無しさん：2013/02/17(日) 21:35:04.15

[a]にもSet aにも同名で同機能なfilterという関数が定義されてるのに
まとめられてないのが気持ち悪く感じたので
同じような機能なら何でもかんでもまとめてクラスにしちゃおうって考え方はマズイかなあ

167 ：デフォルトの名無しさん：2013/02/17(日) 21:42:58.81

foldは単位元と二項演算が必要というのが制約だけど、filterは大した制約ないでしょ?

168 ：デフォルトの名無しさん：2013/02/17(日) 21:56:30.57

いや普通にあってもおかしくないけどfilterable
何がそんなに気に障るのか

169 ：デフォルトの名無しさん：2013/02/17(日) 21:57:24.13

大した制約があるかどうかが重要であるという説明をしないと
大した制約があるかどうかに着目した理由がわからない

170 ：デフォルトの名無しさん：2013/02/17(日) 22:07:20.91

collctionならnatualにfilterableだわねえ

171 ：デフォルトの名無しさん：2013/02/17(日) 22:13:08.21

リストの方のfilterは集合と違って、順序が保存される点で厳密には同じ機能でないからとか

172 ：デフォルトの名無しさん：2013/02/17(日) 22:13:50.30

>>166
Data.List と Data.Set には、filter の他にも
partition や split、(\\) など、共通な関数はあるが、
これらはどうする？

Data.Array 系や Data.Map 系などと Data.Set の間にもいくつかあるね。

173 ：デフォルトの名無しさん：2013/02/17(日) 22:21:15.08

Foldableからfilterは作れないわけではない
http://www.haskell.org/haskellwiki/Foldable_and_Traversable
ApplicativeとMonoidを要求してるけど、Applicativeに関してはpureしか使わないから、あまり誉められた型クラスの
使い方ではない
しかし残念ながら a -> f a のみの型クラスはデフォルトにはない

リストやSetはMonoidにできるけど、Mapなんかは無理だから、
filterを一般化するには専用の型クラスを作るしかないのかな？

174 ：デフォルトの名無しさん：2013/02/17(日) 22:26:47.24

>>171
同じ型のコレクションになるんだから当たり前かと。

175 ：デフォルトの名無しさん：2013/02/18(月) 03:39:16.79

instance Filterable (Hoge a) eliciting Foldable
なんて機能があればいいな(提案)

176 ：デフォルトの名無しさん：2013/02/18(月) 13:39:44.19

もう目が覚めました
今日からhaskellやめてpython使いになります

177 ：デフォルトの名無しさん：2013/02/18(月) 13:47:21.09

>>176
まあちょっと座って落ち着きなさい
このお茶を飲みなさいな

178 ：デフォルトの名無しさん：2013/02/18(月) 13:56:17.46

>>176
お前にOCamlを使う権利を与えよう

179 ：デフォルトの名無しさん：2013/02/18(月) 15:27:36.99

OPyH（ｵﾊﾟｰｲｴｯﾁ）

180 ：デフォルトの名無しさん：2013/02/18(月) 20:15:44.39

Haskellって、最も目を覚ましていないと使えない言語だと思う

181 ：デフォルトの名無しさん：2013/02/18(月) 21:39:12.72

そういう自画自賛的なのは要らないから

182 ：デフォルトの名無しさん：2013/02/18(月) 22:02:57.67

眠い頭じゃコードが書けないってことだろ

183 ：デフォルトの名無しさん：2013/02/18(月) 22:07:24.60

Queryable Combinable Filterable Indexed とか全部作っちゃえよ

http://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data-Set.html

184 ：デフォルトの名無しさん：2013/02/18(月) 22:35:39.05

ハッスル！ハッスル！

185 ：デフォルトの名無しさん：2013/02/19(火) 02:25:51.81

>>181
ここを追い出されたらどこへ行けば……

186 ：デフォルトの名無しさん：2013/02/19(火) 03:28:57.54

別に追い出すなんて言ってないんだから……
べべ別にアンタが居なくなったら寂しいとかそういうんじゃないんだからねっ！

187 ：デフォルトの名無しさん：2013/02/19(火) 08:41:26.00

やはりRubyにおけるRails的なものが無いと広まらない
と思ったけどYesodがそういう位置づけだったか
「Yesodだとこんな簡単にWebアプリが作れる！！」的なステマが足りないのだろうか

188 ：デフォルトの名無しさん：2013/02/19(火) 10:35:36.13

売り込むなら簡単よりも堅牢とかじゃない？
正直Rails等を置き換えるほどのものじゃないと思うけど

189 ：デフォルトの名無しさん：2013/02/19(火) 10:58:08.96

「Yesodだとこんな堅牢にWebアプリが作れる！！」
だと、それが本当だとしても、インパクトが少ない。
目を輝かせたニュービーが大量流入するぐらいのキャッチーさが欲しいところ。

190 ：デフォルトの名無しさん：2013/02/19(火) 12:38:49.18

10分のコーディングでスゲーサイト作るところをYouTubeにアップするとか

191 ：デフォルトの名無しさん：2013/02/19(火) 13:38:00.12

そういうのはもう溢れてるだろ……

192 ：デフォルトの名無しさん：2013/02/19(火) 13:44:32.81

Haskellで作ったシステムで金融危機予知してぼろ儲けしたはｗｗｗｗｗ
みたいな事するしかないな

193 ：デフォルトの名無しさん：2013/02/19(火) 13:48:26.51

>>189
イージーカムイジリーオカダというではないか
そもそもHaskellの取っ付きにくさを見ればキャッチーなんて縁遠くて然るべきなのだ

Haskellの標語には質実剛健こそ相応しい

194 ：デフォルトの名無しさん：2013/02/19(火) 13:58:14.39

こういう奴がいる限りは流行んないでしょ

195 ：デフォルトの名無しさん：2013/02/19(火) 14:13:13.90

僕が間違ってました

196 ：デフォルトの名無しさん：2013/02/19(火) 14:18:51.35

全力で成功を回避する

197 ：デフォルトの名無しさん：2013/02/19(火) 15:35:29.87

入門書の最初の方で必ずと言っていいほど、素数を求めるとかの数学的な例題を出すのがいけないと思う
そのせいで他言語やってきた普通の人が他の言語で解決してきた問題をhaskell(関数型言語)でどう解決するのかがぴんとこなくなっていると思う

198 ：デフォルトの名無しさん：2013/02/19(火) 16:47:25.91

入門書自体そんなにないけど最初に素数を求める本なんて具体的にあったっけ？

199 ：デフォルトの名無しさん：2013/02/19(火) 17:14:52.07

>>197
底辺はお呼びじゃない。

200 ：デフォルトの名無しさん：2013/02/19(火) 17:21:42.63

>>197
そう言う意味では「ふつける」はいい本だったと思う
何故か一部で評判が悪いけど

201 ：デフォルトの名無しさん：2013/02/19(火) 17:28:04.13

Haskell十分流行ってんじゃん
Smalltalkと比べろ

202 ：デフォルトの名無しさん：2013/02/19(火) 17:28:32.84

RealWorldHaskellみたいな本が増えるといいんですけどね
Natural Language Processing for the Working Programmer(Web上で無料で読めるからググれ)
はNLPを題材にしてHaskellも同時に学ぶという本で、
良さそうだったんだけど、まだ未完成。あと英語だし。

203 ：デフォルトの名無しさん：2013/02/19(火) 17:34:04.94

その本のタイトルちょっと慣用とずれてるよね。
応用を視野に入れて理論をスッキリと概説するのが～ for working ～シリーズなので。
タイトルに反してHaskellコードベッタリな本になってしまってる。

204 ：デフォルトの名無しさん：2013/02/19(火) 17:36:32.47

Effective Haskellみたいな本はないの？

205 ：デフォルトの名無しさん：2013/02/19(火) 17:40:36.40

RWH以外のなにかを求めている？

206 ：デフォルトの名無しさん：2013/02/19(火) 17:46:44.86

RWHは内容的にも物理的にも重い
そしてちょっと古い

207 ：デフォルトの名無しさん：2013/02/19(火) 18:38:10.92

・HaskellのTips本が無い

・設計上の陥りやすい罠とその回避策をまとめた本が無い

・Haskellデザインパターンが無い

・Haskellメタプログラミング（HMP）本が無い

・HaskellのガベコレがJavaに適わない

・『Haskellの設計と進化』本が無い

・Haskellマガジンが創刊されない

・Haskellラムダキーホルダーが無い

208 ：デフォルトの名無しさん：2013/02/19(火) 19:01:30.56

Haskellラムダキーホルダーって、それただの棒だよね

209 ：デフォルトの名無しさん：2013/02/19(火) 19:23:48.53

Haskellラムダお菓子として展開すればあるいは

210 ：デフォルトの名無しさん：2013/02/19(火) 19:41:23.45

なにより、マスコットが居ない

211 ：デフォルトの名無しさん：2013/02/19(火) 19:53:58.90

ラムダ饅頭

212 ：デフォルトの名無しさん：2013/02/19(火) 20:12:41.30

そうだ！必要なのはマスコットだ！

213 ：デフォルトの名無しさん：2013/02/19(火) 20:27:33.27

よし、マスコットは病弱そうな女の子風でどうだ？

214 ：デフォルトの名無しさん：2013/02/19(火) 20:37:27.30

Haskellの国際大会で日本の女子中学生が初めて金を取った

ってニュースをNHKが流せば、かなり人気出ると思う

215 ：デフォルトの名無しさん：2013/02/19(火) 21:12:46.43

必要ないだろ…

216 ：デフォルトの名無しさん：2013/02/19(火) 23:00:37.58

マス子ちゃん、君の堅牢な部分をみせてごらん？

217 ：デフォルトの名無しさん：2013/02/19(火) 23:09:06.87

レシピブックほしい

218 ：デフォルトの名無しさん：2013/02/20(水) 01:11:51.91

Set aとかMap k aってどうあがいてもFunctorとかのインスタンスに出来ないの？
出来るような仕様にしても良くね？不便じゃね？

219 ：デフォルトの名無しさん：2013/02/20(水) 02:57:49.14

>>216
ガッチガチじゃあないか……

どれ、早速……

ん、もうかい？意外に速いんだな

220 ：デフォルトの名無しさん：2013/02/20(水) 07:15:58.95

>>218
Map型は標準ライブラリの中でも既にFunctorクラスのインスタンスだよ。

Set型は標準ライブラリの中ではFunctorクラスのインスタンスではないが、
必要なら自分でインスタンス化すれば良いだけじゃないか？

221 ：デフォルトの名無しさん：2013/02/20(水) 08:05:38.31

遠隔操作事件のウィルスがHaskellで作られてたなら警察も操作やりやすかっただろうに( ´Д`)y━･~~

222 ：デフォルトの名無しさん：2013/02/20(水) 10:01:28.62

Set a は a がOrdのインスタンスである必要があるけどそれでもFunctorにできるの？
http://www.randomhacks.net/articles/2007/03/15/data-set-monad-haskell-macros
みたいにゴニョゴニョするしかないの？

223 ：デフォルトの名無しさん：2013/02/20(水) 10:18:39.68

Setはまともな形でFunctorにするのは無理だね

224 ：デフォルトの名無しさん：2013/02/20(水) 12:49:29.55

>>222
では逆に訊くが、もし Set 型が Functor クラスのインスタンスだったら、
Set a 型の値 x と関数 f::(a -> b) に対する関数適用 fmap f x は
どのような戻り値になって欲しいんだ？
具体的な値を使って例示＆説明してみてくれ。

その値と戻り値の組みが作れるかどうか＝ Functor クラスのインスタンスにできるかどうか
という事で良いんだよな？

225 ：デフォルトの名無しさん：2013/02/20(水) 12:53:49.46

>>223
まともって何だ？

今自分がプログラムするのに必要となる型に対して、
必要な分だけ過不足無くインスタンスを定義すれば良いだけだと思うが。

もしかして、fmap の結果が同じ値になってしまって、
Set の構造が元のものと変わってしまう、と言いたいのか？

でも、それは仕方ないだろ。
今自分がプログラムするのにそのような仕様が欲しいのなら、
そのようにプログラムすればいい。
構造が変わってしまっては困るのなら、
構造が変わらない場合だけを正しく定義し、
構造が変わる場合はエラーを出すように作れば良い。

226 ：デフォルトの名無しさん：2013/02/20(水) 13:24:49.73

>>225
instance Functor Set where
fmap = Set.map
とすれば型エラーになるはず

↓こんな風に
http://codepad.org/ynVAbAoF

fmapは(a->b)->Set a->Set bの関数を要求するけど、これにaとbがOrdであることを付け足すことが文法上無理って話じゃないの？

227 ：デフォルトの名無しさん：2013/02/20(水) 16:18:39.68

restricted monadとかいうのと同じテクニックを使ったまともじゃないFunctorの例
http://codepad.org/VdGgAakp

228 ：デフォルトの名無しさん：2013/02/20(水) 20:12:09.85

>>226
そりゃ fmap = Set.map なんてすればエラーになるに決まってる。

fmap = 自作しろ

という話だ。
正確に言えば、自分のプログラムの仕様に合うように自作しろ、ということだ。

あと、Set 型は instance (Ord a) => Set a ではない。
Monoid クラスのインスタンスであるために
型引数 a が Ord クラスのインスタンスであることが要求されるが、
Set 型自体が Ord クラスのインスタンスになっているわけではない。

まぁたしかに、Set 型を使う関数の多くが、
型引数が Ord クラスのインスタンスであることを要求してはいるがね。

229 ：デフォルトの名無しさん：2013/02/20(水) 20:55:55.15

ちょっと何言ってるかわからないですね…
Set a のaがOrdを想定していることはMonoidと何の関係もないし、aがOrdでないようなSet aはemptyとsingleton以外には基本的に構築できないし、当然すべきでもない
型チェックをパスするfmapを定義することは、自明で無意味なもの（fmap _ _ = empty とか）を除いて不可能

230 ：デフォルトの名無しさん：2013/02/20(水) 21:14:23.72

>>229
もとの質問をちゃんと読んでくれ。>>218

どうあがいても無理なのか？と彼は訊いているんだよ。
Haskell の仕様としてできない事になっている、と勘違いしている。
（Map も Functor ではないと勘違いしているのだから、思い込みも甚だしい）

これを否定する事実を提示するだけで、この疑問は解消されるだろう。
つまり、あがけばできるし、できない仕様にはなっていない事を示せば良い。

instance Functor Set where
fmap f s = let xs = toList s
xs' = fmap f xs
in fromDistinctAscList xs'

それに元の質問は、Functor 版 Set をどのようなシーンでどう使いたいのか
まったく言っていない。
だから、質問は無理かどうかを訊いているだけなのだろう。

231 ：デフォルトの名無しさん：2013/02/20(水) 21:22:52.68

fmap = undefined
でなんでもFunctorだよ！

232 ：デフォルトの名無しさん：2013/02/20(水) 21:28:08.21

せめてFunctor則を満たせ

233 ：デフォルトの名無しさん：2013/02/20(水) 21:39:50.06

mapMonotonicは単に型が通るだけで、fmapとしては全く無意味な定義だよ
もし質問の回答として
「fmap _ _ = empty にすればいいよ」
と言われたら、質問者を馬鹿にしてるととられて当然だ
そしてfmap=mapMonotonic も全く同じレベルの話だ

だいたいMonoidのインスタンスであるためにOrdがどうこう、みたいな全く頓珍漢なデタラメを言いながら、>>218を「思いこみも甚だしい」だなんてよく言えたものだ
彼は単にMapがFunctorであることを知らなかっただけだろう

234 ：デフォルトの名無しさん：2013/02/20(水) 21:56:15.19

>>233
> 彼は単にMapがFunctorであることを知らなかっただけだろう

質問する前に、標準ライブラリのドキュメントの Data.Map のページを見て、
Functor のインスタンスではないかどうかを確認するのが
「普通の質問者のすること」だと思うが。

仕様上できないと思っており、確認もしないのなら、
知らないというよりは思い込みだろ（知らないの部類に入ることかも知れんが）。

質問する前にちょっと確認するだけで分かることだぞ。
正確に言えば、ドキュメントの Data.Map のページには、
This module re-exports the value lazy Lazy API, plus several value strict functions from Strict.
と書かれているのだから、Data.Map.Lazy や Data.Map.Strict を見て確認するだろ。
そこにはちゃんと Functor (Map k) と書かれている。

235 ：デフォルトの名無しさん：2013/02/20(水) 22:06:13.42

>>234
たかだかその程度の瑕疵じゃないか
MonoidのためにOrdがどうこうみたいな意味不明な妄言を書いたり、全く無意味な定義で「インスタンスにできる」と言い張ったりするのは「普通の解答者のすること」じゃないよ
少なくとも彼を叩けた立場じゃない

236 ：デフォルトの名無しさん：2013/02/20(水) 22:52:56.26

>>235
あぁ、ごめん
Set 型自体が Ord クラスのインスタンスになっているわけではない、
というのは俺の勘違いだ。
Ord のインスタンスになっている。
たしかに叩けた立場じゃないな。

それは謝る。
申し訳なかった >>218　>>235

それとは別に、>>218 の、「どうあがいても」無理か、という疑問には
俺は問題なく答えてるよな。
できない仕様になっている、という誤った認識をちゃんと正してるつもりだが。

237 ：デフォルトの名無しさん：2013/02/20(水) 23:00:31.06

>>235
あと、「インスタンスにできる」として例示したものが
全く無意味な定義かどうかは、質問の内容によるだろ。

こういうシーンでこう使いたいのだができないか、
と具体的に質問されれば、あの例では全く無意味である可能性は高い。

しかし、あの質問の内容ならば、無理では無いこと、
できない仕様では無いことの証拠を示す例で十分だ。

それを、こちらが勝手に質問の意図を推測するのは余計だと思うぞ。

238 ：デフォルトの名無しさん：2013/02/20(水) 23:06:36.53

いやどうあがいてもまともなFunctorインスタンス無理だろ
ここでいう「まともな」とは
・Functor則を満たす
・ドキュメントで明示的に禁止されているやりかたでSetのAPIを使わない
の二点を守ること

239 ：デフォルトの名無しさん：2013/02/20(水) 23:17:03.02

fmap=mapMonotonic
でもFunctor則は一応満たすよ
まあFunctor則を満たす「だけ」だけど

240 ：デフォルトの名無しさん：2013/02/20(水) 23:17:10.16

>>230ってFunctor則満たすんじゃね
ぱっとみ反例が思いつかん

241 ：デフォルトの名無しさん：2013/02/20(水) 23:20:31.90

満たすよ Functor則はね
でもFunctor則しか満たさない

242 ：デフォルトの名無しさん：2013/02/20(水) 23:27:57.26

Functor則に従うなら問題ないな

243 ：デフォルトの名無しさん：2013/02/20(水) 23:30:20.84

ドキュメントで明示的に禁止されているやりかたでSetのAPIを使わない
ってのがよう分からん

SetのAPIで使い方にルールがある関数があって、
そのルールを満たさないと普通はコンパイルエラーかなんか出るけど、
>>230みたいなことをすると、エラーにならないからダメってことかな

244 ：デフォルトの名無しさん：2013/02/20(水) 23:30:34.29

なんか変なやつが住み着いてるな

245 ：218：2013/02/20(水) 23:34:10.28

fmap は Set.map と同じ仕様を望んでたけど
無理っぽいですね

246 ：デフォルトの名無しさん：2013/02/20(水) 23:34:14.32

>>243
ほとんどの関数において、なぜSet aのaがOrd aであることを要求されているかわかる？

247 ：デフォルトの名無しさん：2013/02/20(水) 23:35:21.14

>>243
たとえばfromDistinctAscListには、昇順なリストしか渡しちゃだめって書いてあるよね
>>230だとfromDistinctAscListに昇順でないリストが渡るかもしれないからまともじゃない

248 ：デフォルトの名無しさん：2013/02/20(水) 23:35:49.48

前提がないなら、>>218の「どうあがいても」は>>238で言われるところの「まともな」範囲の話と考えるのが常識的だと思うの

249 ：デフォルトの名無しさん：2013/02/20(水) 23:41:04.52

>>247
でもさ、それを言ったら標準ライブラリ自体が「まともじゃない」ってならない？

標準ライブラリが、昇順なリストしか渡しちゃだめ、というルールを設けてるんだから、
昇順性を壊さない関数だけ fmap に渡せるというルールを設けてもいいじゃん。

なんでそれを使った自作関数がルールを設けたらまともじゃない扱いになるの？

250 ：デフォルトの名無しさん：2013/02/20(水) 23:48:13.53

>>249
自分で定義する関数ならルールは仕様の一部として勝手に決めていいけど、
クラスメソッドはクラス定義の段階で既に仕様が決まっているから、条件を付け加えるのはまずい
(実用上便利なら、仕様を厳密に守らないインスタンス(Numのabsが実装されてないとか)でも
それなりに許容されるけど、>>230はあまりにも壊れてる)

251 ：デフォルトの名無しさん：2013/02/20(水) 23:53:52.22

>>245
ちゃんとやるにはFunctorの定義に手を入れる必要がある
たとえば、

{-# LANGUAGE ConstraintKinds, TypeFamilies, KindSignatures #-}

import qualified Data.Set as S
import GHC.Exts (Constraint)

type family Domain (f :: * -> *) a :: Constraint

class Functor' f where
　fmap' :: (Domain f a, Domain f b) => (a -> b) -> f a -> f b

type instance Domain S.Set a = Ord a
instance Functor' S.Set where
　fmap' = S.map

type instance Domain [] a = ()
instance Functor' [] where
　fmap' = map

252 ：デフォルトの名無しさん：2013/02/20(水) 23:57:07.72

>>250
なるほどね、納得。

253 ：デフォルトの名無しさん：2013/02/21(木) 01:42:41.62

諸君、久し振りに議論しているね

254 ：218：2013/02/21(木) 08:24:29.44

『すごいＨ』にモナドとしての[]を拡張して確率値付きにしてやろうというのがあったけど
http://codepad.org/8KWk2kXP
結果が Prob {getProb = [(2,1 % 4),(3,1 % 2),(4,1 % 4)]} になるように
同じ事象をまとめたいのだけどそれには a がEqである必要あるから無理だよね？

255 ：デフォルトの名無しさん：2013/02/21(木) 16:20:40.14

[3,1,2,8] -> [1,2,3,8] , "abdc" -> "abcd"この様に小さい順に並びか得たいです。
remove :: (Ord a) => a -> [a] -> [a]
remove _ []= []
remove k (x:xs)
| k == x= remove k xs
| otherwise= x : remove k xs

maxElement :: (Ord a) => [a] -> a
maxElement []= error""
maxElement [x]= x
maxElement (x:y:xs)
| x < y= maxElement (y:xs)
| otherwise= maxElement (x:xs)

inOrder :: (Ord a) => [a] -> [a]
inOrder []= []
inOrder (x:xs)= maxElement (x:xs) : inOrder (remove (maxElement (x:xs)) xs)
綺麗にコードしたいのです。

256 ：デフォルトの名無しさん：2013/02/21(木) 18:05:36.04

ただのソートじゃないか

257 ：デフォルトの名無しさん：2013/02/21(木) 19:30:36.43

すいません。勉強の為に出来るだけprelude?の関数は使わないようにしたいのです。
Quicksortでしたっけコレ？

258 ：デフォルトの名無しさん：2013/02/21(木) 19:35:08.51

quicksort [] = []
quicksort x:xs = [y|y<-xs,y<=x] ++ x ++ [y|y<-xs,x<y]

259 ：デフォルトの名無しさん：2013/02/21(木) 19:36:26.35

間違えた
quicksort x:xs = [y|y<-xs,y<=x] ++ [x] ++ [y|y<-xs,x<y]

260 ：デフォルトの名無しさん：2013/02/21(木) 19:53:40.86

Haskellでソートの実装を学ぶなら
題材はクイックソートよりもマージソードだろ

261 ：259：2013/02/21(木) 20:10:12.44

恥の上塗り……　quicksort x:xs = quicksort [y|y<-xs,y<=x] ++ [x] ++ quicksort [y|y<-xs,x<y]

262 ：デフォルトの名無しさん：2013/02/21(木) 21:22:25.84

比較回数のオーダーがクイックソートじゃないよな

263 ：デフォルトの名無しさん：2013/02/21(木) 21:40:44.51

はあ？

264 ：デフォルトの名無しさん：2013/02/21(木) 22:23:57.99

>>261みたいなのってxsを2回スキャンするの?

y<-xs,x<yの部分（なんて呼ぶのかわからんので教えてくれるとありがたい)は
firter hantei (x:xs) = if (hantei x)
then (x:(firter hantei xs))
else firter hantei xs
相当のことしてるの ?

quicksort (x:xs) = let sub [(as,bs)] (y:ys) = if y < x
then sub [((y:as), bs)] ys
else sub [(as, (y:bs)] ys
sub lst [] = lst
in
let (small, large) = sub [([], []) xs
in (quicksort small) ++ [x] ++ (quicksort large)

ってやったら効率よくなる ?
それとも無駄 ?

あと、
quicksort [] = []
は必要だよNE ?

265 ：デフォルトの名無しさん：2013/02/21(木) 22:34:38.03

>>263
クイックソートのアルゴリズムも知らんのか

266 ：デフォルトの名無しさん：2013/02/21(木) 22:35:53.52

>>264
君のコードが何を意図しているのか、正直よく分からんが・・・

>>261 のコードが xs を2回走査してるという認識は正しい。

同じ事は1回の走査で可能だ。
現に Data.List の patrition 関数は1回の走査でリストを二分している。

実際は quicksort [] = [] は必要だが、
>>261 はHaskellのクイックソートがどういった形になるのか、
外観を軽く示しただけだと思うから、
その文脈においては敢えて書く必要性は乏しいだろう。

>>265
「比較回数のオーダーがクイックソート」という言葉の意味が汲み取れない、
という意図の「はあ？」だと思う。

267 ：デフォルトの名無しさん：2013/02/21(木) 22:41:13.08

このコードがO(n×log(n))じゃないと思ってるということ?

268 ：デフォルトの名無しさん：2013/02/21(木) 22:50:59.87

>>267
「オーダーは O(nlogn)だ」というのは分かるが、
「オーダーがクイックソートだ」というのが分からない、ということかと。

ナンシー : The order is the quick sort.
ボブ : pardon?

269 ：デフォルトの名無しさん：2013/02/21(木) 23:00:19.56

>>261がquicksortじゃないと思う人、素直に手を上げて！

270 ：デフォルトの名無しさん：2013/02/22(金) 06:29:34.13

要素の並び替えがin-placeじゃない（微妙なライン）
pivot選択にmedian-of-medians使ってないので最悪計算量で死ぬ（無くてもいい）

271 ：デフォルトの名無しさん：2013/02/22(金) 07:40:03.34

空間計算量が最悪O(n^2)(やばい)

272 ：デフォルトの名無しさん：2013/02/22(金) 08:11:48.34

スルーされちゃったけど 254 は無理って事でいいよね？

273 ：デフォルトの名無しさん：2013/02/22(金) 12:49:12.14

うん

274 ：デフォルトの名無しさん：2013/02/22(金) 13:47:39.26

計算量をパパッと言える人カッコいい

275 ：デフォルトの名無しさん：2013/02/22(金) 15:18:14.19

lazyな処理系の空間計算量ってよほど慎重に考えないと間違えるよな。
それも、甘く見積もる方向に。

276 ：デフォルトの名無しさん：2013/02/22(金) 16:21:55.14

data Atree a = Null | Node (Atree a) a (Atree a)
deriving (Show)

minElement :: (Ord a) => Atree a -> a
minElement (Node (Null) x (Null)) = x
minElement (Node (lTree) y (rTree)) = Node (minElement lTree) y (rTree)

木の中で最小の値を出したいのですが、うまく出来ません。なんで？

277 ：デフォルトの名無しさん：2013/02/22(金) 16:24:57.45

すみません。自壊しました。
minElement :: (Ord a) => Atree a -> a
minElement (Node (Null) x (Null)) = x
minElement (Node (lTree) y (rTree)) = minElement lTree
でした。

278 ：デフォルトの名無しさん：2013/02/22(金) 17:31:29.04

disintegration

279 ：デフォルトの名無しさん：2013/02/22(金) 18:47:26.22

自壊ー＞自己解決でした。それはそうと、二分木の削除が出来ない。

data Atree a = Null | Node (Atree a) a (Atree a)
deriving (Show)
delete :: (Ord a) => a -> Atree a -> Atree a
delete x Null= Null
delete x (Node (lTree) y (rTree))
| x < y= Node (delete x lTree) y (rTree)
| x == y= join lTree rTree
| x > y= Node (lTree) y (delete x rTree)
join :: (Ord a) => Atree a -> Atree a -> Atree a
join lTree rTree
| (isNull lTree) && (isNull rTree)= error""
| otherwise= Node (lTree) minimumElement (rTree)
where minimumElement = minElement rTree
isNull :: Atree a -> Bool
isNull (Node (Null) x (Null))= True
isNull (Node (lTree) x (rTree))= False

minElement :: (Ord a) => Atree a -> a
minElement (Node (Null) x (Null))= x
minElement (Node (lTree) y (rTree))= minElement lTree
5 5
4 6 2 6
1 3 1 3
2 2<-こいつ消したいのですが....
二分ヒープ？みたいなやつを実効したいのですが、もうこんがらがって訳わからない。

280 ：デフォルトの名無しさん：2013/02/22(金) 18:49:21.05

ごめんなさい。こんな感じです。
*Main> let c = (Node (Node (Node (Null) 1 (Null)) 4 (Node (Node (Null) 2 (Null)) 3 (Null))) 5 (Node (Null) 6 (Null)))
*Main> delete 4 c
Node (Node (Node Null 1 Null) 2 (Node (Node Null 2 Null) 3 Null)) 5 (Node Null 6 Null)

281 ：264：2013/02/23(土) 08:13:36.61

>>266
ありがとう

自明なことかも知れないけど確認しておきたかったんだ

282 ：デフォルトの名無しさん：2013/02/23(土) 10:48:51.04

http://www.moon.sannet.ne.jp/okahisa/haskell-sort/quicksort.html
このページのmedian選択アルゴリズムおかしくないですか？
pivot1は最初と中央と最後の三つの値の中からmedianを仮に選んで、
partitionで真のpivotを選んでいるみたいなんですが、
仮に選択したpivot1と同じ値が常に使われてしまうように見えます。
やっぱりmedian-of-mediansじゃないとO(n)でmedian選択は無理ですよね？

283 ：ちょっと訂正：2013/02/23(土) 10:53:35.69

やっぱりmedian-of-mediansじゃないと（最悪でも）O(n)でmedian選択は無理ですよね？

284 ：デフォルトの名無しさん：2013/02/23(土) 11:13:23.91

http://ja.wikipedia.org/wiki/%E3%82%AF%E3%82%A4%E3%83%83%E3%82%AF%E3%82%BD%E3%83%BC%E3%83%88
wikipediaのhaskellコードもおかしいな…

285 ：デフォルトの名無しさん：2013/02/23(土) 11:17:13.00

マージソートでええやないの

286 ：デフォルトの名無しさん：2013/02/23(土) 12:03:15.60

ランダムに三つの値を選んでその中のmedianをpivotとする方法があるみたいですね。
median-of-3法というらしいです。
アルゴリズムイントロダクションに書いてありました。定数倍しか速くできないらしい。
↑のアルゴリズムはこれの変種なのかな…。

287 ：デフォルトの名無しさん：2013/02/23(土) 19:24:42.87

>>285
マジですかー！

288 ：デフォルトの名無しさん：2013/02/23(土) 20:02:08.43

えっ……

289 ：デフォルトの名無しさん：2013/02/24(日) 02:41:08.93

data d = d (IO d)
これって再定義じゃないの？
参照透過性とかどうなってるの？

290 ：デフォルトの名無しさん：2013/02/24(日) 02:53:08.65

釣り針が太過ぎです。不合格

291 ：デフォルトの名無しさん：2013/02/24(日) 03:18:43.91

>>290
わからないニワカなら黙っててよ
既存のソース読んでて見つけたコードが>>289
Haskellも副作用やってんじゃん

292 ：デフォルトの名無しさん：2013/02/24(日) 03:44:55.66

>>289
型構築子とデータ構築子は同じ名前が使えるんだよ

293 ：デフォルトの名無しさん：2013/02/24(日) 04:04:20.24

型と同名のインスタンスを作ってるって事ですか？
C言語で言う
class C{};
C* C = new C();
のような

294 ：デフォルトの名無しさん：2013/02/24(日) 04:13:14.88

イメージはそんな感じだけど違う
data D=D' (IO D)
こう書き直したとすると
Dは型構築子D'はデータ構築子で役割が全然違う
だから名前が被ったとしても問題がない
Dは型だから関数の型宣言とかにしか使われない例f::D->Integerみたいに
D'はデータ構築子で、すなわち関数
D'::(IO D)->D
例 x::(IO D)->D
x=\k->D' k

295 ：デフォルトの名無しさん：2013/02/24(日) 04:23:32.52

どうもありがとう
Haskellに複数名前空間があることを知らなかった

296 ：デフォルトの名無しさん：2013/02/24(日) 05:37:41.68

既存のソース読む前にHaskellの入門書かなんかで勉強したほうがいい

297 ：デフォルトの名無しさん：2013/02/24(日) 10:57:47.83

型のことで便乗質問だけれど

型のレコード表記による定義をするとそのレコード名が
変数のアクセス関数として定義されるじゃん ?

で、短い普遍的な名前にすると（例えば'name'、'length'等)
名前の衝突が起こるわけなんだけど
やっぱある程度長い名前をつけなきゃだめなの ?

オブジェクト脳だと短い名前付けたくなっちゃうんだけど
Haskellでは名前の衝突はどう回避するの ?

長い長い名前を付けることに抵抗はないんだけど
（どちらかというと説明的な長い名前が好き）
そうでない人はどうしてるのかなぁと思いました。

モジュールとかパッケージとか使うと解決する ?
もしくは、レコード表記はあまり使わない ?

298 ：デフォルトの名無しさん：2013/02/24(日) 12:23:48.32

qualified無しのimportする奴が悪いということで短い名前での衝突は気にしない
import qualified Bar.Foo as Foo

Foo.name
Foo.length

のようなqualified importを使う

299 ：297：2013/02/24(日) 13:04:40.80

>>298
ありがと

300 ：デフォルトの名無しさん：2013/02/24(日) 14:54:27.14

/.に書き込まれてたこれはどう思う？
Haskell のデバッグは絶望的に難しい。従来の手続型言語のようなステップ実行によるデバッグは、あんまり役に立たない。
自分は GHC しか知らないけど、クラッシュした時にスタックトレースすらとれない。
というか、基本が遅延評価の Haskell は原理的にスタックトレースに意味がないので、たいていはどこでクラッシュしたのかすらわからない。
バグの個数は　100分の１になるけど、残り１％のバグが 100 倍強力になって襲い掛かってくる感じ。

301 ：デフォルトの名無しさん：2013/02/24(日) 15:18:35.73

自分のプログラムで「例外も吐かずに」クラッシュするなら、
FFIで制御が外部ライブラリに行っている時をまず疑うな。

unsafePerformIO で IO モナド外しとかバカな事をせず
普通に Haskell を使っているのなら、
100% に近い確率で外部ライブラリに変な値を渡した事が原因だ。

クラッシュはしないが、計算結果が意図したものではないという場合は、
Debug.Trace モジュールの関数を使って調べれば良い。
俗に言う printf デバッグだ。

Haskell は純粋な部分の関数は切り分けて単独でテストできるから、
俺はむしろ他言語よりデバッグしやすいんだがな。

302 ：デフォルトの名無しさん：2013/02/24(日) 18:39:40.60

よく言われるのは遅延評価で空間的、時間的リソースリークがあああとかいうやつ
それと無限ループでCoqやAgdaのような隣の芝生に嫉妬することも
それともうちょっとghciのデバッガ使いやすくなったらなとか

303 ：デフォルトの名無しさん：2013/02/24(日) 18:43:44.58

どんな事が出来たら使いやすいといえるのか、提案すれば？

304 ：デフォルトの名無しさん：2013/02/24(日) 19:14:12.53

これは何が問題なんだ？
main = print $ sum [0..1000000]

305 ：デフォルトの名無しさん：2013/02/24(日) 19:36:23.48

和の公式で求められる

306 ：デフォルトの名無しさん：2013/02/24(日) 19:39:26.00

遅延評価のせい
sum'ってあったっけ

307 ：デフォルトの名無しさん：2013/02/24(日) 19:51:04.18

GHC だと、USE_REPORT_PRELUDE を定義しない限り、
sum の定義は次のようになっている。

sum l = sum' l 0
where
　sum' []　　 a = a
　sum' (x:xs) a = sum' xs (a+x)

これって、最後に sum' [] a の a を評価するまで、
(a+x) の計算がどんどん遅延して長～い加算計算の羅列になったりするの？

もしそうなら、seq a $ sum' xs (a+x) で解消できる？

308 ：デフォルトの名無しさん：2013/02/24(日) 20:07:19.59

>>305
せやな。
せやけどな。

309 ：デフォルトの名無しさん：2013/02/24(日) 20:18:20.36

foldl'でおｋ

310 ：デフォルトの名無しさん：2013/02/24(日) 20:57:55.40

>>304
それは普通に動くんじゃ...?

311 ：デフォルトの名無しさん：2013/02/24(日) 21:16:04.29

遅延評価なくても累積変数使わないとスタックが深くなる。

312 ：デフォルトの名無しさん：2013/02/24(日) 21:26:45.90

>>307
よく考えたら、(+) が引数を即時評価して計算するかどうかは、引数の型に依るか。

もし sum の引数が Int 型だったら、>>307 の (a+x) は即時評価されて、
メモリ内に未評価の計算が 0 + 1 + 2 + 3 ・・・みたいに連なることは無い？

313 ：デフォルトの名無しさん：2013/02/24(日) 21:32:00.76

型じゃ式の評価がどのくらい深いか分からんからな。

314 ：デフォルトの名無しさん：2013/02/24(日) 22:34:46.39

>>310
コストを考えれ
じゃなきゃお前をC/C++が出来ない難民だと認定する

315 ：デフォルトの名無しさん：2013/02/24(日) 23:10:43.76

>>314
コストって何が言いたいんだ？
1000000 程度だったらスタックの深さ的にも動くだろ。

計算量のことを言ってるなら、今言う話じゃない。

316 ：デフォルトの名無しさん：2013/02/24(日) 23:32:12.62

サンクってのがあってね。

317 ：デフォルトの名無しさん：2013/02/25(月) 12:19:04.86

サンクコストとか書くとダブルミー人具

318 ：デフォルトの名無しさん：2013/02/25(月) 12:36:33.67

人具ってなんかエロい

319 ：デフォルトの名無しさん：2013/02/27(水) 21:15:25.24

クイックソートについての質問です。
>>259の関数だと
*Main> qs [13,14,14,19,13]
[13,13,13,14,14,14,19]
*Main> qs [13,13,15,36,13,15,14]
[13,13,13,13,13,13,13,14,15,15,15,36]
になってしまいます。下の
--filter check (x:xs) = if check x
--then (x:(filter check xs))
--else filter check xs
だったら真にならなかった要素がなくなったリストが出来上がると思うのです。
クイックソートのリストの中身は順番などが関係するのでしょうか？

320 ：デフォルトの名無しさん：2013/02/27(水) 21:42:34.42

しない

321 ：デフォルトの名無しさん：2013/02/28(木) 14:23:00.06

>>317
落ちる隕石ｷﾀ━━(ﾟ∀ﾟ)━━!!!

322 ：デフォルトの名無しさん：2013/02/28(木) 15:43:29.85

おまえらソートしかする事ないのかよ

323 ：デフォルトの名無しさん：2013/02/28(木) 16:02:09.96

ソートは知らなかった。

324 ：デフォルトの名無しさん：2013/02/28(木) 19:21:55.79

入門書にソートがあるので勉強してます。所で、
angle :: Float -> Float -> Float
angle x y
| x > 0 && y > 0= (y / x) / tan
| otherwise= error""
のtanがなぜエラーなのでしょうか？

325 ：デフォルトの名無しさん：2013/02/28(木) 19:46:22.92

>>324
(y / x) / tan は演算子を使った式だが、これを関数の形にするとこうなる。

(/) ((/) y x) tan

元の式の中央の除算演算子が、関数にした式の最も左側にある関数 (/) だ。

関数 (/) の型は Fractional a => a -> a -> a だ。
この型変数 a には例えば Float 型などが入る。

関数 (/) が第一引数として適用するのは ((/) y x) だが、
x や y が Float 型なので、ちゃんと全体で Float 型になっている。

ところが、ここで関数 (/) が第二引数として適用しようとしているのは関数 tan だ。

この型は Floating a => a -> a であって Float 型ではない。
もう少し優しく言うと、tan :: Float -> FLoat であって、tan :: FLoat ではない。

なので、関数 (/) の型に合ってないよ、という趣旨のエラーが出る。

もし (y / x) / tan ではなく、例えば (y / x) / tan x とかだったら問題ない。
tan x は Float 型なので、この場合の関数 (/) の第２引数として適用できる。

326 ：デフォルトの名無しさん：2013/02/28(木) 20:34:59.46

なるほど、tanには他に引数がいるのですね。
三角形の角度で、xが2、仮に角度が45の時yは２。
ここではその角度Xを求めたいので2tanX = 2 -> tanX = 2/2 -> X = (2/2) / tan or atan (2/2)。
しかしながらtanは他に引数が必要。けどその引数を知りたい....　プログラムの前に数学勉強してきます。
丁寧な説明、ありがとうございました。

327 ：デフォルトの名無しさん：2013/02/28(木) 21:05:12.94

>>325
tanに引数がないって言えば終わるのにどうしてそんな長くなった

>>326
常識的に高校くらい出ておけ
＞(y / x) / tan
唖然としたわ

328 ：デフォルトの名無しさん：2013/02/28(木) 21:42:39.95

>>327
> tanに引数がないって言えば終わるのにどうしてそんな長くなった

Haskellと付き合うなら型（シグネチャ）を常に意識するようになってほしいからです。

あと、起きているエラーの式がどういった式なのかも意識して欲しかったからです。

329 ：デフォルトの名無しさん：2013/02/28(木) 21:49:16.02

>tanに引数がないって言えば終わる

Cみたいな言語ならそれで終わるんだろうけど、Haskellだとそれじゃ正しくない
今回のは型が違うって言えば終わる
が、それだけだと>>326レベルの初心者では何が何やら分からんだろうから説明長くなったんだろう

330 ：デフォルトの名無しさん：2013/03/01(金) 05:02:16.68

>>325
あんたすげえいい人だな

331 ：デフォルトの名無しさん：2013/03/01(金) 20:27:05.86

モナドが分からん
いろいろな種類のがあって分からん
モナドの何が嬉しいのか分からん
いろんな説明があって分からん
コンテキストの抽象化だというのが一番分からん
これまでのプログラミング手法でいうと何がそれに近い？
分かり易い説明キボン
どこの説明がおススメ、でも結構

332 ：デフォルトの名無しさん：2013/03/01(金) 20:37:45.72

私もモナドは判らない。モナドだけではないwのかも知れないが判らない。

333 ：デフォルトの名無しさん：2013/03/01(金) 20:49:41.32

以前だと、bit誌なんかが、半年位の連載で取り上げそうなテーマだけど、
今はそういう部分が薄くなっているから。

334 ：デフォルトの名無しさん：2013/03/01(金) 21:43:42.51

去年数セミがやっていたけど、あれも、嬉しさは分からないだろな。
bitでやったとしても同じようなものじゃないの？
もっと本質的な分かりにくさの理由があるんじゃないかな
そもそも嬉しいところはないとかｗ

335 ：デフォルトの名無しさん：2013/03/01(金) 21:49:05.90

直観的に明らかなのがいいとは限らないが
分からないのもなー

336 ：デフォルトの名無しさん：2013/03/01(金) 22:08:48.02

分からないことが（たぶん）原因で不便を感じている、
という事でなければ、分からないままでいいんじゃね

337 ：デフォルトの名無しさん：2013/03/01(金) 22:13:44.13

>>331
モナドの嬉しさを理解する前に、モナドの具体例はいくつか理解してる？
IO、Maybe、Stateくらい分かってればいい

338 ：デフォルトの名無しさん：2013/03/01(金) 22:14:47.64

>>336
そういう言語が他にあまりないから。Zとかは別にすると。

339 ：デフォルトの名無しさん：2013/03/01(金) 22:31:39.50

>>337
うん。もちろん知ってるつもり。他にベキ集合もListも例外も非決定性もｗ
>>336
クールだなｗ　分からん者の気持ちがわかってないな
>>338
そういう言語？Z？Zとモナドは関係ないだろ？

340 ：デフォルトの名無しさん：2013/03/01(金) 22:31:56.04

>>331 １．C言語のポインタと一緒で必要以上に難しいと煽られているもの。２．printfの書式指定と一緒で、実装とか細かいことを気にせずに使い方に集中すればいい。３．世の中謎に満ちている。気にしたら負けだ。

341 ：338：2013/03/01(金) 22:34:51.09

>>339
学習する際の話になるけど、
理論的にはさっぽり分からないけど、ともかく進めていくという言語ね。

342 ：デフォルトの名無しさん：2013/03/01(金) 22:57:43.11

>>340
負けたくないんでｗこんなコメントうれしいわ。
でもポインタやprintfよりずっと難しいし、世の中の謎ほどの難問でもないと思うし
>>341
これもあんがと。
でもZは集合記法、これでオシマイ、だよね

343 ：デフォルトの名無しさん：2013/03/01(金) 22:59:41.41

Haskellに集中するのはおすすめしない
コールバック、継続、モナドの順に覚えればいいと思う

344 ：デフォルトの名無しさん：2013/03/01(金) 23:12:17.12

Haskellにグローバルな継続はねえよ
限定継続なら作れるけど標準ライブラリに入ってないし

345 ：デフォルトの名無しさん：2013/03/01(金) 23:14:24.17

だからHaskellに集中するなって言ってるんじゃないの？ｗ

346 ：デフォルトの名無しさん：2013/03/01(金) 23:16:42.24

「モナドが分からん」とだけ言う人は、
複素数が分からんとか微分がわからんと言っているのと同じで、
範囲が広すぎて、こちら側としては何をアドバイスすれば良いのか分からん。

質問の範囲が広すぎると、アドバイスも広く薄くなるし、散漫になる。

モナドの何が分かるようになりたいのか、
まず極狭い範囲の知りたい事をひとつ絞ってくれ。
そうすれば、皆がそれについてピンポイントで濃いアドバイスができる。

それが十分納得できてから、次の知りたい事をまたひとつだけ挙げてくれ。

そうやって少しずつ取り組まないと、たぶん何も得られないと思うよ。

347 ：デフォルトの名無しさん：2013/03/01(金) 23:45:58.08

１．モナドの何が嬉しいの？
２．いろいろあるモナドに共通するのは何？（３則という答えがあるのは知っているが）
まずこれらを普通のプログラム経験はある人なら分かるように教えてほしい

348 ：デフォルトの名無しさん：2013/03/02(土) 00:07:13.27

１．いきなりそれにこたえるのは無理。ファンクター、アプリカティブファンクターを順番に学ぶといいよ
２．モナド則だけです

349 ：デフォルトの名無しさん：2013/03/02(土) 00:36:54.32

do記法を使って(関数型言語のメリットを保持したまま)手続型言語っぽく書ける
しかも"<-"がカスタマイズできる。

であってる？

350 ：デフォルトの名無しさん：2013/03/02(土) 01:09:25.57

IOではないものを色々作ったのが嬉しいのかな
全部IOでやろうと思えばできるし共通点もわかりやすいが
それではIOが過大評価されてしまうので関数型として都合が悪い

351 ：デフォルトの名無しさん：2013/03/02(土) 01:11:22.51

IOやSTを使って計算速度が速いプログラムを書くコツが知りたい。

352 ：デフォルトの名無しさん：2013/03/02(土) 01:16:32.76

・モナドでこれまでのHaskellライフがどの様に変わるのか

353 ：デフォルトの名無しさん：2013/03/02(土) 09:00:41.63

<- は、単にくるんであるものを引っ張り出す記法だからなんか違う。
カスタマイズできるのは >>= の意味、なのかなぁ。

354 ：デフォルトの名無しさん：2013/03/02(土) 09:34:20.78

(>>=) も単に引っ張り出す記法のような気がするが
出る杭は打たれるというか、数学的でない説明を潰そうとする力が働く
といっても物理的な力ではないので無視することはできる

355 ：デフォルトの名無しさん：2013/03/02(土) 09:40:42.63

単に引っ張り出す記法というならどっちもそうだろ
引っ張り出し方をカスタマイズできるだけで

356 ：デフォルトの名無しさん：2013/03/02(土) 12:40:08.94

return は値を箱に入れて封をする。
>>= は箱の封を解いて値を取り出す。

どちらも、その方法が外部から隠蔽されている事が肝です。

だから、箱に入れたり取り出したりする時に何か計算（処理）をさせたり、
箱の中の情報の一部だけを >>= の第２引数の関数に渡したり、
そんな事をしてもモナドを使う側から見れば同じ計算に式に見える。
つまり、同じ扱い方ができる。

これが、１.モナドの嬉しい事であり、
2.いろいろあるモナドに共通する事柄です。

その同じ扱い方ができる保証を与えるのがモナド則です。

357 ：デフォルトの名無しさん：2013/03/02(土) 12:46:59.14

>>356
結局ユーザーとしてはこれだけ知ってればいいんだよね。

358 ：デフォルトの名無しさん：2013/03/02(土) 14:24:05.97

敷居高く見せるために難しくモナド則とか名前付けてるけど結局はinterfaceとかダッグタイプでしかないってこと？

359 ：デフォルトの名無しさん：2013/03/02(土) 14:59:54.46

>>358
（よく言われるけど）敷居高く見せるために、という理由の根拠は？
Haskell の歴史を概略した論文を読んでも、
敷居高く見せる必要があったとは読み取れないよ。

文法では規定できない規則をプログラマにお願いする際に、
その規則を呼ぶキャッチーな名前がある方が便利だよね。
いちいちルールＡとルールＢとルールＣに従ってくださいと言うよりも、
モナド則に従ってくださいという方が簡単だ。

Monad クラスにしても、Haskell という言語の中では、
他の Functor クラスや Show クラス、Eq クラスなどと同じ
ごく一般的な普通のクラスだ。

それに担わせたかったある役割を実現する（表現する）方法として、
たまたま計算機科学におけるモナドの概念がうまくマッチしたから、
その概念や名前を拝借して Monad クラスという名前を付けただけ。
（ある役割というのは、初めはIOを純粋関数型らしく上手く扱う事だったと言う）

360 ：デフォルトの名無しさん：2013/03/02(土) 15:16:15.13

まあモナドって名前はあんまり良くないよね

361 ：デフォルトの名無しさん：2013/03/02(土) 15:27:15.22

>>360
まぁ、それは人によりけりだね。
この名前から初心者を寄せ付けないオーラを感じ取る人もいるだろうし。

私は高尚感はそれほど感じないな。

Monad クラスのインスタンスを
モナディックファミリーと勝手に呼んで親しんでる。

362 ：デフォルトの名無しさん：2013/03/02(土) 15:40:50.82

>>358
参照透明性を保とうとすると、アルゴリズムの教科書なんかで良く出てくる
タイプの逐次処理なんかをどう書くかという問題がでてくる。

逐次処理のうち、あるものは fold 系でまとめることができる。

部分的な結果をつなぎあわせて最後の計算結果にするタイプの
アルゴリズムは必ずしも fold　系で記述できないが、
多相型Fの型コンストラクタが関手であり、さらに
モナドであるばあいのKleisli射の合成として表せるタイプの計算に
対しては、その一連の計算があたかも命令を連ねて値を作っている
かのように人間に感じさせるシンタックスシュガーが用意されている。

要するに、

・do 記法自体はむしろ敷居を下げるために導入された。
・使い方、ではなくデザインの背後にあるロジックを知ろうとすると圏論が出てくる。

わけだ。計算の抽象化うんたらってのはMoggiあたりが言い出したことで、
知りたかったら論文読めばいいし、知らなくてもHaskell使うのに支障はない。

363 ：デフォルトの名無しさん：2013/03/02(土) 15:44:19.40

>>360
モナドって呼ばれる前は数学の中で Triple と呼ばれていた。いくらなんでも
一般名詞すぎるのでマクレーンがモナドと命名した。

そもそもの始まりとして、カテゴリーという名称自体アリストテレスの範疇論から
名前を借りてきており、この辺はマクレーンが最初基礎論を専攻しようと
した哲学的な傾向というか憧れというかコンプレックスというかそんなものの反映。

モナドが酷い名前だというのはまあ同意するけど「りあむ」よりは良い名前だと思うよ。

364 ：デフォルトの名無しさん：2013/03/02(土) 16:25:47.99

参照透過性を保つっていう観点だけなら、モナドより一意型のほうが分かりやすいと思う

365 ：デフォルトの名無しさん：2013/03/02(土) 17:15:26.44

F#だとコンピュテーション式だっけ

366 ：デフォルトの名無しさん：2013/03/02(土) 18:57:57.95

モナドをわかりやすく解説できるかた
解説よろしくです

367 ：デフォルトの名無しさん：2013/03/02(土) 19:08:40.15

すごいH本買って頭から読め、絶対それが一番速いから
基礎は知ってるならファンクタからでも

368 ：デフォルトの名無しさん：2013/03/02(土) 19:10:56.39

本ってモナドはしょってない？

369 ：デフォルトの名無しさん：2013/03/02(土) 19:13:15.30

むしろ半分くらいモナドの話だ、あれは

370 ：デフォルトの名無しさん：2013/03/02(土) 19:14:08.74

入門書2冊程よんだけど、モナドが何なのか結局分かんなかった

371 ：デフォルトの名無しさん：2013/03/02(土) 19:32:53.24

モナドとは特定の人物・血縁を意味する言葉ではなく生き方そのもの
モナドを理解するためにはこのことにまず気付かねばならない

372 ：デフォルトの名無しさん：2013/03/02(土) 19:36:12.01

>>366

>>346 でも言ったが、モナドの何が知りたいのか、具体的に、
できればひとつに絞って質問してもらう訳にはいかないのかな。

それと、モナドをHaskellプログラマとして使う側に沿った説明は、
このスレでも色んな方がされている。
私も稚拙だが >>356 で肝の部分を少しだけ説明したつもり。

＊＊番のレスの～の意味が分からんとか、＊＊番のレスの説明をもう少し詳しくとか、
そんな感じで質問してくれると、アドバイスする方としては大変助かるのだが。

373 ：デフォルトの名無しさん：2013/03/02(土) 19:40:54.26

>>372
モナド則についてとStateモナドについてお願いします
>>356を読んでもそれがStateを管理するのにどうつながるのかよく分かりませんでした

374 ：デフォルトの名無しさん：2013/03/02(土) 19:43:17.74

356以外はなぜかだれも347に答えてないんだな
>>356
その喩えは確かか？
箱って何？なぜわざわざ箱に入れるの？
隠蔽はモナドに限らない常套手段なのでそれが肝と言われても？
>そんな事をしてもモナドを使う側から見れば同じ計算に式に見える。
何と何が同じ計算に見えるの？

375 ：デフォルトの名無しさん：2013/03/02(土) 19:46:21.92

>>374
ここはべつにお前の質問に答えるための板じゃない

376 ：デフォルトの名無しさん：2013/03/02(土) 19:46:21.03

肝心なのは理解することじゃない。
理解したつもりになること。

377 ：デフォルトの名無しさん：2013/03/02(土) 19:48:18.43

>>373
順に質問の幅を狭めて具体化させるぞ。

モナド則の何が知りたい。

Stateモナドの何が知りたい。

378 ：デフォルトの名無しさん：2013/03/02(土) 19:50:13.68

ていうかこの人前も居たような…
自分で考えずに全部オウム返しで漠然と質問してくるから話にならない

379 ：デフォルトの名無しさん：2013/03/02(土) 19:53:31.12

>>375
347、370、373等の質問に答えてないなと言っただけだ。おれはそのどれでもないが
だからよほど難しい質問なのかと思った

380 ：356：2013/03/02(土) 20:00:16.48

>>374
会話しやすいように、私の元の発言のレス番を名前に入れておくな。

> その喩えは確かか？

申し訳ない、>>356 では言い忘れたが、
私が個人的に抱いているイメージなんで、人によっては違うと思う。

> 隠蔽はモナドに限らない常套手段なのでそれが肝と言われても？

そう、情報を隠蔽する方法は Monad クラス以外にもいろいろある。
その方法のひとつが Monad クラスというとして標準ライブラリに用意されており、
また、その方法が特別有用なので文法上も特別扱いされている。

> 何と何が同じ計算に見えるの？

(Monad m) ==> m a 型の値 x と、
(Monad m) ==> m a -> (a -> m b) -> m b 型の関数 f があるとする。

x >>= f という式は、Monad クラスの「どのような」インスタンス型でも成り立つ。
例えばリスト型だろうが Maybe 型だろうが、IO 型だろうが。

同じ計算に見えるというのは現象で、大事なのは同じ扱い方ができる、という事。

381 ：デフォルトの名無しさん：2013/03/02(土) 20:05:27.18

すけべ本のリスト内包表記のとこまでやっと読み進めた俺にもわかりやすく

382 ：デフォルトの名無しさん：2013/03/02(土) 20:06:51.56

おかしくね？

383 ：356：2013/03/02(土) 20:11:10.78

>>374
見落としてた。

> 箱って何？なぜわざわざ箱に入れるの？

箱というのは、return x という式で値 x をモナド化させると言ったり、
x をモナドでかぶせると言ったり、そういう言い回し（しないかな・・・）を、
私は「箱に入れる」とイメージしているだけだ。

なぜわざわざ箱に入れるのか、つまり何故モナドにするのかと言えば、
プログラマの視点から言えば、箱の中身を触らないようにするためだ。
オブジェクト指向のクラスで言うところの、private メンバ変数にして、
外部から勝手に触らせないようにするためだ。

たとえば State モナド。
このモナドの箱の中には、ユーザーが return 関数で入れた値の他に、
状態を表す値も密かに入れられている。
ユーザーによってその状態を表す値が勝手に書き換えられたら、整合性がとれなくなる。
だから State モナドは状態を表す値を隠し、
特別に用意された関数を通してしかアクセスできないようにしている。

384 ：デフォルトの名無しさん：2013/03/02(土) 20:15:17.71

モナドとはなにか？なんて問いに本気で答えるには圏論の話をしなきゃいけないんじゃないの？
俺なんかはその辺は諦めて実際の用法に集中してるんだけど

385 ：デフォルトの名無しさん：2013/03/02(土) 20:16:59.99

モナドはコンテナって言うのはよく聞くね
だけどコンテナに値突っ込んだり出したりって副作用じゃないの？って思ってしまう

386 ：356：2013/03/02(土) 20:18:06.70

>>382 で気づきました。

>>380 の説明の関数 f の型はおかしいですね。
(Monad m) ==> a -> m b です。
すいません。

387 ：デフォルトの名無しさん：2013/03/02(土) 20:21:07.49

> 箱って何？
Monadのインスタンスは種が*->*の型コンストラクタであり
既存の型を包みこむように動作することから
イメージしやすいように箱とかコンテナが良く引き合いに出される

388 ：デフォルトの名無しさん：2013/03/02(土) 20:23:21.29

Javaで言うところのint->IntegerのBoxing？

389 ：デフォルトの名無しさん：2013/03/02(土) 20:30:05.93

種の概念のことを言ってるならJavaだと総称型が近い

390 ：デフォルトの名無しさん：2013/03/02(土) 20:32:56.93

最終的にAgdaとHaskellはシンクロするんです？

391 ：デフォルトの名無しさん：2013/03/02(土) 20:35:05.09

>>384
いや圏論を持ち出してもわからなさは同じだと思う

392 ：デフォルトの名無しさん：2013/03/02(土) 20:36:59.87

>385
プログラムの意味論における「状態が変化する」ことを副作用と言っている。
もっと広く、環境が変化すると言ってもいい。

状態が変化するとか環境が変化するというのは、意味上メモリの内容が変わったり、
コンソールに文字を表示させる事でコンソールの内容が変わったりといった事。
（意味上と限定したのは、実際 GHC は内部でメモリの内容を書き換えるかも知れんから）

コンテナに値突っ込むとか、箱に入れるとかはあくまでイメージなので、
その操作自体に副作用があるとか無いとかは関係ない。
その操作の時に中で何が行われるかによる。

そうイメージされる現象によって状態・環境が変化しなければ副作用は無いと言えるし
そうイメージされる現象によって状態・環境が変化すれば副作用はあると言える。

例えば State モナドは環境が変化しないので副作用は無い。
IO モナドは環境が変化する（可能性がある）ので副作用がある（可能性がある）。

393 ：デフォルトの名無しさん：2013/03/02(土) 20:48:32.92

>>356 ありがと

>私が個人的に抱いているイメージなんで

いやそれで十分

>x >>= f という式は、Monad クラスの「どのような」インスタンス型でも成り立つ

うん。だけどそれがどれほど嬉しいのかが分からん

>なぜわざわざ箱に入れるのか、つまり何故モナドにするのかと言えば、
>プログラマの視点から言えば、箱の中身を触らないようにするためだ。
>たとえば State モナド。
>ユーザーによってその状態を表す値が勝手に書き換えられたら、整合性がとれなくなる。
>だから State モナドは状態を表す値を隠し、
>特別に用意された関数を通してしかアクセスできないようにしている。

ここは違うんじゃないの？箱は隠蔽のためではないでしょ？

394 ：デフォルトの名無しさん：2013/03/02(土) 21:14:57.97

>>385
出した結果がブレるのが副作用
出さなければ副作用はない
コールバックのように自分では呼び出さないようにする

395 ：デフォルトの名無しさん：2013/03/02(土) 21:26:53.64

HaskellでRPGを作るにはどうすればいいです？
例えば主人公がキー入力によって移動して
ある位置に到達すると会話シーンなどのイベントが始まるような
C脳なので主人公が移動するためには座標を管理する変数を書き換える必要があるなとなってしまう

396 ：デフォルトの名無しさん：2013/03/02(土) 21:30:09.70

俺のなかでは、モナドは世界線の移動装置なんだが・・・。

397 ：デフォルトの名無しさん：2013/03/02(土) 21:32:49.44

>>395
まず問題を小さく分けます

398 ：356：2013/03/02(土) 21:35:07.04

>>393
> ここは違うんじゃないの？箱は隠蔽のためではないでしょ？

いや、私のイメージでは隠蔽なんだが。

f :: a -> State s b を作れば >>= で簡単に箱から情報を取り出せる。
もっといえば、do 記法の中で <- を使うだけで情報を取り出せる。
そういう意味では隠蔽していないと言えるかもしれん。

でも、State モナドは return x でユーザーが箱に入れる情報の他に、
「状態を表す情報」もこっそり一緒に箱に入れている。
この「状態を表す情報」はユーザーは勝手に取り出したり書き換えたりできん。

これは情報の隠蔽と言えると思うのだが、どうだろうか。

ぶっちゃけて言えば、State や IO がモナドなのは私も理解できるが、
Maybe や Either などがモナドである必然性はちょっと説明できん。

たまたま Monad クラスに fail 関数があるから、かろうじて
Maybe や Either などがモナドであるメリットはあるが・・・
そもそも Monad クラスに fail 関数がある事自体私も意味が分からん。

399 ：デフォルトの名無しさん：2013/03/02(土) 21:35:47.93

haskellは副作用が無いと聞いたんですけど、IOモナドは副作用が出るのですか？
そもそも副作用がよくわからない。
f :: Int -> Int
f x = ２　機能に影響されない
se :: Int -> Int
se x = se x + 1　機能に影響される
こんなヤツ？

400 ：デフォルトの名無しさん：2013/03/02(土) 21:36:07.78

>>395
プログラム作るだけならIORefとかでぐぐったらいいと思う。

401 ：デフォルトの名無しさん：2013/03/02(土) 21:39:32.28

>>396
つまりHaskellでゲームを作る場合

　・関数Fを評価するとその関数はモナドを返す
　・そのモナドの中身にはステーを反映した関数F'のインスタンスが定義されている
　・次のフェーズではF'を評価してF''のインスタンスが格納されたモナドを返して
　・・・・

この世代交代を毎フレームするってこと？

402 ：デフォルトの名無しさん：2013/03/02(土) 21:43:13.95

>>395
方法はいくつかある。

本当にそのまま座標を管理する変数を書き換える事もできる。
Haskellにはメモリの書き換え処理をする関数も標準ライブラリで用意されている。

他には、移動する度に古い座標の変数を破棄し、新しい座標の変数を作ることもできる。
破棄した変数（を納めたメモリ領域）はガベージコレクタによってそのうち回収される。
こちらは、副作用は伴わない。

403 ：デフォルトの名無しさん：2013/03/02(土) 21:43:45.10

>>401
俺はそう理解している。ちなみに独習でHaskell歴半年。察してくれ。

404 ：デフォルトの名無しさん：2013/03/02(土) 21:45:27.53

モナドってこういうもの？

int x;
int getter(){return x;}
void setter(int a){x = a;}
void f(int* g(), void* s(int))
{
s(g() + 1);
}

f(getter, setter);

405 ：デフォルトの名無しさん：2013/03/02(土) 21:47:30.92

俺の人生

19xx年：生まれる
2013年：モナドがわからない　←いまここ

406 ：デフォルトの名無しさん：2013/03/02(土) 21:53:46.13

>>399
Haskell にも副作用はある。

プログラムソース中の、副作用がある部分と、副作用が無い部分が
明確に分離されるのが Haskell。
Haskell のプログラムで両者が混じることは、普通は無い。

> そもそも副作用がよくわからない。

>>392 でも少し説明したが、もっと簡潔に言うと、
下記の2つの事が両方とも護られていれば、純粋な関数、つまり副作用は無い。

・関数 f について、a == b ならば f a == f b である。
・関数 f について、計算以外の事をしない。

少なくとも一方が守られなければ、たいていは副作用がある関数だと思って間違いない。

407 ：デフォルトの名無しさん：2013/03/02(土) 21:57:15.66

副作用の話はこれが一番分かりやすいと思う
http://d.hatena.ne.jp/kazu-yamamoto/20090627/1246135829
視点の違いであるっちゃあるし、ないっちゃない

408 ：デフォルトの名無しさん：2013/03/02(土) 21:57:55.81

>>404
そのゲッターとセッターが、型 int に結びつけられており、
かつ、そのゲッターとセッターがプログラマから隠されていれば、
Haskellのモナドの機能の一部は似ている、と言える。

409 ：デフォルトの名無しさん：2013/03/02(土) 22:33:39.28

メモリの破壊的な状態書き換えを副作用と呼ぶなら、
少なくとも実行時には副作用起こりまくり。

410 ：デフォルトの名無しさん：2013/03/02(土) 22:40:28.50

Excelシート : 副作用なし。モナドを使わないHaskellプログラム
Excelシート+VBA ：副作用あり。モナドを使うHaskellプログラム

411 ：デフォルトの名無しさん：2013/03/02(土) 22:42:49.41

関数の中で破壊したメモリを関数の外で(関数の戻り値として以外に)参照しないなら、
その関数は副作用を持たない

412 ：デフォルトの名無しさん：2013/03/02(土) 22:49:03.50

>>410
セルの内容書き換えられるがな（´･｀･ω）

413 ：デフォルトの名無しさん：2013/03/02(土) 22:55:47.97

>>409
そういう事もあり得るから、>>392 で意味論におけるとか、
意味上とか言って限定したんだがなぁ

414 ：デフォルトの名無しさん：2013/03/02(土) 22:57:46.02

>>398
たとえばStateモナド（を実装した代数データ型のインスタンス）から、パターンマッチで内部状態を取り出すことが
できるよね。
モナドであることの条件にこれを禁じるルールはないと思う。

415 ：デフォルトの名無しさん：2013/03/02(土) 23:05:11.95

>>413
意味論の側面は「参照透過性」と表現すると思う。

416 ：デフォルトの名無しさん：2013/03/02(土) 23:06:28.07

>>414
そのパターンマッチは m >>= f の f の中でしかできないんじゃないの？

417 ：356：2013/03/02(土) 23:06:56.98

>>414
data や newtype で定義した型の値コンストラクタが公開されていれば、
それが Monad クラスのインスタンスだろうがなんだろうが、
その値コンストラクタでパターンマッチできるよ。

値コンストラクタが公開されていなければ、
パターンマッチでは取り出せない。

モナドの話とは関係ないと私は思ってるんだけど、なんか関係あるかな？

418 ：デフォルトの名無しさん：2013/03/02(土) 23:08:37.40

>>412
ExcelシートのCellに"=2+3"と書き込むことは
Haskellでいうところの定義だろ？
*.hsファイルにエディタでx=2+3と書き込むのと一緒だと思う。

この定義されたセルをプログラムから書き換えるには
VBAを使うしかない。

419 ：356：2013/03/02(土) 23:11:16.90

>>414
あと、モナドで隠蔽するのは中の値だけじゃなく、
箱に値を入れる時にした計算や、箱から値を取り出した時にした計算も、
一緒に隠蔽するよ。

420 ：デフォルトの名無しさん：2013/03/02(土) 23:13:51.69

>>418
それ（Haskellの何をExcelの何で喩えているか）を始めにはっきり言わないと、
たいていの人には話は通じないよ

421 ：デフォルトの名無しさん：2013/03/02(土) 23:18:09.24

>>417
> モナドの話とは関係ないと私は思ってるんだけど、なんか関係あるかな？
俺もそう思ってるが、君が
> これは情報の隠蔽と言えると思うのだが、どうだろうか。
と言っているので。

422 ：356：2013/03/02(土) 23:40:21.81

>>421
ごめん、意味がよく分からない。

return 関数や >>= 演算子の実装で情報は隠蔽されるよね。
値も、その計算も、他の計算も処理も隠蔽されるよね。
そういう事を隠蔽と言ってるんだけど。

そのことと、たまたま data で定義した型の値コンストラクタが公開されている
という事による情報の公開は、モナドによる情報の隠蔽とは何も関係ないよね。

この一連の会話は、モナドの話だよね？

423 ：デフォルトの名無しさん：2013/03/03(日) 00:08:12.18

>>358
無知蒙昧なプログラマがHaskellに一体なんの不義理をしたんだよ

424 ：デフォルトの名無しさん：2013/03/03(日) 00:34:28.92

wxWidgets…　僕はもう疲れたよ…

http://hackage.haskell.org/trac/ghc/ticket/7103
http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault/Windows

425 ：デフォルトの名無しさん：2013/03/03(日) 00:35:47.68

モナドのうれしさは

■具体的な処理をブラックボックスとして扱うこと。
■個々の処理をつなぐことができること(>>=)。
■処理の結果を、次の処理以降では、ある意味でグローバルな変数 (自由変数) として使えること。(実際のスコープは Maybe や IO などのタグ (圏) の中に限定される)

モナドの枠組みが色々なものに当てはまるからわかりにくいけど、本質的には上記の点が共通しているはず。

426 ：デフォルトの名無しさん：2013/03/03(日) 00:39:30.80

例えば、手続き型言語では

■行を実行する
■結果を変数に代入する (しない場合もある)
■後ろの行は前の処理結果 (変数の値) を利用して計算したりする。

なんか、モナドの役割と対応つきそうでしょ？
だから、do を使う関数では手続き型言語っぽい書き方ができる。

私の理解はこんな感じです。
間違ってたらごめんね

427 ：デフォルトの名無しさん：2013/03/03(日) 00:46:27.07

モナドじゃなきゃ出来ないことってあるの？

428 ：デフォルトの名無しさん：2013/03/03(日) 00:51:25.77

実用的なこと全て

429 ：デフォルトの名無しさん：2013/03/03(日) 00:52:31.84

むかしはモナドなかったんよ

430 ：デフォルトの名無しさん：2013/03/03(日) 01:02:47.68

>>427
Haskellにおけるデザパタみたいなものなので、可読性が低くて良いなら
モナドを使った処理は全てモナドなしで書ける。（現在の入出力のように
最初からモナドで書かれたライブラリはのぞく）。

431 ：デフォルトの名無しさん：2013/03/03(日) 09:10:07.41

>■行を実行する
>■結果を変数に代入する (しない場合もある)
>■後ろの行は前の処理結果 (変数の値) を利用して計算したりする。

結局，モナドとは，手続き型言語ではふつうにやることを
関数型でもできるようにするデザパタのことと思えばよいの？

432 ：デフォルトの名無しさん：2013/03/03(日) 09:15:05.57

そういう用途もある

433 ：デフォルトの名無しさん：2013/03/03(日) 10:17:53.94

デザパタというのがＧｏＦのもそうだがまた胡散臭いんだこれがｗ

434 ：デフォルトの名無しさん：2013/03/03(日) 10:33:43.20

staticおじさん乙

435 ：デフォルトの名無しさん：2013/03/03(日) 10:59:19.94

今時デザパタ如きが胡散臭いってどこの原始人だよ

436 ：デフォルトの名無しさん：2013/03/03(日) 11:08:35.30

デザパタとアンチパターンを分ける基準がないから胡散臭い
良いか悪いか判断しないで用例を集めるだけにするべきだった
staticおじさんも良いか悪いかは別としてそういう書き方もありうると言うべきだった

437 ：デフォルトの名無しさん：2013/03/03(日) 11:49:15.77

>今時デザパタ如きが胡散臭いってどこの原始人だよ
これはどういう意味だ？
今はもう、デザパタどころではない胡散臭いのが出回ってるってことか
それともデザパタが偽モノなのはとっくに常識になってるってことか
それともまさか今時デザパタを信奉してんじゃないだろ？

438 ：デフォルトの名無しさん：2013/03/03(日) 11:55:51.70

>そういう用途もある
他の用途もいろいろあるというのでまた分からなくなるわけだ

439 ：デフォルトの名無しさん：2013/03/03(日) 12:13:06.01

ageる奴はバカの法則が見事に的中してるし

440 ：デフォルトの名無しさん：2013/03/03(日) 12:24:21.12

>>437
信奉の意味が分からない
状況に応じて使えそうなら参考にする、それだけのもんだろ
消化した上で使えないと判断するのは勝手だけど、胡散臭いなんて次元で語られる時期はとうに過ぎてる
その意味で原始人

441 ：デフォルトの名無しさん：2013/03/03(日) 12:57:11.67

>>431
Haskellに Monad クラスのインスタンス型がある理由は、本質的にはそれだよ。
特に IO モナドね。

その Monad クラスのインスタンスを引数にとったり返したりする関数に、
いろいろ便利なものがあるから、手続き型言語の事は忘れて、自分で色々応用すれば良いよ。

ただ、

> 手続き型言語ではふつうにやることを
> 関数型でもできるようにする

なんか「関数型ってこんな簡単な事をするのにも面倒だね」という
見下した感じを少し受けるのは私だけだろうか。

モナドの仕組みを組む人たちは面倒というか、そりゃ大変だったろうけど、
それを活用する我々プログラマにとっては、全然面倒じゃない。
むしろ、逆に純粋関数型でこんな事もできる、と幅が広がる。

442 ：デフォルトの名無しさん：2013/03/03(日) 13:46:54.84

なんの御利益があるかと問うこと自体、ある意味見下していると絡めなくもないけど
それは目くじらを立てても仕方ないだろう

443 ：デフォルトの名無しさん：2013/03/03(日) 14:27:02.73

「普通のプログラム経験はある人なら分かるように」なんて言っちゃうのは、普通の（手続き型）プログラム経験の延長上に関数型を捉えている感じでアレ

444 ：デフォルトの名無しさん：2013/03/03(日) 15:36:11.69

foldl f e = ($ e) . foldr ((.) . flip f) id

みたいにfoldlをfoldrで定義する練習問題みたいなのあるじゃん
こういうのを型を比べたり簡約したりでパズルみたいに書くのは出来るんだけど理屈はわからない

で色々考えた結果algebra of programmingにあるようなreverseがListから逆順リストへの自然変換とかいうの見方を使って
foldrそのものが関手μX. 1+A×X-代数のcatamorphismなんだからfoldlはμX. 1+X×A-代数のcatamorphismとみなして

F代数の圏でμX. 1+A×XとμX. 1+X×Aに同型っぽいのがあって、それをfoldrやfoldlに作用させると
最初に示したfoldlを計算で導きだせるんだろうなと思うんだけどそのF-代数同型射っぽいものが何か解らない

何か知ってる人教えてください

445 ：デフォルトの名無しさん：2013/03/03(日) 15:43:43.54

foldl f e = ($ e) . foldr (flip (.) . flip f) id
だったかもしれない

446 ：デフォルトの名無しさん：2013/03/03(日) 18:45:44.23

>>441 >>442 >>443
>>443は手続き型を見下しているようだが
おれは手続き型、関数型のどちらかを上とか下とか思っているわけじゃない
同じ土俵で見ようとしているだけだ
御利益を問われるのは当たり前のことだ。貴族じゃないんだから

447 ：デフォルトの名無しさん：2013/03/03(日) 18:53:37.82

代数データ型やパターンマッチがあり、カリー化があって
簡潔なコードが書き易く、静的型検査が強力で、
副作用のある部分と無い部分をキッチリ分離できる

そんな言語が、副作用のある部分を
手続き型と同じように書けるんだから
それだけで御利益あるだろ

448 ：デフォルトの名無しさん：2013/03/03(日) 19:03:27.10

>>446

>>431 の
> 手続き型言語ではふつうにやることを
> 関数型でもできるように

という言い方がなんかなぁ、と感じる。
「ふつう」なんてわざわざ書く（しかもひらがなで）ところも、
なんとなく馬鹿にしている感じがしないでもない。

例えば、手続き型言語の構文を関数型でも使えるようにするデザパタか、
と問われるなら、べつに嫌な感じはしないが・・・

449 ：デフォルトの名無しさん：2013/03/03(日) 19:06:45.67

手続き型と同じように書けるのはIO型
手続きじゃない部分でもdo記法とか使えるのがMonadクラス

450 ：デフォルトの名無しさん：2013/03/03(日) 19:26:19.16

>>448
それは悪かった。そんなつもりはまったくなかった。
しいて言えば、こっちがモナドに馬鹿にされてると感じてるかもしれん

451 ：デフォルトの名無しさん：2013/03/03(日) 20:30:33.90

>>446
手続き型を見下してなんかいないよ
手続き型プログラミングと関数型プログラミングの間に存在するパラダイムの壁が認識できていないのではないか、ということだよ

452 ：デフォルトの名無しさん：2013/03/03(日) 20:42:19.78

>>451
手続き型はもちろん、モナド込みの関数型でも、どちらのパラダイムも満足
できるものではないと思っている。だからパラダイムとか壁とかという表現も
なんだかなと思うのだ

453 ：デフォルトの名無しさん：2013/03/03(日) 20:53:23.10

>>452
パラダイムに満足できるかどうかと、
パラダイムに違いがあるかどうかという事とは、
全く別の事だと思う。

それとも、両者のパラダイムに満足できなければ、
両者のパラダイムにたいした違いは無いという事になるの？

>>443 >>451 は、パラダイムにはっきりとした違いがあるのだから、
一方のパラダイムをもう一方のパラダイムの延長で考えるのではなく、
違いを認識して別物として考えないといけないのではないか、
と言っているのだと思う。

454 ：デフォルトの名無しさん：2013/03/03(日) 21:40:53.72

>それとも、両者のパラダイムに満足できなければ、
>両者のパラダイムにたいした違いは無いという事になるの？

うん。第三のパラダイムから見ればそういうことになるね。
モナドだってそう思ってるんじゃないの？

455 ：デフォルトの名無しさん：2013/03/03(日) 21:42:49.12

>>447
これに尽きるな。

456 ：デフォルトの名無しさん：2013/03/03(日) 22:09:28.85

>>454
満足できるかどうかは個人の主観の問題だよな。
違いがあるかどうかは視点の問題だよな。

前者の結果によって後者が影響されるのはおかしくないか？

457 ：デフォルトの名無しさん：2013/03/03(日) 23:12:13.13

>>447 >>455
>副作用のある部分と無い部分をキッチリ分離できる
>そんな言語が、副作用のある部分を
>手続き型と同じように書けるんだから

モナドの御利益はこれに尽きるとのことなので、
スマンが、そこが分かるこれぞという例題を一つ教えてもらえんだろうか

458 ：デフォルトの名無しさん：2013/03/03(日) 23:20:44.85

> それだけで御利益あるだろ

これを

> モナドの御利益はこれに尽きるとのことなので、

こう解釈する時点で、悪意があることがハッキリしたね

459 ：デフォルトの名無しさん：2013/03/03(日) 23:22:55.65

頭が悪いだけかもしれん
どうしても自分の理解できる範囲で収めたがってるように感じる

460 ：デフォルトの名無しさん：2013/03/03(日) 23:27:50.12

悪意はないよ

461 ：デフォルトの名無しさん：2013/03/03(日) 23:29:10.07

>>457
import System.Random

main :: IO ()
main = do
　v <- randomIO :: IO Int
　let a = double v
　print a

double :: Int -> Int
double x = x * 2

main 関数は戻り値が IO () 型で副作用がある。
double 関数は戻り値が Int 型で副作用がない。

副作用がある関数とない関数、それぞれの定義が必然的に明確に分かれる。
（ただし変な事をしない限り）

462 ：デフォルトの名無しさん：2013/03/03(日) 23:37:32.74

>>461
とりあえずあんがと

463 ：デフォルトの名無しさん：2013/03/03(日) 23:45:29.84

>>461
>副作用がある関数とない関数、それぞれの定義が必然的に明確に分かれる
これだけだとvoidとintの区別と同じだねと思うよね。もちろん悪意なんかないよ

464 ：デフォルトの名無しさん：2013/03/03(日) 23:51:38.96

え？馬鹿？

もちろん悪意なんてないよ

465 ：デフォルトの名無しさん：2013/03/03(日) 23:52:05.09

>>463
> voidとintの区別と同じ

もっと詳しく説明していただけないでしょうか。
できるだけ例を分かりやすく改善させたいと思います。

Int 型を戻り値とする関数の中で
副作用がある処理はできないという事を簡単な例で示したつもりです。

C 言語の int 型を戻り値とする関数では、
中で printf 関数を呼べたりできるので、
Haskell のものとは全く違うと思うのですが。

466 ：デフォルトの名無しさん：2013/03/04(月) 00:21:37.53

Haskell Report 2010　読めば良い。

467 ：デフォルトの名無しさん：2013/03/04(月) 00:55:52.99

>voidとintの区別と同じ
流石にアホすぎるわ
説明求める前に入門書でも読めよ

468 ：デフォルトの名無しさん：2013/03/04(月) 01:02:54.47

>副作用がある処理はできないという事を簡単な例で示したつもりです。

何が「できない」か説明したくなるのは静的型だから当然ではあるけど
やっぱり何が「できる」かを堂々と言える動的型を先に習得して
その後でHaskellをやった方が話が早いんじゃないかと思う

469 ：デフォルトの名無しさん：2013/03/04(月) 01:06:52.58

動的型だの静的型だのは副作用と関係ねーよ
それとも静的型なら再代入ができなくなるのか

470 ：デフォルトの名無しさん：2013/03/04(月) 01:38:35.27

無駄にプライドの高い中学生みたいな手続き脳&スパゲッティ脳が居る

471 ：デフォルトの名無しさん：2013/03/04(月) 03:15:23.07

ｐｅｒｌ忍者最近見ないな

472 ：デフォルトの名無しさん：2013/03/04(月) 07:01:52.07

>>465
>Int 型を戻り値とする関数の中で
>副作用がある処理はできないという事

なるほど、これは分かる。関数型だからね。
しかしそれなら、Ｃでもコンパイラでチェックしようとすればできることだ。
むしろmainの方が本質的なのか？

473 ：デフォルトの名無しさん：2013/03/04(月) 07:02:55.62

>>468

>>457 で求められたのは次の要素を含む例でした。

>副作用のある部分と無い部分をキッチリ分離できる
>そんな言語が、副作用のある部分を
>手続き型と同じように書けるんだから

まず、関数 double 内では副作用がある処理はできないことで、
副作用のある部分と無い部分をキッチリ分離「できる」事を示しています。

そして、main 関数の中で副作用がある処理を
手続き型と同じように「書ける」事を示しています。

「できる」「書ける」ことを例として示しましたが、
分かりづらければ、具体的に何処が分からなかったか指摘してください。
改善します。

474 ：デフォルトの名無しさん：2013/03/04(月) 07:04:20.32

>>472
コンパイラ依存の話をしているのではなく、
言語としての仕様の話をしているのだと思っていました。

それは私の勘違いでしょうか。

475 ：デフォルトの名無しさん：2013/03/04(月) 07:30:32.05

>>472
Cコンパイラは次の関数ポインタを受け取る関数

int twice(int (*f)(int), int x) {
return f(f(x));
}

が副作用があるか無いかを、どうやって知れば良いの？
渡される関数ポインタfがどんなものか分からないのに。
それとも、関数ポインタが渡されるときは、常に副作用があると考えるの？

なお、Haskellの場合は、副作用の無い関数として定義できるよ。

twice :: (Int -> Int) -> Int -> Int
twice f = f . f

476 ：デフォルトの名無しさん：2013/03/04(月) 08:29:51.07

Haskellのコンパイラは副作用の有無をどうやって知るの？

477 ：デフォルトの名無しさん：2013/03/04(月) 08:35:33.68

知るも何も、Haskellに副作用は存在しないから

478 ：デフォルトの名無しさん：2013/03/04(月) 08:39:28.49

>>476-477
お前らスレの流れも追えないのか

479 ：デフォルトの名無しさん：2013/03/04(月) 09:40:58.03

分かってる人には当たり前なのかもしれないが

> double :: Int -> Int
> double x = x * 2

これを
> 関数 double 内では副作用がある処理はできない
こう説明されても、なぜできないのかサッパリ分からんぞ？

480 ：デフォルトの名無しさん：2013/03/04(月) 10:50:47.04

それは単に副作用とは何かを理解していないだけでは？
そもそもHaskellは、副作用のある関数を書くことが文法上できないのだから

481 ：デフォルトの名無しさん：2013/03/04(月) 10:56:46.98

元々「副作用」って言葉に明確な定義なんてないだろ。アホか

482 ：デフォルトの名無しさん：2013/03/04(月) 11:00:29.57

>>479
できない理由として考えられる物は二つ
・わざとできないように公理系を作ったから
・公理をいくら変えてもできないものはできないから
後者は科学
前者は科学ではないかも

483 ：デフォルトの名無しさん：2013/03/04(月) 11:12:37.52

流れ全く読まずにドヤ顔レスするやつが定期的に湧くね、このスレ

484 ：デフォルトの名無しさん：2013/03/04(月) 11:17:51.63

↑ドヤ顔レスの一例です

485 ：デフォルトの名無しさん：2013/03/04(月) 11:36:27.90

例えば画面への出力を副作用と呼ぶなら、その時に”副作用でない”、意味のある処理って何？って話だな。
世間一般でいう副作用って、本来は不要なものってイメージがあるから。

486 ：デフォルトの名無しさん：2013/03/04(月) 11:49:11.42

>>485
言語によっては、GCを強制的に掛けることができるものがある。
時系列 t1, t2 を考えて、強制GCの応答速度が t1,t2で異なるとすると、
ほとんどの計算に副作用があることになる。

487 ：デフォルトの名無しさん：2013/03/04(月) 11:49:38.54

プログラミング言語の文脈では、たとえばCの規格の用語である「副作用完了点」のように、
世間一般の用語とは別に、意味がある術語だから。

488 ：デフォルトの名無しさん：2013/03/04(月) 11:50:12.12

>>486
GCと副作用関係なくね？

489 ：デフォルトの名無しさん：2013/03/04(月) 11:52:56.51

関係ないことを証明せよ

490 ：デフォルトの名無しさん：2013/03/04(月) 11:53:12.11

>>488
少なくとも>>485はReturn 以外に何かプログラマに影響を与えるものが
残されるのが副作用という解釈のように読めたから。

491 ：デフォルトの名無しさん：2013/03/04(月) 12:04:41.81

>>484
そんな脊髄反射レスするほど悔しかったのか……

492 ：デフォルトの名無しさん：2013/03/04(月) 12:10:01.00

>>491
うぜぇ

493 ：デフォルトの名無しさん：2013/03/04(月) 12:14:19.56

お前らが何について話したいのか全く分からん

494 ：デフォルトの名無しさん：2013/03/04(月) 12:17:36.04

>>493
>>485は功利的な価値のあるものが主作用であって、副作用と呼ばれて
いるものが主作用なのではないの？と訊いている。

495 ：デフォルトの名無しさん：2013/03/04(月) 12:20:33.94

その答えは >>487 で出てる

496 ：デフォルトの名無しさん：2013/03/04(月) 12:22:38.05

関数の副作用について話してるんじゃないのか？
関数の主作用は関数の戻値
戻値以外に何か意味のある作用があればそれが関数の副作用

497 ：デフォルトの名無しさん：2013/03/04(月) 12:25:51.49

このおっさん副作用も知らんで
やたら偉そうに質問してくるのが凄いよな

498 ：デフォルトの名無しさん：2013/03/04(月) 12:32:10.99

>>496
そうだよ。だから最後の「なにか意味のある」を引き出したくて、
>>486を書いたんだ。

499 ：498：2013/03/04(月) 12:33:47.60

ごめん。「何か意味のある」だった。

500 ：デフォルトの名無しさん：2013/03/04(月) 12:33:53.28

>>494
そこで静的型が関係してくる
returnする型を静的に宣言したり解析したりするから主作用
そういうことをしてない方が副作用
してない方が主になったら静的型が衰退するから

501 ：デフォルトの名無しさん：2013/03/04(月) 12:40:21.80

副作用の定義なんか誰も聞いてないのに、どうしてこうなった？

502 ：デフォルトの名無しさん：2013/03/04(月) 12:42:31.24

わかったぞｗ頭のおかしい奴が2匹いるｗ

503 ：デフォルトの名無しさん：2013/03/04(月) 12:47:06.02

>>502
まあ待て、まだ自演説が残されている

504 ：デフォルトの名無しさん：2013/03/04(月) 12:50:53.77

最後に返す型がIOじゃないと作用しないんじゃね
letとかでIOの関数定義したとしてもただの定義だから動かないからin以降でその関数呼び出すことになる
結局元の関数の型はIOになる

505 ：デフォルトの名無しさん：2013/03/04(月) 13:13:43.30

Haskellのモナドが意味無いものという結論が欲しいので、
副作用のある部分と無い部分をキッチリ分離できるというモナドの特性を否定するために、
副作用について議論をしたいと思います

506 ：デフォルトの名無しさん：2013/03/04(月) 13:26:33.54

いや、意味はあるが意味を求めた代償として不自然になる
自然は不変だが不自然は変化しやすいので気をつけよう

507 ：デフォルトの名無しさん：2013/03/04(月) 13:32:04.44

>>501
突然「お前は副作用を理解してない」とか言い出すやつが来たから

508 ：493：2013/03/04(月) 13:41:19.16

>>505
なるほど理解できた、ありがとう

509 ：デフォルトの名無しさん：2013/03/04(月) 14:23:47.28

で、結局モナドてなんなの？

510 ：デフォルトの名無しさん：2013/03/04(月) 14:39:07.14

暗殺集団だろ

511 ：デフォルトの名無しさん：2013/03/04(月) 14:42:25.73

IOを中心とする型の集合

512 ：デフォルトの名無しさん：2013/03/04(月) 14:43:58.29

自己関手の圏のモノイド対象

513 ：デフォルトの名無しさん：2013/03/04(月) 14:52:27.78

手続き処理を記述するための汎用性の高い抽象クラス
具象化する際にいろんな仕組みを多重的に組み込める

514 ：デフォルトの名無しさん：2013/03/04(月) 15:05:01.66

手続きはIOだけ
IO以外のモナドは、演算子オーバーロードで手続きのように見えるだけ

515 ：デフォルトの名無しさん：2013/03/04(月) 15:07:51.87

m>>=fのfが手続き的に順番に評価されていくのがすべてのモナドで基本じゃないの？

516 ：デフォルトの名無しさん：2013/03/04(月) 15:19:13.10

Monadは型クラスで、型クラスはオーバーロードしかしないよ

517 ：デフォルトの名無しさん：2013/03/04(月) 15:26:13.03

それがどうした

518 ：デフォルトの名無しさん：2013/03/04(月) 15:50:28.23

誰も突っ込んであげなかったようなので僕が処理しときますね

>>510
それはモサドやろが！

519 ：デフォルトの名無しさん：2013/03/04(月) 17:23:56.54

518の優しさに泣いた

520 ：デフォルトの名無しさん：2013/03/04(月) 20:01:38.17

Haskellに副作用がないなら、C言語にも副作用はないといえるのでは？
C言語を、ソースコードと実行ファイルを結び付ける関数とすれば、そこには副作用はない。

521 ：デフォルトの名無しさん：2013/03/04(月) 20:03:41.88

eval は Env と f を引数に取る。 eval の後に Env が変化するとき、それを副作用と呼ぶ。

522 ：デフォルトの名無しさん：2013/03/04(月) 20:09:16.91

>>520
だから、それは副作用をどう定義するかによる。
と今までいくつかのレスで言われていますが、見ていませんか？

あなたの定義ではC言語にも副作用はないと言える。
しかし別の定義ではそれは成り立たない場合もある。

普通、「Haskell は副作用のある部分とない部分を明確に分ける」
と言った場合の副作用は、たいていのHaskellプログラマの共通認識として、
C言語にも副作用はないとは言えないような定義だと思う。

523 ：デフォルトの名無しさん：2013/03/04(月) 20:16:13.53

ある結果 (型など) を期待した時に
期待を裏切るというか期待と無関係な副作用が問題になる
期待がなければ主作用も副作用もない

524 ：デフォルトの名無しさん：2013/03/04(月) 20:24:15.20

コンピュータ・サイエンスにおける副作用
http://en.wikipedia.org/wiki/Side_effect_%28computer_science%29

Haskell のプログラミングという文脈で副作用といった場合は、
普通はこれを指します。

525 ：デフォルトの名無しさん：2013/03/04(月) 20:45:42.34

副作用の有無で、Haskellと、C言語などの他の言語を切り分けるのは難しいと思うよ。
副作用という言葉について、よほど恣意的で狭い定義を作らない限りは。

でも「参照透過性」なら、切り分けられるだろう。

526 ：デフォルトの名無しさん：2013/03/04(月) 21:05:55.56

>>473 　遅くなったがありがと

>まず、関数 double 内では副作用がある処理はできない
これはgoodだが、Ｃでもできる（モナド固有の利点ではない）と472で言った。

>副作用がある処理を手続き型と同じように「書ける」
これももちろん、Ｃでもできる。

結局、どちらもＣでもできることだがなあ、というのが現時点での感想。
どうなの？

>>474

>コンパイラ依存の話をしているのではなく、
>言語としての仕様の話をしているのだと

うん。言語としての仕様の話でいいです。
コンパイラ依存の話をしたつもりはないんだが。

527 ：デフォルトの名無しさん：2013/03/04(月) 21:10:07.17

間違った
>これはgoodだが、Ｃでもできる（モナド固有の利点ではない）と472で言った。
（正）これはgoodだが、Ｃでも、できないようにできる（モナド固有の利点ではない）と472で言った。

528 ：デフォルトの名無しさん：2013/03/04(月) 21:19:21.75

>>526
>>475のC言語のコードで副作用のある関数を渡したら
コンパイルエラーになる（警告でもいい）コンパイラを教えてくれ
無いなら、CでHaskellと同じことはできてない

529 ：デフォルトの名無しさん：2013/03/04(月) 21:32:39.33

>>526
たぶん、私のレスが勘違いをさせた原因なのでしょう、申し訳ないです。
Haskellでしかできない事だ、とは私は言っていないんです。

副作用のある処理、特に IO 処理をHaskellで表現する際に、
Haskellの利点（型安全、遅延評価、純粋性など）を
できる限り壊さず、かつ使いやすい方法は無いかと模索していたところで
モナドのアイデアを閃いたのが、もともとの発端だったと思います。
閃いたというよりは、出会ったと言った方がより正確ですが。
この辺りの経緯は、論文「A History of Haskell」に少し載っています。

ですが、考えてみてください。
副作用のある処理って、C言語ではできないのでしょうか。
Haskell の特徴なのでしょうか。
違いますよね、むしろC言語なら「普通にできる」事です。

副作用は、実用的なアプリケーションを作るのにまず間違いなく必要なものです。
Haskellは実用的になるように目指した言語なので（上記論文参照）、
Haskellでも「手続き型言語のように」副作用が絶対に必要です。

それを、Haskellの利点を壊さないように取り入れるのに使ったアイデアがモナドです。
モナドのアイデアが採用される前は別の方法でIO処理をしていました（上記論文参照）

したがって、C言語でもできるよね、と感じるのはむしろ当たり前です。
C言語でできる事をHaskellでも、といって取り入れた機能なのですから。

だから本当は、副作用のある処理ができる事がモナドの特徴なのではなくて、
副作用のある処理が「Haskellの良さを壊さずに」できることが特徴なのです。

副作用の部分をきっちり分けることでHaskelの良さを壊さない、
型システムになじませることでHaskelの良さを壊さない、ということです。

530 ：デフォルトの名無しさん：2013/03/04(月) 21:59:42.46

>>529 丁寧な説明ありがとう

>だから本当は、副作用のある処理ができる事がモナドの特徴なのではなくて、
>副作用のある処理が「Haskellの良さを壊さずに」できることが特徴なのです。

はい。そうなのだろうと思います。それは分かります。

>副作用の部分をきっちり分けることでHaskelの良さを壊さない、

副作用の部分を分けることは、Ｃの場合でもvoidとintなどの区別でできると
前に言いました。「きっちり」というところがHaskellとＣとで違うという
ことでしょうか？しかし少なくとも先のdoubleの例題ではそんなに違いは
見えないのですが。

>型システムになじませることでHaskelの良さを壊さない、ということです。
この点も（たぶん）分かってると思います。

531 ：デフォルトの名無しさん：2013/03/04(月) 22:09:30.20

>>530
Haskellは参照透過な形で副作用を含む処理を表現できるけれども、
C言語では、ほとんどの場合、参照透過な形では表現できない。ってところでは？

529ではないけれど。

532 ：デフォルトの名無しさん：2013/03/04(月) 22:10:43.57

>>528
おもしろい例題なので返答を考えていた所だったが時間がないので
そのうちにということにしてくれ。すまん。
ただこの例題は、もとのモナドの問題と直接関係ないと思うし、
現実のＣと比べることもあんまり意味はないと思う。
ポインタというのもなんだかなだし。今日はそんなところだ。

533 ：デフォルトの名無しさん：2013/03/04(月) 22:18:02.78

>>531 コメントありがと

>Haskellは参照透過な形で副作用を含む処理を表現できるけれども

ごめん。それが分からんのだ。
なにかこれぞというプログラム例はある？
doubleの例がそれかい？

534 ：デフォルトの名無しさん：2013/03/04(月) 22:19:56.81

>>532
ポインタが出てくるのは、Haskellのクロージャに近いものが
Cでは関数ポインタしか無いからだし、
間違って副作用のある関数を渡せないという例なんだから
副作用のある部分とない部分を明確に分けるという話に直接繋がってるよ

535 ：デフォルトの名無しさん：2013/03/04(月) 22:22:33.09

>>533
横レスだけど少しはモナドでググって知識を付けてから質問したらいいと思いました

536 ：デフォルトの名無しさん：2013/03/04(月) 22:27:06.98

このおっさん都合の悪いレスは全部無視するから無駄だと思うぞ

537 ：デフォルトの名無しさん：2013/03/04(月) 22:27:07.99

Cだったら副作用のある関数を「書こうと思えば書けてしまう」けど，
Haskellだったらそんなものはそもそもコンパイルが通らない（から安全）
って話じゃないの？

538 ：デフォルトの名無しさん：2013/03/04(月) 22:43:10.55

mainに一回だけunsafePerformIOを適用すること
それ以外はunsafePerformIOを適用しないこと

このルールをコンパイラが保証できるか？
暗黙のルールをこっそりと保証するにはどうすればいいのか

539 ：デフォルトの名無しさん：2013/03/04(月) 22:44:47.74

Cに副作用がないとか言ってる奴は、そもそも計算とは何かなんて考えた事もないんだろうな。

540 ：デフォルトの名無しさん：2013/03/04(月) 22:48:42.18

そもそも計算とは何なの？

541 ：デフォルトの名無しさん：2013/03/04(月) 22:49:18.35

親切に何度もリンク貼ってくれてるのに読んでないんだろうなあ>副作用
この人質問するのはいいけど全然自分で調べようとしないから話が進まないにも程がある

542 ：デフォルトの名無しさん：2013/03/04(月) 22:51:21.15

「汚いまま、アホなままで良いからシンプルにしとけ。」
それがマシンパワーの弱かった時代のCとUNIXの哲学だからな。
ところが本物のアホは今やそれがアホげた志向だと気づく事が出来ない。
こういうアホはそのうち今のCOBOLとコボラー並に邪魔ものになるよ。

543 ：デフォルトの名無しさん：2013/03/04(月) 22:55:03.82

いや、CとUNIXの汚さは副作用とか以前の問題だし……

544 ：デフォルトの名無しさん：2013/03/04(月) 23:24:24.15

>>530
きっちりなんて曖昧でしたね、すいません。
「きっちり分けられる＝関数単位で分けられる」です。
Haskell のプログラムの基本単位は関数です。

Haskell の言語仕様では関数単位で副作用の有無が定まります。
ステートメント単位とか、命令単位とか、行単位とかではなくて、
関数単位です。

戻り値が IO a 型ではない関数は、絶対に副作用はありません。
（本当は例外があるのですが、話がややこしくなるので今は考えません）
しかし、ほんの少しでも副作用をさせたいのなら、
その関数は IO a 型の値を戻さないといけません。
ほんの少しであっても、「その関数自体が副作用がある」と見なされます。

逆に IO a 型を戻す関数は、副作用があるかどうかは、
実はその関数の定義（中身）を見なければ明らかにはなりません。
ですが、この関数は中に副作用がある処理を含めることが「可能」なので、
IO a 型を戻す関数を内部に含む関数も IO b 型の値を戻すと決められています。

これらは言語仕様です。
プログラマが注意してそのように書くとこで安全性が保たれる、
というレベルの話ではなく、そうしなければコンパイルできないというレベルです。
（>>537）

コンパイラは関数の戻り値の型によって、
副作用が絶対に無い関数か、副作用がある可能性がある関数かを見分けます。

そして、ここが大事ですが、プログラマもコンパイルが通るように、
副作用がある関数か、副作用がない関数かをしっかり意識して分けます。
（初心者にとっては、分けざるを得ないという認識でしょうか）

545 ：デフォルトの名無しさん：2013/03/04(月) 23:42:07.28

>>530
C言語でも分けられると言いますが、実際のところ、
Haskellのようにしっかり分けるCプログラマはまずいないでしょう。

実行効率やプログラムソースの読みやすさなど、理由はいくつかあります。

やろうと思えば分けられる言語と、分けることが前提の言語では全く違うと思います。

この辺りは、C vs C++ におけるオブジェクト指向と似てるかも知れません。

546 ：デフォルトの名無しさん：2013/03/04(月) 23:52:28.17

C vs C++は酷かった
CでOOPできないと主張するために、OOPの必須条件が次々と追加されたよね

547 ：デフォルトの名無しさん：2013/03/05(火) 00:26:28.70

haskellでは副作用がある部分とない部分を区別して書くことができます
じゃなくて
haskellでは副作用がある部分とない部分を区別しないと書けません
だろ

できることじゃなくてできないことに意味がある
カプセル化みたいなもん

548 ：デフォルトの名無しさん：2013/03/05(火) 00:45:39.99

Haskellは全部副作用ありで書くことはできるんじゃない

549 ：デフォルトの名無しさん：2013/03/05(火) 00:56:33.07

コンパイラはそれを許してくれる
周囲の人間の方が厳しい

550 ：デフォルトの名無しさん：2013/03/05(火) 01:15:51.28

いや、普通に規格違反だから。拡張使えば書けるけど、Haskellの仕様としては無理。
コンパイラも標準ではそんな書き方認めてないだろ

551 ：デフォルトの名無しさん：2013/03/05(火) 01:25:00.64

それでHaskellに於ける副作用とは何なんですか。誰がどういう基準で
それを副作用と考えるのですか。

552 ：デフォルトの名無しさん：2013/03/05(火) 01:25:43.62

型を全部IO xとかで定義しなおしていけばできるんじゃない？ｗ
ひどくメンドクサイことになると思うがｗ

553 ：デフォルトの名無しさん：2013/03/05(火) 01:25:57.36

便乗質問というか教えてほしいんだけど
(文法うろ覚えで間違ってるだろうけどふいんきを読み取ってほしい)

unMaybe :: Maybe Int -> Int
unMaybe Just num = num
unMaybe Nothing = 0

みたいな感じで
unIO :: IO Int -> Int

とかできないの ?
できちゃうと副作用の分離が壊れちゃうような気がするんだけど.....

多分、モナドと副作用とIOをごっちゃにしてるんだと思うんだけど、
あと、上で出てきた関数単位では分離出来ているとかそういう話が
理解できてないんだと思うんだけど、
ご教授お願いします。

554 ：デフォルトの名無しさん：2013/03/05(火) 01:45:00.19

>>553
できない

555 ：デフォルトの名無しさん：2013/03/05(火) 01:58:32.92

>>551
>>524

556 ：デフォルトの名無しさん：2013/03/05(火) 03:46:01.48

unsafe～を risky～に替えよう（提案）

557 ：デフォルトの名無しさん：2013/03/05(火) 06:44:09.97

>>553
unsafePerformIOを使えばできる
が、これは通常使用されるべきものではない

558 ：デフォルトの名無しさん：2013/03/05(火) 18:46:22.28

Haskellは参照透過だというのは納得している。
すべてを数学的な関数で表現しているという意味で。

だけど、Haskellには副作用がない・・とする主張は詭弁だと思う。

Haskellに副作用がないといえるなら、C言語もある意味で副作用ないといえると思う。
実際に動作する前までは・・。

DanoMoiの説明を見たときは、ケムにまかれたという感想でもなくて、単に「は？」だった。

559 ：デフォルトの名無しさん：2013/03/05(火) 18:58:39.16

なにか高級な機構を「けむに巻くかのように」説明するかと思えば・・。

副作用の定義を慎重に狭く決めた上、C言語とHaskellの間の、
解釈から実行に至るまでの処理の違いを大げさに主張しただけ。

Haskellの処理と実行の間に、仮想の？プロセスを挟み込んで
そのプロセスをHaskellではないとみなすことで、
副作用とやらについて、やっとC言語と差別化できる。

まあ、偉そうなハスケラーには反感を持っていたので
最初から同意するつもりなかったけどね。

560 ：デフォルトの名無しさん：2013/03/05(火) 18:58:42.24

わけわかめ

561 ：デフォルトの名無しさん：2013/03/05(火) 19:02:10.79

>>535
モナド何読んでもわからないという話から始まっているんだこのスレッド。

562 ：デフォルトの名無しさん：2013/03/05(火) 19:15:45.30

定期的に恨みつらみを述べてスレを埋めるお仕事乙です

563 ：デフォルトの名無しさん：2013/03/05(火) 19:16:01.07

なぜHaskellとCが同じになるのかさっぱりわからん

564 ：デフォルトの名無しさん：2013/03/05(火) 19:16:29.69

>>558
Cは問題ないが、クラスとコンストラクタがある言語が問題だ
static変数を初期化する段階ですでに副作用がある
そういう実行前の副作用をなくしたことは評価されるべき

565 ：デフォルトの名無しさん：2013/03/05(火) 19:20:16.33

>>559
何を見ても偉そうに感じる人生なんて想像できない
もっと教えてください！

566 ：デフォルトの名無しさん：2013/03/05(火) 20:05:34.24

>>559
もうちょい頭良かったら理解できたのにね
まあその日本語力からして無理か

567 ：デフォルトの名無しさん：2013/03/05(火) 20:14:52.77

Cプログラマを下に見ているのは真のLisperぐらいだと思っていたが。
関数型プログラミングの流行で浅はかなHaskellerが増えたんだな。

568 ：デフォルトの名無しさん：2013/03/05(火) 20:23:42.37

Cプログラマじゃなくて
このおっさんがバカだなって話だけどな

569 ：デフォルトの名無しさん：2013/03/05(火) 20:24:39.28

ごめん、別スレでこのおっさんにそんなだからHaskellerに相手されないんだみたいなこと言ったの俺かもしれない。

570 ：デフォルトの名無しさん：2013/03/05(火) 20:27:21.90

>>567
Cプログラマに失礼だろ、Cでガリガリプログラム組むようなやつは
Cの問題点もきっちり理解してるし
Haskellみたいなやり方があることも理解してる

571 ：デフォルトの名無しさん：2013/03/05(火) 20:32:01.14

>>569
おまえか
おかげでここ数日アホみたいな質問で埋まってウンザリしたわ
長文で我慢強く答えてた人は天使だと思った

572 ：デフォルトの名無しさん：2013/03/05(火) 20:32:03.85

いやHaskellをそれなりぐらいには理解してるCエキスパートって、まだそんなに多くないだろ

573 ：デフォルトの名無しさん：2013/03/05(火) 20:41:59.59

Haskellのやり方が理解できないとか、Cのエキスパート以前にプログラマとしてダメダメやん

574 ：デフォルトの名無しさん：2013/03/05(火) 20:47:58.77

>>570
さよう

575 ：デフォルトの名無しさん：2013/03/05(火) 20:52:44.25

>>573
純粋関数型なのに、どうやって入出力を実現するの？　というのが疑問、ってぐらいが普通だと思うけど。
まだそんなにはHaskellは普及してない。

576 ：デフォルトの名無しさん：2013/03/05(火) 20:54:59.78

上の方にも副作用を分離してるって書いてあるだろ
分離できる（それを静的にチェックできる）だけで副作用はあるよ

577 ：デフォルトの名無しさん：2013/03/05(火) 21:03:45.37

>>575
C言語のエキスパートなら、
関数型的なコードと入出力部分のコードを分離してみるなんて普通に試してみたりするもんだ

578 ：デフォルトの名無しさん：2013/03/05(火) 21:04:35.35

C等命令型言語には副作用があって、Haskellには副作用はないと主張する立場から、
それなりに答えたのは、DanoMoiの例くらいだと思うよ。
他の「Haskellには副作用は存在しない」教信者は、「お前は理解してない」と言い張るのみだ。

なお、「Haskellには副作用は存在しない」教信者とHaskell信者は一致しない。

579 ：デフォルトの名無しさん：2013/03/05(火) 21:09:58.41

このスレのほとんどの奴は副作用が無いんじゃなくて副作用を分離してるって言ってるだろｗ

580 ：デフォルトの名無しさん：2013/03/05(火) 21:11:29.88

恐らく、Haskellを純粋関数型言語である
ということくらいしか知らない多くの他言語プログラマにとっては、
「Haskell ＝副作用が無い」という認識なのだと思います。

それくらい、他言語プログラマにとって Haskell はまだまだ謎な言語で、
関わりの無い言語だと言うことなのでしょう。

もし、他言語プログラマにもHaskellに興味を持ってほしいと思っているのなら、
Haskell プログラマがもっと増えるといいなと思っているのなら、
根気よく丁寧に説明していくしか無いと思います。

そんなのはどうでもいい、という事なのでしたら、
せめて説明している人の邪魔だけはしないであげてほしいです。
勘違いの指摘は大歓迎だと思いますが。

581 ：デフォルトの名無しさん：2013/03/05(火) 21:18:44.93

あんた偉いよ
どうでも良いとは思わんけど、ここ数日の質問者クラスのアホだと教える気なくすわ

582 ：デフォルトの名無しさん：2013/03/05(火) 21:33:54.20

べつに丁寧に教えなくても
ヒントを少し書いてはい論破でいいんだよ
難しく考えすぎ

583 ：デフォルトの名無しさん：2013/03/05(火) 21:42:17.34

こんなこともできるんだって興味持って貰えるような
GUIアプリとかゲームとかクライアントサーバ的なものとか作って世に出してかないと
関数型の（精神的な）敷居は高すぎる

584 ：デフォルトの名無しさん：2013/03/05(火) 21:48:09.03

フロントエンドは.NETに頼るとして、Haskellをバックエンドとして使えないかな・・
と思っていますが・・。

シミュレーションゲーム作ろうとして挫折しているけど、思考部などをHaskellで作りたい。

Haskellに慣れるための練習として、パズル解答ソフト作成中です。

585 ：デフォルトの名無しさん：2013/03/05(火) 21:49:50.13

みんなHaskellでどんなアプリ作ってるの？

586 ：デフォルトの名無しさん：2013/03/05(火) 21:53:13.00

UIは入出力しかないしネットは文字列しかない
消去法でゲームが正解

587 ：デフォルトの名無しさん：2013/03/05(火) 21:55:20.69

>>475 >>532

>Cコンパイラは次の関数ポインタを受け取る関数
>int twice(int (*f)(int), int x) {
> return f(f(x));
>}
>が副作用があるか無いかを、どうやって知れば良いの？
>渡される関数ポインタfがどんなものか分からないのに。

twiceが副作用のない関数であることは、"int twice"から自明だ。
そして*fで指されたfが本当にint->intであることをチェックしたいなら
twice呼び出し側の"int (*f)(int)"パラメータの素姓を辿っていけばよい。
それだけのことだ。

>それとも、関数ポインタが渡されるときは、常に副作用があると考えるの？

そんなことはしない。

588 ：デフォルトの名無しさん：2013/03/05(火) 21:55:24.81

IOモナドのおかげで泥臭いIOがそれなりに安全に書ける
Haskell強力な手続き型言語だと思った

589 ：デフォルトの名無しさん：2013/03/05(火) 21:58:20.39

>>587
"int twice"から自明であると思った根拠を述べてください

590 ：デフォルトの名無しさん：2013/03/05(火) 22:03:57.07

>>587
int twiceから自明ってどういうこと？

int twice(int (*f)(int), int x){
static int n = 10;
return n = f(n);
}

591 ：デフォルトの名無しさん：2013/03/05(火) 22:04:55.30

副作用はvoidを返す関数のことじゃない

592 ：デフォルトの名無しさん：2013/03/05(火) 22:05:29.83

中でグローバル変数を更新してるかもしれないし、
Cでそれを型から確認する方法はないな。

GCCなら __attribute__ ((pure)); と書いて、プログラマの責任でコンパイラに対して
保証してやることはできるが。

593 ：デフォルトの名無しさん：2013/03/05(火) 22:06:40.17

>>587
> twiceが副作用のない関数であることは、"int twice"から自明だ。
え？

int twice(int (*f)(int), int x) {
    static int n = 0;
    n += f(f(x));
    printf("%d\n", n);
    return n;
}

594 ：デフォルトの名無しさん：2013/03/05(火) 22:13:34.88

だからバカなんだから相手すんなよ
まだ続けんのかよ

595 ：デフォルトの名無しさん：2013/03/05(火) 22:15:33.03

unsafePerformIOを自粛することが自明であるのと同じだと思うよ
voidではない関数の中では副作用を自粛する

596 ：デフォルトの名無しさん：2013/03/05(火) 22:17:21.80

>>595

int main(int argc, char* argv[]) {
}

副作用を自重してくださいね！

597 ：デフォルトの名無しさん：2013/03/05(火) 22:23:46.83

>>593
なんでそんなややこしい例をだすんだよｗ
int twice(int (*f)(int), int x) {
printf("%d\x", x);
return x;
}
でいいんだろ

598 ：デフォルトの名無しさん：2013/03/05(火) 22:24:48.69

int printf(const char*, ...)
なんか副作用ない気がしてきた

599 ：デフォルトの名無しさん：2013/03/05(火) 22:26:49.85

>>595
unsafePerformIOはgotoレベルだからまた別だと思うの

600 ：デフォルトの名無しさん：2013/03/05(火) 22:30:55.57

>>598
ようやく分かってきたか
それは副作用ないと判断すればいいんだよ
ほんとに分かってる？

601 ：デフォルトの名無しさん：2013/03/05(火) 22:32:41.74

>>598
ライブラリを作り直す必要があるね
Haskellはライブラリのついでに言語も作り直したのだ

602 ：デフォルトの名無しさん：2013/03/05(火) 22:36:28.74

printf系は副作用そのものを目的にしていると思うけど。

603 ：デフォルトの名無しさん：2013/03/05(火) 22:41:51.97

C++でさえ、<stdio.h>等を無かったことにする風潮だからな

604 ：デフォルトの名無しさん：2013/03/05(火) 22:42:54.23

>>597
static変数が使われたら自説が破綻するからややこしいということにしてstatic変数を消した

605 ：デフォルトの名無しさん：2013/03/05(火) 23:08:35.21

OpenGL の GLUT で簡易GUI作ったけど、C言語で書いた場合より複雑になった
もうダメだわ

606 ：デフォルトの名無しさん：2013/03/05(火) 23:14:14.74

>>605
何々をやってみたがダメだったとだけ言われても、
それがどうしたとしか言いようがない。

Haskellは使えんと言いたいのか？
それとも、何か質問や議論したいことがあるのか？

607 ：デフォルトの名無しさん：2013/03/05(火) 23:21:40.78

少なくとも、GUIデザインする場合、「俺には」使えん

608 ：デフォルトの名無しさん：2013/03/05(火) 23:23:10.41

だから、それがどうした

そんなもんツイッターにでも書いておけよ

609 ：デフォルトの名無しさん：2013/03/05(火) 23:25:58.50

議題：Callbackを簡潔に書くには？

610 ：デフォルトの名無しさん：2013/03/05(火) 23:28:54.79

それをクロージャがある言語に訊くか？馬鹿なのか？

611 ：デフォルトの名無しさん：2013/03/05(火) 23:34:32.38

じゃあGUIなんか簡単だよな>>610

612 ：デフォルトの名無しさん：2013/03/05(火) 23:36:09.19

私もglutはツールバーとかテキストフィールドで操作するのは発狂しそうになったから
マウスのクリックとドラッグ以外の操作は全部削除する方向で設計してる
細かい数値やテキストが必要になったら、起動時にファイル読み込み

http://www.dotup.org/uploda/www.dotup.org4010417.png

613 ：デフォルトの名無しさん：2013/03/05(火) 23:37:11.30

GUIは言語あんまり関係無い
RADツール次第

614 ：デフォルトの名無しさん：2013/03/05(火) 23:40:31.91

>>612
これ参考になりますか
http://www.cs.unc.edu/~rademach/glui/

615 ：デフォルトの名無しさん：2013/03/05(火) 23:42:12.72

GLUTは設計がクソすぎだから分からなくても仕方ないと思う

これ使えよ
http://www.haskell.org/haskellwiki/GLFW

616 ：デフォルトの名無しさん：2013/03/05(火) 23:43:07.77

>>611 はCallbackが簡潔に書ければGUIは簡単に書ける
と言っているように聞こえる。

そんな馬鹿なと言いたい。

617 ：デフォルトの名無しさん：2013/03/05(火) 23:46:30.93

GLUTは分からんというか、分かった上で複雑すぎる気がする

618 ：デフォルトの名無しさん：2013/03/05(火) 23:52:32.13

>>616
Callbackするフレームワーク
イベントキューを含めた話で

619 ：デフォルトの名無しさん：2013/03/05(火) 23:56:07.89

GLUTは低水準でもフレームやキューやコールバックを使いまくってるから困る

620 ：デフォルトの名無しさん：2013/03/05(火) 23:57:07.79

>>618
>>609 の時点で暗黙だったその前提が >>610 にちゃんと伝わってたと思ってるのか？

621 ：デフォルトの名無しさん：2013/03/06(水) 00:12:47.20

>>620
>>それをクロージャがある言語に訊くか？馬鹿なのか？
この発言が出るくらいだから理解しているはず

622 ：デフォルトの名無しさん：2013/03/06(水) 00:17:31.67

今日も微妙にかみあってないな、このスレ

623 ：デフォルトの名無しさん：2013/03/06(水) 01:06:15.27

一緒にからみあおうぜ！

624 ：デフォルトの名無しさん：2013/03/06(水) 02:26:45.23

外部APIなしでプラットフォームに付属してるモノだけでOpenGLのGLUTのメインウィンドウが表示されたときは少し感動したが

625 ：デフォルトの名無しさん：2013/03/06(水) 06:58:07.99

>>621
それはお前の思い込みだ。

お前は会社や学校でもそうやって後足しして
仲間を苛つかせてないか？

626 ：デフォルトの名無しさん：2013/03/06(水) 07:12:25.76

>>625
>後足しして

後出しして

627 ：デフォルトの名無しさん：2013/03/06(水) 08:03:03.67

>>589
言うまでもないと思うが聞かれたから言うよ
"int twice"と書かれているからだよ
ほんとにそうかはtwiceのbody部を見ればよい
xがintでfがint->intなのだし他に何もないからほんとだとわかる
fがほんとにint->intかは...（同じことの繰返し）

628 ：デフォルトの名無しさん：2013/03/06(水) 08:06:25.70

>>627
へー、じゃあコンパイラでチェックできますよね？
>>593のコードに警告かエラーを出すコンパイラ教えてください！

629 ：デフォルトの名無しさん：2013/03/06(水) 08:19:04.13

>ほんとにそうかはtwiceのbody部を見ればよい
バーカバーカ

630 ：デフォルトの名無しさん：2013/03/06(水) 09:07:50.97

>>628
君は>>589なのか。なのだろうな。もういいよ

631 ：デフォルトの名無しさん：2013/03/06(水) 09:09:45.69

>>629
お前も>>589なのか

632 ：デフォルトの名無しさん：2013/03/06(水) 09:33:07.68

>>627
副作用とは何かが全く分かってなさそう

633 ：デフォルトの名無しさん：2013/03/06(水) 09:34:52.26

副作用とは何ですか？

634 ：デフォルトの名無しさん：2013/03/06(水) 09:37:53.33

>>629
名言が生まれた瞬間だった

635 ：デフォルトの名無しさん：2013/03/06(水) 09:44:26.43

100歩譲ってint twiceの副作用と渡された関数の副作用を分けて考えてるとしても、「見れば分かる」ってすごいなｗ

636 ：デフォルトの名無しさん：2013/03/06(水) 09:56:04.04

いや、見てわからなきゃどうしろと？

637 ：デフォルトの名無しさん：2013/03/06(水) 09:57:46.43

最終的には見なきゃ分からないのが問題

638 ：デフォルトの名無しさん：2013/03/06(水) 09:59:36.88

モナドの話はどうなったのでしょうか？
ＩＯや副作用の話ばっかりになったようなのですが。

639 ：デフォルトの名無しさん：2013/03/06(水) 10:00:04.97

消えた

640 ：デフォルトの名無しさん：2013/03/06(水) 10:07:09.97

>>637
見るのがコンパイラでも？
Haskellは見なくても分かるの？

641 ：デフォルトの名無しさん：2013/03/06(水) 10:10:56.20

>>639
天使の君はどこへ行った？

642 ：デフォルトの名無しさん：2013/03/06(水) 10:22:23.61

>>640
どのコンパイラの話をしているの？
Haskellは文法上書けないから見るまでもない

643 ：デフォルトの名無しさん：2013/03/06(水) 10:26:49.28

>文法上書けないから
書いたらどうなるの？

644 ：デフォルトの名無しさん：2013/03/06(水) 10:28:43.09

>>643
だから書くための文法がないんだってば
書きたくても書けない
「書いたら」なんてあり得ない

645 ：デフォルトの名無しさん：2013/03/06(水) 10:38:20.10

書いた場合と書かなかった場合の両者を想定するのは動的型の発想
静的型は片方をあり得ないと想定し複雑度を下げようとするんだよな

646 ：デフォルトの名無しさん：2013/03/06(水) 10:40:02.89

>>644
書けないのはコンパイラが文法の観点から　見　て　いるからでしょ。
640の言うのも、単なる文法チェックでは済まないだろうけど機械が
見　れ　ば分かるので、その意味では同じじゃないのと言ってるんじゃないの？　

647 ：デフォルトの名無しさん：2013/03/06(水) 10:40:44.72

「文法上書けない」ってすごいな
どんな凄い文法なんだろう

648 ：デフォルトの名無しさん：2013/03/06(水) 10:46:48.22

>>646
そりゃ当然どこかで副作用の無いことを保証しなくちゃいけないし、その保証のプロセスを「見る」というならそうかもしれない
でも、その保証が文法レベルで存在することって重要なことじゃない？

そして、それを「見て」くれるCコンパイラってどれのことを言ってるの？って聞いてるのに答えてくれないんだよ…

649 ：デフォルトの名無しさん：2013/03/06(水) 10:53:36.87

若干話はそれるが、Haskellが関数に副作用がないのを保証したいのはなんでなの？

650 ：デフォルトの名無しさん：2013/03/06(水) 10:56:47.89

副作用がないのを保証するというより、参照透明性を保証する

651 ：デフォルトの名無しさん：2013/03/06(水) 11:02:28.68

副作用を認めると
引数や戻り値の型とは違う型のデータを、どこかに隠された変数に入れたり
例外として投げたりできるから

652 ：デフォルトの名無しさん：2013/03/06(水) 11:12:58.29

x = yの時f x = f yが言えないと等式推論が役に立たないからプログラム運算関連の人の飯の種が減るという大変困ったことになる

653 ：デフォルトの名無しさん：2013/03/06(水) 11:13:45.73

そりゃ大変だ

654 ：デフォルトの名無しさん：2013/03/06(水) 11:14:47.69

>>651
計算している間に音が出るというようなことには
副作用という観点からはあまり関心がないという
ことになるが。

655 ：デフォルトの名無しさん：2013/03/06(水) 11:15:27.50

他の関数型言語はHaskellほど縛りがきつくないのもあるんだろ？
逆に言うとHaskellは副作用(参照透明性の確保？)に対して厳格すぎるから
モナドとかいう難しいものを導入しなければならなかった、と理解してるんだけどあってるかな？
そこまで厳格に参照透明性にこだわるメリットってなに？

656 ：デフォルトの名無しさん：2013/03/06(水) 11:16:55.86

そういう宗教

657 ：デフォルトの名無しさん：2013/03/06(水) 11:29:19.44

中途半端になると弱い
現に、オセロでは中央より隅の方が強い

658 ：デフォルトの名無しさん：2013/03/06(水) 11:31:35.23

C++等でテスタビリティとモジュラリティの為にconst付けまくるみたいなスタイルは
手続き型言語における参照透過性のメリットの一例
意味論で考えると参照透過な実装はそうでないものより事前事後条件が簡単っていうのがある
つまり意味論的な解析を利用するような静的検査がやりやすい
こういうのがデフォルトで使えるっていうのは「タイプは基本的に遅いけどconstは一瞬で打てるようになった」みたいな人にとっては青い芝生だわな

659 ：デフォルトの名無しさん：2013/03/06(水) 11:43:40.81

つまりバグの出にくいプログラミングスタイルを言語で強制するって事？

660 ：デフォルトの名無しさん：2013/03/06(水) 11:54:23.35

少し自分の頭を使えよ
参照透過性のメリット理解できてないとか
プログラマとして普通に三流だぞ

661 ：デフォルトの名無しさん：2013/03/06(水) 11:55:06.10

テストしやすい、ということもある。
入力以外の、たとえばグローバル変数みたいなものに影響されないから。

662 ：デフォルトの名無しさん：2013/03/06(水) 11:55:42.00

>>660 の人は何がしたいんだろうか

663 ：デフォルトの名無しさん：2013/03/06(水) 11:56:44.40

どんな状況でも常に同じ結果を返す関数なら、
結果をキャッシュしたりすることもできるんだよね。

664 ：デフォルトの名無しさん：2013/03/06(水) 11:57:48.69

関数の実行順序を考慮する必要が無くなるってことは並列処理にも向いてる

665 ：デフォルトの名無しさん：2013/03/06(水) 11:59:41.13

マルチスレッド処理でロックの必要が無くなる

666 ：デフォルトの名無しさん：2013/03/06(水) 12:06:56.12

>>660
プログラマを買いかぶってはいけない。プログラマの99%は三流以下だよ。

667 ：デフォルトの名無しさん：2013/03/06(水) 12:27:28.45

タイムリーなネタかな？

http://shuklan.com/haskell/lec08.html#/

668 ：デフォルトの名無しさん：2013/03/06(水) 12:38:24.67

IOネタはもうずっと年中タイムリー

669 ：デフォルトの名無しさん：2013/03/06(水) 12:50:01.18

>>654
beep()で考えると、一回beep()が実行されると、一度音が鳴る。
続けて3回実行されれば、三度鳴る。というように積み重ねられる
ことによって、コンピュータの挙動が変化する。beep()自体は
変化がなくても、コンピュータ全体としては変化してしまう。
これが一般的な副作用。参照透過性の議論は計算モデル内部に
限定しての話でこれは勿論副作用論議の重要な部分だがすべて
ではない。

670 ：デフォルトの名無しさん：2013/03/06(水) 12:53:19.80

haskellを使う理由を教えてください
当方PHPしかできません

671 ：デフォルトの名無しさん：2013/03/06(水) 12:54:00.85

beep() がグローバル変数を書き換えてしまう事が無いことを保証できないしね

672 ：デフォルトの名無しさん：2013/03/06(水) 13:10:31.81

>>670
生産性を高める為。

673 ：デフォルトの名無しさん：2013/03/06(水) 14:34:31.13

659への返答は「そうだよ」じゃ駄目なんかな

まあでも，なんでわざわざ関数型言語を使うのか，というのは別の話のしかたもあるかも
lyahとか「なぜ関数プログラミングは重要か」あたりの文章を読んでみるとか

674 ：デフォルトの名無しさん：2013/03/06(水) 14:48:43.95

いやっはー

675 ：デフォルトの名無しさん：2013/03/06(水) 16:20:27.75

オレも質問。
・モナドにはIO、State、List、Exception、Maybe等々いまでも多数あるが、
これで終わりじゃないよね？まだこれからいろんなモナドが現れるんだよね？
アドホックに。
・それらは皆モナド則を満たすわけだが、このモナド則って結局何を言ってる
んだっけ？

676 ：デフォルトの名無しさん：2013/03/06(水) 16:24:43.85

>>675
モナド則はモナドのモジュールを作る側が気をつけることで、
おまえみたいに誰かがモナドを作ってくれると思ってる奴は気にする必要が無い

677 ：デフォルトの名無しさん：2013/03/06(水) 18:20:44.32

参照透過性
参照透明性

訳語として、どっちが普及してるの？

僕は参照透明性です！

678 ：デフォルトの名無しさん：2013/03/06(水) 18:38:20.92

>>676
この人正常範囲の人？

679 ：デフォルトの名無しさん：2013/03/06(水) 20:09:26.11

もうだめかもねこのスレ
はぁ

680 ：デフォルトの名無しさん：2013/03/06(水) 20:15:24.32

おっさんが居なくなれば普通に平常運転だと思うけど

681 ：デフォルトの名無しさん：2013/03/06(水) 20:19:24.63

>>630とか都合悪くなったら話逸らしてるし
無知を装った荒らしか無知な荒らしだと思います＞＜

682 ：デフォルトの名無しさん：2013/03/06(水) 20:35:02.50

おっさんが居なくなって別の奴が別の話を始める事象と
同一人物が話を逸らす事象は見分けがつかない

683 ：デフォルトの名無しさん：2013/03/06(水) 20:55:04.16

Haskellでメモ化をしたいのだけれど
どうやるのがいいと思う？

684 ：デフォルトの名無しさん：2013/03/06(水) 20:58:31.43

>>683
HaskellでPrologインタプリタを書く。

685 ：デフォルトの名無しさん：2013/03/06(水) 21:03:09.41

>>679 など
このスレはなんかデリケートなオタクが多いようだな

686 ：デフォルトの名無しさん：2013/03/06(水) 21:06:22.10

また来たのかおっさん

687 ：デフォルトの名無しさん：2013/03/06(水) 21:07:03.58

ナイーブだな

688 ：デフォルトの名無しさん：2013/03/06(水) 21:08:42.80

>>684
(´・ω・`)

689 ：デフォルトの名無しさん：2013/03/07(木) 04:10:12.84

>>583
精神的な不義理ってなんだよ

690 ：デフォルトの名無しさん：2013/03/07(木) 07:25:13.65

いまだに「敷居が高い」に突っ込み入れる阿呆居るんだな

691 ：デフォルトの名無しさん：2013/03/07(木) 09:15:52.79

Haskellスレらしくていいじゃないか

692 ：デフォルトの名無しさん：2013/03/07(木) 09:40:40.92

関数型言語は那珂太郎の詩のようなところがあるから。
..の..の..の..の..の..の..の..の..

693 ：デフォルトの名無しさん：2013/03/07(木) 13:14:36.66

>>679
前スレよりはマシだよ……

694 ：デフォルトの名無しさん：2013/03/07(木) 13:15:56.88

Haskellを汎用CPUで動かすの効率どうなの？
そういう最適化の準備あるなら専用プロセッサあった方がいいんじゃないの？

695 ：デフォルトの名無しさん：2013/03/07(木) 13:20:28.26

GHCについて言うなら、基本設計からstock hardwareで最適に設計されてるので、
あまりそういう改善の余地は少ない。

696 ：デフォルトの名無しさん：2013/03/07(木) 13:26:46.67

(´･ω｀･)そうなんだー

697 ：デフォルトの名無しさん：2013/03/07(木) 17:45:45.03

679が泣いたりするからつまらんくなったな
なんか言えよおまえら

698 ：デフォルトの名無しさん：2013/03/07(木) 17:50:31.81

ソフトウェアトランザクショナルメモリの欠点について教えて

699 ：デフォルトの名無しさん：2013/03/07(木) 18:46:50.69

口に出すと読みにくい

700 ：デフォルトの名無しさん：2013/03/07(木) 21:33:41.08

遅い

701 ：デフォルトの名無しさん：2013/03/08(金) 00:24:53.46

(´･ω｀･)そうなんだー

702 ：デフォルトの名無しさん：2013/03/08(金) 01:49:14.17

なんだその顔は！ふざけてんのか！

703 ：デフォルトの名無しさん：2013/03/08(金) 02:11:11.39

　　＼|／
　　/⌒ヽ　　　
　　| ゜Θ゜）　そうなんだー
　　|　∵ つ　
　　|　∵　|
　　＼＿／

704 ：デフォルトの名無しさん：2013/03/08(金) 09:51:59.79

組み込みHaskell

http://leventerkok.github.com/hArduino/

705 ：デフォルトの名無しさん：2013/03/08(金) 11:48:49.71

http://this-plt-life.tumblr.com/post/44462204757/simon-peyton-jones-adding-the-io-monad-to-haskell

706 ：デフォルトの名無しさん：2013/03/08(金) 18:53:56.06

おっさんがいないと、何をしても心から楽しめないの、、、

707 ：デフォルトの名無しさん：2013/03/08(金) 20:36:19.00

これってもしかして……恋？

708 ：デフォルトの名無しさん：2013/03/09(土) 05:49:08.73

　　ξ　　　　　　　　　　ゞシヾ"　　ヽ　　　　　　　　　,,,....,,,､､...,,,....,,
　　!　　　　　　　　　　彡　　　　　　ヽ:::　　　　　..i'´.　　　　　　　ヾ'''､､､,,,
　　ｼ　　　　　　　　　　彡　　　　　　　,j:::　　　..,／ヾ,　　　　　　　　　　　ヽ
　　　!ｼ　　　　　　　　　,,彡　　　　　　 :ｼ　　,;''''　　　ヾ　　　,___　　　　　　　ヽ
　　　　j　　,-‐-､　　　i　　　　ッ三ﾐ:;j i､'　　j-‐ 　　　｀, , ‐'' =　)　　　　　　　ヽ:
　　　　し { !⌒- ヽ!　j　　　　　‐-‐'j　ヽ､...'　　　　　　'　 .,_//,　　　　　　　　!;::
　　　　　ヾ丶｀-'　　! !　　　　　　　 {__,__,!'　　　　　　　　　-‐'　ヾ　　　　　　ﾉ:::
　　　　　　,ヾ　　'　､　　　　　　　,'　 ....,)　　　　　　　　::　　　　　ヽ　　　　　ﾉ::::::
　_...-‐‐'''´　:::　　　　　　　　　　　　´::( 　　　　　_...　´　　　　　　　ヽ　　　 /:::::::
　　　　　　　 ::　　　　　　　　　　　　　 !　....　-‐´　　　　　　　　　　ヽ　 /:::::　　　　 __,....,,-‐-､
　::::.　　　　　　ヽ　　 !......:-‐ー､　,,,,,,;;;ヽ＿_ ...-‐､　　　　　::　　　　　｀ヽ-､___,--/'´　,､　　 ,　｀ヽ､
　　　　　　　　　　　　!:::,´´´´´:::::｀"""´:::::::::::::::;;;;;;;;ヽ､　　　 ;::　　　　　　　　　　　ヽ-‐' !　 ./　　 iヽ

709 ：708：2013/03/09(土) 05:49:42.46

誤爆しました・・・申し訳ありません

710 ：デフォルトの名無しさん：2013/03/09(土) 07:50:42.74

"nを法とする剰余類環"の型って作れないのかなあ…
"Mod 12" 自体が型になってるようなの( C++風に書くと"Mod<12>" )
でも12の部分は型名じゃなくちゃいけないんだから無理か

711 ：デフォルトの名無しさん：2013/03/09(土) 08:08:22.08

TH を使えばいけるかもあるいは
data Zero
data Succ a

的なのでゴニョゴニョ

712 ：デフォルトの名無しさん：2013/03/09(土) 09:03:13.45

>>710
GHC7.6ならDataKinds拡張で12を型として使える
でも型レベルの加減乗除はまだ実装されてないのでまともに使えるかは知らん

{-# LANGUAGE DataKinds, KindSignatures, ScopedTypeVariables #-}
import GHC.TypeLits

newtype Residue (n :: Nat) = Residue Int {- invariant: 0<=x<n -}
　deriving (Eq, Ord)

-- smart constructor
residue :: forall n. (SingI n) => Int -> Residue n
residue a = Residue $ mod a $ fromIntegral n
　where
　　n = fromSing (sing :: Sing n)

instance Show (Residue n) where
　showsPrec p (Residue x) = showsPrec p x

instance SingI n => Num (Residue n) where
　Residue x + Residue y = residue $ x + y
　Residue x - Residue y = residue $ x - y
　Residue x * Residue y = residue $ x * y
　signum (Residue 0) = 0
　signum _ = 1
　abs x = x
　fromInteger = residue . fromInteger

main = do
　print (3 + 4 :: Residue 2)
　print (3 + 4 :: Residue 3)
　print (3 + 4 :: Residue 4)

713 ：デフォルトの名無しさん：2013/03/09(土) 09:17:24.88

ほいな
http://ideone.com/O243Zk

714 ：デフォルトの名無しさん：2013/03/09(土) 11:21:45.67

質問です
ファイルをインポートしようとしたのですがエラーがこのようにでました。
Could not find module `Dates'
Use -v to see a list of the files searched for.
Failed, modules loaded: none.
Dates.hsでは
module(
--- data　や関数
) where
のように外部からアクセス出きるようにして、
インポート側はimport Datesを最初の行にいれています。何がいけないのでしょうか？

715 ：デフォルトの名無しさん：2013/03/09(土) 12:03:57.56

>>714
Dates.hsを置いてるディレクトリと、GHCを実行してるディレクトリは同じになってる？
もし違うなら、-iとかを渡さないといけない

716 ：デフォルトの名無しさん：2013/03/09(土) 14:22:34.44

同じディレクトリに移動してやったら出来ました。
ありがとうございます。

717 ：デフォルトの名無しさん：2013/03/10(日) 03:59:11.20

みんなHaskellのことならなんでも知ってるな

718 ：デフォルトの名無しさん：2013/03/10(日) 09:04:58.99

自分で言語を作るならどういう選択肢があるかを知ってる
Haskellの作者がどれを選んだかは知らないので後で調べる

他人が何をしたか調べる時間よりも、自分ならどうするかを考える時間の方が長い

719 ：デフォルトの名無しさん：2013/03/10(日) 10:42:33.73

サーベイをさぼって「もうOlegがやってた」とかで数日無駄にするとかよくあった

720 ：デフォルトの名無しさん：2013/03/10(日) 11:09:26.16

その代わり速読(笑)で数日短縮できるんじゃね
Olegが何を言いたいのか読む前から知ってるんだから

721 ：デフォルトの名無しさん：2013/03/10(日) 17:15:35.63

以下をGHCiにロードすると' Parse error in pattern: n + 1'というエラーがでます
HUGでは通るそうなのですが何が悪いのでしょうか

drop2 :: Int -> [a] -> [a]
drop2 0 xs = xs
drop2 (n + 1) [] = []
drop2 (n + 1) (_:xs) = drop2 n xs

722 ：デフォルトの名無しさん：2013/03/10(日) 17:34:47.51

>>721
(n+k)パターンはデフォルトでは使えなくなったような気がする。

あきらメロン

723 ：デフォルトの名無しさん：2013/03/10(日) 17:36:49.41

NPlusKPatterns を指定

724 ：デフォルトの名無しさん：2013/03/10(日) 17:40:50.58

{-# LANGUAGE NPlusKPatterns #-}

drop2 :: Int -> [a]->[a]
drop2 0 xs = xs
drop2 n [] = []
drop2 n (_:xs) = drop2 (n-1) xs

725 ：721：2013/03/10(日) 18:29:24.02

そうだったんですか
オプションが必要になるならあきらめマスクメロン

726 ：デフォルトの名無しさん：2013/03/11(月) 15:13:22.76

関数内で関数定義するとテストできないよね？
みんなどうしてるの？

727 ：デフォルトの名無しさん：2013/03/11(月) 17:03:19.41

テストが要るような関数をローカル定義にしないという解決法

728 ：デフォルトの名無しさん：2013/03/11(月) 17:37:17.22

Javaだとリフレクション使ってprivateメソッドもテスト可能だが
Haskellの関数定義にはそのような抜け穴が存在しないのではないか

729 ：デフォルトの名無しさん：2013/03/11(月) 18:01:03.80

テストが要るほどに非自明な関数はトップレベルに定義すればよい

730 ：デフォルトの名無しさん：2013/03/11(月) 18:11:01.15

テストが困難になるのは使い道が無数にある場合だから
一回ぐらいしか使わないローカル関数のテストは難しくない

731 ：デフォルトの名無しさん：2013/03/11(月) 18:15:33.54

ghc-modでローカル定義拾うのあるし
GHCにも穴はあるんだよ多分

732 ：デフォルトの名無しさん：2013/03/11(月) 19:41:39.12

>>726
関数内で関数定義する場合に、
どういうテストが不可能だと言っているの？

733 ：デフォルトの名無しさん：2013/03/11(月) 19:49:03.11

>>731
ローカル変数は、名前とソースの位置が同じだが値が異なる変数を何個も定義できるよ
トップレベルの変数を一個拾うのとは全然違う

734 ：デフォルトの名無しさん：2013/03/11(月) 23:19:17.34

関数内関数までテストしたくないです
理由は、関数内関数には外部から見える仕様が存在しないからです

735 ：デフォルトの名無しさん：2013/03/12(火) 07:57:44.38

大元の関数をテストすればいいんじゃないの？

736 ：デフォルトの名無しさん：2013/03/12(火) 08:43:58.57

内部関数というのは、他の言語で言えばコードブロックみたいなものだからね
コードブロックの一つ一つまでテストする必要はないし、テストの必要があるほど大きなブロックなら独立させればいい

737 ：デフォルトの名無しさん：2013/03/12(火) 08:58:22.30

Smalltalkだとメソッド内ブロック使わないと何もできない
その後、OOPにブロックは不要という考え方が定着し
OOPと関数型は完全に分裂した

738 ：デフォルトの名無しさん：2013/03/12(火) 09:36:49.37

>>737
最近のOO言語はやっぱりクロージャが必要って流れになってるよ。JavaもC++も。

739 ：デフォルトの名無しさん：2013/03/12(火) 10:43:28.34

三大やっぱり必要
テスト
public
lambda

740 ：デフォルトの名無しさん：2013/03/12(火) 10:55:43.66

リフレクションかな
haskell-src-extsとか使ってローカル定義を参照できるようなツールがあればいける

741 ：デフォルトの名無しさん：2013/03/12(火) 11:55:07.13

>>740
全力で成功を回避しろ

742 ：デフォルトの名無しさん：2013/03/12(火) 12:41:31.93

>>737
その場合、SmalltalkはOOPと関数型のどっちの所属なんだ？w
今でもSmalltalkはブロックがないと何もできないわけだが。

743 ：デフォルトの名無しさん：2013/03/12(火) 13:02:36.67

特定のクラスに所属しないユニバーサルな関数はOOPとは相性が悪い
プリミティブ型がOOPと相性が悪いのと同じ理屈

744 ：デフォルトの名無しさん：2013/03/12(火) 13:14:10.01

>>743
そんなことないよ。Javaとは相性悪いけど、OO言語だからじゃなくて、Javaが糞だから。

745 ：デフォルトの名無しさん：2013/03/12(火) 19:39:31.34

>>743
SmalltalkのクロージャーはSmalltalkと相性悪いの？
Smalltalkってクロージャーがないと条件分岐すらできないんだけど？

746 ：デフォルトの名無しさん：2013/03/12(火) 19:53:49.06

HaskellとSmalltalk、唯一の共通点はモヒカンっぷり

747 ：デフォルトの名無しさん：2013/03/12(火) 21:36:09.68

HaskellとSmalltalkはモヒカンの中でも最弱・・・
本物のモヒカンは静的型とGUIを否定する

748 ：デフォルトの名無しさん：2013/03/12(火) 21:40:50.33

いまだにモヒカンの定義が良く分からんのだよなあ

749 ：デフォルトの名無しさん：2013/03/12(火) 22:20:34.02

良く分からないものの擬人化
モヒカンの陰謀か何かで、分かるはずのものが分からなくなる

750 ：デフォルトの名無しさん：2013/03/13(水) 01:52:45.11

>>745
クロージャーもクラスにできるんだけど、プリミティブなくせに抽象度が違うので、これをクラスとして扱いつづけるといろいろおかしくなる

751 ：デフォルトの名無しさん：2013/03/13(水) 18:24:51.16

>>750
BlockClosureクラスだと何がいろいろおかしくなるの？
SmalltalkってBlockClosureクラスがないと条件分岐すらできないんだけど？

752 ：デフォルトの名無しさん：2013/03/13(水) 19:19:43.13

もしかしてJavaの.classファイルがものすごい数になるのを心配してるんじゃないか

753 ：デフォルトの名無しさん：2013/03/13(水) 19:24:19.19

>>743
どう相性が悪いの？
カプセル化する必要のない関数はクラスに所属させる必然性はないけど
それがOOPの妨げになる理由は？
それにnamespaceとかあるよね？
そのレスただ言いたかっただけに見えるよ

754 ：デフォルトの名無しさん：2013/03/13(水) 20:37:45.01

クロージャをクラスにしても問題ないだろう
単にJavaみたいに1クロージャを1クラスに対応させるのが腐れなだけ
クロージャをリテラルにしてどのクロージャも同じクラスになれば問題なし

755 ：デフォルトの名無しさん：2013/03/13(水) 21:08:47.67

ユニバーサルな関数やクロージャがOOPと相性悪いとか頭悪すぎだろｗ
Javaしか（もしくはJavaすら）知らないんだろうね

756 ：デフォルトの名無しさん：2013/03/13(水) 21:35:41.02

「いろいろおかしくなる」ってなかなか趣深いフレーズだな

757 ：デフォルトの名無しさん：2013/03/14(木) 00:24:02.48

>>753-754
・　OOPにおけるクロージャは飛び先が隠ぺいされる goto
・　クラスの遠隔に設置される場合は、名前がないのでクロージャのセマンティクスが明確に消失する　(\x -> \x +1)は加算？曜日のシフト？
・　(\x -> \x +1) と (\y -> \y +1)　をそれぞれクロージャクラスのオブジェクトにしたときの同値判定
・　(\x -> \x + 1) 1　のとき、アプライが必要になってクラス表現するときとプリミティブのときでセマンティクスが崩れる　ネストしたときのリフト
・　クロージャのオブジェクト生成がクラスのオブジェクト生成と同期しない
・　クロージャの生存期間がクロージャだけを見ても分からない

758 ：デフォルトの名無しさん：2013/03/14(木) 00:42:03.34

頼むからちゃんとした日本語で書いてくれ

759 ：デフォルトの名無しさん：2013/03/14(木) 01:16:40.42

これは早口言葉のようなもので
日本語の読み書きの問題ではない気がする

760 ：デフォルトの名無しさん：2013/03/14(木) 01:22:36.05

>>757
何が言いたいのかよくわからんから最大限エスパーして答えるけど、ほとんどOOPじゃなくてクロージャ自体の話に見える
例えばそれぞれlispのクロージャだと何故問題にならないの？
＞・　OOPにおけるクロージャは飛び先が隠ぺいされる goto
そう言いたければ好きにすればいいけど、で？OOPとの関係も不明
＞・　クラスの遠隔に設置される場合は、名前がないのでクロージャのセマンティクスが明確に消失する　(\x -> \x +1)は加算？曜日のシフト？
OOPと無関係
＞・　(\x -> \x +1) と (\y -> \y +1)　をそれぞれクロージャクラスのオブジェクトにしたときの同値判定
なぜ同値判定が必要なの？OOPとの関係も不明
＞・　(\x -> \x + 1) 1　のとき、アプライが必要になってクラス表現するときとプリミティブのときでセマンティクスが崩れる　ネストしたときのリフト
何が言いたいのかわからん（何をクラス表現するのか、セマンティクスがどう崩れるのか、何をネストしてリフトするのか）
＞・　クロージャのオブジェクト生成がクラスのオブジェクト生成と同期しない
「クロージャのオブジェクト（生成）」の意味がわからん。生成が同期しないことによる弊害も書かれてない
＞・　クロージャの生存期間がクロージャだけを見ても分からない
OOPと無関係

761 ：デフォルトの名無しさん：2013/03/14(木) 01:28:31.53

俺も頑張って>>757エスパーしたわ。>>760が答えてるけどエスパーした時間が勿体無いので投下。
・　OOPにおけるクロージャは飛び先が隠ぺいされる goto
→OOPでもオブザーバーパターン使うと飛び先が隠ぺいされる。
・　クラスの遠隔に設置される場合は、名前がないのでクロージャのセマンティクスが明確に消失する　(\x -> \x +1)は加算？曜日のシフト？
→(\x -> x.addNum(1))や(\x -> x.addDay(1))としたらいい。
・　(\x -> \x +1) と (\y -> \y +1)　をそれぞれクロージャクラスのオブジェクトにしたときの同値判定
→参照の同値性を実装している言語はあるけど、それだけだとOOPとして困る状況ってある？あと「振る舞い同値性」や「α同値性」でググれ。
・　(\x -> \x + 1) 1　のとき、アプライが必要になってクラス表現するときとプリミティブのときでセマンティクスが崩れる　ネストしたときのリフト
→これは意味不明。
・　クロージャのオブジェクト生成がクラスのオブジェクト生成と同期しない
→「同期しない」が意味不明。newという構文を使わないから駄目だという話か？OOPでファクトリ使うときも使用側にnew無いけど。
・　クロージャの生存期間がクロージャだけを見ても分からない
→OOPもクラス定義だけ見ていては分からない。インスタンスへの参照がどこで消えるか注意深く追う必要がある。

762 ：デフォルトの名無しさん：2013/03/14(木) 01:33:57.27

なんだこの最強エスパー決定戦は

763 ：デフォルトの名無しさん：2013/03/14(木) 02:28:30.07

>>760
・　クロージャが特にOOPで飛び先が隠ぺいされる goto になる理由は、個性のないクロージャがオブジェクトに抽象化されてオブジェクト自身が持ちまわされるから
・　クラスの遠隔に設置される場合に名前がないのでクロージャのセマンティクスが明確に消失するという問題は、裏を返せば、クラスの遠隔に設置される場合と同じリテラスなのにセマンティクスが変わってしまうということ
・　クロージャのオブジェクトとしての同値判定は、クロージャをクラスにしなければOOPとは無関係
・　プリミティブの場合は (\x -> \x + 1)1 でOKだが、クラスにするとただ並べるだけではダメでクロージャのオブジェクトに1を適用するというステップが間に入り、セマンティクスが異なる
・　他のクラスのオブジェクトと生成が同期しないことによる弊害はリソースを保持するコストの推定が難しくなること
・　クロージャの生存期間がクロージャだけを見ても分からない理由は、OOPではクラスのオブジェクトの生存期間の明示が難しいから

764 ：デフォルトの名無しさん：2013/03/14(木) 02:45:02.81

>>761
OOPでもオブザーバーパターン使うと飛び先が隠ぺいされる。
→ここでの「隠ぺい」はコードを追って保守するのが難しいという意味

(\x -> x.addNum(1))や(\x -> x.addDay(1))としたらいい。
→このように、クロージャを利用するクラスの近くか遠くかにより必要となる記述が異なるので、ユニバーサルなクロージャとOOPは相性が悪い

参照の同値性を実装している言語はあるけど、それだけだとOOPとして困る状況ってある？
→メソッドの出力またはフィールドの値がクロージャのクラスを単体テストする場合

これは意味不明。
→「(\x -> \x + 1) 1」と「(インスタンス化(\x -> \x + 1)).apply(1)」は字面が違うでしょ、という意味

「同期しない」が意味不明。
→リソースを消費するクロージャは、代入のときか、代入が予定されるクラスのオブジェクトが生成されたときか、実行されるときか、いつオブジェクト化されるかが問題になる

OOPもクラス定義だけ見ていては分からない。
→当然そのクラスで回されるクロージャはもっと分からない

765 ：デフォルトの名無しさん：2013/03/14(木) 05:01:53.57

はすけるスレでこんなこと言うのもなんだが
>>763-764はOOPまるでわかってないに1票

恥ずかしいことじゃないよ、ここははすけるスレだから

766 ：デフォルトの名無しさん：2013/03/14(木) 06:04:52.65

うーん。。。要はケースバイケース、使い分けしてナンボだと思うけど。
わざわざクロージャの悪い使い方を上げて、クロージャ自体を批判しなくとも良いのでは？

767 ：デフォルトの名無しさん：2013/03/14(木) 07:13:50.85

>>754
クロージャが問題ならInterpreterパターンを使えば良いよね

768 ：デフォルトの名無しさん：2013/03/14(木) 07:35:56.05

いやOOPが分かってないって問題じゃないだろこれｗ
プログラミングがまるで分かってない

769 ：デフォルトの名無しさん：2013/03/14(木) 07:40:37.07

こんなに議論ができる人たちが、
プログラミングが分かっていない、状態になるのだとしたら、
OOPもクロージャもなくす方向に向かうほかないのでは。

770 ：デフォルトの名無しさん：2013/03/14(木) 07:49:48.96

>>768
確かに、コード一行も書いたこと無い人が本だけ読んで語るとこういうことになるのかもね

>>769
いや分かってないのは一人だけでしょ
稀にこういうどうしようもない馬鹿が表れるのは仕方無い

771 ：デフォルトの名無しさん：2013/03/14(木) 10:13:01.66

>>763-764に足りないのは論理的思考能力じゃね？
まあ論理的思考能力に欠けてるやつがプログラミングできるとは思わんが

772 ：デフォルトの名無しさん：2013/03/14(木) 10:55:38.74

>>726 あたりから延々と続いている議論はどんなレベルのプログラマに必要な
ものなのかな。
もし関数型を理解することがこんな議論が分かるようになることを含むのだと
すると、関数型言語を勉強しようとする人はほとんどいなくなってしまうだろう。

773 ：デフォルトの名無しさん：2013/03/14(木) 11:02:43.21

バカの妄想にレベルもクソもなかろうもん

774 ：デフォルトの名無しさん：2013/03/14(木) 11:33:21.40

×関数型
○Haskell
頼むから他のまともな関数型言語まで一緒にしないでくれ

775 ：デフォルトの名無しさん：2013/03/14(木) 11:51:25.15

>>772
日本語や英語の議論に飽きた人は、ますますプログラミング言語への興味が増すだろう

776 ：デフォルトの名無しさん：2013/03/14(木) 12:20:22.38

確かに >>760->>764 を読むとHaskell本当に大丈夫か？という気になる。

777 ：デフォルトの名無しさん：2013/03/14(木) 14:28:12.83

生兵法は怪我の素

778 ：デフォルトの名無しさん：2013/03/14(木) 15:33:16.63

生なんだよね
人が作った物というより生物に似ているから、期待通りに動かないのは当たり前
人間以外の生き物を知ってたらどんなレベルの人でも理解できると思う

779 ：デフォルトの名無しさん：2013/03/14(木) 15:54:03.21

また変なやつまで来たし。もうやだこのスレ……

780 ：デフォルトの名無しさん：2013/03/14(木) 17:02:19.25

>>763-764にレスする強豪エスパーはおらんのか！

781 ：デフォルトの名無しさん：2013/03/14(木) 21:06:46.35

>>763-764を納得してしまったのは俺だけか？
とくにクロージャがgotoというのは至言

782 ：デフォルトの名無しさん：2013/03/14(木) 21:20:49.40

何がどうgotoなのかさっぱり話が見えない

783 ：デフォルトの名無しさん：2013/03/14(木) 21:25:42.52

オブザーバーパターンみたいなコールバック使うとOOPでもコード追うの難しいよね
っていうことを言ったはずなのに伝わった気がしない

784 ：デフォルトの名無しさん：2013/03/14(木) 22:31:21.29

>>781
そうだとしてもOOPと関係ないだろって突っ込まれてるんだが……
お前もズレてるな

785 ：デフォルトの名無しさん：2013/03/14(木) 22:46:50.83

言ってることを一文ずつ取り出すと完全に間違ってるとは言えないんだが、全体として整合性が取れてなかったり会話の流れからずれまくってるやつ、俺の近くにも居るわ
何の障害なんだろうか

786 ：デフォルトの名無しさん：2013/03/14(木) 23:18:50.65

よいGOTOとしてのクロージャ　：　ハンドラ関数に渡すクロージャ

悪いGOTOとしてのクロージャ　：　制御構造に干渉するクロージャ
c = (\(f,xs) -> " and " ++ (f xs))
func [x] = x
func (x:xs) = x ++ (c (func, xs))

787 ：デフォルトの名無しさん：2013/03/14(木) 23:20:05.54

>>784
>>763-764 が主張するOOPとの関係に納得してしまってのは俺だけか？

788 ：デフォルトの名無しさん：2013/03/14(木) 23:20:27.61

皆さん次のエスパー課題です

789 ：デフォルトの名無しさん：2013/03/14(木) 23:22:05.41

>>787
是非とも翻訳してもらいたい

790 ：デフォルトの名無しさん：2013/03/14(木) 23:28:19.48

>>787
じゃあgotoの話に絞ると、クロージャを変数に代入した場合は何故同じ問題が起きない？

791 ：デフォルトの名無しさん：2013/03/14(木) 23:34:34.62

>>790
クロージャを変数に代入して問題が起きるなら、別のソースコードで定義してあるクラスのオブジェクトのフィールドに代入するともっと問題が起きるよね

792 ：デフォルトの名無しさん：2013/03/14(木) 23:42:59.46

>>791
グローバル変数に代入したり、関数からクロージャを返して別のソースコードで利用されるのとどう違う？

793 ：デフォルトの名無しさん：2013/03/14(木) 23:45:49.63

えっ、クロージャがオブジェクトに抽象化されて持ちまわされるのが問題って言ってるのに、なんで別のオブジェクトのフィールドに代入する話になってんの？

794 ：デフォルトの名無しさん：2013/03/14(木) 23:49:20.89

第二次エスパー大戦

795 ：デフォルトの名無しさん：2013/03/14(木) 23:51:18.59

>>792
アクセス可能性(参照性)が違う
クロージャを使うコンポーネントの粒度と、そのコンポーネント自身を使いまわされる度合いが違う
OOP原理主義に走ってオブジェクトに属さないグローバル変数を認めない場合は根本的に違う

796 ：デフォルトの名無しさん：2013/03/14(木) 23:51:31.61

>>791に書いてる「クラス」「オブジェクト」「フィールド」って言葉は全く何の意味も成してないな
「別のソースコード」はまだ分かるがそれこそOOPと何の関係もない
マジでOOPとクロージャの関係にケチ付けたいだけなんだな

797 ：デフォルトの名無しさん：2013/03/14(木) 23:53:12.71

>>795は>>763-764本人だろｗ

798 ：デフォルトの名無しさん：2013/03/14(木) 23:53:27.11

>>793
合成による抽象化

799 ：デフォルトの名無しさん：2013/03/14(木) 23:54:06.77

最強のスパゲッティ言語 = ラムダ計算

800 ：デフォルトの名無しさん：2013/03/14(木) 23:58:49.81

>>795
>>791
グローバル変数に代入したり、関数からクロージャを返して別のソースコードで利用される場合と比べて、別のソースコードで定義してあるクラスのオブジェクトのフィールドに代入する場合にどう問題が大きくなるか聞いてるんだが

801 ：デフォルトの名無しさん：2013/03/15(金) 00:00:32.90

なんでラムダがgotoと同じってことになったのか理解できない
関数呼び出しはPCの変更だからgotoと同じって言ってるのと同レベルの屁理屈ってことでFA？

802 ：デフォルトの名無しさん：2013/03/15(金) 00:01:50.65

>>796
クラス＝クラスの仕様そのもの、ソースコード上で確認できる
オブジェクト＝クラスをインスタンス化してメモリ上に存在している実体
フィールド＝クラス上で定義され、オブジェクトに属し、明示的にアクセスを制限されるプロパティ、変数

「別のソースコード」でかつOOPだと困る理由は、OOPでは別クラスのフィールドの定義だけを一ヶ所に寄せ集めるコーディングができず、場合によってはアクセスを制限されるから

803 ：デフォルトの名無しさん：2013/03/15(金) 00:02:21.85

>>801
かつ、それがOOPとどう関係するのかも分からない状態

804 ：デフォルトの名無しさん：2013/03/15(金) 00:05:36.55

追跡する必要があるってことは副作用のある名前のない関数について話してるんだよねこの人
それはいいとしてそれをHaskellスレで披露して暴れてるのは何でなん

805 ：デフォルトの名無しさん：2013/03/15(金) 00:07:43.39

こいつの噛み合わないレスを見てると、なんか恐怖を感じる……

806 ：デフォルトの名無しさん：2013/03/15(金) 00:08:59.39

>>800
・OOPでは、個性のないクロージャがオブジェクトに抽象化されてオブジェクト自身が持ちまわされるが、グローバル変数に代入する場合にはそれが難しい
・クラスの遠隔に設置される場合は名前がないのでクロージャのセマンティクスが明確に消失するが、クラスの内部にあればクラスそのものがクロージャのセマンティクスを修飾する
・クロージャのオブジェクト生成がクラスのオブジェクト生成と同期しない
・クロージャの生存期間がクロージャだけを見ても分からない

807 ：デフォルトの名無しさん：2013/03/15(金) 00:09:12.95

次回
「人外っているんだなって」

808 ：デフォルトの名無しさん：2013/03/15(金) 00:10:36.66

やっと翻訳できる人が表れたかと思ったらご本人様だったか

809 ：デフォルトの名無しさん：2013/03/15(金) 00:11:39.94

噛み砕いて書いたと思いきや繰り返して同じこと書いてるだけだった

810 ：デフォルトの名無しさん：2013/03/15(金) 00:14:00.44

>>801
GOTOしての関数呼び出しと、GOTOとしてのλ式の違いは、GOTOが制御を奪えるかどうか
GOTOとしてのλ式はフローや繰り返しの最中で制御を横取りできてしまう

811 ：デフォルトの名無しさん：2013/03/15(金) 00:15:31.38

>>806
>>763の第一項目（goto）の話をしてるんだが

812 ：デフォルトの名無しさん：2013/03/15(金) 00:17:05.88

多分この人、プログラミングじゃなくて文学とかの方が向いてる

813 ：デフォルトの名無しさん：2013/03/15(金) 00:24:32.25

せめて具体例とかつけてくれよ

814 ：デフォルトの名無しさん：2013/03/15(金) 00:33:09.83

>>806
＞・OOPでは、個性のないクロージャがオブジェクトに抽象化されてオブジェクト自身が持ちまわされるが、グローバル変数に代入する場合にはそれが難しい
いやいやオブジェクト云々は問題が起きる理由の一つでしょ？それを否定してどうするんだ
そうじゃなくて、クロージャが（悪い？）gotoになる問題が、
（プリミティブな）クロージャをグローバル変数に代入したり、関数からクロージャを返して別のソースコードで利用される場合には発生しなくて、
別のソースコードで定義してあるクラスのオブジェクトのフィールドに代入する場合には発生する理由を聞きたいんだけど

815 ：デフォルトの名無しさん：2013/03/15(金) 00:35:42.74

>>812
え・・・国語も出来ないのに

＞メソッドの出力またはフィールドの値がクロージャのクラスを単体テストする場合

メソッドの出力かフィールドの値は自発的に単体テストを施行しちゃうAIらしい

816 ：デフォルトの名無しさん：2013/03/15(金) 00:37:18.73

これ間違った方向に勉強しちゃったこないだのおっさんじゃね？

817 ：デフォルトの名無しさん：2013/03/15(金) 00:40:18.23

おっさん得意の実例出さないで抽象化した言葉を並べる続けることで
反論を跳ね返すオナニー用のマジックミラーやで
実際のところ何もわかってないから相手するだけ無駄

818 ：デフォルトの名無しさん：2013/03/15(金) 00:42:39.94

しかしこんだけ絶妙に意味不明な文章を羅列できるのって才能っちゃ才能だよな
モスバーガーの食い方のアレを思い出すわ

819 ：デフォルトの名無しさん：2013/03/15(金) 00:45:20.03

誰かstaticおじさんを連れてきてくれ
こいつと話し合いができるのは彼しかいない

820 ：デフォルトの名無しさん：2013/03/15(金) 00:46:11.66

>>810
制御を横取りするのはschemeのcall/ccとかでは？
クロージャが制御を横取りする具体例を出してよ
まさかただの高階関数を指して制御を横取りとか言ってないですよね

821 ：デフォルトの名無しさん：2013/03/15(金) 00:59:02.98

母親がホームで自転車で痴漢されたやつみたいになってきたな

822 ：デフォルトの名無しさん：2013/03/15(金) 01:17:00.64

>>798がなかなかシンプルで好きだな

823 ：デフォルトの名無しさん：2013/03/15(金) 01:18:39.77

↑ご本人様

824 ：デフォルトの名無しさん：2013/03/15(金) 01:20:58.56

好きって絶妙な意味不明さがってことだぞｗ

825 ：デフォルトの名無しさん：2013/03/15(金) 01:29:13.38

>>801
限定継続　とかで調べるといいよ

826 ：デフォルトの名無しさん：2013/03/15(金) 01:33:41.13

>>825
それ呼び出し元に戻ってくるじゃん
goto？

827 ：デフォルトの名無しさん：2013/03/15(金) 01:38:10.55

限定継続って単語出せば煙に巻けると思ったんだろうねｗ

828 ：デフォルトの名無しさん：2013/03/15(金) 01:51:41.63

限定継続とラムダ計算の関係は意外とまとまった読みものないな。
（読みにくいものはいくらでもあるけどさ。）

http://ja.wikibooks.org/wiki/Scheme/%E7%B6%99%E7%B6%9A%E3%81%AE%E7%A8%AE%E9%A1%9E%E3%81%A8%E5%88%A9%E7%94%A8%E4%BE%8B

自分は同人誌でこの辺読んだだけだけど。

829 ：デフォルトの名無しさん：2013/03/15(金) 03:33:32.04

>>820
○最単純例　(\f -> exitSuccess) (print "hai")
○よくやる悪い例(>>786)
c = (\(f,xs) -> " and " ++ (f xs))
func [x] = x
func (x:xs) = x ++ (c (func, xs))
○推奨される例　ハンドラの例外処理にクロージャを渡す

830 ：デフォルトの名無しさん：2013/03/15(金) 04:43:47.18

「制御を奪う」とかいう話を、よりによってHaskellスレで聞けるなんて、ムネアツだぜ！

831 ：デフォルトの名無しさん：2013/03/15(金) 04:45:39.07

話の腰を折ってすまんが
「OOPとクロージャは相性悪い」
なんて言ってる人は
「FPと高階関数は相性悪い」
と言ってるのにほぼ等しいことを自覚してくれ。

832 ：デフォルトの名無しさん：2013/03/15(金) 04:46:51.79

あと、JavaをOOPLだと思うのはやめてくれ。
あれはOOPLではない。OO用語を使った命令型言語だ。

833 ：デフォルトの名無しさん：2013/03/15(金) 05:58:49.49

>>831
クロージャが元凶だってことだけはわかった。

834 ：デフォルトの名無しさん：2013/03/15(金) 07:01:56.72

元凶はJavaだけでOOP騙っちゃう例のあの人でしょw

835 ：デフォルトの名無しさん：2013/03/15(金) 08:03:31.86

こいつみたいな知ってる専門用語を適当に並び立てるんだけど、全く意味が通ってないやつ居るなー
一般人や初心者にはなんか頭良さそうって思われてるけど、同じ分野の人からは馬鹿にされてるタイプ

836 ：デフォルトの名無しさん：2013/03/15(金) 08:10:50.98

批判は得意な人ばかりのスレですね
少しは建設的なことはいえないのですか？

837 ：デフォルトの名無しさん：2013/03/15(金) 08:15:58.62

プログラム変換について拘るというのなら分かるが、数学的洗練を期待して
このスレに来ている人たちは、OOPもクロージャも関係ない。
「プログラミングHaskell」の巻末索引に登場する程度の概念でさらっと
やって欲しい。

838 ：デフォルトの名無しさん：2013/03/15(金) 08:17:56.92

>>836
直球のブーメランだな

839 ：デフォルトの名無しさん：2013/03/15(金) 08:35:00.29

さすがにクロージャは関係あるんじゃね？

840 ：デフォルトの名無しさん：2013/03/15(金) 11:28:08.92

>>832
>OOPLではない。OO用語を使った命令型言語だ。
もしかしてOOPLと命令型言語が相反する概念だと勘違いしてる？
JavaもC++もRubyも、どれも全部「OOPLであり同時に命令型言語」だぞ

841 ：デフォルトの名無しさん：2013/03/15(金) 12:58:51.77

>>840
メッセージ送信をメソッド呼び出しだと思ってるでしょ？

842 ：デフォルトの名無しさん：2013/03/15(金) 13:13:34.50

ちがうの？

843 ：デフォルトの名無しさん：2013/03/15(金) 15:23:39.18

このスレ何だか難しいね！(´＾ω＾｀)

844 ：デフォルトの名無しさん：2013/03/15(金) 15:37:54.52

一般人から見たら馬鹿かと思えるような会話を難なくこなせるようでないと
自らHaskell使いを名乗ることなど出来んのだよ

845 ：デフォルトの名無しさん：2013/03/15(金) 19:13:30.59

メソッド呼び出しはオブジェクト指向においてメッセージ送信を実現する方法の一つ

846 ：デフォルトの名無しさん：2013/03/15(金) 19:52:31.54

はずれ

847 ：デフォルトの名無しさん：2013/03/15(金) 20:30:33.49

メソッド呼び出しがメッセージ送信を実現すれば、メッセージ送信は正義
いろいろおかしくなったらメソッド呼び出しは悪 (メッセージ送信は悪ではない)

848 ：デフォルトの名無しさん：2013/03/15(金) 21:52:37.55

Haskellは全力で反証不可能を回避する

849 ：デフォルトの名無しさん：2013/03/16(土) 03:39:46.94

>>840-842
メッセージ送信かメソッド呼び出しかは、(構造としての)オブジェクトの粒度と独立性の程度の問題
クラスとメソッドがオブジェクトとして閉じていて、送信元オブジェクトとメッセージとレシーバのオブジェクトが独立していると「表現できるか」がが問題
呼び出し元をオブジェクトとして表現して、関数モジュールを呼び出す際の引数をオブジェクトとは独立して存続していると表現すれば機械語も立派なOOPL

ソースコード上の表現だけで判断するなら真にメッセージパッシングしてるのはerlangだけ

言語仕様だけ見た場合のOOPLと命令型言語の決定的な違いは、メソッドやフィールドの隠匿にこそある

850 ：デフォルトの名無しさん：2013/03/16(土) 06:40:17.89

>>849
> ソースコード上の表現だけで判断するなら真にメッセージパッシングしてるのはerlangだけ

Smalltalkでもメッセージセレクタは識別子ではなく文字列リテラルなんだが？

851 ：デフォルトの名無しさん：2013/03/16(土) 08:35:55.67

SmallTalkはもうおなかいっぱい。

852 ：デフォルトの名無しさん：2013/03/16(土) 09:05:29.79

真に並行動作してるErlangから見れば
Smalltalkのメッセージパッシングなんてゴミ

853 ：デフォルトの名無しさん：2013/03/16(土) 09:14:56.05

OOPとActorモデルの区別ついてますか？

854 ：デフォルトの名無しさん：2013/03/16(土) 09:52:30.15

うんこSmalltalkerがErlangに嫉妬してるの？

855 ：デフォルトの名無しさん：2013/03/16(土) 09:57:44.45

SmalltalkもErlangもよくわかってない人が泥沼にはまってるように見える

856 ：デフォルトの名無しさん：2013/03/16(土) 11:52:01.28

そろそろHaskellの話をだな・・・

857 ：デフォルトの名無しさん：2013/03/16(土) 11:59:17.56

レコード型を定義すると全フィールド名がネームスペースを侵食するの何とかならない？

858 ：デフォルトの名無しさん：2013/03/16(土) 12:04:28.46

だって関数ですから

859 ：デフォルトの名無しさん：2013/03/16(土) 12:06:07.78

やだやだやだっなんとかしてっ

860 ：デフォルトの名無しさん：2013/03/16(土) 12:08:56.23

ネームスペースを侵食する、の意味がよく分からん

861 ：デフォルトの名無しさん：2013/03/16(土) 12:18:03.85

qualified module import

862 ：デフォルトの名無しさん：2013/03/16(土) 12:22:03.07

Haskellのレコード型は諦めろ

863 ：デフォルトの名無しさん：2013/03/16(土) 12:35:18.75

関数takeを作りたいのですが、うまくいきません。
myTake :: Int -> [a] -> [a]
myTake num (x:xs)
| num < 0 = error"Not Valid"
| num == 0 = []　-- Non-Exhastiveになる　myTake 0 []
| num == 1 = [x]
| num > 0 = [x] ++ myTake (num -1) (xs)
| otherwise = error"Not Valid"
myTake 2 [] -> Non-Exhastive

864 ：デフォルトの名無しさん：2013/03/16(土) 13:13:57.95

空のリストをx:xsパターンマッチで束縛しようとするとダメなんじゃね？
take _ [] = []

865 ：デフォルトの名無しさん：2013/03/16(土) 13:14:13.91

>>863
myTake 2 [] は myTake num (x:xs) にパターンマッチしていません。

第1引数の 2 は num にパターンマッチしていますが、
第2引数の [] が (x:xs) にパターンターンマッチしていないからです。

マッチするパターンが記述されていないから、Non-Exhastive になります。

Haskell はデフォルトでは、第1引数がパターンマッチすれば、
第2引数以降のパターンマッチ調査は必要になるまでとりあえず棚上する、
という動きはしません。

コンパイルが通るようにするには、
myTake num [] に対する関数定義をちゃんと書く必要があります。
これが一番素直で簡単で根本的な解決です。

ついでながら、先ほどの棚上げ処理をするように明示する方法もあります。
棚上げ処理は正確には反駁不可パターンなどと言い、
棚上げしたいパターンの記述にチルダ文字を前置することで指定します。
myTake num ~(x:xs) = ・・・
ただし、少なくとも今回あなたが書いたプログラムに限れば、
反駁不可パターンをそのまま使うだけではコンパイルが通るというだけで、
根本的な解決にはならない（実行時例外が起きる）ので意味はないですが。

866 ：デフォルトの名無しさん：2013/03/16(土) 13:24:38.95

なんか効率悪いな　↓こうでしょ
| num > 0 = x : myTake (num -1) xs

867 ：デフォルトの名無しさん：2013/03/16(土) 13:29:06.32

これって、フィールド名 x と xs を定義しているけれど名前空間は侵食されてないよね

868 ：デフォルトの名無しさん：2013/03/16(土) 13:31:58.09

出来れば、
nBanme :: [a] -> Int -> a
nBanme [] _ = error"カラ"
nBanme (x:xs) n
| n < 0= error"セロ"
| n == 0 = x
| n > 0 = nBanme (xs) (n-1)
| otherwise = error"ヘン"
のように関数ノ名が何個もあるのではなく

nBanme :: [a] -> Int -> a
nBanme list n
| list == [] || n < 0 = error""
| n == 0 && list == (x:xs) = x
| n > 0 && list == (x:xs) = nBanme (xs) (n-1)
| otherwise = error"Something Wrong"
な感じで関数名が一つなのを定義したいです。
反駁不可パターンなどはもうすこし勉強して理解したいとおもいます。

869 ：デフォルトの名無しさん：2013/03/16(土) 13:41:52.01

case (n, xs) ofを使う

870 ：デフォルトの名無しさん：2013/03/16(土) 14:15:16.07

867は何言ってるんだ

871 ：デフォルトの名無しさん：2013/03/16(土) 14:18:26.87

>>868
そんな変なこだわり持って読みにくいコード書くつもりならPGやめたほうがいいと思う

872 ：デフォルトの名無しさん：2013/03/16(土) 14:25:08.70

case 式で書けるには書けるんだけど、
プログラミングHaskellの最後の章にあるみたいなプログラムの正しさを確認する時とかに、
等式の集まりからなるパターンのほうが扱いやすい、みたいなのがあるので、
一つの式にすることにこだわるのはあまり良くないと思う。

873 ：デフォルトの名無しさん：2013/03/16(土) 14:51:33.52

haskellの並行処理でforkOに対するjoin関数が見当たらないんですが普通どうするんですか？
MVarとか使ってforkIO先で書き換えて同期取るんですかね？

874 ：デフォルトの名無しさん：2013/03/16(土) 14:59:25.48

なぜHaskellはアクターモデルを採用しなかったのか

875 ：デフォルトの名無しさん：2013/03/16(土) 15:32:27.70

>>873
fork した計算の結果が得られるまで待てばいいんだよね。
mergeIO や nmergeIO はなんか使えると思う。

GHC 7.8 でライブラリから取り除かれるから、
代わりに SafeSemaphore パッケージ使えとも書かれているが。

876 ：デフォルトの名無しさん：2013/03/16(土) 18:27:13.33

GHCはパッケージ構成コロコロ変え過ぎだろ
開発で使う場合、実質Haskell = GHCなのに何考えてんだ

877 ：デフォルトの名無しさん：2013/03/16(土) 18:30:20.89

標準化の過程で階層化が遅れてたんからしょうがないじゃない。
2010 標準は、もうそんなには変わらないと思うけど。

標準化されてないものは、そりゃあもうしょうがないでしょ。

878 ：デフォルトの名無しさん：2013/03/16(土) 20:50:47.45

>>875
なるほどありがとう

879 ：デフォルトの名無しさん：2013/03/16(土) 22:11:33.58

{-}
nth' :: [a] -> Int -> [a]
nth' list number = case (list, number) of
([], number < 0)-> error"Invalid Negative"
([], number == 0)-> error"Index Too Large"
((x:xs), number > 0)-> [x] ++ nth' xs (number - 1)
_-> error"Something Wrong"
-}
nBan :: [a] -> Int -> [a]
nBan list number = case (list) of
[] -> case (number) of
number < 0 -> error"dame"
[] -> case (number) of
number == 0 -> error"dame"
(x:xs) -> case (number) of
number > 0 -> [x] ++ nBan xs (number - 1)
_ -> error"Hen"
どっちもなぜか違う。

880 ：デフォルトの名無しさん：2013/03/16(土) 22:15:22.80

MaybeってC#で言うところのint?？

881 ：デフォルトの名無しさん：2013/03/16(土) 23:09:13.30

>>880
似たようなものだと考えていいけど、値を使おうとしたときに
中身がnullだった場合の処理を書くことを強制させられるという点が違う。
でもfromJustというチート関数があるので完全じゃない。
検索するとわかるから多少ましかも。

882 ：デフォルトの名無しさん：2013/03/16(土) 23:18:18.70

通りすがりだけど
>>769 と>>772に一票づつ
HaskellもOOPもまとめて終わりだな

883 ：デフォルトの名無しさん：2013/03/16(土) 23:22:12.34

>>881
別に強制されないと思う

f x = let (Just y) = x in y

とか書けるし

884 ：デフォルトの名無しさん：2013/03/16(土) 23:29:23.73

>>883
それもそうですね
これ警告出せなかったっけ？

885 ：デフォルトの名無しさん：2013/03/17(日) 01:38:55.96

>>882
終わってもいいけど次の言語も半分は今までと同じになるよ
どの辺が同じになるのかも見当がつくから完全に白紙に戻ることはない

886 ：デフォルトの名無しさん：2013/03/17(日) 09:16:17.29

>>885
次の言語、どの辺が同じになるか、
面白いね。もうちょっとしゃべってよ

887 ：デフォルトの名無しさん：2013/03/17(日) 09:29:11.66

Haskell 参照透明性
OOP メッセージパシング

888 ：デフォルトの名無しさん：2013/03/17(日) 09:32:24.21

参照透明性なんてMLやpure LISPの時代から言われていることで
Haskell特有でもなんでもない。

メッセージパッシングはとっくにOOPから捨てられただろ。
今のメジャーなOOPLはみんなメソッドを叩くだけだ。

889 ：デフォルトの名無しさん：2013/03/17(日) 09:39:08.20

ふーんw

890 ：デフォルトの名無しさん：2013/03/17(日) 09:41:48.63

オブジェクト指向のこころもMeyerのオブジェクト指向入門も読まずにOOP語ってる恥ずかしいやつが多いね

891 ：デフォルトの名無しさん：2013/03/17(日) 10:01:57.35

>>890
いいねえ
次は、オブジェクト指向のこころとMeyerのオブジェクト指向入門の
限界についても意見を聴きたいね

>>889
ｗてなんだ？

892 ：デフォルトの名無しさん：2013/03/17(日) 10:07:18.78

何がしたい

893 ：デフォルトの名無しさん：2013/03/17(日) 10:09:18.32

いいねえｗ

894 ：デフォルトの名無しさん：2013/03/17(日) 10:15:41.34

何も理解してないやつの「俺は会話についていってますよ」アピール

895 ：デフォルトの名無しさん：2013/03/17(日) 10:42:41.69

>>894
納得

896 ：デフォルトの名無しさん：2013/03/17(日) 10:43:39.58

OOPLはOOが育てた、Haskellは育ててないといって
OOが言語を差別するから、次世代の言語を同じだと思えなくなる
それならOOの本を読まずにOOPLを語る方が良い

897 ：デフォルトの名無しさん：2013/03/17(日) 10:48:45.72

>>896
>OOPLはOOが育てた、Haskellは育ててないといって

ソースplz

898 ：デフォルトの名無しさん：2013/03/17(日) 10:52:24.70

ソースを要求する以前に>>896の意味がわからない
このスレ情緒不安定しぐる

899 ：デフォルトの名無しさん：2013/03/17(日) 10:56:54.31

ちょっと前に暴れてたやつと同じ臭いを感じる
と言うか同一人物かな

900 ：デフォルトの名無しさん：2013/03/17(日) 11:09:27.84

第三次エスパー大戦の始まりか……

901 ：デフォルトの名無しさん：2013/03/17(日) 11:13:33.50

ここはHaskellのスレなのに、Haskellの関係ないOOの話を延々続けてる奴は一体何なの？

902 ：デフォルトの名無しさん：2013/03/17(日) 11:19:55.91

>>900
こんな感じですか
http://www.youtube.com/watch?v=oTKSTf4dr-k

903 ：デフォルトの名無しさん：2013/03/17(日) 11:27:45.29

>>901
等式推論とかやりたいなら
あまり関係ないものでも等価だと主張するぐらいが丁度いいんじゃないの

904 ：デフォルトの名無しさん：2013/03/17(日) 11:37:39.75

OOとHaskellは全く無関係かというとそれもまたアレだし微妙だねえ

型クラス継承はメッセージOOの継承とは別物だけど
メイヤーの表明OOでのサブタイプ多相は成立してるよね

905 ：デフォルトの名無しさん：2013/03/17(日) 13:38:31.31

OOはコーディングする本人の主観的な主義にすぎないから、機械語もOO

906 ：デフォルトの名無しさん：2013/03/17(日) 13:44:53.28

>>905
どこのスレのOO厨にフルボッコされたんだ？
俺がかわりにやっつけてきてやるよ。

907 ：デフォルトの名無しさん：2013/03/17(日) 14:09:24.34

>>905
抽象度と客観度は比例すると思ってる奴がいるんだよ
そういう奴は、抽象的であるOOが主観的なわけがないと思い込む

908 ：デフォルトの名無しさん：2013/03/17(日) 15:01:08.42

>>891
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

909 ：デフォルトの名無しさん：2013/03/17(日) 19:47:03.86

>>901
「完全教祖マニュアル」に、トンデモ論を言い続けていれば理論づけてくれる人が現れる、ってのがあるな。

910 ：デフォルトの名無しさん：2013/03/17(日) 21:06:33.94

>>906
やだ、かっこいい……

911 ：デフォルトの名無しさん：2013/03/17(日) 22:14:45.70

>>906
いいねえ

912 ：デフォルトの名無しさん：2013/03/17(日) 22:58:32.26

>>906
濡れた

913 ：デフォルトの名無しさん：2013/03/17(日) 23:32:19.51

>>910-912が全部同一人物

914 ：デフォルトの名無しさん：2013/03/17(日) 23:36:40.33

いいねえｗｗｗ

915 ：デフォルトの名無しさん：2013/03/17(日) 23:50:59.17

>>910-915は同一人物

916 ：デフォルトの名無しさん：2013/03/18(月) 00:05:15.78

サブルーチンのバグを逆手にとって関数化するとは具体的にどのような意味なのでしょうか

917 ：デフォルトの名無しさん：2013/03/19(火) 18:21:48.31

これは俺も気になった

918 ：デフォルトの名無しさん：2013/03/19(火) 18:59:24.84

日本語の意味がわからないのを逆手にとってソースコードの読みやすさに気づかせる

919 ：デフォルトの名無しさん：2013/03/20(水) 16:50:21.69

Haskellって実用アプリ作れるの？

920 ：デフォルトの名無しさん：2013/03/20(水) 16:56:05.16

>>919
何か作ることができない訳を思い付きますか？

921 ：デフォルトの名無しさん：2013/03/20(水) 16:59:11.84

チューリング完全がどうたら↓

922 ：デフォルトの名無しさん：2013/03/20(水) 17:21:30.27

先に言うなよ！↑

923 ：デフォルトの名無しさん：2013/03/20(水) 17:25:14.72

>>920
Haskell製の商用ゲームがないこと

924 ：デフォルトの名無しさん：2013/03/20(水) 17:28:45.26

だれかHaskellでどうぶつの森作ってくれ

925 ：デフォルトの名無しさん：2013/03/20(水) 17:36:30.01

>>923
Nikki and the robotsはポシャったけど商用レベルじゃないんですか（泣）

926 ：デフォルトの名無しさん：2013/03/20(水) 17:38:06.32

>>925
残念だけど商用レベルを名乗るならPS3で出せるくらいのクオリティじゃないと・・・

927 ：デフォルトの名無しさん：2013/03/20(水) 17:38:50.43

なんかあったじゃん、Haskellオンリーの結構いけてるゲーム
と思ったら>>925のだった

928 ：デフォルトの名無しさん：2013/03/20(水) 18:15:23.03

PS3みたいにSPUを利用する環境こそ
HaskellってSPUを使いこなすには有利だと思うんだけどね
現場じゃSPUまともに使いきれてないところ多いし

929 ：デフォルトの名無しさん：2013/03/20(水) 19:32:23.13

PS3で出せるくらいのクオリティに到達していない感がするゲームも
普通にPS3で出てるがな・・・

それはそうと、Haskellでゲーム作るなら、
データ駆動型が相性良いような気がするのだがどうだろう？

930 ：デフォルトの名無しさん：2013/03/20(水) 20:55:16.29

せやかて工藤

931 ：デフォルトの名無しさん：2013/03/20(水) 21:02:49.68

作ってから言え

932 ：デフォルトの名無しさん：2013/03/20(水) 22:28:59.15

Monadius www.geocities.jp/takascience/haskell/monadius_ja.html
Quake clone の Frag とか www.haskell.org/haskellwiki/Frag

商用のアプリって質の低い実装者とテスターを大量に投入して作り上げるものだから
出来上がった中身は大抵がそびえたつクソなんだよな

933 ：デフォルトの名無しさん：2013/03/20(水) 22:39:02.75

そのクソすらできないのがHaskellと言いたいの？

934 ：デフォルトの名無しさん：2013/03/20(水) 22:56:14.36

ゲーム会社が商用ゲームを作るのにメイン言語としてHaskellを選ばないのは、
プログラミング言語としてHaskellがクソだからという理由ではなくて、
単にC/C++で何も問題なく上手くいっているように感じているからだ。

そもそも現場でプログラミング言語を比較検討するという行為が行われていない。
だから、Haskellに限らずJavaやC#、ErlangやOCaml、LISPなども使わない。

スクリプト言語ならいくつかの候補から選ぶが、
それは一般にスクリプト言語と呼ばれているものだけを候補にするため、
やはりHaskell（やJavaなど）は初めから候補リストに入る余地がない。

935 ：デフォルトの名無しさん：2013/03/20(水) 22:56:42.66

その文脈でMonadiusを挙げるのは、皮肉で言ってるようにしか……

936 ：デフォルトの名無しさん：2013/03/20(水) 23:26:00.41

IOｗｗｗｗｗｗｗｗ doｗｗｗｗｗｗｗ

937 ：デフォルトの名無しさん：2013/03/20(水) 23:28:28.22

商用のアプリじゃなくても、日常業務で使うスクリプトでもいいんだけどね
schemeで作ったCUIの2chブラウザをhaskellに移植しようとしたら、文字化けがひどすぎて投げた
AAの表示は無理だよ、これ

938 ：デフォルトの名無しさん：2013/03/20(水) 23:34:15.97

ブラウザをschemeでとかHaskellでとか適材適所過ぎるェ…

939 ：デフォルトの名無しさん：2013/03/20(水) 23:43:35.35

何にしても大きいシステムを作るには関数型は部品が細かくなりすぎて逆に読みにくくなるのは仕方ないものなのかね

940 ：デフォルトの名無しさん：2013/03/21(木) 01:52:33.83

部品が細かいなら大きいタプルに入れればいいだけ
Lispのようなタプルが読みにくいのは仕方ない
JSONのようにすればよかった

941 ：デフォルトの名無しさん：2013/03/21(木) 02:45:14.42

大規模アプリでコケるのは、単体テストじゃなくて結合テストなんだから、純粋関数並べられても訳に立たない

942 ：デフォルトの名無しさん：2013/03/21(木) 05:39:52.86

>>941
「純粋関数並べられても訳に立たない」の意味がわからない。

943 ：デフォルトの名無しさん：2013/03/21(木) 05:57:15.78

大きなタプルとかアホ？
単にちゃんとレイヤー設計しましょう、ってだけでそ？

944 ：デフォルトの名無しさん：2013/03/21(木) 07:01:11.84

お前らが話しているのは、きっと作りにくい、きっとコケるだろうという予測の話。

実際に作ってみたが、ここで問題が起きた、どうすれば良い？という話は出てこない。

945 ：デフォルトの名無しさん：2013/03/21(木) 07:14:22.11

>>944
つまり、
「お前達、結合テストが必要となるような大規模開発やったことないだろ？」
ということですか。

946 ：デフォルトの名無しさん：2013/03/21(木) 07:37:43.75

C++以降の言語はみんな、Cはきっとこけるだろうという予想で作った言語だ
実際にこけたという話は出てこない

947 ：デフォルトの名無しさん：2013/03/21(木) 07:50:17.36

実際に何か作るような人はこんなスレに居ないんで

948 ：デフォルトの名無しさん：2013/03/21(木) 10:42:00.83

>>946
なんだかんだいって、最終的にCで実装することになる
その次に実装につかわれる言語がVBというおかしな世界

949 ：デフォルトの名無しさん：2013/03/21(木) 10:45:02.18

>>948
実装に深い意味がありそうだね。

950 ：デフォルトの名無しさん：2013/03/21(木) 11:13:49.08

いつの時代の人間だよ

951 ：デフォルトの名無しさん：2013/03/21(木) 11:25:55.85

インフラ系は40年前のソフトのメンテやバージョンアップが主業務なんてのはザラでして…

952 ：デフォルトの名無しさん：2013/03/21(木) 12:03:44.35

大勢が憧れている安定した大企業の勝ち組IT土方の実態というものか

953 ：デフォルトの名無しさん：2013/03/21(木) 12:10:32.77

大企業Disのブームはもう終わりましたよ

954 ：デフォルトの名無しさん：2013/03/21(木) 12:17:28.01

冷静に考えたら、製品の劣化なし完全コピーが可能なんだから、新言語が普及しないのは当然
開発用ツールのスクリプトがタケノコみたいにポコポコ出てくるのも当然

955 ：デフォルトの名無しさん：2013/03/21(木) 13:32:36.37

>>954
？

956 ：デフォルトの名無しさん：2013/03/21(木) 20:16:20.82

メンテ用ツールか、旧言語のコードの自動生成しか新言語の活躍の場はない

957 ：デフォルトの名無しさん：2013/03/21(木) 21:23:29.51

実行は速いがコンパイルは遅いという伝統を踏襲しなかったから、スクリプトは新しい
相変わらずコンパイルが遅い言語はどこが新しいのか分かりにくい

958 ：デフォルトの名無しさん：2013/03/21(木) 22:49:33.70

今更だけどここのスレタイってあんまりよくないよな
言語の名前は最後じゃなくて頭のほうに持ってきてほしい

959 ：デフォルトの名無しさん：2013/03/21(木) 23:00:29.25

Haskell part 21 : 歴史

960 ：デフォルトの名無しさん：2013/03/22(金) 13:32:02.69

いいねえ

961 ：デフォルトの名無しさん：2013/03/22(金) 21:48:04.93

>>584に書いたパルズ解答ソフトについて。

以前にC++で作ったソフトをHaskellで作りなおしてみた。
なんとか完成させ、新しい機能もちょっと追加。
とりあえず作った…。これから修正していこうと思う。

ソースコードサイズ(両方ともに未参照コード含む)
C++版 167kB
Haskell版 54kB

計算時間
C++版 1.77秒
Haskell版 38.2秒

962 ：961：2013/03/22(金) 21:48:55.34

感想。
コードは短くなったけれども、思ったより短くない。
C++版とHaskell版は、両方ともスパゲッティ状態。
Haskellのほうが短いとはいえ、スパゲッティ状態もまた
濃縮されているようなものだ。

Haskell版のほうが計算時間が長いのは仕方ない。
"はじめてのHaskell"ではね・・。
これから改善して2秒以内にするのを挑戦してみる。

963 ：デフォルトの名無しさん：2013/03/22(金) 21:50:26.93

パルズ！

964 ：961：2013/03/22(金) 22:31:56.28

>>963
「パズル」の間違いです。

「プログラミングin Haskell」は最後まで読んだ。
「すごいHaskell楽しく学ぼう」は、今200ページ前後を読んでいる最中。あと半分・・。

965 ：デフォルトの名無しさん：2013/03/22(金) 23:19:11.19

バルス

966 ：デフォルトの名無しさん：2013/03/22(金) 23:20:34.18

前者を先に読むのってどうなんだ
++がくっ付いた記号とかλとか→とか⇒とか
記号がおかしくて初心者は実際に全角を入力するし頭おかしいよあの本
2冊目としては良書なんだけどなんで記号使ってんだボケって言いたい

967 ：デフォルトの名無しさん：2013/03/22(金) 23:51:54.62

>>966
Haskell系の論文だと、そういう記号わんさか出てくるな。

著者も研究者だし、この本もどちらか言うと
関数プログラミングを学問として学ぶ系だと思うよ。

968 ：デフォルトの名無しさん：2013/03/22(金) 23:53:26.79

実用書じゃないオナニー本ってこと。

969 ：デフォルトの名無しさん：2013/03/22(金) 23:54:35.26

すごいHaskell～も分かった気になるだけの本だしなあ

970 ：デフォルトの名無しさん：2013/03/22(金) 23:55:03.81

嫌な言い方をする人はコードも嫌な感じ

971 ：デフォルトの名無しさん：2013/03/22(金) 23:58:41.14

>>970すごい本のこと？
確かになんかネラー臭のする言葉がたまに出るけど…

972 ：デフォルトの名無しさん：2013/03/22(金) 23:59:34.32

>>966
日本語版は巻末に書中で使われている記号と実際の入力方法の対応表が巻末に付いてるし
そこまで怒るようなものでもないんじゃないか

973 ：デフォルトの名無しさん：2013/03/23(土) 00:05:06.89

>>971
勘違いするな

>>968 のことだ

974 ：デフォルトの名無しさん：2013/03/23(土) 00:11:08.89

プログラミングHaskellは単にIFPHに倣っただけだろ

975 ：デフォルトの名無しさん：2013/03/23(土) 00:13:50.62

>>973
いや、学問は知識欲を満たすためのオナニーだよ。

976 ：デフォルトの名無しさん：2013/03/23(土) 00:35:43.48

記号の凡例は前書きや巻末にひっそりと載ってるから物言いがつくんじゃね
本文第一章あたりで堂々と説明しとけば初学者でも迷わないと思う

977 ：デフォルトの名無しさん：2013/03/23(土) 00:54:56.29

誰かモナデウスのソースコード解説を

978 ：デフォルトの名無しさん：2013/03/23(土) 01:02:35.32

すごいHaskellは原文からしてあの口調だからな
しかしそこがいい

979 ：デフォルトの名無しさん：2013/03/23(土) 05:14:06.88

つい最近立ったと思ってたのになんでもう埋まりそうなんだよ

980 ：デフォルトの名無しさん：2013/03/23(土) 07:29:02.39

getで出したリストの値をcouで使用。get [1,3,4,3,4,7,4]->[4,4,7,4]
それでcouでそのリスト内の4の数を求めたい。しかし、返された値は0。なぜ？

get :: [Int] -> [Int]
get list = case (list) of
[] -> []
(x:xs) -> [x | x <- xs, x > 3]

cou :: [Int] -> Int
cou (list) = case (get list) of
[] -> 0
(x:xs) -> case (x > 3) of
True -> 1 + cou xs
_-> cou xs

981 ：デフォルトの名無しさん：2013/03/23(土) 07:40:52.02

ごめん日本語の部分がよく分からない
ちゃんと順序立てて言葉足らずにならないように説明してよ

982 ：デフォルトの名無しさん：2013/03/23(土) 08:56:08.27

すごいH、完全にLand of Lispに食われたなw

983 ：デフォルトの名無しさん：2013/03/23(土) 09:14:01.92

>>981
getは数値が３以下の数全てを除いたリストを返したい。例えばget[1,4,6,2,4,1]のリストは[4,6,4].
そして、couの関数でgetの返されたリスト（[4,6,4]）の中に何個’４’の数があるか？を数えたい。この場合[4,6,4]には4が二つあるので2を返してほしい。
cou [2,5,4,3,4] >> 2
式が間違ってました。

get :: [Int] -> [Int]
get list = case (list) of
[] -> []
(x:xs) -> [x | x <- xs, x > 3]

cou :: [Int] -> Int
cou (list) = case (get list) of
[] -> 0
(x:xs) -> case (x ==4) of
True -> 1 + cou xs
_-> cou xs

984 ：デフォルトの名無しさん：2013/03/23(土) 09:28:34.82

貼ってみたらちゃんと動いてるみたいだけど。。。
http://codepad.org/RlPkEbhg

985 ：デフォルトの名無しさん：2013/03/23(土) 10:40:38.45

これでいいの？
*Main> get [4,4,5]
[4,5]
*Main> get [4,5,4]
[5,4]
*Main> get [1,4,6,4,2]
[4,6,4]
*Main> get [4,6,4,2]
[6,4]
*Main>

986 ：デフォルトの名無しさん：2013/03/23(土) 10:50:27.19

わざわざありがとうございます。
getが何か変だと思い始めてます。
Main> get [3,4,2,4,5,4]
[4,4,5,4]
Main> cou [4,4,5,4]
2 -- 3を返して欲しい所

こんな感じになってしまいます。
get [4,4,5]の戻りはなぜ[4,4,5]ではなくて[4,5]になるのでしょうか？またget[4,6,4,2]もしかり。

987 ：デフォルトの名無しさん：2013/03/23(土) 11:04:15.91

get :: [Int] -> [Int]
get list = case (list) of
[] -> []
(x:xs) ->
if x > 3 then x : get xs
else get xs
ようやく直せました。x | x<- xsではxが判定に入っていなかったからでした。色々ありがとうございました。

988 ：デフォルトの名無しさん：2013/03/23(土) 11:06:56.43

[4, 4, 5]を(x: xs)でパターンマッチするとxに先頭要素4、xsに残りの要素[4, 5]が束縛される
あとcase式は使わずにトップダウンで定義を書き下したほうがいいと思うよ

989 ：デフォルトの名無しさん：2013/03/23(土) 11:07:29.69

?トップダウン
○トップレベル

990 ：デフォルトの名無しさん：2013/03/23(土) 11:10:58.21

>>987
( x : xs ) -> [x | x <- (x : xs), x > 3]

こう直すだけでいい筈です。

991 ：デフォルトの名無しさん：2013/03/23(土) 11:12:42.38

>>987
>>988 の言うように 983 にある get の最後の行
(x:xs) -> [x | x <- xs, x > 3]
がおかしかった。
この書き方したいなら、
(y:ys) -> [x | x <- (y:ys), x > 3]
とかとするか、
y@(x:xs) -> [x | x <- y, x > 3 ]
とかかな。

992 ：デフォルトの名無しさん：2013/03/23(土) 11:19:25.79

get xs=[x|x<-xs,x>3]

993 ：デフォルトの名無しさん：2013/03/23(土) 11:37:03.05

内包表記とcaseを同時に使う必要はないね
使わないと機会損失だから同時に使うみたいなパターンは危ない

994 ：デフォルトの名無しさん：2013/03/23(土) 11:43:18.84

なんでコンスにしてんの？

995 ：デフォルトの名無しさん：2013/03/23(土) 11:54:25.38

トップレベルを調べてみます。
内包＝if elseのことでしょうか？
(x:xs) ->
| x > 3 = x : get xs
| otherwise = get xs
だとエラーが出てしまったのでif使ってしまいました。まだよく分かっていないのですが、caseならcase, | なら |で統一した方がいいのでしょうか？ま～名前がcouなのは適当に打ったからです。

996 ：デフォルトの名無しさん：2013/03/23(土) 12:22:00.99

997 ：デフォルトの名無しさん：2013/03/23(土) 12:31:21.96

>>995
こういうプログラムを書きたかったんじゃないのかな。
get :: [Int] -> [Int]
get list = case (list) of
　[] -> []
　(1 : xs) -> [x | x <- xs,x > 1]
　(2 : xs) -> [x | x <- xs,x > 2]
　(x : xs) -> [x | x <- (x : xs), x > 3]

cou :: [Int] -> Int
cou (list) = case (get list) of
　[] -> 0
　(x:xs) -> case (x ==4) of
　　True -> 1 + cou xs
　　_-> cou xs

998 ：デフォルトの名無しさん：2013/03/23(土) 12:38:35.91

次スレゆうどう
http://toro.2ch.net/test/read.cgi/tech/1364009659/

999 ：デフォルトの名無しさん：2013/03/23(土) 14:00:30.97

よし、埋めはまかせろ！

1000 ：デフォルトの名無しさん：2013/03/23(土) 14:01:24.94

バリバリバリ

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。