はじめに

関数型言語は、そのシンプルさ、明快さ、および予測可能性が大好きです。 私は主にElixir / Erlang / OTPで書いて、他の言語を試しましたが、Erlangとそのアクターは、例えばLispやHaskellよりもずっと身近です。 ご存じのように、Erlang == webであり、Web用に作成されたものには、クライアント側のWebインターフェイス（html、css、js-content）が含まれることがあります。 残念ながら、jsは現代のWebの標準です。ほとんどすべての場合、ほぼすべてのタスクに対応するライブラリがあり、これが多かれ少なかれ、クライアント側のブラウザーで何かを行うための唯一の利用可能なツールです。 したがって、まだjsが必要です。 最初は、「ラムダと高階関数があるので、jsで書くのは簡単です。 Erlang / Lisp / Haskellで書いているように構文を学び、書いていきます。 私がどれほど間違っていたか。

言語を選択してください

そもそも、純粋なjsはコードの記述にはまったく適していません。 豊富なブラケットとセミコロンが目の波紋から。 関数の本体のどこかに書かれた「return」という言葉は、言語の命令性を暗示する完全に不透明なヒントであり、私の最高の信念を破壊します。 を含む多くの言語があります jsでコンパイルされた機能的（ purescript 、 fay 、 clojurescript ）。 しかし、私自身のために、私はcoffeescriptを選択しました。これは、機能者と大将軍の両方が理解できるかなり妥協したオプションです。 部分的に、この選択は、私がプロジェクトを構築するためにcoffeescriptで書かれたbrunchを使用するという事実によって正当化されました。 たとえば、fayと比較すると、jsからcoffeescriptに切り替えるオーバーヘッドはほぼ0です。

フレームワークの選択

2番目の興味深い質問は、コードとhtmlページを接続する方法です。 本当に多くのオプションがあります。 実際にはかなり全体的に見える巨大なフレームワークがたくさんあります。 私自身はしばらくの間angularjsを使用していましたが、いくつかの練習の後、明らかな欠点が明らかになりました：何かをするためには、ディレクティブが必要です。そうでない場合は、独自のバイクを書く必要があり、角度の内部構造を理解することは見た目よりも難しいです率直に見てください-最も一般的に使用されるng-modelディレクティブは双方向データとプレゼンテーションバインディングを提供します。ファンクタの観点からは、これらはすべての角度アプリケーションに加えて、イデオロギー的に完全に不正確であり、一般的にカプセル化に違反します スクーターなどは、コードに大きな重みを付けています。 はい、ところで、角度の性能は本当にまあまあです。 少し前に私はリアクションjsに会いました-そして、私の選択は彼に落ちませんでした。 このアイデアは、そのシンプルさと多かれ少なかれ機能的な宣言スタイルに感銘を受けます。 アプリケーションの操作中に何らかの形で変化する可能性のある状態があります。 レンダリングのために時々jreactに渡すだけです。

widget = require("widget") do_render = () -> React.render(widget(state), domelement) if domelement? render_process = () -> try do_render() catch error console.log error setTimeout(render_process, 500)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それだけです！ 非常にシンプルで効果的。 React自体がレンダリングの最適化を処理しますが、この問題にはまったく関心がないかもしれません。 機能パラダイムと一致するように状態オブジェクトが変更されることを保証するために残ります。 そして、ここから楽しみが始まります。

キッチンのトラブル

最初の、それほど重要ではない問題は、ソフトjs型です。 アーランではもちろん柔らかくもありますが、jsでは表現が大変申し訳ありません。 たとえば、このトピックに関するあまり有益ではないが、かなり面白いビデオです。 しかし、実際には、型変換はめったに行われません（少なくともコードが良い場合）。だから、私はソフトjs型を多かれ少なかれそのまま受け入れました。



