2016年5月23日月曜日

module H = Dom_html
let g x = Js.Opt.get x (fun () -> assert false)
let o = Js.Opt.return
let s = Js.string

let _ = H.window##onload <- H.handler (fun _ ->
  Firebug.console##debug (s "DoNe starting");
  let d = H.document in
  let tm = g (d##getElementById (s "todo_time")) in
  ignore
    (H.window##setInterval
       (Js.wrap_callback (fun _ ->
         tm##textContent <- o (jsnew Js.date_now ()##toString ())),
        100.));
  let txt = g (H.CoerceTo.input (g (d##getElementById (s "todo_text")))) in
  let btn = g (H.CoerceTo.input (g (d##getElementById (s "todo_button")))) in
  let ul = g (d##getElementById (s "todo_ul")) in
  btn##onclick <- H.handler (fun _ ->
    let v = txt##value in
    Firebug.console##debug (s ("DoNe adding: " ^ Js.to_string v));
    let li = H.createLi d in
    li##textContent <- o v;
    Dom.appendChild ul li;
    btn##value <- s ("NewDoNe#" ^ string_of_int (1 + ul##childNodes##length));
    txt##value <- s "";
    Js._false);
  Js._false)

今回は「状態渡し」すら要らないので「お絵かき」より簡単。何をさせたかったのかまったくわからない。

すでに別の人も指摘しているとおり、以前の「状態渡し」のほうがOCaml上のGUIアプリの実装としては異常。書けないとか言うから反例として書いただけ。OCamlは非純粋関数型なので、普通は副作用（破壊的代入を含む）を使う。FRPを含め、純粋関数型のGUIプログラミングがしたかったらHaskellのライブラリなりElmなり、それ用の適切な道具を使えば良い。

自分から要求した「お絵かき」の「トイプログラム」すら1年もかかって自称FRP（実際にはFunctionalですらない命令型プログラム。哲学とか時刻とか理屈をこねたり過去の値を保存したところで、ユーザから見て命令型の非単一代入であることに何ら変わりはない。ちなみにその保存のしかただとJS処理系がガベコレできないのでメモリリークします。）でしか書けないのに、また他人に実装を要求する正当性は1ミリもない。

(引用終わり)

なんで、この連中、先の「ライブラリ内のソースコード」や「命令型」「破壊的代入」のこともそうなんですが、おんなじこと何度も言わないと理解できないのかな？と常にイラっとさせられるんですが、当方がOCamlでの関数型コードのGUIアプリ課題　あらあためて、住井英二郎@esumii (東北大)、らくだの卯之助@camloeba、@nonstarterその他へむけてで示した条件は、以下でした。

念の為に付随要件、OCamlの状態渡しによる関数型で実装せよ

OCaml で君らがお題目唱えているとおり、（状態渡し）の関数型のコードで書くこと。これまで君らが誤魔化してきたように、HaskellやElmなど他の言語を「都合よくつまみ食い」してはならない。
FRPのメリットなんてない、とかぶちあげているみたいなので、たとえFRPのメリットをようやく今更途中で気づいたとしても、間違ってもOCamlのFRPライブラリなんかを検索して探し出して、そのFRPライブラリを利用して書いてはならない。あくまでも（状態渡し）の関数型コードで書くこと。

これは、君らが延々とこちらの主張を押さえ込むように強弁してきた要件なので、当たり前。出来なきゃ、その時点で君らの嘘が確定する。以上の条件に反しなければ別にどんなライブラリを使おうが自由。

これだけ。たったこれだけなんですよ。

OCamlの状態渡しによる関数型で実装せよ

上記引用したコードは、
OCaml ◯　
関数型　◯
状態渡し　X

です。よって不合格。

もちろん、これワザとやらかしてる、つまり、
関数型で実用的アプリが書けるか？

関数型プログラミング（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はあくまで否定。
まったくもってわけのわからない理由で。

えーっとさ、
http://okaml.blogspot.jp/　のやつ。

君、前からいたよな？そのブログに、この@nonstarterの主張に呼応して、
状態渡しでのOCamlのお絵かきアプリ書いて「ほらみろ」とばかりにやらかしてるよな？
@nonstarterの上記の発言に明らかに同調し、それをもって、こちらの主張を否定しているのは明白だよな？

ところが！ここにきて、

以前の「状態渡し」のほうがOCaml上のGUIアプリの実装としては異常。

と来た。こういうのが、

嘘ごまかし

だというんだ。

?OCamlは非純粋関数型なので、普通は副作用（破壊的代入を含む）を使う。FRPを含め、純粋関数型のGUIプログラミングがしたかったらHaskellのライブラリなりElmなり、それ用の適切な道具を使えば良い。

へえ、つまり、実用的なアプリを書くには、OCamlでは関数型言語としては役不足であり適切ではない、不適切であることをここに来て認めるんだ？

これ、こちらが最初からずーーっと主張していたことだけど？
@nonstarter は

追記(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プログラミングをするには、不適切であると。だからさっさと認めろよな？

「関数型言語」に関するFAQ形式の一般的説明 - Qiita

住井＠東北大の例のFAQにもこう書いてある。

それだと入出力や状態(state)すら表せないのでは？

いいえ、純粋な関数型プログラミングでも、入力を引数、出力を戻り値とする関数を考えることにより、入出力も表現できます。非常に簡単に言うと、例えばhello(x) = “Hello, ” + x + “!”みたいな関数で（これも文法は適当です）、文字列hogehogeを入力するとHello, hogehoge!と出力する、みたいなプログラムを書くことができます。
同様に、状態（の変化）についても、古い状態を引数として受け取り、新しい状態を戻り値として返す関数により表すことができます。

この人物はOCamlのプログラマーであるが、関数型のおすすめの本としての各種教科書には、そのまさに、「普通は副作用（破壊的代入を含む）を使う」デスクトップアプリの例ばかり書かれていた。だから、おかしいだろう？といえば、この@nonstarterの状態渡しバンザイ、FRP必要なしネガキャンが不当に巻き起こされた。

「岡部のいうことがまちがっていた」という印象のみを拡散することにやっきになり、集団的に「お絵かきアプリが関数型で書けない」「破壊的代入だ」だのそういうことばかり喧伝していた。君らは嘘つきなんだよ。
誰が割りを食う？読者だろう？真面目に勉強したい初学者たちだろう？恥をしれよ。デマ集団。

だから、そういう嘘誤魔化しをやめろ、と。わからないですかね？自覚あるでしょ？
ここでの命題は、極めてシンプルで明瞭で、それはただひとつ。

関数型プログラミング（OCaml）の「状態渡し」は実用的アプリのコードに耐えうるか？

それだけ。そして前回のお題で、

状態渡し　X
であるということは、
さっそくもう、この程度の複雑さのGUIアプリについて、

「状態渡し」では書けなかった

ということでよろしいですね？

逆に言うと、こちらががわざわざ手間をかけて、こういう連中の嘘、ごまかしについて
指摘してやらないと、そのまま「逃げ切る」つもりでいるわけです。

つまり、大局的な構図としては、

１　私、岡部が、この一連の国内の自称関数型コミュニティの連中による嘘、ごまかしを指摘する。
２　それが、事実だと、薄々感づいてるjが、嘘、ごまかしの上塗りをして、あたかも岡部が間違っているような印象操作をする
３　私がアホらしくなって、放棄するのを待つ

こんなところでしょう。
実際に
３の私がアホらしくなって、放棄すれば、連中の逃げ切り勝ちです。つまり嘘、ごまかしを拡散したまま、読者に嘘ごまかしを信用させ、正しい批判を加えた岡部が間違っていると思わせ、自分たちの嘘、ごまかしが正しいと信じさせる。

自分から要求した「お絵かき」の「トイプログラム」すら1年もかかって自称FRP（実際にはFunctionalですらない命令型プログラム。

「自分から要求した」とか、１年もかかって、とかいう要素は、上記の、この悪質な人物が、単に嘘誤魔化しを延々と続けてきたという上記の話なのでおわり。

次に、

自称FRP（実際にはFunctionalですらない命令型プログラム。哲学とか時刻とか理屈をこねたり過去の値を保存したところで、ユーザから見て命令型の非単一代入であることに何ら変わりはない。

これだけど、もう馬鹿に何度同じ話をしても同じだと痛感。

こちらとしては、もう、これ

TimeEngineの　 x.t = x.t + 1;　について

以上、噛み砕いて説明するのは、多分不可能だし、
「あーあー都合の悪いこと聞こえない」
と理屈もへったくれもなく、よりによってFRPについて「時刻とか理屈をこねたり」などと平気でいうオバカさん相手にはどうしようもないです。

ちなみにその保存のしかただとJS処理系がガベコレできないのでメモリリークします。）でしか書けないのに、また他人に実装を要求する正当性は1ミリもない。

こういう悪質な相手の「ちなみに」は、自分が上記のような理屈もへったくれもない、デタラメをまきちらして、説得力のない文章を書いてる直後に出るのが常套手段（この人物に限らないパターン）なので、最大限の注意が必要。まず、本論と関係ない、次に、主張の信ぴょう性がない。

「メモリリークします」ってあほかと。FRPは、たとえば、こういうTODOリストなど、全部のデータが必要な場合、そんな、FRP値が処理系によって知らない間にガベコレされたら、それは単にデータの損失なの。わかるかな？わからないかな？

最後に、

また他人に実装を要求する正当性は1ミリもない。

別に君に実装を要求した覚えはない。自分で、

ご指名ではないけど久々に書いてみました。OCamlもJSも詳しくないので細かいことは知らない。（追記：入力消すの忘れてたので修正。）

ひまだから、やってやったみたいなポーズでしゃしゃりでてきたんだろう？

しかも、すべて、例題が単純であることをよいことに、
できないことをあたかも簡単にできるように見せかける誤魔化しという連中の一貫した悪質な手口。

「状態渡し」では書けなかった

今回は、きっちり宣言したとおり、「状態渡し」で書いたら複雑になるように、問題設定していたが、「状態渡し」でも書けるという問題の単純さを悪用し、「状態渡し」で書いたら複雑になる、と痛感したがゆえに、ルール違反の「状態渡し」なしので書いて、しかも、それが例外的、異常な実装だと言い訳し、前回まで状態渡しで、nonstarterを擁護していたのは、「反例」だから、とまた言い訳する。

また他人に実装を要求する正当性は1ミリもない。

というのは、上記のような自己都合で「状態渡し」なしのルール違反をした
「状態渡し」のコードが書けなかったことを後ろめたいと自覚しているから、最後っ屁で、
ルール設定にいちゃもんつけてるんだね。

いやあのね、こっちが、嘘つけよ！と批判していて、
「OCaml」で、関数型で、実用的なアプリを、状態渡しで、FRPなしで、書ける！とさんざん反論していたのは、こちらでなく君らだから。

今回のTODOリスト、こんな、内部的にリストの状態を保持しない、画面に書きっぱなしの代物なんぞ、
内容をろくに管理も保存もなにもできないのは自明で、実用的ではない。

こんなことは、大前提として、つまり、アプリが状態を扱うという意味を大前提として「状態渡し」で書け、と条件付けたのに、
「状態」を扱えば煩雑になるとわかりきっているからそこから逃げて、誤魔化してこう書いたわけです。

今回は「状態渡し」すら要らないので「お絵かき」より簡単。何をさせたかったのかまったくわからない。

盗っ人猛々しいですね（苦笑

関数型プログラミング（OCaml）の「状態渡し」は実用的アプリの実装に耐えうるか？

「状態渡し」で書けんのか？　と問いただしている。
君らの誤魔化しを一個一個潰すことをしたい。

わかってるくせに、「状態渡し」で書けない卑怯な言い訳をして、あたかもこちらのせいにしているようなので、より「状態渡し」で書けるのか？というのを明確にするように、この延長で、
もう一段、例題のハードルをあげてやることにしましょう。

再度確認ですか、今回、上記のような大前提をもって、
「状態渡し」をもって書けという条件でしたので、
この人物は、この条件を満たせなかった、つまり課題をクリアできなかった、ということを確認しておきます。

そしてそれを踏まえながら、新たにこういう誤魔化しさえ通用しない、
つまり、アプリが単純であることをいいことに、
必要な要件を潰して、表面上だけは動作しているように見せかける、
という誤魔化しができないように、ハードル一段引き上げ、
状態を扱うしかないように、アプリを少し複雑にしてみます。　
状態渡しでは煩雑にしかかけないようにハードルを設定する。

あたかもスケールするように喧伝している誤魔化しがある。では問題を複雑にしていって
その誤魔化しの延長線上で、そのアプローチが破綻しないか？
スケールするのか？

そういうことを確認しているにすぎない。

ちょっと複雑になったら通用しない、破綻する、ならそんなもんは「机上の空論だ」

そういうことを言っているにすぎない。

私が気に入らないのは、
この一連の国内の自称関数型コミュニティの連中による、悪質な手口
つまり、
本質とずらす、議論のすり替え、ひとりが誤魔化す、
あとの連中はその嘘、誤魔化しに気づいているが沈黙、そういう手口。

その嘘、誤魔化しによって、あたかも、まるで、私、岡部のほうがいい加減なことを主張している、
と初学者をはじめとする真摯にプログラミングを学びたいと考えている衆目、読者にむけて印象づけようとする。

こちらが黙っていると、「真理」について割を食ってる広い読者の犠牲のもとに、自分たちがただしいと嘘をついたまま、有耶無耶にしようとする。

しかし、こうやっていろいろ突っついてやると、そのうち必ずこの誤魔化している連中の馬脚が現れます。

ハードル上げによって、今回君、君らがごまかしたように、
「状態渡しで書け」ときちんと明示してるのに
「状態渡しなしでも書けるから、状態渡しで書く必要がない」という論理をすり替えを無効化する。

そんな誤魔化しは許容されるはずもない。あたりまえだろう？
「状態渡しでは書けない」あるいは「状態渡しで書くことは困難で煩雑である」
という論点に、改めて引き戻すことになる。

なんで、こっちがこんな明確化をわざわざせんといかんのか？
それは君、君らが、誤魔化しをしているからだろう？ということです。
すぐバレるような嘘、誤魔化しをすんな、ってことです。
それをわざわざこっちが訂正しないと、その嘘、ごまかししたまま逃げ切るつもりだろう？
その嘘、誤魔化しで割を食うのは誰だい？君らの嘘、ごまかしを真に受けて信じてしまった学習者だろう？
ってことです。

ああもちろん

「指名されてないですが」などと、出てきた分際で、
もうどうしようもない、とおもったら、投げ出して逃げて結構ですよ？
そのための「匿名ブログ」でしょうからね？恥のかき捨て結構じゃないですか。
嘘誤魔化し全開の自覚アリアリで中傷する相手は実名
自分は責任負わずにすむ匿名。いつもの悪質な手口です。
一体、誰が　、その学習者を欺く、嘘誤魔化しまみれで、人を中傷することだけが唯一の存在価値の
悪質な捨てブログ書いてるんでしょうね？

毎度悪質ですね。

課題

前回書いたアプリ：ToDoリストをそのまま拡張し、複数のリストを扱えるようにせよ

以下、こちらですでにJavaScript＋TimeEngine+Reactをもって実装したライブデモ
TimeEngine公式サイト
http://timeengine.github.io/
のDemo11
を提示しながら説明。

以下は動作中のスクリーンショット画像

① 起動させた直後、前回の仕様とほぼ同じであるが、これはデフォルトで、[List#1]になっている。

enter image description here

② [NewList]ボタンをクリックすることで、次の[List#2]を新規に作成できる。このように新規に作成されたリストは、別のリストとは独立しながら同様の動作をする。たとえば、[NewToDo#N]ボタンに表示されているNはそれぞれのリスト固有のカウント値である。

enter image description here

③ すでに作成しているToDoリストについては上部の[List#1]や[List#2]ボタンをクリックすることで切り替え表示ができる。

enter image description here

ソースコード(index.jsx)

const TodoElement = () => {
  const ClockElement = __Element(__.intervalSeq(Immutable.Range(), 100)
    .__(() => (<div>{moment().format('MMMM Do YYYY, h:mm:ss a')}</div>)));
  const __fdList = __().__((val) => (__.log.t = val));
  const __lists = __(true).__((__list) => (__fdList.t = __lists.length));
  const ListofListElement = __Element(__([__lists])
    .__(() => ((__lists).map((list, i) => (
      <button onClick = {() => (__.log.t = __fdList.t = i)}>{'List#' + (i + 1)}</button>)))));
  const InputElement = () => {
    const __value = __();
    const onChange = (e) => (__value.t = e.target.value);
    const onClick = () => (__.log.t = __lists[__fdList.t].t = __value.t);
    const onClickNL = () => (__.log.t = __lists.t = __(true));
    const __seqEl = __([__value]).__((value) => (<div>
          <h4>{'List#' + (__fdList.t + 1)}
          <button onClick = {onClickNL}>{'NewList'}</button></h4>
            {__lists[__fdList.t].map((item) => (<li>{item}</li>))}
            <input type="text" value={value} onChange={onChange}/>
            <button onClick = {onClick}>{'NewToDo#' + (__lists[__fdList.t].length + 1)}</button></div>));
    __.log.__(() => (__value.t = ""));
    return __Element(__seqEl);
  };
  __lists.t = __(true); //new items-list
  const __delay = __.intervalSeq(Immutable.Seq.of("started!"), 1000)
    .__(() => (__.log.t = "showInput"));
  return (<div><h2>ToDo</h2>{ClockElement}<p/>
      {ListofListElement}<p/>{InputElement()}</div>);
};
const mount = ReactDOM.render(TodoElement(), document.getElementById('todo'));

このコードは、前回示したコードに、要件が複雑になった差分だけ順当に、コードを積みましたにすぎません。GUIはFRPとReactで接続して書かれており、単に宣言型のコードが増えただけです。
命令型って言いたいだけの頭のおかしい指摘はあてはまりません。
こういうのをスケールする設計であると言います。

さて、例の人、人たちは、「あたかもなんでもできるような」今回の
「状態渡しすら必要ない」とか言ってたコードの延長でどんなコードを書いてくれるんでしょうか？
そろそろコードが、これまであなたがたが広い真摯な読者を欺くような形でやってきた、
あらゆる悪質な嘘誤魔化しが効かないレベルに突入してきました。
OCamlで、スケールする「関数型」の「状態渡し」のGUIアプリのコードを書いてください。

FRP必要ない、とかぶちあげてた@nonstarterを「擁護」あるいは結託してたんだから、FRP使うとかもちろんなしで。
純粋関数型の「状態渡し」で実用的なアプリを「なんら困難もなく」書けるんでしょ？
FRPと複雑性は変わらんのでしたよね？じゃあ、当方のFRPのコードと同等以下の複雑性で、
関数型「状態渡し」をもって書けるはずです。　
もっともらい適当な嘘ハッタリじゃあなければね。
さあやって見せてください。どうぞ。

なお、念の為ですが、「状態渡し」での素の実装が見たいわけなので、なんかGUIフレームワークの「タブ」切り替えライブラリみたいなもんを使って、また誤魔化さないでください。そういう議論ではない、くらいもうわかっているでしょう。

岡部　健の技術記事　Ken Okabe's tech writing

Contact : kenokabe@gmail.com

Topics

2016年5月23日月曜日

スケールするFRPアプリ課題：わかりやすい嘘誤魔化しをしないように

K

okaml

できないことをさもできるように見せかける嘘誤魔化し

2016年5月21日土曜日

Done

念の為に付随要件、OCamlの状態渡しによる関数型で実装せよ

OCamlの状態渡しによる関数型で実装せよ

関数型プログラミング（OCaml）の「状態渡し」は実用的アプリの実装に耐えうるか？

関数型プログラミング（OCaml）の「状態渡し」は実用的アプリの実装に耐えうるか？

追記(2015/05/30)：デスクトップアプリケーション？？

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用を使用せずに書くのもなんら困難ではありません。

純粋な関数プログラミングでGUIアプリケーションを作成するのにFRPがなんら必要でない、という趣旨には充分です。

嘘ごまかし

追記(2015/05/30)：デスクトップアプリケーション？？

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用を使用せずに書くのもなんら困難ではありません。

純粋な関数プログラミングでGUIアプリケーションを作成するのにFRPがなんら必要でない、という趣旨には充分です。

「関数型言語」に関するFAQ形式の一般的説明 - Qiita

それだと入出力や状態(state)すら表せないのでは？

関数型プログラミング（OCaml）の「状態渡し」は実用的アプリのコードに耐えうるか？

「状態渡し」では書けなかった

TimeEngineの　 x.t = x.t + 1;　について

「状態渡し」では書けなかった

関数型プログラミング（OCaml）の「状態渡し」は実用的アプリの実装に耐えうるか？

課題

前回書いたアプリ：ToDoリストをそのまま拡張し、複数のリストを扱えるようにせよ

① 起動させた直後、前回の仕様とほぼ同じであるが、これはデフォルトで、[List#1]になっている。

③ すでに作成しているToDoリストについては上部の[List#1]や[List#2]ボタンをクリックすることで切り替え表示ができる。

ソースコード(index.jsx)

0 コメント:

コメントを投稿

Popular Posts

Blog Archive

Topics

2016年5月23日月曜日

K

okaml

できないことをさもできるように見せかける嘘誤魔化し

2016年5月21日土曜日

Done

念の為に付随要件、OCamlの状態渡しによる関数型で実装せよ

OCamlの状態渡しによる関数型で実装せよ

関数型プログラミング（OCaml）の「状態渡し」は実用的アプリの実装に耐えうるか？

関数型プログラミング（OCaml）の「状態渡し」は実用的アプリの実装に耐えうるか？

追記(2015/05/30)：デスクトップアプリケーション？？

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用を使用せずに書くのもなんら困難ではありません。

純粋な関数プログラミングでGUIアプリケーションを作成するのにFRPがなんら必要でない、という趣旨には充分です。

嘘ごまかし

追記(2015/05/30)：デスクトップアプリケーション？？

もちろん、OCamlであれHaskellであれ破壊的代入の類の副作用を使用せずに書くのもなんら困難ではありません。

純粋な関数プログラミングでGUIアプリケーションを作成するのにFRPがなんら必要でない、という趣旨には充分です。

「関数型言語」に関するFAQ形式の一般的説明 - Qiita

それだと入出力や状態(state)すら表せないのでは？

関数型プログラミング（OCaml）の「状態渡し」は実用的アプリのコードに耐えうるか？

「状態渡し」では書けなかった

TimeEngineの __x.t = __x.t + 1; について

「状態渡し」では書けなかった

関数型プログラミング（OCaml）の「状態渡し」は実用的アプリの実装に耐えうるか？

課題

前回書いたアプリ：ToDoリストをそのまま拡張し、複数のリストを扱えるようにせよ

① 起動させた直後、前回の仕様とほぼ同じであるが、これはデフォルトで、[List#1]になっている。

③ すでに作成しているToDoリストについては上部の[List#1]や[List#2]ボタンをクリックすることで切り替え表示ができる。

ソースコード(index.jsx)

0 コメント:

コメントを投稿

Popular Posts

Blog Archive

TimeEngineの　 x.t = x.t + 1;　について