第一に、それは、ストリーム(FRPの値の定義)の問題であって、ユニットテストすれば良い。もしくは単にFRPのログを取れば良い。
グローバル変数ではそういうことはできない。FRPでは、岡部氏のFRPライブラリも特にそうだけど、基本的にミュータブルな値同士が関数でリアクティブに連携されて常に整合性を保っているのだから、グローバル変数の、各所で更新されたそれぞれの値によって全体の整合性が損なわれないように気を配らなければいけないという(テスト自体困難な)問題は発生しない。それがFRPの唯一とも言えるメリットだとも言える。
使用する関数の問題じゃないし、「印」として引数に加えても別に構わないと思うが、君のいうグローバル変数の問題と一緒というのはまったく違う。
いや、それがそもそもの発端であるとブログの経緯には書かれている。説明されている方式でGUIアプリまで書けるのか?と疑念が呈されたことがきっかけ。
この論点は聞いたことがない。岡部氏がこだわっているのは非手続き型の宣言型で、純粋がどうとか議論はされてないように思う。
あと、OCamlでGUIを状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね?
原理的に可能かという議論ではなく、実用的な範疇か?という議論。反対派ブログで出てきたコードは、本人が認めるように普通のやり方ではなく、実用的なコードだとは思えない。あと、FRPと状態渡しは同じ複雑さだという主張も崩されている。そこが重要。
段階を踏んだ上で、非FRPのHaskellのIOモナドのコードを誰かが書いたらいんじゃない?当面、最初はOCamlの話だったのに、いきなりHaskellやElmのコードで書いて、そういうのがごちゃまぜに、何がどの言語でできるのかできないのか、誤魔化しがあると見做されたから制限されたんでしょ。実際には、OCamlの関数型では冗長でしか書けないと実証されたけど、そういうのがバレないように、別の言語を利用していたと看破されて当然の状況だと俺は思うね。
FRPライブラリのサブタイトルに、 library that provides first class reactive value 'over time' と書かれている、これ拡張じゃないのか? 拡張なら「関数型的じゃない」っていわれたら「関数型を拡...
拡張なら「関数型的じゃない」っていわれたら「関数型を拡張してるから」って答えればいいだけの話 関数型という枠組みを拡張しているのではなく、関数型という枠組みの中にミュ...
関数型という枠組みの中にミュータブルな時間要素が純粋に収まるようにしているのがFRPだろ。 ストリームを関数の外部に持つFRPを純粋関数型っていうのは少数派でしょ。 関数の結果...
ストリームを関数の外部に持つFRPを純粋関数型っていうのは少数派でしょ。 否。ストリームに限らず、定数は引数で与えなくても純粋関数型である、という見解はごく普通。 http://stac...
否。ストリームに限らず、定数は引数で与えなくても純粋関数型である、という見解はごく普通。 定数って、プログラム中で更新不可能で、いつ読みだしても同じ値が出てくるから、...
バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ? それであるならば、「印」として引数に加えても別に構わないと思うが、君のいうグロ...