#モナドに走らせるというイメージがあんまりないなぁ．
#しいていえばState系だけかなぁ．
#ちゅうか．s -> (a,s) のような関数をラップしたものだけのイメージかなぁ．
#そうです、runState的なものですね。
#モナドをプログラム（手続き）とすると、(>>=)はプログラムの組み立て、run関数はプログラムの実行、という様に考えられます。
#STMではrun関数はatomicallyだったり、STではrunSTだったりしてそれぞれ非常に明確な意味を持ってますよね(forall x. m x -> n x)。 むしろrun関数が無いIOやMaybe, Listモナドの方が特殊と考えた方が分かり易いと思ってます。
#もちろんMaybeとListはパターンマッチがrunに相当しているので、wrapすればrun関数を明示的に扱うことは出来ますし、実際MonadTransではそうなっています(runMaybeT, runListT)
#もうrun関数でいいですかね...
#あ、函数型なんたらでの説明に使おうと思っているだけです。
#runなんとかって，データ構成子を剥すだけのものじゃないかしらん．
#newtypeの場合はそうですね。一般的にはそうではないと思います。
#一般にそうではないのですか．．．
#MonadTransの場合、モナドを単にwrapしたものが多いですから剥がすというイメージはありますけど、先の例STM, STは
#atomically :: STM a -> IO a
#runST :: forall s. ST s a -> IO a
#というのは何かを剥がしているわけではないですよね
#STとIOならむしろSTの方が一般的なモナドですし
#ああそういうことですか．run
#それだとモナドを走らせるというイメージがないような気がしますが．．．
#なにがしかのモナドから実行可能なコマンド(IO a)を作るというイメージではありますが．．．
#走らせた際にIOを作るというモナドもやはり一般的ではないです
#new A a = A { unA :: IO a }
new B a = B { unB :: IO a }
runAtoB :: A a -> B a
runAtoB a = liftIO $ unA a#「走らせるの」意味が私としては固定できない感じでいます．
#例えばこんなのですね
#まあ詰まるところはその名前は割とどうでもいいのですけど、「プログラムを走らせる」という意味合いは悪くはないなあと思ってますね
#STMはatomicallyにプログラムを走らせてくれる、とか。
#それならモナド一般ではなくて，IO a に変換するというところに限定して「走らせる」といってもらった方がよいような気がします < 個人の感想ですが．．．
#run :: forall x. m x -> n x という関数は、 m というプログラムを実行して、n というプログラム上へ埋め込んでくれる関数と見なすことが出来ます。
#モナドをDSLとして捉えたとき、全てのモナドはプログラムとして扱われます。その場合、任意のモナドについて「走らせる」という表現は特におかしくはないと思いますね。
#「プログラム」「実行」の意味がひろすぎませんか？(まちがっているという意味じゃないです)
#foo :: Monad m => m x は m というプログラムの実行 foo を表す？
#いえ、fooはプログラム m 上で結果 x を得ることを意味します
#プログラム m の実行とはなんでしょう？
#runM :: m x -> n x (ただし n /= m) の適用ですね
#runM を「プログラム m 上で結果 x をうること」に適用することをプログラム m の実行という？
#ということですか？
#m ≠ n という限定はなぜ必要なのですか？
#そうです > runM を「プログラム m 上で結果 x をうること」に適用することをプログラム m の実行という？
#> m ≠ n という限定はなぜ必要なのですか？
#言われてみると要らない気がしますね。
#run :: m a -> m a
#run = id
#になってしまうから意味ないと思ってましたが、別にidになることは自明ではないですね。
#ついでに，Monad m, Monad n という限定はなぜ必要ですか？
#今はモナドをDSL(プログラム)として扱おうとしているからですね。有用ならば限定する必要は無いでしょうけど、今回の僕のプレゼンはモナド限定です。
#なるほど，そもそも議論の対象はモナドだからということですね．
#はい。この辺りの考えをベースにモナドのエンジニアリング上の意義を延々と話すつもりです。
#apply と区別するのは run :: m x -> n x であって run :: m x -> n y ではないからですかね．
#そうですね、それは全くの別物に見えます
#ポイントはapplyとrunの区別なんですね．
#プログラム上のプログラムの埋め込み(DSL)として捉えるなら、そこは重要かと思います。
#「モナド = EDSL と見做して議論する」と理解しましたがこの理解のしかたであってます？
#合ってます。
#DSLと聞いて
#よかった．面白そうな講演になりそうですね．> ruicc さん
#参加できなくて残念
#アドバイスありがとうございます。スライドまだなのでがんばって作ります..
#(他の方もツッコミあればどうぞ)
#モナドをEDSLと見たとき、それはDSLとして意味的に適切な抽象なのかが気になりますね。
#モナドはモナド則を満たすモノなわけですが、それがDSLとして適切かどうかということですか
#もしくは「DSLはチューリング完全であるべきではない」といった誰かの言葉を考慮してますか
#一部のモナド（インスタンス）はDSLとして適切であるが、全てのモナドがDSLとして適切ではないかもしれない、と言う意味ですかね。
#DSLとして適切かどうかですね。「DSLはチューリング完全であるべきではない」は個人的にはドメインに依存すると思うので、そこは考慮していないですね。ある意味、EDSLとして設計がどのぐらい自由なものか、と言ったものでしょうか。
#DSLの適切さとはなんでしょう。特定の問題に対して特定のモナドがDSLとして適切かどうかという話なら分かります。
#あ、適切な抽象かどうか、ですか。意味合い間違ってますかね。
#あれ、ドメインに依存せずにDSLが適切かどうか、か。
#なんか混乱させてすいません、シンプルに言えば、DSLとして見たとき、「モナド」ぽさを消せるかといったところでしょうか。ドメインに依存せずは、「チューリング完全であるべき」との回答なので、DSL自体はドメインに依存しますよね。
#すると思いますね。ドメイン非依存とするとモナドのインスタンスであるという情報しかありません。
#ドメイン非依存としてDSLはありえないので、そういうことでは無くて、チューリング完全な適切な抽象のDSLもありえる、って話がしたかっただけですね。
#「DSLにモナドぽさが残っていると適切ではないのでは」という意見ですか。
#モナドぽさを消すことは今のところ考慮はしてないですね。外部DSLならHaskell非依存な構文を持っているべきかもしれないですけど、今回はEDSLを考えていますし。
#「DSL使用者に学習コストが高くなり過ぎやしないか」ということですかね。
#ただ良く良く考えれば、それはモナドでは無くHaskell言語自体のにあるのかもしれないですね。
#現状プレゼンの構成としては、IOモナドを使えるを前提として考えてます。
#もちろん一般には中には使いづらいDSLを構築出来てしまうとは思いますが。
#個人的にはJSのjQueryのようなものを考えてました。
#モナドの記述の自由さが、Haskellの低レベルコードを抽象化し、新しい意味付けをして、非Haskellerでも書きやすさをもたらすことができれば良いのかなと、最近思っています。
#なるほど。そういう道もあるかもしれません。
#今のところ考えているのは、jQueryよりもさらに狭いDSLです。
#今回のプレゼンは、Haskellerがモナドを用いてどうやって設計すればいいか、その考え方の提案という様な形ですね。
#HaskellerがHaskellerのために、モナドをどう設計するかで、ある意味それはEDSLを設計するのを念頭に置くと良いってことなのですかね?
#あと、すいません、途中から見たので、流れから、プレゼンをするというのは分かってますが、いつどこでやるなどの詳細が分からないので、教えてくれませんかね?
#そうです、EDSLを武器の一つとして設計しましょうという話です.
##これです、今週の土曜日ですね。
#なるほど、行けないですね....
#まあスライド見れば理解出来る様にはしたいなあと思ってます。
#あとニコ生があるとかなんとか
#それはありがたいですね。
#Maybe を走らせる関数は maybe と言います。
#なるほど、そうですね。
#純粋なモナドの場合は run :: m a -> a ですかね。
#List..
#atomically 以外に ma -> a ではない実行関数ってありますか？
#そう考えると、リストも特殊かも。
#m a -> a は m a -> Identity a だと思えばよいような．．．
#あ、それがきれいですね。
#extract :: Comonad m => m a -> a というのもあって．．．そうなるとちょっと広がりすぎますね．
#Comonadも興味深い対象ですね。後でComonadもMonadと同様にどれだけ便利かというところを考えたいですね。
haskell-ja > Archives > 2014/10/23