関数型プログラミング言語Haskell Part21
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2013/01/21(月) 02:16:16.07ttp://www.haskell.org/
日本語サイト
ttp://www.sampou.org/cgi-bin/haskell.cgi
ttp://www.shido.info/hs/
過去ログ
関数型プログラミング言語Haskell
Part1 ttp://pc.2ch.net/tech/kako/996/996131288.html
Part2 ttp://pc2.2ch.net/test/read.cgi/tech/1013846140/
Part3 ttp://pc8.2ch.net/test/read.cgi/tech/1076418993/
Part4 ttp://pc8.2ch.net/test/read.cgi/tech/1140717775/
Part5 ttp://pc8.2ch.net/test/read.cgi/tech/1149263630/
Part6 ttp://pc11.2ch.net/test/read.cgi/tech/1162902266/
Part7 ttp://pc11.2ch.net/test/read.cgi/tech/1174211797/
Part8 ttp://pc11.2ch.net/test/read.cgi/tech/1193743693/
Part9 ttp://pc11.2ch.net/test/read.cgi/tech/1211010089/
Part10 ttp://pc12.2ch.net/test/read.cgi/tech/1231861873/
Part11 ttp://pc12.2ch.net/test/read.cgi/tech/1252382593/
Part12 ttp://hibari.2ch.net/test/read.cgi/tech/1272536128/
Part13 ttp://hibari.2ch.net/test/read.cgi/tech/1286706874/
Part14 ttp://hibari.2ch.net/test/read.cgi/tech/1299385928/
Part15 ttp://hibari.2ch.net/test/read.cgi/tech/1310199414/
Part16 ttp://toro.2ch.net/test/read.cgi/tech/1317958045/
Part17 ttp://toro.2ch.net/test/read.cgi/tech/1325510368/
Part18 ttp://toro.2ch.net/test/read.cgi/tech/1331902463/
Part19 ttp://toro.2ch.net/test/read.cgi/tech/1340760070/
Part20 ttp://toro.2ch.net/test/read.cgi/tech/1350428908/
0357デフォルトの名無しさん
2013/03/02(土) 12:46:59.14結局ユーザーとしてはこれだけ知ってればいいんだよね。
0358デフォルトの名無しさん
2013/03/02(土) 14:24:05.970359デフォルトの名無しさん
2013/03/02(土) 14:59:54.46（よく言われるけど）敷居高く見せるために、という理由の根拠は？
Haskell の歴史を概略した論文を読んでも、
敷居高く見せる必要があったとは読み取れないよ。
文法では規定できない規則をプログラマにお願いする際に、
その規則を呼ぶキャッチーな名前がある方が便利だよね。
いちいちルールＡとルールＢとルールＣに従ってくださいと言うよりも、
モナド則に従ってくださいという方が簡単だ。
Monad クラスにしても、Haskell という言語の中では、
他の Functor クラスや Show クラス、Eq クラスなどと同じ
ごく一般的な普通のクラスだ。
それに担わせたかったある役割を実現する（表現する）方法として、
たまたま計算機科学におけるモナドの概念がうまくマッチしたから、
その概念や名前を拝借して Monad クラスという名前を付けただけ。
（ある役割というのは、初めはIOを純粋関数型らしく上手く扱う事だったと言う）
0360デフォルトの名無しさん
2013/03/02(土) 15:16:15.130361デフォルトの名無しさん
2013/03/02(土) 15:27:15.22まぁ、それは人によりけりだね。
この名前から初心者を寄せ付けないオーラを感じ取る人もいるだろうし。
私は高尚感はそれほど感じないな。
Monad クラスのインスタンスを
モナディック ファミリーと勝手に呼んで親しんでる。
0362デフォルトの名無しさん
2013/03/02(土) 15:40:50.82参照透明性を保とうとすると、アルゴリズムの教科書なんかで良く出てくる
タイプの逐次処理なんかをどう書くかという問題がでてくる。
逐次処理のうち、あるものは fold 系でまとめることができる。
部分的な結果をつなぎあわせて最後の計算結果にするタイプの
アルゴリズムは必ずしも fold 系で記述できないが、
多相型Fの型コンストラクタが関手であり、さらに
モナドであるばあいのKleisli射の合成として表せるタイプの計算に
対しては、その一連の計算があたかも命令を連ねて値を作っている
かのように人間に感じさせるシンタックスシュガーが用意されている。
要するに、
・do 記法自体はむしろ敷居を下げるために導入された。
・使い方、ではなくデザインの背後にあるロジックを知ろうとすると圏論が出てくる。
わけだ。計算の抽象化うんたらってのはMoggiあたりが言い出したことで、
知りたかったら論文読めばいいし、知らなくてもHaskell使うのに支障はない。
0363デフォルトの名無しさん
2013/03/02(土) 15:44:19.40モナドって呼ばれる前は数学の中で Triple と呼ばれていた。いくらなんでも
一般名詞すぎるのでマクレーンがモナドと命名した。
そもそもの始まりとして、カテゴリーという名称自体アリストテレスの範疇論から
名前を借りてきており、この辺はマクレーンが最初基礎論を専攻しようと
した哲学的な傾向というか憧れというかコンプレックスというかそんなものの反映。
モナドが酷い名前だというのはまあ同意するけど「りあむ」よりは良い名前だと思うよ。
0364デフォルトの名無しさん
2013/03/02(土) 16:25:47.990365デフォルトの名無しさん
2013/03/02(土) 17:15:26.440366デフォルトの名無しさん
2013/03/02(土) 18:57:57.95解説よろしくです
0367デフォルトの名無しさん
2013/03/02(土) 19:08:40.15基礎は知ってるならファンクタからでも
0368デフォルトの名無しさん
2013/03/02(土) 19:10:56.390369デフォルトの名無しさん
2013/03/02(土) 19:13:15.300370デフォルトの名無しさん
2013/03/02(土) 19:14:08.740371デフォルトの名無しさん
2013/03/02(土) 19:32:53.24モナドを理解するためにはこのことにまず気付かねばならない
0372デフォルトの名無しさん
2013/03/02(土) 19:36:12.01>>346 でも言ったが、モナドの何が知りたいのか、具体的に、
できればひとつに絞って質問してもらう訳にはいかないのかな。
それと、モナドをHaskellプログラマとして使う側に沿った説明は、
このスレでも色んな方がされている。
私も稚拙だが >>356 で肝の部分を少しだけ説明したつもり。
＊＊番のレスの〜の意味が分からんとか、＊＊番のレスの説明をもう少し詳しくとか、
そんな感じで質問してくれると、アドバイスする方としては大変助かるのだが。
0373デフォルトの名無しさん
2013/03/02(土) 19:40:54.26モナド則についてとStateモナドについてお願いします
>>356を読んでもそれがStateを管理するのにどうつながるのかよく分かりませんでした
0374デフォルトの名無しさん
2013/03/02(土) 19:43:17.74>>356
その喩えは確かか？
箱って何？なぜわざわざ箱に入れるの？
隠蔽はモナドに限らない常套手段なのでそれが肝と言われても？
>そんな事をしてもモナドを使う側から見れば同じ計算に式に見える。
何と何が同じ計算に見えるの？
0375デフォルトの名無しさん
2013/03/02(土) 19:46:21.92ここはべつにお前の質問に答えるための板じゃない
0376デフォルトの名無しさん
2013/03/02(土) 19:46:21.03理解したつもりになること。
0377デフォルトの名無しさん
2013/03/02(土) 19:48:18.43順に質問の幅を狭めて具体化させるぞ。
モナド則の何が知りたい。
Stateモナドの何が知りたい。
0378デフォルトの名無しさん
2013/03/02(土) 19:50:13.68自分で考えずに全部オウム返しで漠然と質問してくるから話にならない
0379デフォルトの名無しさん
2013/03/02(土) 19:53:31.12347、370、373等の質問に答えてないなと言っただけだ。おれはそのどれでもないが
だからよほど難しい質問なのかと思った
0380356
2013/03/02(土) 20:00:16.48会話しやすいように、私の元の発言のレス番を名前に入れておくな。
> その喩えは確かか？
申し訳ない、>>356 では言い忘れたが、
私が個人的に抱いているイメージなんで、人によっては違うと思う。
> 隠蔽はモナドに限らない常套手段なのでそれが肝と言われても？
そう、情報を隠蔽する方法は Monad クラス以外にもいろいろある。
その方法のひとつが Monad クラスというとして標準ライブラリに用意されており、
また、その方法が特別有用なので文法上も特別扱いされている。
> 何と何が同じ計算に見えるの？
(Monad m) ==> m a 型の値 x と、
(Monad m) ==> m a -> (a -> m b) -> m b 型の関数 f があるとする。
x >>= f という式は、Monad クラスの「どのような」インスタンス型でも成り立つ。
例えばリスト型だろうが Maybe 型だろうが、IO 型だろうが。
同じ計算に見えるというのは現象で、大事なのは同じ扱い方ができる、という事。
0381デフォルトの名無しさん
2013/03/02(土) 20:05:27.180382デフォルトの名無しさん
2013/03/02(土) 20:06:51.560383356
2013/03/02(土) 20:11:10.78見落としてた。
> 箱って何？なぜわざわざ箱に入れるの？
箱というのは、return x という式で値 x をモナド化させると言ったり、
x をモナドでかぶせると言ったり、そういう言い回し（しないかな・・・）を、
私は「箱に入れる」とイメージしているだけだ。
なぜわざわざ箱に入れるのか、つまり何故モナドにするのかと言えば、
プログラマの視点から言えば、箱の中身を触らないようにするためだ。
オブジェクト指向のクラスで言うところの、private メンバ変数にして、
外部から勝手に触らせないようにするためだ。
たとえば State モナド。
このモナドの箱の中には、ユーザーが return 関数で入れた値の他に、
状態を表す値も密かに入れられている。
ユーザーによってその状態を表す値が勝手に書き換えられたら、整合性がとれなくなる。
だから State モナドは状態を表す値を隠し、
特別に用意された関数を通してしかアクセスできないようにしている。
0384デフォルトの名無しさん
2013/03/02(土) 20:15:17.71俺なんかはその辺は諦めて実際の用法に集中してるんだけど
0385デフォルトの名無しさん
2013/03/02(土) 20:16:59.99だけどコンテナに値突っ込んだり出したりって副作用じゃないの？って思ってしまう
0386356
2013/03/02(土) 20:18:06.70>>380 の説明の関数 f の型はおかしいですね。
(Monad m) ==> a -> m b です。
すいません。
0387デフォルトの名無しさん
2013/03/02(土) 20:21:07.49Monadのインスタンスは種が*->*の型コンストラクタであり
既存の型を包みこむように動作することから
イメージしやすいように箱とかコンテナが良く引き合いに出される
0388デフォルトの名無しさん
2013/03/02(土) 20:23:21.290389デフォルトの名無しさん
2013/03/02(土) 20:30:05.930390デフォルトの名無しさん
2013/03/02(土) 20:32:56.930391デフォルトの名無しさん
2013/03/02(土) 20:35:05.09いや圏論を持ち出してもわからなさは同じだと思う
0392デフォルトの名無しさん
2013/03/02(土) 20:36:59.87プログラムの意味論における「状態が変化する」ことを副作用と言っている。
もっと広く、環境が変化すると言ってもいい。
状態が変化するとか環境が変化するというのは、意味上メモリの内容が変わったり、
コンソールに文字を表示させる事でコンソールの内容が変わったりといった事。
（意味上と限定したのは、実際 GHC は内部でメモリの内容を書き換えるかも知れんから）
コンテナに値突っ込むとか、箱に入れるとかはあくまでイメージなので、
その操作自体に副作用があるとか無いとかは関係ない。
その操作の時に中で何が行われるかによる。
そうイメージされる現象によって状態・環境が変化しなければ副作用は無いと言えるし
そうイメージされる現象によって状態・環境が変化すれば副作用はあると言える。
例えば State モナドは環境が変化しないので副作用は無い。
IO モナドは環境が変化する（可能性がある）ので副作用がある（可能性がある）。
0393デフォルトの名無しさん
2013/03/02(土) 20:48:32.92>私が個人的に抱いているイメージなんで
いやそれで十分
>x >>= f という式は、Monad クラスの「どのような」インスタンス型でも成り立つ
うん。だけどそれがどれほど嬉しいのかが分からん
>なぜわざわざ箱に入れるのか、つまり何故モナドにするのかと言えば、
>プログラマの視点から言えば、箱の中身を触らないようにするためだ。
>たとえば State モナド。
>ユーザーによってその状態を表す値が勝手に書き換えられたら、整合性がとれなくなる。
>だから State モナドは状態を表す値を隠し、
>特別に用意された関数を通してしかアクセスできないようにしている。
ここは違うんじゃないの？箱は隠蔽のためではないでしょ？
0394デフォルトの名無しさん
2013/03/02(土) 21:14:57.97出した結果がブレるのが副作用
出さなければ副作用はない
コールバックのように自分では呼び出さないようにする
0395デフォルトの名無しさん
2013/03/02(土) 21:26:53.64例えば主人公がキー入力によって移動して
ある位置に到達すると会話シーンなどのイベントが始まるような
C脳なので主人公が移動するためには座標を管理する変数を書き換える必要があるなとなってしまう
0396デフォルトの名無しさん
2013/03/02(土) 21:30:09.700397デフォルトの名無しさん
2013/03/02(土) 21:32:49.44まず問題を小さく分けます
0398356
2013/03/02(土) 21:35:07.04> ここは違うんじゃないの？箱は隠蔽のためではないでしょ？
いや、私のイメージでは隠蔽なんだが。
f :: a -> State s b を作れば >>= で簡単に箱から情報を取り出せる。
もっといえば、do 記法の中で <- を使うだけで情報を取り出せる。
そういう意味では隠蔽していないと言えるかもしれん。
でも、State モナドは return x でユーザーが箱に入れる情報の他に、
「状態を表す情報」もこっそり一緒に箱に入れている。
この「状態を表す情報」はユーザーは勝手に取り出したり書き換えたりできん。
これは情報の隠蔽と言えると思うのだが、どうだろうか。
ぶっちゃけて言えば、State や IO がモナドなのは私も理解できるが、
Maybe や Either などがモナドである必然性はちょっと説明できん。
たまたま Monad クラスに fail 関数があるから、かろうじて
Maybe や Either などがモナドであるメリットはあるが・・・
そもそも Monad クラスに fail 関数がある事自体私も意味が分からん。
0399デフォルトの名無しさん
2013/03/02(土) 21:35:47.93そもそも副作用がよくわからない。
f :: Int -> Int
f x = ２ 機能に影響されない
se :: Int -> Int
se x = se x + 1 機能に影響される
こんなヤツ？
0400デフォルトの名無しさん
2013/03/02(土) 21:36:07.78プログラム作るだけならIORefとかでぐぐったらいいと思う。
0401デフォルトの名無しさん
2013/03/02(土) 21:39:32.28つまりHaskellでゲームを作る場合
・関数Fを評価するとその関数はモナドを返す
・そのモナドの中身にはステーを反映した関数F'のインスタンスが定義されている
・次のフェーズではF'を評価してF''のインスタンスが格納されたモナドを返して
・・・・
この世代交代を毎フレームするってこと？
0402デフォルトの名無しさん
2013/03/02(土) 21:43:13.95方法はいくつかある。
本当にそのまま座標を管理する変数を書き換える事もできる。
Haskellにはメモリの書き換え処理をする関数も標準ライブラリで用意されている。
他には、移動する度に古い座標の変数を破棄し、新しい座標の変数を作ることもできる。
破棄した変数（を納めたメモリ領域）はガベージコレクタによってそのうち回収される。
こちらは、副作用は伴わない。
0403デフォルトの名無しさん
2013/03/02(土) 21:43:45.10俺はそう理解している。ちなみに独習でHaskell歴半年。察してくれ。
0404デフォルトの名無しさん
2013/03/02(土) 21:45:27.53int x;
int getter(){return x;}
void setter(int a){x = a;}
void f(int* g(), void* s(int))
{
s(g() + 1);
}
f(getter, setter);
0405デフォルトの名無しさん
2013/03/02(土) 21:47:30.9219xx年：生まれる
2013年：モナドがわからない ←いまここ
0406デフォルトの名無しさん
2013/03/02(土) 21:53:46.13Haskell にも副作用はある。
プログラムソース中の、副作用がある部分と、副作用が無い部分が
明確に分離されるのが Haskell。
Haskell のプログラムで両者が混じることは、普通は無い。
> そもそも副作用がよくわからない。
>>392 でも少し説明したが、もっと簡潔に言うと、
下記の2つの事が両方とも護られていれば、純粋な関数、つまり副作用は無い。
・関数 f について、a == b ならば f a == f b である。
・関数 f について、計算以外の事をしない。
少なくとも一方が守られなければ、たいていは副作用がある関数だと思って間違いない。
0407デフォルトの名無しさん
2013/03/02(土) 21:57:15.66http://d.hatena.ne.jp/kazu-yamamoto/20090627/1246135829
視点の違いであるっちゃあるし、ないっちゃない
0408デフォルトの名無しさん
2013/03/02(土) 21:57:55.81そのゲッターとセッターが、型 int に結びつけられており、
かつ、そのゲッターとセッターがプログラマから隠されていれば、
Haskellのモナドの機能の一部は似ている、と言える。
0409デフォルトの名無しさん
2013/03/02(土) 22:33:39.28少なくとも実行時には副作用起こりまくり。
0410デフォルトの名無しさん
2013/03/02(土) 22:40:28.50Excelシート+VBA ： 副作用あり。モナドを使うHaskellプログラム
0411デフォルトの名無しさん
2013/03/02(土) 22:42:49.41その関数は副作用を持たない
0412デフォルトの名無しさん
2013/03/02(土) 22:49:03.50セルの内容書き換えられるがな（´･｀･ω）
0413デフォルトの名無しさん
2013/03/02(土) 22:55:47.97そういう事もあり得るから、>>392 で意味論におけるとか、
意味上とか言って限定したんだがなぁ
0414デフォルトの名無しさん
2013/03/02(土) 22:57:46.02たとえばStateモナド（を実装した代数データ型のインスタンス）から、パターンマッチで内部状態を取り出すことが
できるよね。
モナドであることの条件にこれを禁じるルールはないと思う。
0415デフォルトの名無しさん
2013/03/02(土) 23:05:11.95意味論の側面は「参照透過性」と表現すると思う。
0416デフォルトの名無しさん
2013/03/02(土) 23:06:28.07そのパターンマッチは m >>= f の f の中でしかできないんじゃないの？
0417356
2013/03/02(土) 23:06:56.98data や newtype で定義した型の値コンストラクタが公開されていれば、
それが Monad クラスのインスタンスだろうがなんだろうが、
その値コンストラクタでパターンマッチできるよ。
値コンストラクタが公開されていなければ、
パターンマッチでは取り出せない。
モナドの話とは関係ないと私は思ってるんだけど、なんか関係あるかな？
0418デフォルトの名無しさん
2013/03/02(土) 23:08:37.40ExcelシートのCellに"=2+3"と書き込むことは
Haskellでいうところの定義だろ？
*.hsファイルにエディタでx=2+3と書き込むのと一緒だと思う。
この定義されたセルをプログラムから書き換えるには
VBAを使うしかない。
0419356
2013/03/02(土) 23:11:16.90あと、モナドで隠蔽するのは中の値だけじゃなく、
箱に値を入れる時にした計算や、箱から値を取り出した時にした計算も、
一緒に隠蔽するよ。
0420デフォルトの名無しさん
2013/03/02(土) 23:13:51.69それ（Haskellの何をExcelの何で喩えているか）を始めにはっきり言わないと、
たいていの人には話は通じないよ
0421デフォルトの名無しさん
2013/03/02(土) 23:18:09.24> モナドの話とは関係ないと私は思ってるんだけど、なんか関係あるかな？
俺もそう思ってるが、君が
> これは情報の隠蔽と言えると思うのだが、どうだろうか。
と言っているので。
0422356
2013/03/02(土) 23:40:21.81ごめん、意味がよく分からない。
return 関数や >>= 演算子の実装で情報は隠蔽されるよね。
値も、その計算も、他の計算も処理も隠蔽されるよね。
そういう事を隠蔽と言ってるんだけど。
そのことと、たまたま data で定義した型の値コンストラクタが公開されている
という事による情報の公開は、モナドによる情報の隠蔽とは何も関係ないよね。
この一連の会話は、モナドの話だよね？
0423デフォルトの名無しさん
2013/03/03(日) 00:08:12.18無知蒙昧なプログラマがHaskellに一体なんの不義理をしたんだよ
0424デフォルトの名無しさん
2013/03/03(日) 00:34:28.92http://hackage.haskell.org/trac/ghc/ticket/7103
http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault/Windows
0425デフォルトの名無しさん
2013/03/03(日) 00:35:47.68■具体的な処理をブラックボックスとして扱うこと。
■個々の処理をつなぐことができること(>>=)。
■処理の結果を、次の処理以降では、ある意味でグローバルな変数 (自由変数) として使えること。(実際のスコープは Maybe や IO などのタグ (圏) の中に限定される)
モナドの枠組みが色々なものに当てはまるからわかりにくいけど、本質的には上記の点が共通しているはず。
0426デフォルトの名無しさん
2013/03/03(日) 00:39:30.80■行を実行する
■結果を変数に代入する (しない場合もある)
■後ろの行は前の処理結果 (変数の値) を利用して計算したりする。
なんか、モナドの役割と対応つきそうでしょ？
だから、do を使う関数では手続き型言語っぽい書き方ができる。
私の理解はこんな感じです。
間違ってたらごめんね
0427デフォルトの名無しさん
2013/03/03(日) 00:46:27.070428デフォルトの名無しさん
2013/03/03(日) 00:51:25.770429デフォルトの名無しさん
2013/03/03(日) 00:52:31.840430デフォルトの名無しさん
2013/03/03(日) 01:02:47.68Haskellにおけるデザパタみたいなものなので、可読性が低くて良いなら
モナドを使った処理は全てモナドなしで書ける。（現在の入出力のように
最初からモナドで書かれたライブラリはのぞく）。
0431デフォルトの名無しさん
2013/03/03(日) 09:10:07.41>■結果を変数に代入する (しない場合もある)
>■後ろの行は前の処理結果 (変数の値) を利用して計算したりする。
結局，モナドとは，手続き型言語ではふつうにやることを
関数型でもできるようにするデザパタのことと思えばよいの？
0432デフォルトの名無しさん
2013/03/03(日) 09:15:05.570433デフォルトの名無しさん
2013/03/03(日) 10:17:53.940434デフォルトの名無しさん
2013/03/03(日) 10:33:43.200435デフォルトの名無しさん
2013/03/03(日) 10:59:19.940436デフォルトの名無しさん
2013/03/03(日) 11:08:35.30良いか悪いか判断しないで用例を集めるだけにするべきだった
staticおじさんも良いか悪いかは別としてそういう書き方もありうると言うべきだった
0437デフォルトの名無しさん
2013/03/03(日) 11:49:15.77これはどういう意味だ？
今はもう、デザパタどころではない胡散臭いのが出回ってるってことか
それともデザパタが偽モノなのはとっくに常識になってるってことか
それともまさか今時デザパタを信奉してんじゃないだろ？
0438デフォルトの名無しさん
2013/03/03(日) 11:55:51.70他の用途もいろいろあるというのでまた分からなくなるわけだ
0439デフォルトの名無しさん
2013/03/03(日) 12:13:06.010440デフォルトの名無しさん
2013/03/03(日) 12:24:21.12信奉の意味が分からない
状況に応じて使えそうなら参考にする、それだけのもんだろ
消化した上で使えないと判断するのは勝手だけど、胡散臭いなんて次元で語られる時期はとうに過ぎてる
その意味で原始人
0441デフォルトの名無しさん
2013/03/03(日) 12:57:11.67Haskellに Monad クラスのインスタンス型がある理由は、本質的にはそれだよ。
特に IO モナドね。
その Monad クラスのインスタンスを引数にとったり返したりする関数に、
いろいろ便利なものがあるから、手続き型言語の事は忘れて、自分で色々応用すれば良いよ。
ただ、
> 手続き型言語ではふつうにやることを
> 関数型でもできるようにする
なんか「関数型ってこんな簡単な事をするのにも面倒だね」という
見下した感じを少し受けるのは私だけだろうか。
モナドの仕組みを組む人たちは面倒というか、そりゃ大変だったろうけど、
それを活用する我々プログラマにとっては、全然面倒じゃない。
むしろ、逆に純粋関数型でこんな事もできる、と幅が広がる。
0442デフォルトの名無しさん
2013/03/03(日) 13:46:54.84それは目くじらを立てても仕方ないだろう
0443デフォルトの名無しさん
2013/03/03(日) 14:27:02.730444デフォルトの名無しさん
2013/03/03(日) 15:36:11.69みたいに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-代数同型射っぽいものが何か解らない
何か知ってる人教えてください
0445デフォルトの名無しさん
2013/03/03(日) 15:43:43.54だったかもしれない
0446デフォルトの名無しさん
2013/03/03(日) 18:45:44.23>>443は手続き型を見下しているようだが
おれは手続き型、関数型のどちらかを上とか下とか思っているわけじゃない
同じ土俵で見ようとしているだけだ
御利益を問われるのは当たり前のことだ。貴族じゃないんだから
0447デフォルトの名無しさん
2013/03/03(日) 18:53:37.82簡潔なコードが書き易く、静的型検査が強力で、
副作用のある部分と無い部分をキッチリ分離できる
そんな言語が、副作用のある部分を
手続き型と同じように書けるんだから
それだけで御利益あるだろ
0448デフォルトの名無しさん
2013/03/03(日) 19:03:27.10>>431 の
> 手続き型言語ではふつうにやることを
> 関数型でもできるように
という言い方がなんかなぁ、と感じる。
「ふつう」なんてわざわざ書く（しかもひらがなで）ところも、
なんとなく馬鹿にしている感じがしないでもない。
例えば、手続き型言語の構文を関数型でも使えるようにするデザパタか、
と問われるなら、べつに嫌な感じはしないが・・・
0449デフォルトの名無しさん
2013/03/03(日) 19:06:45.67手続きじゃない部分でもdo記法とか使えるのがMonadクラス
0450デフォルトの名無しさん
2013/03/03(日) 19:26:19.16それは悪かった。そんなつもりはまったくなかった。
しいて言えば、こっちがモナドに馬鹿にされてると感じてるかもしれん
0451デフォルトの名無しさん
2013/03/03(日) 20:30:33.90手続き型を見下してなんかいないよ
手続き型プログラミングと関数型プログラミングの間に存在するパラダイムの壁が認識できていないのではないか、ということだよ
0452デフォルトの名無しさん
2013/03/03(日) 20:42:19.78手続き型はもちろん、モナド込みの関数型でも、どちらのパラダイムも満足
できるものではないと思っている。だからパラダイムとか壁とかという表現も
なんだかなと思うのだ
0453デフォルトの名無しさん
2013/03/03(日) 20:53:23.10パラダイムに満足できるかどうかと、
パラダイムに違いがあるかどうかという事とは、
全く別の事だと思う。
それとも、両者のパラダイムに満足できなければ、
両者のパラダイムにたいした違いは無いという事になるの？
>>443 >>451 は、パラダイムにはっきりとした違いがあるのだから、
一方のパラダイムをもう一方のパラダイムの延長で考えるのではなく、
違いを認識して別物として考えないといけないのではないか、
と言っているのだと思う。
0454デフォルトの名無しさん
2013/03/03(日) 21:40:53.72>両者のパラダイムにたいした違いは無いという事になるの？
うん。第三のパラダイムから見ればそういうことになるね。
モナドだってそう思ってるんじゃないの？
0455デフォルトの名無しさん
2013/03/03(日) 21:42:49.12これに尽きるな。
0456デフォルトの名無しさん
2013/03/03(日) 22:09:28.85満足できるかどうかは個人の主観の問題だよな。
違いがあるかどうかは視点の問題だよな。
前者の結果によって後者が影響されるのはおかしくないか？
■ このスレッドは過去ログ倉庫に格納されています