  |
はてなキーワード: OCAMLとは
コーンフレークじゃなくて、Haskellだとして、全体のネタを書き直してくださいっていう指示した結果
ボケ＆ツッコミ「お願いしますー ありがとうございますー」
ツッコミ「あー ありがとうございますー ねっ 今Githubでスターをいただきましたけどもね」
ボケ＆ツッコミ「ありがとうございますー」
ツッコミ「ねー 有り難いですよ ほんとにね」
ボケ「入れておきましょう」
ボケ「いきなりですけどね うちのオカンがね 好きなプログラミング言語があるらしいんやけど」
ツッコミ「プログラミング言語の名前忘れてもうて どうなってんねそれ」
ツッコミ「分からへんの？ いや ほな俺がね おかんの好きなプログラミング言語 ちょっと一緒に考えてあげるから どんな特徴ゆうてたかってのを教えてみてよ」
ボケ「あのー関数型言語で、型システムが強力で、遅延評価するやつやって言うねんな」
ツッコミ「おー Haskellやないかい その特徴はもう完全にHaskellやがな」
ツッコミ「すぐ分かったやん こんなんもー」
ツッコミ「いやそうやろ？」
ボケ「オカンが言うには 将来の夢はそれで書かれたOSを使うことやって言うねんな」
ツッコミ「あー ほなHaskellと違うかぁ Haskell製のOSなんてまだ無いもんね」
ボケ「そやねん」
ツッコミ「HaskellはOSを作るのには向いてへんからなぁ」
ボケ「そやねんな」
ツッコミ「な？ Haskell側もOS開発に任命されたら荷が重いよあれ」
ボケ「そやねんそやねん」
ツッコミ「Haskellってそういうもんやから ほなHaskellちゃうがなこれ」
ボケ「そやねん」
ツッコミ「あれほなもう一度詳しく教えてくれる？」
ツッコミ「Haskellやないかい モナドは確かに難しいねんHaskellの でも俺はね あれはHaskellの良いところやと思うねん 俺の目は騙されへんよ 俺騙したら大したもんや」
ボケ「まあねー」
ツッコミ「ほんであれよー いざ使ってみたらね モナドのおかげでコードがスッキリするねん 俺は何でもお見通しやねんから Haskellのモナドなんて」
ツッコミ「そうやろ」
ボケ「オカンが言うには プロダクションで使うにはまだ早いって言うねんな」
ツッコミ「ほなHaskellちゃうやないかい プロダクションでHaskell使ったら 上司がひっくり返すもんね Haskellはねー まだ研究段階やから実務では使いにくいねん」
ボケ「そやねんそやねん」
ツッコミ「な？ Haskell使ってみたらだんだん罠が見えてくるから 最後ちょっとだけ避けてまうねんあれ」
ボケ「そやねんそやねん」
ボケ「そやねんな」
ツッコミ「Haskellちゃうがな ほな もうちょっとなんか言ってなかった？」
ボケ「学生の頃 なんでみんな憧れるんか分からんかったらしいねん」
ツッコミ「Haskellやないかい 学生の頃はHaskellとOCamlとLispに憧れるんやから あとSmalltalkも憧れたな Haskellそんなもんよ」
ツッコミ「そうやろ」
ボケ「オカンが言うには 関数型プログラミングの教科書に必ず載ってるっていうねん」
ツッコミ「ほなHaskellやないかい 教科書のサンプルコードにHaskellのコードが出てこんわけないやん」
ツッコミ「Haskellはね 関数型プログラミングの王道中の王道やねん」
ツッコミ「Haskellや絶対 ほな ほなもうちょっとなんかゆうてなかったか？」
ツッコミ「Haskellやないかい Yesodとかあるやろ な？ RubyとかPythonの次はHaskellが来るって言われてるねん 俺はそう思うよマジで Haskellや絶対」
ツッコミ「そうやて」
ボケ「オカンが言うには ジャンルでいうたら数学やっていうねん」
ツッコミ「ほなHaskellやないかい ジャンルで数学言うたらHaskellしかあらへんやん な？ Haskellは数学の理論がベースになってるんやで ラムダ計算とか圏論とかな」
ボケ「そやねんそやねん」
ツッコミ「ほなHaskellに決まりやないかい ほなもうちょっとなんかゆうてなかった？」
ツッコミ「Haskellやないかい Haskellは変数が不変やから 変数に感謝するのは当然やねん ね？ 状態変更せんと安心して使えるからな」
ボケ「そやねんそやねん」
ツッコミ「Javaとかの変数は裏切るからアカンねん Haskellの変数は一生そばにおってくれるから最高やで」
ボケ「でも分かれへんねん」
ツッコミ「分からへんことない おかんの好きなプログラミング言語はHaskell もぉ」
ボケ「でもオカンが言うには Haskellではないって言うねん」
ツッコミ「ほなHaskellちゃうやないかい オカンがHaskellではないと言うんやから Haskellちゃうがな」
ボケ「そやねん」
ツッコミ「先ゆえよ 俺がラムダ計算の説明してる時どう思っててんお前」
ツッコミ「ホンマに分からへんがなこれ どうなってんねんもう」
ボケ「んでオトンが言うにはな」
ツッコミ「オトン？」
でもガチのＣＳを勉強しようと思ったらアルゴリズムとデータ構造は必須で、それに適した言語となるとＣ以下あれやこれやでしょ。
あと、デザイン・レシピとかいう考え方なら OCaml とかの関数型言語が入門に適しているし、オブジェクト指向ならＣじゃ無理だし。
初心者にもいろんなタイプがいるんだよ。すぐ何かに役立つ知識よりもＣＳの基本からじっくり勉強したい初心者もいる。（俺とか）
大学によっては一年生向けの最初の言語が C だったり OCaml だったり Haskell だったり Oberon だったり Pascal や Ada だったりするところもあるくらいだからな。もちろん少数派だけど。（今の多数派は多分 Python か C）
初心者はPythonから始めましょう。やりたいことはPythonでだいたいできます。世界で一番人気の言語で資産も豊富にあります。低学歴の素人がなんと言おうとPythonです。Pythonを覚えるのです。簡単なので1日あれば覚えられるでしょう。
次にSQLを勉強しましょう。SQLは3日くらいあれば中級者になれるでしょう。現代のデータベースはだいたいSQLかそれのパチモンが備わっています。SQLができると仕事の幅が広がるでしょう。
そしてJavaScriptは勉強しておきましょう。Webブラウザは全部JavaScriptが動きます。JavaScriptを勉強することでWebページで遊ぶことができるようになります。スクレイピングなどの理解も深まります。JavaScriptは便利です。
さて、ここまで来たら仕事に必要なプログラミングは身についているので次に進む必要は無いです。コンピュータの気持ちを理解するためにはC言語をかじってみるのもいいでしょう。大企業で働きたいならJavaは必須です。型に興味を持ったらOCamlやHaskellに手を出してみても良いでしょう。システムプログラミングをしたいならGoやRustも良いです。Goはバカみたいに簡単ですがRustは初心者向きではないです。
Scala や Elm と Lisp やら Haskell と OCaml に SML と関数型のプログラミング言語を勉強したけど、これらが命令型言語に劣る理由を解説しよう。
これは、SQL も同じ問題を持っているが、関数型言語は「こういうふうに動いてね」という解釈をインタープリターやコンパイラが「推測する」必要があるのだ。つまり、書いているときにパフォーマンスをプログラマーが想像できない。
それが、現実的に厳しいのだよ。マジでコンパイラ関連は金にならない領域になってきたので、関数型言語のための独自コンパイラを作る持続可能な組織が無い。確かに、LLVM を使えば x64 や arm といった最新のアーキテクチャに対応できるかもしれないけど、フロントエンドのレベルすら応対が辛い。よって、関数型言語は C言語にてチューリング完全な同等なコードだと「いくら最速に書いても」遅いのである。
例えば if と書いたら、関数型言語は else が必須ですが、命令型言語は else 無しでも動いちゃうのですね。文系の連中が数学的な背景を加味して要件定義できると思うか？違うだろ。毎回、上に else のことについて聞いたら、プログラマーの生産性は下がるだろ。関数型言語は、上が文系だとますますだが、分岐もきっちりとおさえる必要があるから、生産性は命令型言語に劣るよ。
やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。
話し合い、耳を傾け、承認し、任せてやらねば、人は育たず。
やっている、姿を感謝で見守って、信頼せねば、人は実らず。
まずは、あなた自身がプログラマーになって、見本を見せることが第１歩です。
その後受託系の会社に就職できたのだけど、人間関係がうまくいかなかったようで数ヶ月で辞めた。
鬱病気味になったみたい...。
どうやら、プログラミングという仕事の特徴について、あなたは理解していないようですね？
プログラミングの特徴は、「コンピューターが相手なので、嘘やハッタリが一切通用しない」ということです。
人間相手なら、適当に指示を出したり、いい加減な対応でも何とかなるけど、コンピューター相手だと1mmも融通が利きません。
という3点が必要です。
警察に職務質問されて有名になった江添亮さんのブログ等を読んで、この方のようにネチネチと論理をこねくり回すのが好きなら、プログラマーに向いています。
(例)本の虫: 麻布十番で職務質問を受けた話 https://cpplover.blogspot.jp/2017/08/blog-post.html
プログラムというのは、小さな部品を組み合わせて、大きなシステムが作られています。
小さな部品がパズルのピースに相当して、大きなシステムがパズルの完成品です。
つまり、大きな問題を小さな問題に分解して、１つずつ順番に問題をつぶして行く姿勢が必要です。
があります。
命令型のプログラミング言語しか使えない人がプログラマーになると、テスト地獄に陥って、結果的に鬱病を発症しやすくなるだろうと危惧しています。
上述のように、パズルのピースを組み合わせてプログラムを作るには、「関数型」の作法を身に付けておくと良いでしょう。
関数型プログラミングを習得するために、今なら「Haskell」または「OCaml」というプログラミング言語をお勧めします。
HaskellやOCamlは、良い参考書がたくさんあるので、本屋に行って実物を確かめてください。
Haskellを学んでみて、パズルのピースを組み合わせる感覚が理解できたら、あなたはテスト地獄に苦しめられないプログラマーになれるでしょう。
もしも、Haskellが理解できないようだったら、残念ですがプログラマーには向いていないかもしれません。
（例外的に、あなたがマゾで、テスト地獄や残業、徹夜が楽しいと思える性格なら、Haskellが理解できなくても大丈夫かもしれません。）
Haskellの教材（英語）を紹介するので、参考までに読んでみてください。
http://learnyouahaskell.com/chapters
（このサイトの内容は、日本語の書籍「すごいHaskellたのしく学ぼう！」として出版されています。）
Haskellは、順番に学べば必ず理解できるようになっています。
もしも、Haskellが習得できなければ、大きな問題を小さな問題に分解して解決していく作業には不向きな性格かもしれないので、他の仕事も検討してはいかがでしょうか？
（人生は一度きり。時間の無駄にならないようにお気を付けください。）
あなたと友人が、無事Haskellを習得して、テスト地獄を乗り超えるスーパーハッカーになり、日本のIT産業を牽引されることに期待いたします。
（追記）
自分が作りたいプログラムすら作れない人が、他人が希望するプログラムを作るなんてできっこないからねｗ
（プログラマーが楽で簡単な仕事だと思ったら大間違いですよ？）
（追記 その２）
関数型プログラミングをマスターしておけば、OOPでも役に立つよ。（現実には、関数型もOOPも必要に応じて投入するし）
iOS→「プロトコル指向プログラミング」「RxSwift」、Android→「RxJava」辺りのキーワードでググってみて。
別に皮肉とか宗教戦争で煽ってるわけじゃなくて、自分も苦労して辿りついた口だから、今から始める人には遠回りして、余計な苦労を味わって欲しくない。
（追記 その３）
他の人が書いてたけど、１人でプログラミングするんじゃなくて、２人（ペアプログラミング）や３人以上（モブプログラミング）から始めたら良いかも。
Googleの「プロジェクト・アリストテレス」で、仕事の生産性を改善するには「心理的安全性」が重要と分かり、プログラミングの仕事もやり方が変わって来ています。
https://kuranuki.sonicgarden.jp/2017/01/psychological-safety.html
（追記 その４）
元記事が消えていたのでバックアップしておきます。（この投稿だけ読むと意味が分からなくなるため）
https://anond.hatelabo.jp/20170910205249
2017-09-10
■知り合いをプログラマにさせたいんだけど知恵を貸してくれ
プログラマって育休からの復帰しやすいだろうし、アルバイトよりは待遇いいし、勤怠ゆるいし、労力の割に楽ちんだと思うんだよね。
接客のバイトで消耗するくらいなら、プログラマになればいいと思っているのだが、その知り合いは自身のことをプログラミングを不向きと評価しているらしい。私は、プログラミングに限らず物事は時間をかければ習熟していくものだと思っているので、不向きではないと思うんだ。不向きというのは物理的に制限のある時だと思う。
その知り合いについて。
Vimはぎこちないけど使える。日常的にmacOSを使っていてターミナルの操作はできている。cd, ls あたりは理解している。
趣味を含めてアプリケーションを完成させた経験はないが、ifやfor文などの基本構文は理解している。数年前にプログラミングスクールのようなところに半年間通っていた。その後受託系の会社に就職できたのだけど、人間関係がうまくいかなかったようで数ヶ月で辞めた。鬱病気味になったみたい...。
何か成功体験があれば自然とのめり込んでと思うんだけどなかなかスイッチが入っていないみたい。
こちら側からは、プログラマーになれば？と直接は伝えてはなくて、素人でもプログラミングできましたみたいなネットの記事をシェアーしているくらい。(心理的リアクタンス避け)
知恵を貸して欲しい。
第一に、それは、ストリーム（FRPの値の定義）の問題であって、ユニットテストすれば良い。もしくは単にFRPのログを取れば良い。
グローバル変数ではそういうことはできない。FRPでは、岡部氏のFRPライブラリも特にそうだけど、基本的にミュータブルな値同士が関数でリアクティブに連携されて常に整合性を保っているのだから、グローバル変数の、各所で更新されたそれぞれの値によって全体の整合性が損なわれないように気を配らなければいけないという（テスト自体困難な）問題は発生しない。それがFRPの唯一とも言えるメリットだとも言える。
使用する関数の問題じゃないし、「印」として引数に加えても別に構わないと思うが、君のいうグローバル変数の問題と一緒というのはまったく違う。
いや、それがそもそもの発端であるとブログの経緯には書かれている。説明されている方式でGUIアプリまで書けるのか？と疑念が呈されたことがきっかけ。
この論点は聞いたことがない。岡部氏がこだわっているのは非手続き型の宣言型で、純粋がどうとか議論はされてないように思う。
あと、OCamlでGUIを状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね？
原理的に可能かという議論ではなく、実用的な範疇か？という議論。反対派ブログで出てきたコードは、本人が認めるように普通のやり方ではなく、実用的なコードだとは思えない。あと、FRPと状態渡しは同じ複雑さだという主張も崩されている。そこが重要。
段階を踏んだ上で、非FRPのHaskellのIOモナドのコードを誰かが書いたらいんじゃない？当面、最初はOCamlの話だったのに、いきなりHaskellやElmのコードで書いて、そういうのがごちゃまぜに、何がどの言語でできるのかできないのか、誤魔化しがあると見做されたから制限されたんでしょ。実際には、OCamlの関数型では冗長でしか書けないと実証されたけど、そういうのがバレないように、別の言語を利用していたと看破されて当然の状況だと俺は思うね。
関係ある。君ひとりは、そうじゃない、と君ひとりが言ってもそれが本当だとは確認のしようがないし、
定数って、プログラム中で更新不可能で、いつ読みだしても同じ値が出てくるから、グローバルでも問題無いんだよ。
ストリームは定数だ、って言ってみたところで、プログラム全体から更新可能なんじゃ、グローバル変数と同じでしょ？
バグがあって、ストリームに変な値が入った時、どこがバグなのか、追跡するのが困難でしょ？
なんで伝わらないんだろ。
複数人でプログラム開発したり、他人のプログラムをデバッグしたり、したこと無いんだろうか。
「純粋関数型」とは何か、という話と、とOCamlでそれが推奨スタイルか、って別の話だよね？
岡部氏との争いって「OCamlでGUIアプリを純粋関数型(状態渡し)で簡潔に書けるか」ってところじゃないよね？
純粋関数型とは何かといった時にHaskellのように、IOも含めて引数と戻り値で表現する、関数のふるまいが関数の外の状態に依存しない、関数に副作用が伴わないとかの性質をいうと思うんだけど、岡部氏はFRPで状態を関数の外部に持ってても純粋関数型だ、と言ってて、そこで争ってるんだよね？
あと、OCamlでGUIを状態渡しで書いたら簡潔で無いのを「書けない」、「不可能」って言ってるのはわざと印象操作しようとしてるよね？
Haskellで書けて、OCamlで冗長になっても、書けるなら「書ける」、「可能」だよね？
その発言が事実か確かめる術はないし、ここで岡部氏攻撃しているのは君ひとりなのか？他の人間まで一連の誹謗中傷集団ではない、す駱駝、住井が含まれていないみたいに断言する根拠は何か？
俺の書き込みが他人といきなり結び付けられたから、電波だな、と思ったの。
否。ストリームに限らず、定数は引数で与えなくても純粋関数型である、という見解はごく普通。
つまり、GUIになればもはや関数型では書けない、というのが推奨スタイルだ、って言ってるようなもので、OCamlベースでいくら関数型の講義やっても、最終的にはその関数型でまともなGUIアプリすら書けない、という批判でしょ。その批判が岡部氏からされたら、あたかも関数型で書ける、という強弁から生まれたのが「状態渡し」理論。それが無理筋だ、ということが今回実証された。
その発言が事実か確かめる術はないし、ここで岡部氏攻撃しているのは君ひとりなのか？他の人間まで一連の誹謗中傷集団ではない、す駱駝、住井が含まれていないみたいに断言する根拠は何か？
あのね、グローバル変数の欠点とは、それが「変数」だからなの。
ストリームを関数の外部に持つFRPを純粋関数型っていうのは少数派でしょ。
ユーザからの入力をリアルタイムに処理するプログラムにはFRPは有効だよね。
「OCamlでは」じゃないの？
全部純粋関数型(引数と戻り値に収める、状態渡し)にするのを良しとするHaskellと違って、OCamlは副作用も部分的に使うのが普通で、IOモナドみたいな入出力までも純粋に書くための道具立てが揃ってない、それでちょっと冗長になる、ってことでしょ？
OCamlの元々の推奨スタイルならもっと短く書けるんでしょ？
俺はそう読んだけど。
それっぽい書き込みほどそうやって、事実誤認だ、と強調するから、なんで当事者でもないのに、そんなことが断言できて、電波だということになるんだ？
だって駱駝でも住井でもない面識も無い俺の書き込みが住井扱いされるんだもの。
いやだから、どの関数で読み書きされようと、誰が書き換えようとも、時間にたいしてイミュータブルな定数なんだから、定数は定数なのよ。
http://okaml.blogspot.jp/2016/05/done2.html#more
↓
kenokabe氏に、
JavaScript+React+TimeEngineのFRP : 29行
kenokabe氏のFRPじゃ半分以下のコードで実装できたと、トドメをさされて終了
http://kenokabe-techwriting.blogspot.jp/2016/05/frptimeenginereactjsocaml.html
http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine.html
nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題をOcamlの関数型の状態渡しをもって実装してみせればいいだけだが、言い訳始めてるからな。
nonstarterはこの発言の時点では、Ocamlの関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。
しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。
そのうち、OCamlの実際的な環境じゃスケールしないという指摘がはいる。
nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない！」ってことなんだろｗ
しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリでお絵かきアプリを示して、
ついでに、ハードルを引き上げた。
nonstarterの言うとおり、
岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。
もちろん、他のHaskellやFRPは使うな、という至極当然の縛りつき。
http://anond.hatelabo.jp/20160520153948
そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、
nonstarterが、
と急に何故かいきなりHaskellを持ち出し、Haskellのコードを引っ張り出した。
いろいろとっちらかしてんじゃねーよ、ってことだろ。
OCamlではライブラリも足りず机上の空論だったという、ひとつの区切りはついた。
とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。
http://kenokabe-techwriting.blogspot.jp/2016/05/timeengine.html
nonstarterの言うことがハッタリじゃなければ、さっさとToDoListの課題をOcamlの関数型の状態渡しをもって実装してみせればいいだけだが、言い訳始めてるからな。
nonstarterはこの発言の時点では、Ocamlの関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。
しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。
そのうち、OCamlの実際的な環境じゃスケールしないという指摘がはいる。
nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない！」ってことなんだろｗ
しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリでお絵かきアプリを示して、
ついでに、ハードルを引き上げた。
nonstarterの言うとおり、
岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。
もちろん、他のHaskellやFRPは使うな、という至極当然の縛りつき。
http://anond.hatelabo.jp/20160520153948
そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、
nonstarterが、
と急に何故かいきなりHaskellを持ち出し、Haskellのコードを引っ張り出した。
いろいろとっちらかしてんじゃねーよ、ってことだろ。
OCamlではライブラリも足りず机上の空論だったという、ひとつの区切りはついた。
とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。
nonstarterはこの発言の時点では、Ocamlの関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。
しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。
そのうち、OCamlの実際的な環境じゃスケールしないという指摘がはいる。
nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない！」ってことなんだろｗ
しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリでお絵かきアプリを示して、
ついでに、ハードルを引き上げた。
nonstarterの言うとおり、
岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。
http://anond.hatelabo.jp/20160520153948
nonstarterのいうことが嘘ハッタリじゃないのならば、さっさとOCamlの関数型状態渡しでToDoリストアプリ書いて見せればいいだけ。
出来ない時点で終わってる。
nonstarterはこの発言の時点では、Ocamlの関数型の状態渡しに限界があることはお首にもだしていない。読んだものはそうだったのか、何でもできると思って不思議ではないだろう。
しかしなぜか、Haskellが急に登場する。別の言語の助けを求め始めた最初がここ。
そのうち、OCamlの実際的な環境じゃスケールしないという指摘がはいる。
nonstarterは、複雑性への限界を認めるが、同時に、FRPの足をひっぱることも忘れ得なかった。つまり「負けてない！」ってことなんだろｗ
しばらく有耶無耶にされていたが、お絵かきアプリもまだ書けないといか書かれているのを目撃した岡部氏が、すでに実装していた自作FRPライブラリでお絵かきアプリを示して、
ついでに、ハードルを引き上げた。
nonstarterの言うとおり、
岡部氏が示したFRPコードと同等のかんたんさで、OCamlでも出せるはずだ。
もちろん、他のHaskellやFRPは使うな、という至極当然の縛りつき。
そもそもの最初がesumiiやlambadaなどのOCamlユーザへむけての課題で、
nonstarterが、
と急に何故かいきなりHaskellを持ち出し、Haskellのコードを引っ張り出した。
いろいろとっちらかしてんじゃねーよ、ってことだろ。
OCamlではライブラリも足りず机上の空論だったという、ひとつの区切りはついた。
とこの点について「一般化」を試みた、誤魔化そうとしたのは、nonstarterだ。