私がjsで少し練習し始めたとき、最初はすべてが多かれ少なかれ良かったのですが、ある時点で何らかの理由でアプリケーションが思い通りに機能しなくなりました。 さらに深く登ると、恐ろしいものが見えました。

 coffee> map = {a: 1} { a: 1 } coffee> lst = [] [] coffee> lst.push map 1 coffee> map.a = 2 2 coffee> lst.push map 2 coffee> map.a = 3 3 coffee> lst.push map 3 coffee> lst [ { a: 3 }, { a: 3 }, { a: 3 } ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、私は確かに見ると期待していましたが

 coffee> lst [ { a: 1 }, { a: 2 }, { a: 3 } ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

本当にショックでした。 ビンゴ、jsのデータは変更可能です！ そして判明したように、数字、文字列、null、未定義よりも複雑なものはすべて参照渡しされます！



しかし、私はそれを見たとき

 coffee> [1,2,3] == [1,2,3] false coffee> {a: 1} == {a: 1} false
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それから私の髪はいろいろな場所で動いた。 この人生は私を準備しませんでした。 jsのデータ型マップとリストは、値ではなく参照によって比較されます。



私はどうあるべきかを考え始めました。 たとえば、可変性に関して、定数データをアリティゼロのラムダ関数でラップする（たとえば、値を初期化する）ことが決定されました。そのような場合、それらは一般に可変ではありませんでした。 それらを必要とする式で単純に呼び出すことができ、それら（データ）が変更されることを恐れることはありません。

 coffee> const_lst = () -> [1,2,3] [Function] coffee> new_lst = const_lst().concat([4,5,6]) [ 1, 2, 3, 4, 5, 6 ] coffee> const_lst() [ 1, 2, 3 ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

原則として、すべてのデータがラムダで再帰的にラップされる場合、すべての関数がラムダを取り、ラムダを返す場合、言語は本当に機能するようになると思いました！ 原則として、これは解決策です。 通常の型に基づいてこれらのラムダデータ型を記述し、通常のjs型への再帰的な順方向および逆方向変換のための関数を記述するだけでなく、これらのラムダ型（map、reduce、filter、zipなど）を操作するための高階関数を記述する必要があります。 同時に、ちなみに、これらの新しいタイプは柔らかくすることはできません。 原則として、問題は解決可能ですが、このライブラリですでに実装されている方法などにより、かなり膨大です。 しかし、このアプローチには非常に重大な欠点があります。



1）私たちのコードは通常空中に中断されませんが、他のjsライブラリに依存しているため、それらに目を向けるたびに、ラムダ型を通常型に、またはその逆に変換することを忘れないでください。

2）このアプローチでは、もちろん、関数の純度とデータの不変性をある程度保証しますが、トランザクション性はありません。

3）このようなコードは、命令型アプローチを好む人にはあまり明確ではありません



したがって、私はこのアイデアを放棄しました（しかし、将来的には注意する必要があります）。 明らかに、可変性の問題を局所的に解決し、参照によってデータを比較するために、jsデータを値によって再帰的にコピーして比較する方法を学ぶ必要がありました。



クローン関数を書きます

 clone = (some) -> switch Object.prototype.toString.call(some) when "[object Undefined]" then undefined when "[object Boolean]" then some when "[object Number]" then some when "[object String]" then some when "[object Function]" then some.bind({}) when "[object Null]" then null when "[object Array]" then some.map (el) -> clone(el) when "[object Object]" then Object.keys(some).reduce ((acc, k) -> acc[clone(k)] = clone(some[k]); acc), {}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

イコール関数を書きます

 equal = (a, b) -> [type_a, type_b] = [Object.prototype.toString.call(a), Object.prototype.toString.call(b)] if type_a == type_b switch type_a when "[object Undefined]" then a == b when "[object Boolean]" then a == b when "[object Number]" then a == b when "[object String]" then a == b when "[object Function]" then a.toString() == b.toString() when "[object Null]" then a == b when "[object Array]" len_a = a.length len_b = b.length if len_a == len_b [0..len_a].every (n) -> equal(a[n], b[n]) else false when "[object Object]" keys_a = Object.keys(a).sort() keys_b = Object.keys(b).sort() if equal(keys_a, keys_b) keys_a.every (k) -> equal(a[k], b[k]) else false else false
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

思ったよりも簡単でしたが、唯一の「しかし」データに循環リンクがある場合、もちろんスタックオーバーフローが発生します。 私にとって、これは基本的に問題ではありません。「循環参照」などの抽象化を使用していないからです。 データクローニングのプロセスで何らかの方法で処理することは可能だと思いますが、もちろんコードはそれほど単純でエレガントではありません。 一般的に、これらの関数とライブラリの他のいくつかの関数を収集し、jsのデータの可変性の問題はしばらくの間解決されたと思います。

俳優

次に、トランザクションデータの変更が必要な理由について説明します。 多かれ少なかれ複雑な状態があり、関数を実行するプロセスでそれを変更するとします。

 state.aaa = 20 state.foo = 100 state.bar = state.bar.map (el) -> baz(el, state)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際には、状態を変更するプロセスはもちろん、より複雑で時間がかかり、外部APIへの非同期呼び出しなどを含むことができます。 しかし、要点は、どこかで状態を変更するプロセスのどこかで、func（状態）関数が呼び出された場合です-何が起こるのでしょうか？ 半分変更された状態は有効ですか？ または、半修正状態のシングルスレッドjsが原因で、まったく存在せず、すべてが正常ですか？ そうでない場合は？ また、外部呼び出しを行う必要があり、状態を変更する間、それが不可欠である場合はどうすればよいですか？ このような難しい質問を解決するために、状態の変更をトランザクション化します。



その後、多くの人がミューテックスについて覚えていると思います。 ミューテックスも思い出しました。 そして、レース条件について。 そして、デッドロックについて。 そして、私はこれをまったく望んでいないことに気付いたので、ミューテックスを作成しませんが、Erlang言語から「actor」の概念を借用します。 jsのコンテキストでは、アクターは特定の状態によって初期化されるオブジェクトの一種であり、3つのことのみを行います



1）アリティ関数1または0の形式で「メッセージ」を受信し、キューに追加します

2）独立してメッセージキューを「レイク」し、内部状態にアリティ関数1を適用します（アリティ関数0が単に呼び出され、状態は変化しません）-これらはすべて、メッセージが受信された順序で厳密に行われます。

3）要求に応じて、その内部状態の値を返す



当然、データの非可変性を維持するために、変更するたびに状態を複製し、get関数では状態自体ではなく、そのコピーを返します。 このため、以前に作成したライブラリを使用します。 その結果、コードを取得します。

 window.Act = (init_state, timeout) -> obj = { # # priv # state: Imuta.clone(init_state) queue: [] init: () -> try @state = Imuta.clone(@queue.shift()(@state)) while @queue.length != 0 catch error console.log "Actor error" console.log error this_ref = this setTimeout((() -> this_ref.init()), timeout) # # public # cast: (func) -> if (func.length == 1) and Imuta.is_function(func) @queue.push(Imuta.clone(func)) @queue.length else throw(new Error("Act expects functions arity == 1 (single arg is actor's state)")) zcast: (func) -> if (func.length == 0) and Imuta.is_function(func) @queue.push( ((state) -> Imuta.clone(func)(); state) ) @queue.length else throw(new Error("Act expects functions arity == 0")) get: () -> Imuta.clone(@state) } obj.init() obj
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

*ラムダをキューに入れる関数は、Erlangのhandle_cast関数と同様に、castおよびzcastと呼ばれます



すべてのjs-dataが複製可能であるわけではないため（循環リンクと外部ライブラリを思い出してください）、内部状態のクローンを削除し、すべてをライブラリに収集するアクタのコンストラクタの別のバージョンを作成します 。



お楽しみください：

 coffee> actor = new Act({a: 1}, "pure", 500) { state: { a: 1 }, queue: [], init: [Function], cast: [Function], zcast: [Function], get: [Function] } coffee> actor.cast((state) -> state.b = 1; state) 1 coffee> actor.get() { a: 1, b: 1 } coffee> actor.cast((state) -> state.c = 1; state) 1 coffee> value = actor.get() { a: 1, b: 1, c: 1 } coffee> value.d = 123 123 coffee> value { a: 1, b: 1, c: 1, d: 123 } coffee> actor.get() { a: 1, b: 1, c: 1 } coffee> actor.zcast(() -> console.log "hello") 1 coffee> hello coffee> actor.get() { a: 1, b: 1, c: 1 } coffee> global_var = {foo: "bar"} { foo: 'bar' } coffee> actor.cast((_) -> global_var) 1 coffee> actor.get() { foo: 'bar' } coffee> global_var.baz = "baf" 'baf' coffee> global_var { foo: 'bar', baz: 'baf' } coffee> actor.get() { foo: 'bar' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべての状態変更は、キャスト関数を使用してキューを介して排他的に実行されます。 「純粋な」バージョンでわかるように、get関数から取得した後の状態に関係なく、状態はアクター内に完全にカプセル化されます（外部からキャスト関数に何かを追加した場合も同様です）。 トランザクションはメッセージキューによって提供されます。 jsでのみ、ほとんどErlangianコードを取得しました。 何らかの理由で状態でクローンされていないデータを使用する場合は、グローバル状態で「ダーティ」バージョンのアクターを使用します。 原則として、そのようなオプション（アクターを介して厳密に状態を変更する場合）でも受け入れられ、データのトランザクションの変更を提供します。 トランザクションだけでなく、ある意味でアトミックでさえ、データの変更を1つのラムダではなく3つ（たとえば、外部ライブラリでの何らかの実行の場合）に転送するという考えがありました。

 actor.cast( { prepare: (state) -> prepare_process(state) apply: (state, args) -> do_work(state, args) rollback: (state, args) -> do_rollback(state, args, error) })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、私はこれがすでに過剰だと思った、特に現在のバージョンでは、あなたは単に書くことができるので

 actor.cast((state) -> args = init_args(state) try do_work(state, args) catch error rollback(state, args, error))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

原子性が非常に重要な場合。

おわりに

Jsは私が最初に思ったほど絶望的ではないことが判明しました。 ラムダ関数の背後には実際の機能的なパワーがあり、適切なレベルの器用さで、かなり宣言的なスタイルで記述できます。 そしてまず、俳優+反応+玉+サス+弾丸（Erlang websockets）を使用した簡単な例です。 機能を維持し、ウェブを維持します！

UPD

Habrの住人は、私のコードの多くの重大なエラーを指摘しました。これに感謝します:)欠点を修正しました、すなわち：



1）クローンバインディング関数を、より適切で明白な関数クローニング操作に置き換えました

2）equal関数では、最初に、パフォーマンスを向上させるはずのかなり明白なチェックを追加しました:)

3）値func.toString（）による関数の愚かなチェックを削除しました 。

4）配列を比較するとき、おそらく再定義されたフィールド長を使用せず、単に要素を数えます

5）オブジェクトを保存するとき、「Object.keys」関数を使用せず、オブジェクトからすべてのキーを収集します。 ある意味では、コードはさらにスリムで機能的になりました。



このコードの改善に貢献してくれたすべての人に感謝します。 ライブラリの現在のバージョンは、 こことここにあります 。 私はあなたの希望と提案を聞いてうれしいです。