関数型で実用的アプリが書けるか?関数型プログラミング(OCaml)の「状態渡し」は実用的アプリの実装に耐えうるか?というテーマで連中が嘘誤魔化しばっかりやらかしてるから、耐久テストしてあげてるんですね。Xなんで、アウトです。いう連中は悪質ですから、Xなのにまるで◯のように偽装します。Xの言い訳がこれです。今回は「状態渡し」すら要らないので「お絵かき」より簡単。何をさせたかったのかまったくわからない。いやいや、「すら要らない」って、こっちは、「状態渡し」で書けと縛りをかけたんだ。何をさせたかったのかまったくわからない。関数型プログラミング(OCaml)の「状態渡し」は実用的アプリの実装に耐えうるか?ということ。わかってるよね?さらに言い訳が続きます。別の人も指摘しているとおり、以前の「状態渡し」のほうがOCaml上のGUIアプリの実装としては異常。書けないとか言うから反例として書いただけ。あのさ、例の@nonstarterは、こう書いてるんだ。『関数型プログラミングに目覚めた!』のレビュー(Day-1)追記(2015/05/30):デスクトップアプリケーション??(当該の記事で著者がOCamlで「お絵かきロジック」を実装してみせよと要求する一方で自身ではJavaScriptによるそれを公表していない点も気になります)。OCamlであれHaskellであれ破壊的代入の類の副作用を使用せずに書くのもなんら困難ではありません。(追記:コメント欄にてyataketa9056さんに、既存のGUIライブラリを前提にスケールするコードを書こうとするとOCamlでは困難であろうという指摘を頂いています。利点はともかくHaskellと同じようにモナドを利用したライブラリを作成するなら純粋な関数型でのプログラミングも可能になる(けれどもOCamlプログラミングとしてはわざわざそのようなことをしても嬉しくはない)ということになります。いえ原理的に不可能でないのなら(そして不可能でないので)、純粋な関数プログラミングでGUIアプリケーションを作成するのにFRPがなんら必要でない、という趣旨には充分です。この主張自体はHaskellでのコードによっても充分に示されています。)いずれにせよ、状態機械の数学的構成では状態遷移が状態と入力から状態への関数として表現されるというだけのことではあり(状態渡し)、状態遷移が複雑になれば状態遷移を純粋な関数として表現する作業も複雑になり困難になるので(そしてそれはしばしば綺麗な関数合成では上手くいかないようなものになることが多いので)、結局のところ少なくとも現状のFRPも(イベントのシグナルから状態のシグナルを構成する際に状態遷移をそうした関数で表現する必要が出てくるので)本質的には銀の弾丸にはならないと言わなければなりません(関数プログラミングで書けるということの恩恵はもちろんあるとしても)。OCamlであれHaskellであれ破壊的代入の類の副作用を使用せずに書くのもなんら困難ではありません。純粋な関数プログラミングでGUIアプリケーションを作成するのにFRPがなんら必要でない、という趣旨には充分です。いずれにせよ、状態機械の数学的構成では状態遷移が状態と入力から状態への関数として表現されるというだけのことではあり(状態渡し).....結局のところ少なくとも現状のFRPも(イベントのシグナルから状態のシグナルを構成する際に状態遷移をそうした関数で表現する必要が出てくるので)......らしい。関数型(状態渡し)で書けるらしい。FRPが関数型プログラミングで、なんら必要でないという「趣旨」を示すために、(状態渡し)に固執しているが、でもいちおう(状態渡し)の限界を別のひとから指摘されたから、それは一応発言する、でもなおFRPはあくまで否定。もってわけのわからない理由で。以前の「状態渡し」のほうがOCaml上のGUIアプリの実装としては異常。嘘ごまかしだというんだ。?OCamlは非純粋関数型なので、普通は副作用(破壊的代入を含む)を使う。FRPを含め、純粋関数型のGUIプログラミングがしたかったらHaskellのライブラリなりElmなり、それ用の適切な道具を使えば良い。追記(2015/05/30):デスクトップアプリケーション??みたいな、「状態渡し」で書ける、FRPがなんら必要でない、という趣旨には充分だ、と宣い、あたかもこちらが間違った主張をしているように「見せかけた」。君はその頃から、?OCamlは非純粋関数型なので、普通は副作用(破壊的代入を含む)を使う。FRPを含め、純粋関数型のGUIプログラミングがしたかったらHaskellのライブラリなりElmなり、それ用の適切な道具を使えば良い。いう知見をもち、発言の訂正を促したのかい?君がそのブログで書いたのは、@nonstarterの主張を擁護すべくOCamlによる関数型「状態渡し」のお絵かきアプリだ。以前の「状態渡し」のほうがOCaml上のGUIアプリの実装としては異常。おいおい、冗談だろ?(苦笑じゃあいったい何が、OCamlをもって、関数型で実用に足るGUIアプリの実装として適切で正常なんだ??はい、その言い訳が続く書けないとか言うから反例として書いただけ。@nonstarterの「趣旨」は、もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用を使用せずに書くのもなんら困難ではありません。純粋な関数プログラミングでGUIアプリケーションを作成するのにFRPがなんら必要でない、という趣旨には充分です。?これ誰が読んでも、「ああそうか、OCamlで状態渡しでなんでも書けるんだ」って思うだろう。このとき誰が以前の「状態渡し」のほうがOCaml上のGUIアプリの実装としては異常。なんてことを思うんだい?「書けないとか言うから反例として書いただけ」?嘘こけ。総体として、とにかく、@nonstarterの援護射撃をして、岡部が間違っているという「印象」を拡散できればそれでよかったんだろ?そういうのが、悪質で、嘘ごまかしだっていうんだ。OCamlは非純粋関数型なので、普通は副作用(破壊的代入を含む)を使う。FRPを含め、純粋関数型のGUIプログラミングがしたかったらHaskellのライブラリなりElmなり、それ用の適切な道具を使えば良い。うん、つまりOCamlで、関数型のGUIプログラミングをするには、不適切であると。Qiita住井@東北大の例のFAQにもこう書いてある。それだと入出力や状態(state)すら表せないのでは?いいえ、純粋な関数型プログラミングでも、入力を引数、出力を戻り値とする関数を考えることにより、入出力も表現できます。hogehoge!と出力する、みたいなプログラムを書くことができます。同様に、状態(の変化)についても、古い状態を引数として受け取り、新しい状態を戻り値として返す関数により表すことができます。この人物はOCamlのプログラマーであるが、関数型のおすすめの本としての各種教科書には、そのまさに、「普通は副作用(破壊的代入を含む)を使う」デスクトップアプリの例ばかり書かれていた。おかしいだろう?といえば、この@nonstarterの状態渡しバンザイ、FRP必要なしネガキャンが不当に巻き起こされた。「岡部のいうことがまちがっていた」という印象のみを拡散することにやっきになり、集団的に「お絵かきアプリが関数型で書けない」「破壊的代入だ」だのそういうことばかり喧伝していた。君らは嘘つきなんだよ。誰が割りを食う?読者だろう?真面目に勉強したい初学者たちだろう?恥をしれよ。いう嘘誤魔化しをやめろ、と。わからないですかね?自覚あるでしょ?ここでの命題は、極めてシンプルで明瞭で、それはただひとつ。関数型プログラミング(OCaml)の「状態渡し」は実用的アプリのコードに耐えうるか?それだけ。「状態渡し」では書けなかったということでよろしいですね?逆に言うと、こちらががわざわざ手間をかけて、こういう連中の嘘、ごまかしについて指摘してやらないと、そのまま「逃げ切る」つもりでいるわけです。私、岡部が、この一連の国内の自称関数型コミュニティの連中による嘘、ごまかしを指摘する。私がアホらしくなって、放棄するのを待つこんなところでしょう。実際に3の私がアホらしくなって、放棄すれば、連中の逃げ切り勝ちです。嘘、ごまかしを拡散したまま、読者に嘘ごまかしを信用させ、正しい批判を加えた岡部が間違っていると思わせ、自分たちの嘘、ごまかしが正しいと信じさせる。自分から要求した「お絵かき」の「トイプログラム」すら1年もかかって自称FRP(実際にはFunctionalですらない命令型プログラム。「自分から要求した」とか、1年もかかって、とかいう要素は、上記の、この悪質な人物が、単に嘘誤魔化しを延々と続けてきたという上記の話なのでおわり。自称FRP(実際にはFunctionalですらない命令型プログラム。哲学とか時刻とか理屈をこねたり過去の値を保存したところで、ユーザから見て命令型の非単一代入であることに何ら変わりはない。これだけど、もう馬鹿に何度同じ話をしても同じだと痛感。「あーあー都合の悪いこと聞こえない」と理屈もへったくれもなく、よりによってFRPについて「時刻とか理屈をこねたり」などと平気でいうオバカさん相手にはどうしようもないです。ちなみにその保存のしかただとJS処理系がガベコレできないのでメモリリークします。)でしか書けないのに、また他人に実装を要求する正当性は1ミリもない。いう悪質な相手の「ちなみに」は、自分が上記のような理屈もへったくれもない、デタラメをまきちらして、説得力のない文章を書いてる直後に出るのが常套手段(この人物に限らないパターン)なので、最大限の注意が必要。本論と関係ない、次に、主張の信ぴょう性がない。「メモリリークします」ってあほかと。FRPは、たとえば、こういうTODOリストなど、全部のデータが必要な場合、そんな、FRP値が処理系によって知らない間にガベコレされたら、それは単にデータの損失なの。わかるかな?わからないかな?最後に、また他人に実装を要求する正当性は1ミリもない。別に君に実装を要求した覚えはない。自分で、ご指名ではないけど久々に書いてみました。OCamlもJSも詳しくないので細かいことは知らない。(追記:入力消すの忘れてたので修正。)ひまだから、やってやったみたいなポーズでしゃしゃりでてきたんだろう?しかも、すべて、例題が単純であることをよいことに、できないことをあたかも簡単にできるように見せかける誤魔化しという連中の一貫した悪質な手口。「状態渡し」では書けなかった今回は、きっちり宣言したとおり、「状態渡し」で書いたら複雑になるように、問題設定していたが、「状態渡し」でも書けるという問題の単純さを悪用し、「状態渡し」で書いたら複雑になる、と痛感したがゆえに、ルール違反の「状態渡し」なしので書いて、しかも、それが例外的、異常な実装だと言い訳し、前回まで状態渡しで、nonstarterを擁護していたのは、「反例」だから、とまた言い訳する。他人に実装を要求する正当性は1ミリもない。いうのは、上記のような自己都合で「状態渡し」なしのルール違反をした「状態渡し」のコードが書けなかったことを後ろめたいと自覚しているから、最後っ屁で、ルール設定にいちゃもんつけてるんだね。「OCaml」で、関数型で、実用的なアプリを、状態渡しで、FRPなしで、書ける!とさんざん反論していたのは、こちらでなく君らだから。内容をろくに管理も保存もなにもできないのは自明で、実用的ではない。「状態」を扱えば煩雑になるとわかりきっているからそこから逃げて、誤魔化してこう書いたわけです。今回は「状態渡し」すら要らないので「お絵かき」より簡単。何をさせたかったのかまったくわからない。君らの誤魔化しを一個一個潰すことをしたい。わかってるくせに、「状態渡し」で書けない卑怯な言い訳をして、あたかもこちらのせいにしているようなので、より「状態渡し」で書けるのか?というのを明確にするように、この延長で、もう一段、例題のハードルをあげてやることにしましょう。「状態渡し」をもって書けという条件でしたので、この人物は、この条件を満たせなかった、つまり課題をクリアできなかった、ということを確認しておきます。状態を扱うしかないように、アプリを少し複雑にしてみます。状態渡しでは煩雑にしかかけないようにハードルを設定する。スケールするように喧伝している誤魔化しがある。問題を複雑にしていってその誤魔化しの延長線上で、そのアプローチが破綻しないか?スケールするのか?そういうことを確認しているにすぎない。複雑になったら通用しない、破綻する、ならそんなもんは「机上の空論だ」そういうことを言っているにすぎない。本質とずらす、議論のすり替え、ひとりが誤魔化す、あとの連中はその嘘、誤魔化しに気づいているが沈黙、そういう手口。その嘘、誤魔化しによって、あたかも、まるで、私、岡部のほうがいい加減なことを主張している、と初学者をはじめとする真摯にプログラミングを学びたいと考えている衆目、読者にむけて印象づけようとする。こちらが黙っていると、「真理」について割を食ってる広い読者の犠牲のもとに、自分たちがただしいと嘘をついたまま、有耶無耶にしようとする。やっていろいろ突っついてやると、そのうち必ずこの誤魔化している連中の馬脚が現れます。「状態渡しで書け」ときちんと明示してるのに「状態渡しなしでも書けるから、状態渡しで書く必要がない」という論理をすり替えを無効化する。そんな誤魔化しは許容されるはずもない。あたりまえだろう?「状態渡しでは書けない」あるいは「状態渡しで書くことは困難で煩雑である」という論点に、改めて引き戻すことになる。なんで、こっちがこんな明確化をわざわざせんといかんのか?それは君、君らが、誤魔化しをしているからだろう?ということです。バレるような嘘、誤魔化しをすんな、ってことです。それをわざわざこっちが訂正しないと、その嘘、ごまかししたまま逃げ切るつもりだろう?その嘘、誤魔化しで割を食うのは誰だい?君らの嘘、ごまかしを真に受けて信じてしまった学習者だろう?ってことです。「指名されてないですが」などと、出てきた分際で、もうどうしようもない、とおもったら、投げ出して逃げて結構ですよ?そのための「匿名ブログ」でしょうからね?恥のかき捨て結構じゃないですか。自分は責任負わずにすむ匿名。いつもの悪質な手口です。その学習者を欺く、嘘誤魔化しまみれで、人を中傷することだけが唯一の存在価値の悪質な捨てブログ書いてるんでしょうね?毎度悪質ですね。前回書いたアプリ:ToDoリストをそのまま拡張し、複数のリストを扱えるようにせよ以下、こちらですでにJavaScript+TimeEngine+Reactをもって実装したライブデモTimeEngine公式サイトhttp://timeengine.github.io/のDemo11を提示しながら説明。起動させた直後、前回の仕様とほぼ同じであるが、これはデフォルトで、[List#1]になっている。[NewList]ボタンをクリックすることで、次の[List#2]を新規に作成できる。このように新規に作成されたリストは、別のリストとは独立しながら同様の動作をする。[NewToDo#N]ボタンに表示されているNはそれぞれのリスト固有のカウント値である。作成しているToDoリストについては上部の[List#1]や[List#2]ボタンをクリックすることで切り替え表示ができる。document.getElementById('todo'));このコードは、前回示したコードに、要件が複雑になった差分だけ順当に、コードを積みましたにすぎません。GUIはFRPとReactで接続して書かれており、単に宣言型のコードが増えただけです。命令型って言いたいだけの頭のおかしい指摘はあてはまりません。いうのをスケールする設計であると言います。例の人、人たちは、「あたかもなんでもできるような」今回の「状態渡しすら必要ない」とか言ってたコードの延長でどんなコードを書いてくれるんでしょうか?そろそろコードが、これまであなたがたが広い真摯な読者を欺くような形でやってきた、あらゆる悪質な嘘誤魔化しが効かないレベルに突入してきました。OCamlで、スケールする「関数型」の「状態渡し」のGUIアプリのコードを書いてください。FRP必要ない、とかぶちあげてた@nonstarterを「擁護」あるいは結託してたんだから、FRP使うとかもちろんなしで。関数型「状態渡し」をもって書けるはずです。もらい適当な嘘ハッタリじゃあなければね。さあやって見せてください。念の為ですが、「状態渡し」での素の実装が見たいわけなので、なんかGUIフレームワークの「タブ」切り替えライブラリみたいなもんを使って、また誤魔化さないでください。いう議論ではない、くらいもうわかっているでしょう。「これ以上は説明も回答もしない。(東北大)、らくだの卯之助@camloeba、@nonstarterその他へむけてC言語は純粋関数型である。自称関数型コミュニティの胡散臭さと海外論調の違いこの辺の続きとなります。前回のエントリTImeEngineは命令型でも破壊的代入でもないの続きです。「破壊的代入」なんておこりうるはずもない。イミュータブルな定数であるという意味なんて、本当はこれっぽちも理解していない、ということが白日の下にさらされます。中傷してる連中は、FRPの哲学的理解が足りないからそういうことが言えるのだ、ということですね。それでもなお「どうしても理解できない人」はいます。仕方ないですが、それはその人物の知的素養の問題であって、私の問題でもTimeEngineというFRPライブラリの問題でもありません。本来のFRPを理解せず中傷を重ねる連中への再度宿題で、すでに説明したこれです。読み込んだ状態で、以下のようになります。__x.t;2なお私を他の誰かと決めつけるのは、その方たちにご迷惑ですのでおやめください。......と言っても聞き入れていただけるとは思えないので、私ももうこれ以上の書き込みはやめます。できるだけ丁寧に技術的な誤りだけを指摘したつもりですが、やはり誹謗中傷しか返ってこないようで残念です。1;というFRPライブラリの使用は概念的な意味を成しません。なんでこういうことをするのか?というと、なんか悪意があるか、それとも、FRPが「時間軸上の値を表現したデータタイプ」についてのパラダイムである、ということを全く理解していないから、こういう文句のつけかた、それこそ誹謗中傷をして平気なのでしょう。右辺の現在値に1を加えて、改めて、左辺の現在地とするということです、つまり、左辺、右辺の現在時間が異なる、FRPライブラリにおいては、.tによって表現される時刻による「時間軸上の値」は異なって当然であるということになります。右辺を評価した現在時間における__x上のある値に1を加えたものを次の瞬間以降の__x上の値として更新する、という意味合いになります。これは、=の左右で値が異なるという命令型ステップの解釈であり、そういう命令形パラダイムを大前提とした記法においては、TimeEngineの振る舞いはこう解釈される、ということにすぎませんし、そのような記法を禁じるようなSanityCheckを実装しているわけではありません、ご自由にどうぞ、といったところでしょうか。(再掲ここまで)なんかよくわかりませんが、そんなに難しいこと言っていますかね?同じことを言うと思いますが、また同じことを言いたいと思います。「破壊的代入」など原理的に起こりえない、と自然に理解できる、ということです。理解できないのならば、それはその人の哲学的側面における知性の問題であり、そもそも時間にまつわる、関数型プログラミング、FRPのことなどははなっから諦めたほうが良い、ということです。身の程をわきまえて、こちらを中傷することなどもっての他です。根本的に、式を用意したならば、その両辺が等しい、という数学的宣言をすることと同じです。1;という、方程式の左右で値が異なる「論理破綻」した記述をするのは、そういう宣言を記述した、コーダーその人の責任です。TimeEngineでは、そんなところまでSanityCheckするつもりもないですから、どうぞご勝手に、ということですが、こう書けるから、TimeEngineは命令形で、破壊的代入だ!つまり、これは岡部健氏が著書で「論理破綻」と批判していた、命令型言語の破壊的代入そのものです。できるだけ丁寧に技術的な誤りだけを指摘したつもりですが、やはり誹謗中傷しか返ってこないようで残念です。表明するに至っては「頭がおかしい」としか思えません。破壊的代入を試みたたのは、この人であるし、FRPライブラリの領分でもなんでもないわけです。「思い込みの激しい」人間に説明をするには、困難を極めるのですが、できるだけこの人物の意図を想像しながら、こちらもやってあげましょう。命令型プログラミングをやりたい!というのがあるのでしょう。1;ってのは、両辺の値が明らかに異なっているので、論理破綻しており、=の両辺の値が等しいと宣言することで、コーディングする関数型、宣言型のパラダイムからは逸脱しています。破壊的代入をしたい!という強い意図が感じられます。=の両辺の値が等しいというパラダイムにおいては、そういう行為は意味を成さないし、そういうスタイルで書いてはいけないのですが、JavaScriptのネイティブな仕様としては、破壊的代入も自由にできるので、やろうと思えば可能です。関数型プログラミングを志向するならやるべきではないのは自明です。この人物は、破壊的代入をしたい!と駄々をこねているわけです。自由にさせておきましょう。したいというのは、FRPライブラリの責任でも設計者の私の責任でもなく、彼自身の強い希望なのです。私のせいだ、みたいなことは言わないでください。いうか言われてますが、あほらしいですが。__x.tに代入されます。1;こんなコードを書いてみましょう。FRP値のフラグをtrueとするのは、この人物が、「破壊的代入」に興味があるからです。(方程式の左右)の時間経過みたいなことを前提にしてコードを書きたがっているからです。彼がそうしたいと熱望しているわけです。好きにさせてあげましょう。結果はどうなるか?というと、すでに書いています。「破壊的代入」なんておこりうるはずもない。//100となります。__x.tが分布しています。継続して分布しています。99;というのがありますから、それが得られています。「破壊的代入」というのは、そういう行為です。新たに、左辺の値を上書き破壊するように代入する。「時間」が違うわけです。破壊前、破壊後と、この人物が、意図したであろう、2つの異なる時間の値が存在するはずです。//100意図したとおりになってるじゃないですか?なんか問題あります?どこにも論理の破綻はない。式の両辺で時間が異なる、という自覚があればこのように整合的にコーディングすることは可能です。しつこい中傷行為は、いい加減にしてほしいです。「これ以上は説明も回答もしない。(東北大)、らくだの卯之助@camloeba、@nonstarterその他へむけてC言語は純粋関数型である。自称関数型コミュニティの胡散臭さと海外論調の違いこの辺の続きとなります。「課題」についてですが、いまのところ、私が知る限り、まだどこにもされていません。念の為ですが、Twitterやら幼稚な念仏唱えているだけと一部馬鹿にされている病人が誹謗中傷連ねたいだけの2chスレの書き込みなんかいちいちチェックしてるわけもないので、万一そんなとこに書きなぐっても見てるわけもありません。「これ以上は説明も回答もしない。」という嘘説明のFRPの基本原理コードなるものと説明したとおりです。http://anond.hatelabo.jp/20160520054338http://anond.hatelabo.jp/20160517023637>ライブラリユーザは現在時刻から状態への写像fを>参照透明な関数なりストリームなりで記述して、>それを処理系が実際のシステム時刻t=0,1,2,...に適用して>状態f(0),f(1),f(2),...を得るはっきりと「処理系が」って書いてあるのに、K氏は本気でユーザプログラムにf(0),f(1),f(2),...みたいなコードがないのが「反論」になると思ったのだろうか......まさか本当に「処理系」という言葉がわからなかった??もちろん、わかっていますよ?それ込みです。状態f(t)にしているところがあるんですか?「これ以上は説明も回答もしない。裏でイベントドリブンで、処理系「実際のシステム時刻t=0,1,2,...」とか、あんた何が言いたいの?誤魔化したいだけだよね?っていうことです。いう誤魔化しばかり書きなぐるのはもういい加減にしろ、っていうことです。(東北大)、らくだの卯之助@camloeba、@nonstarterその他へむけてToDoの関数型GUIアプリについてもいまのところ無回答です。私のFRPライブラリは参照不透明?で、命令型の破壊的代入っていう中傷について、またしばらく後にエントリします。あたらしい課題つきで。あたらしい課題を示唆したのですが、連中が出来もしないことを机上の空論を並べ立てていた、という分水嶺となる良い課題だ、という意見をもらったこととや、あたらしい課題を与えて、ペンディングされてる課題が未解決なのに、つけ入るスキを与えるべきではない、議論が発散してしまい、また誤魔化される余地が生まれる危険性がある、という意見も頂いたので、当面上記の、ToDoリストアプリにもとづいて話を進めていきます。直近の中傷はこういう感じです。客観的にはマウスクリック等のたびに同じメンバ変数__value.tや__items.tへの破壊的代入が何度も実行される命令型プログラムそのもの。__valueや__itemsにconstがついていても、__value.tや__item.tはconstではない。課題の私が書いたToDoリストアプリのコードを再掲しておきましょう。document.getElementById('todo'));})();まずね?constのお話なんですが、もう散々繰り返しているとおり、これはライブラリユーザのレベル、目線で、まぎれもなく定数です。具体的には、時間軸をFRPで抽象化してファーストクラスにした値。これも何度も説明しました。本来イミュータブルな時間軸において、FRPで抽象化してファーストクラスにした値、のことです。10分前に追加したある「リストアイテム」は、イミュータブルな時間軸の世界線上で、その10分前のポイントに分布、2分前に追加したある「リストアイテム」は、イミュータブルな時間軸の世界線上で、その2分前のポイントに分布。未来に追加されるであろう「リストアイテム」でさえ、イミュータブルな時間軸の世界線上で、その未来方向のあるポイントに分布。未来方向に広がっている無限リストでもこうやって抽象化できる、ということです。いう概念をまず理解してんの?っていう疑念がある。__(true);とイミュータブルな定数として宣言してしまいます。ほんでですね、__valueや__itemsにconstがついていても、__value.tや__item.tはconstではない。以上のはなしを理解しておれば、そのそれぞれ、つまり10分前に追加したある「リストアイテム」は、イミュータブルな時間軸の世界線上で、その10分前のポイントに分布、2分前に追加したある「リストアイテム」は、イミュータブルな時間軸の世界線上で、その2分前のポイントに分布。未来に追加されるであろう「リストアイテム」でさえ、イミュータブルな時間軸の世界線上で、その未来方向のあるポイントに分布。ある、ということが自然と理解できるはずです。自然と理解できてない、ってことは、すなわち、上で言ってるような「意味」がわかっていないということです。現在値というのはtであるとか、nowであるとか、そういうあるシンボルでしか表現できないものであって、こうするしかない、という意味が理解できないひとたちです。破壊的代入しまくるし、このtだって、オブジェクトのプロパティとして破壊的代入はされるわけです。いい加減しつこいんですよねー。「ライブラリの実装下レベル」で、破壊的だの命令型だのいう、中傷。言語実装レベル下で、純粋関数型でソースコード書かれてるの?C++とかで破壊的代入されてるだろう?という話です。しつこいし、いい加減にしてくれ、っていうのがまたあります。__(true);(ちなみにこの__(true)については、後で話します。trueがあろうがなかろうが、本題とは関係ないので、当面気にせずに)というように、定数です。tが破壊的代入されている!とおもっているのは、上記のとおりそれは使い手の理解の問題であり、ライブラリ下の実装と結びつけて、批判するのは、間違いです。実装の本題に戻ります。別のイミュータブルな定数__value.tの時間軸上のそのイベントが発生した、ある時間Tにおける値(現在値)は、__value.tで表現される値と等しくなる、と宣言します。これは断じて命令型ではないし、なんの「破壊的代入」も発生していない宣言である、ということが理解できるでしょうか?理解してる人は良い。中傷している一連の連中はなんも理解していないということになります。要するに、イミュータブルな時間軸の世界線において、イベントが発生したそれぞれのポイントで、それぞれの値を順次格納していく、ということになります。数学的には、決定論的に最初から決定されている、とみなす宣言文です。未来方向においても「それぞれの値を順次格納している」定数として扱っているということです。イミュータブルな定数です。イミュータブルな定数である本当の意味です。「破壊的代入」なんておこりうるはずもない。イミュータブルな定数であるという意味なんて、本当はこれっぽちも理解していない、ということが白日の下にさらされます。中傷してる連中は、FRPの哲学的理解が足りないからそういうことが言えるのだ、ということですね。__(true);とされた時点でもう「すでに」全部入っています。FRP的には、そう見做されている、数学の定数です。__value.t);という、クリックイベントの宣言文です。えーっとクリックイベントの宣言文って、命令型ですか?違うでしょ?単に、これもイミュータブルな時間軸の世界線におけるマウスクリックの挙動の分布と、イミュータブルな時間軸の世界線におけるリストアイテムの分布が一致している、という数学的な宣言にすぎません。上記の時間軸上の世界線の分布について、ある要素とある要素でマッピングして呼応させる、というのとまったく関係ありません。__value.t);単に、イミュータブルな時間軸の世界線における値の分布の宣言文であり、コードの宣言においては何も評価されません。断じて命令型の要素などない、ということです。よろしいですか?さて、__itemsというFRP定数には、すべてのリストアイテムの値が時間軸上に分布して格納されています。そのままでは、数学的な抽象的存在であり、ユーザの目にもふれず「実用的なアプリ」として、役に立たないわけですから、Reactを利用して、フロントエンドのDOM要素としてマッピングしてやります。(<li>{item}</li>)))));これもただ数学的な関係を宣言しているだけです。命令型の要素はどこにもありません。tが「破壊的代入」されて破壊されてしまったのなら、いったいなぜ、このようなマッピングが可能になって、実際に、TimeEngine公式サイトhttp://timeengine.github.io/のDemo10というように、動作してしまうのでしょうか!?論より証拠。私が実装したFRPは、そのFRPの設計哲学どおりに挙動しているわけです。命令型の要素なんて微塵もないし、破壊的代入をもって破壊されたのならば、リストなんて列挙表示されてるはずがないだろう?でも実際には、破壊されずに全部きちんと表示されていますよね?ってことです。いいでしょうか?意味もわかってないのに、己の無知無理解を棚に上げて中傷するのはもういい加減にしてください。いうか、どなたがやってるんですかね?匿名で恥はかきすてで毎度結構なことですよね?岡部が、kenokabeが、と書き込むが、自分の名前はださずに、なんか複数でやってる。オモテにでてこいよ?と思う。あと、なんでもいいから、さっさとこの課題のコード書いてみせてください。「机上の空論」でないのならば。最後に、本論と関係ないことですが、テクニカルなことです。__();というようになっています。現在時間が未来方向に進むにつれて、計算機上のメモリにデータが蓄積されていきますから、メモリリークのような現象が起こります。扱いたいので、過去のデータは全部捨てていきます。いうか、ライブラリ実装上は、単に保持はしない。__(true);とかオプションつけた場合、ちゃんと保持するし、別の宣言文をもってデータ全体にアクセスできますよ、ということです。「お絵かきアプリ」のFRP値で、オプションつけて、データ保持させると、ドローしたすべてのストロークがデータとして蓄積されるし、リプレイみたいなことも簡単にできます。C言語は純粋関数型である。「これ以上は説明も回答もしない。(東北大)、らくだの卯之助@camloeba、@nonstarterその他へむけてこの辺の続きとなります。「課題」についてですが、いまのところ、私が知る限り、まだどこにもされていません。念の為ですが、Twitterやら幼稚な念仏唱えているだけと一部馬鹿にされている病人が誹謗中傷連ねたいだけの2chスレの書き込みなんかいちいちチェックしてるわけもないので、万一そんなとこに書きなぐっても見てるわけもありません。「これ以上は説明も回答もしない。」という嘘説明のFRPの基本原理コードなるものと説明したとおりです。(東北大)、らくだの卯之助@camloeba、@nonstarterその他へむけてToDoの関数型GUIアプリについてもいまのところ無回答です。理論的には不可能ではないかもしれんが、もともと非純粋なので誰もそういうライブラリを整備してないから、ライブラリから作るのはまあ面倒だろうし、わざわざ非純粋関数型言語で純粋関数型のGUIを作る動機も現時点ではまずないだろう。これもすでに指摘されているとおり。http://anond.hatelabo.jp/20160520051838「状態渡し派」なんてレッテル張りも典型的な詭弁(藁人形論法)。誰も状態渡しで何でも簡単に書けるなんて言ってないし、状態渡しで書くべきとも言ってない。「お絵かきアプリ」には自称FRPが絶対に必要、という明らかに誤った主張に対する反例としてnonstarter他が「状態渡し」を挙げただけ。それなのにHaskellだから認めないとか、OCamlでも簡単だったから認めないとか......自分で「FRPが必要」と断言して挙げた例題なのに。「やらない」「できない」言い訳を始めているようで非常にほほえましいですね。ちなみにこの胡散臭い人物がいう「純粋関数型」については後述します。「実用的アプリ」を書ける、という観点において、この程度の簡単なアプリなら書ける、書けたという誤魔化しがなされたにすぎません。「お絵かきアプリ」というのは、あくまで複雑なものが普通である「実用的アプリ」の具体例のひとつとして登場しただけで、その課題が「実用的なアプリ」というトピックにおいてどうも単純すぎたようだ、だからもうちょっと複雑な具体例で検討してみようか?、というのが現在進行している議論です。「原理的」に複雑な「実用的アプリ」が書ける、わけもないですが、それが「実用的」な観点で、君ら誤魔化してるだろ?と言ってるわけです。以上の2点の嘘ごまかしを証明しようというのが今のステップです。「原理的」に問題ないというポーズだけ示し、さらに、FRPでも一緒だ!と「誤魔化している」ことを批判されているのに、意味が伝わりませんかね?「机上の空論」であると。「机上の空論」じゃ埒が明かないので、こちらは、さらに複雑な課題において、証明してみせよ、と具体的なコードを示せと言ってる。君らのなかの「純粋関数型」君らののなかの「FRP」がどうであれ、こちらはすでに、コードを示した。君らは頑なに強弁してた、Ocaml+状態渡し(FRPのメリットなんてないらしい)関数型でコードは示せない。それがすべてを物語っているだろう?君らの一連の関数型のGUI実用アプリのの言説なぞ机上の空論であると。『話題の岡部健(kenokabe)が自分のブログで凄いこと言ってる』http://anond.hatelabo.jp/20160519214037で、ttp://kenokabe-techwriting.blogspot.jp/このブログエントリの昨日と本日日付の分を見ると、たくさんの増田の投稿がリンク付きで引用されている。見ると、個々の増田の投稿を、実在の学者やツイッターユーザーが行ったと決めつけてるフシがあるんだよね。自説を否定する増田に対して憤慨してる様子なんだけど、文脈からするとどうも「駱駝」っていう人物が投稿していると言いたげなんだよね。「あなた」とか「君ら」という言葉からすると。いうか、完全にそれを前提にブログを書いているんだどう見ても。増田の投稿に対して憶測で特定の人物だと決めつけてこういうエントリ書くような奴は初めて見た。対してよくわからない挑戦状みたいなエントリを何の前触れもなくアップロードしてるんだよ。内容からすると、やはり誰が書いたのか正体が見えない投稿を、その両名が行ったと決めつけてるようなんだよね。英二郎@esumii氏、らくだの卯之助@camloeba氏その他が、犯罪者集団に合流して2ちゃんねるでの誹謗中傷チームの「8賢者」「ウィザード組」とかアホなことをやってる件についてどこの厨房だよと思ったらどうも真剣に書いてるみたいなんだよね。第三者による書き込みhttp://anond.hatelabo.jp/20160518171946って言ってるけど、これ岡部氏本人による自己弁護だよねぇ・・・・。何をしたらここまで常軌を逸した発言に及ぶんだ。いうttp://kenokabe-techwriting.blogspot.jp/という2ch記法ではじまる、たいへんわかりやすい印象操作工作活動をあいかわらずやらかしています。英二郎@esumii氏、らくだの卯之助@camloeba氏その他が、犯罪者集団に合流して2ちゃんねるでの誹謗中傷チームの「8賢者」「ウィザード組」とかアホなことをやってる件についてこの構成員の口癖そのものです。文脈からするとどうも「駱駝」っていう人物が投稿していると言いたげなんだよね。「あなた」とか「君ら」という言葉からすると。憶測で特定の人物だと決めつけてこういうエントリ書くような奴は初めて見た。対してよくわからない挑戦状みたいなエントリを何の前触れもなくアップロードしてるんだよ。「今初めて知りました感」を演出している。「背景に詳しい事情通」なのに「今初めて知りました感」を演出。いうのを「自作自演」っていうんでしょ?いつも工作活動ごくろうさまです。最後に第三者による書き込みhttp://anond.hatelabo.jp/20160518171946って言ってるけど、これ岡部氏本人による自己弁護だよねぇ・・・・。何をしたらここまで常軌を逸した発言に及ぶんだ。