私はこの記事を読んでいました:
http://www.doc.ic.ac.uk/~nd/surprise_97/journal/vol2/pjm2/
そしてそれはそれについて言及しています:
...アクターモデルでは、整数もアクターとして表されます...
ウィキペディアは確認します:
Actorモデルは、すべてが俳優であるという哲学を採用しています。
Erlangには多くのデータ型があり、これらの型は私が知る限りではアクターではありません。
Erlangがアクターモデル言語ではないという意味ではありませんか。 Javaは、特定の関数型プログラミング機能が欠けているからといって、関数型言語ではありませんか?
PS:つまり、ホスト言語からの非俳優データ型に加えて、継承アクターがホスト言語機能を介して動作を拡張することもできるため、Akkaは明らかに俳優モデルではありません。
Actor ModelはErlangより古いですが、Erlangの設計者はErlangを設計した後に初めてActor Modelについて学びました。そのため、いくつかの違いが予想されます。
しかし、彼らは進化の平行した道をたどりました:アクターモデルは、Smalltalkのメッセージパッシングセマンティクスに基づいてカールヒューイットによって作成されました。 Alan Kayは、Smalltalkのメッセージパッシングセマンティクスを、…Carl Hewittによって設計されたPLANNERの目標駆動型評価に基づいていました。
PLANNERはPrologの前身でした。 Erlangは元々言語を意図したものではなく、Prologのフォールトトレラント分散プログラミング用のライブラリとして始まり、その後Prologの方言に発展し、その後独自の言語になりましたが、今でもPrologの影響を強く受けています。 (さらに、元のErlangインタープリターはPrologで作成されました)。
したがって、Erlangのプロセス、OOのオブジェクト、アクターモデルのアクターの類似点は、偶然ではありません。
Erlangは複数のレイヤーを持つ言語であり、それぞれが下位レイヤーのスーパーセットです。最小のレイヤーはFunctional Erlangです。これは、Prologから継承されたいくつかの追加機能を備えた標準の関数型言語です。たとえば、結合/等価ではなく、統合などです。これにProcessesおよびMessagesを追加すると、Concurrent Erlangが得られます。リモートプロセスをスローすると、Distributed Erlangが得られます。次に、OTPからいくつかのライブラリーと設計パターンを追加すると、フォールトトレラントなErlangが作成されます。
プロセスはアクターです。 (これらもオブジェクトです。)プロセスのinsideは、Actorベースではなく、Functionalです。 OTPのツールとパターンを使用して構築された大規模なフォールトトレラントErlangシステムの構造は、多くの場合、非常にオブジェクト指向です。
したがって、それはあなたが見ているスケールに依存します。
典型的な大規模なErlangシステムでは、関数型プログラミングを使用して実装されたメッセージ受け渡しアクターを備えたオブジェクト指向アーキテクチャーがあります。 OTPがserver
と呼ぶものはオブジェクトと密接に関連しています。server
sはプロセス(アクター)で構成され、プロセスは内部で関数を使用します。
一般に、純粋なアクター言語が研究から離れたことはないと思います。ヘック、カールヒューイットのプラズマ、オリジナルアクター言語が実装されたことさえありません。