#命令型言語だと思って見ると「xという変数に7を代入している」という副作用に見える。
#関数型言語だと思ってみると「xは7である」という定義ないし宣言に見える。
#前者なんだけど。それを「副」作用というとしたら、「副」ではないものがなにかあるのだろうか。
#純粋な命令型言語だったらなさそうな気もする。
#現実の言語だったらこれが7を返す式になってたりして、それが主作用なんじゃないかな。
#後者は、環境(変数と値の束縛の集合)の拡張です。これは環境をいじるという意味で副作用ではないのだろうか？
#つまりこれは7って書くのと同じなんだけどxにも7を代入してくれるよ、という式。
#ちょっと即答できそうにない。＞環境の拡張ゆえ副作用
#x := 7 はassignment が主で値は従じゃないのかしらん
#いや、そもそもx:=7が式であるという位置づけにある段階で純粋に命令的ではないので
#どっちを主としてどっちを従とするかは絶対的な基準はないんじゃないかなー
#環境を拡張せずに変更するのが副作用？
#いっぱんの命令型言語で「副作用」といったら、どのようなことを言うの？
#なにがしかの状態を変えるものを指すんじゃないでしょうか
#そのときの状態って何？
#なんだろう
#「どうして副作用がなくてプログラムが書けるのか？」という疑問はどこから来るの？
#そのとき副作用って何のことを言っているの？
#Cなりjavaなりでコードを書きますわな。
#はい。
#その時に、式と文ってたいていあると思うんですけど
#そのうちの式と呼ばれる要素だけでプログラムを組み直せを言われたら
#まずお手上げになると誰もが思うんじゃないでしょうか
#式は副作用がなくて、文は副作用があるということ？
#私の中ではそんな感じ
#文は何がしかの状態を変える命令文
#状態を変えることが計算
#式は値に簡約（変換？）される
#式を値に簡約することが計算
#だから副作用の「副」に重きはあまりないなー＞自分
#ううん。簡約なんて概念、SchemeやHaskellを知らないときに使ったことある？
#あくまで状態を変える命令を副作用と呼んでる
#状態ってなに？
#使ってないし、知らないときに式と文の違いは自分でも区別しようとしたことなかった
#それでも、副作用という言葉を知っていた？
#知ってた
#どういうときに副作用を気にしてた？
#代表的なのはやっぱりグローバル変数ではないかと
#それって、参照透明性の話？
#そうかもしれないです
#参照透明性の話と副作用とどう結びつくの？
#副作用があると参照不透明になるのでは？
#なぜ？
#副作用によってxの状態が7->9に変わったらxを使って評価しているものは変わっちゃわない？
#束縛のときとどう違うの？
#見える範囲が違いますね
#副作用とは状態の変更のことである。
#状態とは変数の状態である。変数の状態って何？
#中に入っているものじゃないかな
#中って？
#変数って何かを保持するコンテナのようなものですよね？
#変数は容れ物の識別子である？
#命令型言語で変数っていったらそうだと思うし、それで大抵通じるとおもう
#int x = 1; というのも副作用？
#Cのつもり
#うーん。どうだろう。副作用と呼んでいいと思うけど。
#このスコープで x は = の左辺にくることは一度もありませんでした。このコードにも副作用があるの？
#常にあるとは限らないよそりゃ。
#もしそのスコープで変更することがないなら
#const int x = 1と書くんじゃないかな。ちょっと潔癖なら。
#ともかく副作用があるかもしれないというのがグローバル変数を使ったときに気になる点なんじゃないかと思う。
#いや、いま言語の話であって、プログラミングスタイルの話じゃないよ。
#あるかもしれないというか
#たとえば命令型言語でバグったら
#そもそも、変数は容れ物だという主張なのだから、const int x = 1; でも副作用があるんじゃないの？
#ああそうですね
#じゃあ。なぜ変数は容れ物じゃなければならないの？
#どゆこと？
#変数は値についた名前。というのもありだよね。
#ええ
#今度はプログラミングスタイルの話だけど。変数は値についた名前だと思うと、Cではプログラミングできないの？
#そう思ってもいいんじゃないでしょうか。
#単にメタファの問題なので
#たとえば、簡単なプログラムで例をあげて。
#x = 1
#y = 2
#z = x + y
#とか？
#それって、C？
#ああ、セミコロンいりますね。
#それなら、変数は値について名前だと思っても、プログラムできたことになるよ。
#そりゃ何もできないとは思ってないと思うよ。
#出来る範囲もあるだろうと
#でも実際のプロジェクトで成果物を納品したときに
#できないものというなにか簡単な例なあい？
#仮にこれを式だけで書き直してって言われたら多分お手上げになる
#ループとか使って計算する例はどうでしょう？
#具体的に
#for (int i = 0, s = 0; i < 10; i++) s += i
#あれこれでよかったんだけ？ for構文なんてわすれちゃった。
#たとえば今仕事でやっているのだと
#あるWebサイトを生成するコードで、
#反復するものを書くにはループが必要、ループを書くためには容れ物としての変数と、その内容物という状態を変化させる副作用が必要である。
#こいつの中にファイルをアップロードできるコンテナのようなものを数百個生成するんだけど
#ループが必要になるのはCの事情だけどね
#そいつの権限というやつをコンテナ別に設定し直してやるコードがある
#でもって、そいつをサイトの内部に設置して保存するために更新処理を呼ぶようになっている。
#APIの設計も含めて、そういう発想で書かれるようになっているからではあるけど、
#ふむふむ
#そういう発想で考えている人からしたら、副作用なしでも書けるって言われても難しいと思うのは結構当然だと思う。
#自分で計算とは・・・などと考えられる学者さんは別なんだろうけど。
#ふむふむ
#でもそれって、副作用とは関係ないんじゃないの？
#なぜ？
#権限の設定しなおしとか、更新処理ってもろ副作用じゃん
#なんで？
#権限の設定しなおしも、更新処理もHaskellで書けるよね。
#だから？
#というより
#権限の設定しなおしがなぜ副作用と結びつくのかわからないので、説明してちょ。
#すみません。自分では当たり前にしか思えないので説明してと言われても困ります。
#それを副作用と呼んでいるからかとは思いますけど。
#権限のし直しが副作用ということは、権限は状態である。ということ？この理解OK？
#権限設定はコンテナの状態の一部である。というのはそう。
#権限の設定変更という操作で、手に入れたいものは、権限の設定が変更されたコンテナである。これOK？
#そうですよ。
#何を主張したいのか分からなくもないですが、私は命令型言語でしかできないことがあるなんて一言も主張してないので、そこんとこよろしく。
#命令型言語で、その考え方で慣れているプログラマに副作用なしでコードを書けと言ったらみんなそれは無理だと思うというのも理解できるなってだけのことを言ってますよ。
#わたしもそんなことを期待しているわけじゃなく。「副作用がなくてプログラムが書ける理由がわからん」という人にどのように説明すればいいかを考えているだけだよ。
#その考え方からすれば、どう説明してもダメだと思うのが現時点での私の考えだな。
#副作用がなくては書けないと思うこと自体変だとはぜんぜん思いません。だってそれしか知らないんだから。
#ええ。水泳と同じで、畳の上じゃわからん、泳げ！と。
#ある意味そう。
#水に入らないと分からないのと同じで、Haskellで書かないと分からないってのは当然あると思う。
#でも。水泳だってコーチがいて教えてくれるというか、アドバイスをしてくれるよね。具体的に。
#でも、それは水の中に入ってからの話ですよね。
#ああそういうこと。水に入らねぇボケには説明するだけ無駄？
#そのためにMicrosoftやらSUNなんかは膨大な広告を打っているんだと思う。
#説明の前に説明を聞いてもらう場を金で作っている
#暴言ktkr RT : nobsun: ああそういうこと。水に入らねぇボケには説明するだけ無駄？ http://bit.ly/4nBJxY #げっ。やば！
#少なくとも水の中に入らずに泳ぎを教えられるコーチはいない。
#プールに来てください。そしたら教えられます。
#なのですよ。
#Haskellを書きはじめた人に「副作用ないのにどうやってまともに前に進めるのですか」ときかれたら、どう説明するのだろう。
#それこそkazuさんが言ってたみたいに「やべぇ、モナディウスできちゃってるよ」と思わせるってことじゃないかなぁ
#そりゃ100m を1分で泳げるやつがいるんだから、そういう泳法なりなんなりがある。それはだれでもわかる。でも、問題はそれはどういうものか、どういう方法かということだよね。
#「モナディウス」できちゃってるよ。まではいいとして、そうおもった人に副作用云々をどう説明するか。
#よく IO = 副作用 という議論もあるんだけど、あれってどういうこと？
#副作用云々の議論の時に、厳密に副作用とはなんであるかを定義して議論できているのを私は知らないし
#実際今の場合もあいまいに私が答えて、なんとなく議論してますよね。
#正直副作用がなくても書けるということを説明しなくてもいいんじゃないかと。
#水に入ってもらうのが目的なら「モナディウスできちゃってるよ」で良いと思うんですよ。
#水に入ってきたところから説明するなら
#副作用云々はおいておいて、「やりたいこと」をHaskellではこう書きます。
#そのどこを副作用と呼ぶかは知らないけど、とりあえずこれでOK。
#あなたがこれを副作用と呼ぶとしたら、その副作用というやつはHaskellではこれで実現できる。
#もちろん、副作用なしでゲーム書けますか？と尋かれているなら、つ Monadius でいいんです。副作用なしで、どうしてゲームが書けるんですか？という問いに答えようとしているのです。それで、どうして副作用がないと書けないと思うのか？あるいは、何を副作用と思っているのか？という純粋な疑問があって、それを知ればすこし説明ができるかもと思ったのです。
#いや、たとえば、副作用とは入出力のことであるとか、画面描画は副作用だと思っているとしたらどうでしょう？
#そういう定義なら副作用なしではMonadiusは作れないですよ。やっぱり。
#そうですよね。ということはHaskellのありがたみは副作用とは無関係。参照透明性にある。ということにしよう。
#というのでいいのかしらん？
#手法をひとつしか知らないと、手法と効果が別だと認識できないからわからない、ってことかもよ。「副作用」が厳密には何かは知らないけどある手法を副作用と言うってことは知ってて (例えば、Schemeで (begin X1 X2 ... Xn-1 Z) のX1, ... Xn-1 に書いて意味のある式は副作用を持つ式だ、とか)、ある効果をもたらすのにそういう手法を使うことは知ってる。で、他の手法は知らない。だから副作用無しで書けるというのがわからない。
#同型のロジックとして、サブルーチンというものを知らない人は「goto無しで意味のあるプログラムが書けるとは思わない」かもしれないし、組み木というものを知らない人は「釘やネジなしで棚を作れるとは思わない」かもしれない。
#副作用不要を納得させるには、なくても書けることを示せばよい。というのはなっとく。さらに「副作用」と呼んでいたものは何で、その役割はなんだったのか、あるいはそれは抽象の高みから見ると何に見えるのかは知りたいとおもう。
#うーん、抽象の高みから見たらimplementation detailになっちゃうんじゃないかなあ。チューリングマシンのモデルに書き換え可能な磁気テープという具体物を考えてるような話でさ。(参照透明でもチューリングマシン書けるけど、おおもとのアイディアは物理的に書き換え可能なテープって具体物でしょ)
#(ありゃ。chaton_haskellへのtwitter postがover daily limitで蹴られてる。そんなに盛り上がったかね。)
#抽象の高みってのを誤解しているかもしれないけど、たとえば仮に副作用が「変数への代入」だとして、命令型言語で何を実現するために「変数への代入」があって、関数型言語ではそれをどんな概念によって実現しているのか？というのはマッピングできてもよさそうに思うし、説明はしやすそう。
#でも「何をするためか」ってのが非常に難しそう。
#たとえば「状態を書きかえるため」って言っちゃったらその時点で命令型言語に特化しちゃう
#かといって「計算するため」とまで言っちゃったらなんか意味ない
#一体「何を実現」するために「変数への代入」というテクノロジがあるのでしょう？？
#うーん、「変数への代入」については「何のため」という目的指向というよりも、下層にある機械のモデルがそのまま滲み出て来てるだけなんじゃないかなあ。言い換えれば歴史的経緯。
#まーやっぱりそうなりそう ＞ 下層のモデルがそのまま
#つまり「計算」が「マシンの状態を書き換える」ことだというのが直接反映されている
#ということは、そういう脳の人には、G-machineとかの説明するのかしらん。
#ところで、命令の人が、入出力＝副作用とよく言うんだど、これは入出力＝計算機と特定のアドレスの状態を変更することを指して言っているの？それとももっと別のものを指してるのかしらん？
#抽象の高みからみれば、副作用は実装の詳細にすぎない。副作用はプログラミング言語処理系の実装の話であって、プログラミング言語でプログラミングすることとは関係ない？ああそうか、下層にある機械モデルが滲みでてきているというのは、プログラミング言語処理系の実装の詳細が抽象化されずにプログラムの記述に影響するということか。
#入出力の場合は外界の状態を変更してるんじゃないのかな。そうすると外界は何かって話になるか。計算が見ている世界の外。メモリアドレスの場合は一応モデルの中の話ではあるけれど、プログラムの字面に陽に現れないから、メモリという対象が計算の外に客体として存在している、って感じなのかな。
#出力に対しては世界の状態の変更というイメージはなんとなくわかる。入力に対してはどうだろう？
#外界の状態、計算が扱う世界からは触れられない何かが侵入してくる。「状態の変更」というのは正しくないかも。「状態の影響」というべきだろうか。
#effect か。
#副作用というのを、「可能性の切り捨て」あるいは「縮退」とみるのはどうだろう。メモリにせよ外界にせよ、それを計算のモデルの中に取り込んでしまえば形式的に参照透明にすることはできる。ただ、計算モデルの中ではある時点のメモリの状態を保存しといて後からリスタートすることはできるし、ある時点の入力にあらゆる可能性を認めることができる (
#[
#「もし入力がこれじゃなくあれだったら」として計算の再出発が可能)。
#でも現実世界ではスナップショットを取ってリスタートすることができない。そこであきらめてしまう、というのを副作用と呼んでみる、とか。
#非決定性をあきらめるメカニズム？
#Control.Applicative というライブラリの元になった "Applicative programming with effects" http://www.soi.city.ac.uk/~ross/papers/Applicative.html という記事があるんですが、このタイトルの applicative programming というのはいかにも、non side-effect という感じなんですが、with effects の方の effect というのがどういうニュアンスなのかいまひとつピンと来ていない。 #Conal の名言 : Every expression in Haskell denotes a pure value, only some of which
are functions (have type a->b for some types a & b). : http://www.haskell.org/pipermail/haskell-cafe/2008-December/052642.html
#あれ、pre になっちゃった
#まあいいか。
#Haskell にはあらゆる side-effects がない via What Haskell matters. : http://www.haskell.org/haskellwiki/Why_Haskell_matters #Why だったが、まあいい
#'with effect' ってのは、その論文の Introduction にある sequence の実装のリストの case 分解の [] じゃないほうの説明みてわからないかなあ
#べつに IO じゃなくてもいいんだけど、モナドならなんでも。
#モナドが effect を隠蔽するメカニズムなんですよって、どこかに書いてないのかな。探したら G. Hutton の "Programming in Haskell" Chap. 8-9 だった :-)
#英語のニュアンスが読む能力がないので、sequenceの説明では effectual computation がモナドで表現されたものであるという対応はわかるけど、effectual のニュアンスが読めない。orz
#んーむ、Applicative (Monad より弱い規則で effectual computation) を使える人が、そこでなやむのがふしぎだ
#定義が ambiguity になっているのではないだろうかと推測
#あいまいさを回避するページをあたまのなかにつくろう
#nobsun の chaton ブリッジからの発言が反映されない件
#effect とか side-effect とか：定義
#ん? nobsunがtwitterで発言したのがchatonに来てない? twitterのアクセスで何度か503エラーが出てるからそれでロストしたかも。
#chatonからtwitterについてはover daily quotaで蹴られたりしてる。
#なるほど。
#himaの準備にchatonを立てようとしたら、また、へたやってる。ひとつき程まえに動いたはずのものが、うごかん。なんかへんなことしたらしい。メモどおりやったんだけどなぁ。orz
haskell-ja > Archives > 2009/12/10