「「What Is Functional Programming? に対する反論」を読んで考えたこと」に対する反応
何か一々記事まで書いてもらったので、一応…
関数の外部から書き換え可能で、関数の内部から参照可能なmutable変数は、関数への入力として使うことができる。（このような入力を副原因という。）
副原因という、特に有用性のない（私感です、詳細な理由は後述）term をこれ以上使うのは止めて欲しいです。正直元記事に対する一番強い気持ちはこれです。
関数の純粋性を副作用（side-effect）を引き起こす（cause）もの、というと長いですが、前回の記事から参照した中野先生のスライド見て貰えば分かる通り、そもそも元記事で副原因（side-cause）と呼んでいるものは、「定義次第では」副作用に含まれます。
120901fp key from ksknac
www.slideshare.net前回の記事でも言った通り、ページ指定したリンクを貼ってもそのページは埋め込めないようなので 27 ページ、また 27 ページで参照されている各種 url を参照して下さい。
関数への入力として使うことができる。
関数への入力は、数学的にもプログラミング的にも引数を指す語として定義されるべきでしょう。認識の相違ですね。ここの認識に相違があったこと初めてなんですが。
元記事や id:mandel59 さんの主張通りに入力を引数以外も含むものとして定義していいなら、例えばプログラムを実行する時間であるとか、そういったものまで入力と解釈することが可能になるのですが、それでもいいならどうぞ、というところです。
多角的に物を見ることは大事ですが、定義が複数あればうれしいかというと、そんなわけはないという話です。腕時計を二つ付けたら、どちらを正確な時間をどうすべきか困りますね。比喩として昔ウェブ上で詩人をしていた人のポエムを使わせていただきました（ランダムにポエムが表示されるので見たい場合は表示されるまでリロードしてください）。
ここで言っている「環境」って、何を指しているんでしょうか？
環境という語は明確な定義をもってして使ったわけではありません。これはプログラミング言語の仕様として環境が定義されているものもあればそうでないものもあるとかそういう事情です、というのは今取って付けたもので環境も通じない人間いないでしょという気持ちで書いてただけです。ということで「一般的によく言われる環境」くらいの意味です。それでは足りないといわれるなら、R5RS の 14.4 辺りの定義に従ってください。
こういう場合も「暗黙的に環境内の変数を参照する」に入るんでしょうか？
前述の R5RS に従えば入ります。入らない「環境」の定義って存在するんですか…？side-cause みたいに作ればその瞬間から存在するでしょうけど…
このくだりはほとんど意味が分かりません。
すいませんがここが分からないのは完全に Ryuusei さんの勉強不足なので勉強してください以外いうことないです。環境に対する理論的な理解も実行時の実際の挙動の理解も足りてないように思います。もしくは理解しているけれど理解していない体で書いてる？いやなんというか、ここ理解できないレベルの人に何か言われたりしないだろうという気持ちがあったので、正直「意味が分かりません」と id:mandel59 さんに言われると全く思っていませんでした。
そもそも書いてもいないことを突然やりだしたように見えます。
一例目は「環境」を言語から触れるようにした例なので、環境の話の文脈からのコード例としては妥当だと主張したいです。
二例目はやりすぎました、無視していいです。
揚げ足取りに見えます。
「このコードに副作用が生じる可能性がある個所はどこでしょうクイズ」の定番なので、副作用の話をしておいてここスルーはないです。せめて前提に陽にその箇所には副作用はないと書いてもらわないと困ります。
これは理論がどうとか抜きに「実務的に」困ります。この関数は純粋ですよとかいって高階関数書いておいて渡される引数の関数が純粋である保証、もしくは precondition をドキュメンテーションなどしていないコードとか書かれたら、普通に困ります。本当に困るので三回書いておきます、困ります。
まあ正直揚げ足取りですと認めてもいいです、どうでもいい。ただ「より注意深く観察すると、ここにも副作用が潜んでいる可能性はありますね？」ということが、ボクの記事を読んだ人間に伝われば、それでいいです。
この定義では、副原因を持たないが副作用を持つ、次のような関数を除外できないのでダメです。
すいません自明すぎて書き忘れました。これは自分の凡ミスです。暇なときに修正します。
ほぼ同じこと言ってますよね
その通りですが全く同じではありません。
まず大事な点として副原因という term は使っていません。純粋性を「副作用をまったく用いない関数型プログラムないし関数型言語を純粋」と定義し、副作用を「「式の値を計算して求める」（評価(evaluation)と言います）以外の動作」と定義していることから分かるように、副原因と呼ばれるものを副作用の一部と認めても良い（陽に認める形では書かれていないが、定義からはそう解釈することができる）ものとして定義しています。ということでまずここが違います。
第二に関数の「入力」について、元記事とは違い「入力を引数、出力を戻り値とする関数を考えることにより」とあるように、明確に関数の入力を引数として定めています。
こういう説明が簡単にできるようになるので、「副作用」と「副原因」を区別するのは有意義だと思います。
前述した通り副原因という term を勝手に作られるのに対して非常に否定的です、有意義だとは思いません。前述したように、副作用の定義の中には副原因と呼ばれるものも副作用とするものが既にあるので、単に混乱させるだけの可能性があるからです。
以上です。
