Monaden und Schauspieler

Ich habe versucht, alles zu finden, das diskutiert, wenn Sie die Verwendung von Monaden über Akteure bevorzugen (in Parallelitätsszenarien), aber ich habe nichts gefunden. Insbesondere frage ich mich über die Verwendung der Reactive Extensions (LINQ to Events) vs F # 's MailboxProcessor. Bitte geben Sie Beispiele zu philosophischen Überlegungen, die Sie haben könnten.Monaden und Schauspieler

Update Für einen besseren Kontext implementieren die Reactive Extensions die Continuation Monad in Form von IObservable/IObserver. Ich sage nicht unbedingt, dass ich F # verwenden muss, nur dass F # ein konkretes "Akteurmodell" in einer .NET-Sprache in Form von MailboxProcessor < 'T> hat.

Was ich versuche zu verstehen, ist, wenn eine Monade (in diesem Fall eine Fortsetzung Monade) gegen ein Akteurmodell für den gemeinsamen Zugriff verwendet wird. Wo die Monade (wie ich es verstehe) keinen Staat einführt, hat der Akteur seinen eigenen internen Zustand, der so modifiziert wird, dass er einen geschützten Zugang bietet.

Ich habe eine Reihe von Beispielen für die Verwendung von beiden gesehen: Rx und node.js (CPS, nicht wirklich die Fortsetzung monad) vs. F # MailboxProcessor und Scala Akka-Framework. Ich weiß einfach nicht, warum du dich für eines entscheiden würdest.

Quelle

2010-08-30 Anonymous

Dies wird wahrscheinlich für Sie völlig nutzlos sein, da ich f # weiß nicht, und nicht wirklich verstehen, wo Ihre Frage kommt, aber ich schrieb, die eine Schauspieler Modellimplementierung in Haskell Verwendung von Monade macht stack (eine Actor-Berechnung ist eine Reader/IO-Monade): http://hackage.haskell.org/packages/archive/simple-actors/0.1.0/doc/html/Control-Concurrent-Actors.html – jberryman

[Phil Trelford ] (http://twitter.com/ptrelford) hat auch eine Implementierung von [Rx mit Schauspielern] (http://minirx.codeplex.com/) erstellt, so dass es scheint, dass, je nachdem, was Sie tun, Sie könnte Akteure mit Monaden oder Monaden unter Verwendung von Schauspielern implementieren. –

Ein weiteres Stück, das Ihnen vielleicht nicht behagt. Ich habe einmal darauf hingewiesen, dass der primäre Zweck von Rx nicht darin besteht, Nebenläufigkeit einzuführen, sondern sie anzugehen. Während man F # -Agenten als einen geeigneten Weg betrachten kann, um Nebenläufigkeit einzuführen. –

Ich werde auf meine eigene Frage antworten und sagen, dass Sie beide verwenden sollten. Dies basiert auf Don Syme's post. Ein MbP verwendet die Async-Berechnung, um seine Arbeit zu erledigen, und der Async ist eine Thread-bewusste Fortsetzungs-Monade. Sieht so aus, als ob du es für einige Zwecke selbst benutzen kannst, aber der MbP benötigt es definitiv.

~~Ich mag diese Antwort nicht wirklich, und ich würde mich freuen, wenn jemand mit einer besseren Erklärung darüber antwortet, wann ich sie verwenden soll.~~

Aktualisiert:

MiniRx Siehe, die für eine Implementierung eines Rx-Stil Monade jetzt abgesehen von FSharpx ist MailboxProcessor realisiert. Da MailboxProcessor selbst unter Verwendung der async Monade implementiert wird, arbeiten diese tatsächlich zusammen. Sie sind nur verschiedene Abstraktionsmittel.

Quelle

2011-02-07 20:26:23

Bitte entschuldigen Sie mein Neuling, da ich gerade F # lerne.

Ich bin fasziniert zu sehen, die Verwendung von RX anstelle eines MailboxProcessor, wenn Sie Links zu relevanten Materialien haben.

Mit meinem begrenzten Verständnis; Ich würde MbPs in meinem eigenen Code wählen, da die Ereignisse ein bisschen unordentlich sind, um in F # einzurichten (von dem, was ich von diesem Artikel nehmen kann: MSDN). Und Sie brauchen Ereignisse, damit sich RX richtig einklinken kann?

Wo ich mit einem MbP alles brauche, ist eine diskriminierte Vereinigung von Nachrichten, eine Liste von Funktionen, die ich ausführen möchte, wenn eine bestimmte Nachricht empfangen wird. Und der Mailbox-Prozessor, der das handhabt.

Das sieht alles ziemlich hübsch im Code aus. Ich kann Haufen mein MBP zusammen in einem Modul dann mein „Objekt“ Modul sieht aus wie

Rekord
Nachricht DU
Wrapper mit einigen Getter und Setter, die Daten an die MBP

schreiben Für mich sieht das viel besser aus als wenn ich meinen Code mit Ereignissen schreiben würde, wie sie in dem MSDN-Artikel beschrieben sind, mit dem ich verlinkt bin.

Obwohl ich nur ein F # junior bin, so kann ich mit meiner Rechnung meilenweit entfernt sein und es ist ein Look-& -Essen Sache eher als eine Eignung für den Zweck Wahl (wie ich nicht qualifiziert, das zu machen ruf an, aber)

Quelle

2010-08-30 10:07:16 jdoig

Je nachdem, wie Sie Ihre Ereignisse bereitstellen, können Sie mit der in der Subscribe-Methode aufgerufenen Trigger() -Methode so wenig wie ein Ereignis deklarieren und es als IObservable zurückgeben. Daher sind Ereignisse nicht so schlimm. MbPs haben ihre eigenen Anforderungen. –

@jdoig Was Sie beschrieben haben, ist mehr oder weniger das Standardmuster für die MbP-Nutzung. Es gibt verschiedene Beispiele hier: http://fssnip.net/tags/Agent – 7sharp9

Beachten Sie, dass Sie Observables sogar aus den verschiedenen integrierten statischen Methoden generieren können. Ich würde nicht denken, dass Sie jemals irgendwelche Ereignisse einrichten müssten, und der Code würde mehr idiomatische/funktionale Rx sein. –

Ich bin mir nicht sicher, ob die Frage Sinn ergibt - es gibt viele verschiedene Monaden (zB die Identitätsmonade, die Listenmonade, die Option Monade, ...), von denen die meisten nichts haben mit Nebenläufigkeit zu tun haben. Darüber hinaus wäre es hilfreich, mehr über das spezielle Szenario zu erfahren, mit dem Sie es zu tun haben - "Nebenläufigkeit" ist ein etwas nebulöses Thema. Je nachdem, was Sie erreichen möchten, sind die Workflows von F # async (die auf der Async Monade basieren) die beste Wahl.

Wenn Sie F # verwenden, empfehle ich die direkte Verwendung von LINQ-to-everything, da diese Bibliotheken beim Zugriff über F # sehr fremdartig wirken. Sie könnten jedoch angenehme F # -Wrapper erstellen (z. B. die vorhandenen Module Seq und Observable). Darüber hinaus könnten Sie für monadische Typen einen Builder für Berechnungsausdrücke erstellen (z. B. können Sie mithilfe der Reaktiven Erweiterungen einen Builder erstellen, mit dem Sie mithilfe von Berechnungsausdrücken IObservable erstellen und verfassen können).

Quelle

2010-08-30 16:28:22 kvb

Ich bin mit den Optionen vertraut. Ich bin neugierig, warum und wann du eines über das andere wählen solltest. Das mag eine Vorliebe sein, aber ich dachte, ich würde versuchen, ein besseres Verständnis zu bekommen. Für einige F # zu Rx-Wrapper, überprüfen Sie mein bitbucket Repo: http://bitbucket.org/riles01/fsharp.reactive –

Es scheint, als ob Sie eine vergleichen, die einen Backing-Speicher hat, der unabhängig von der Berechnung (MbP), gegen eine, die nicht (Seq/Observable). Dies sind sehr unterschiedliche Situationen und wären anwendungsspezifisch. – 7sharp9

-1

Würdest du Antworten von der Scala-Welt akzeptieren?

Wenn Sie "eine rein funktionale Alternative zum Schauspieler-Modell" suchen dann finden Sie in diesem großen Beitrag von Paul Chiusano Blog

pchiusano.blogspot.ro/2010/01/actors-are-not-good-concurrency-model.html (Archiv hier: http://archive.is/NxNLc)

und einige Referenzen unter:

http://noelwelsh.com/programming/2013/03/04/why-i-dont-like-akka-actors/

Schauspieler komponieren nicht Ak ka's Actors sind nicht sinnvoll typisiert Das Typsystem ist der Grund warum wir Scala benutzen.

https://opencredo.com/akka-typed/

Leider leidet die aktuelle API von wenigen Nachteile, die zu einem guten Grad sind mit dem Mangel an Typsicherheit assoziiert

http://doc.akka.io/docs/akka/snapshot/scala/typed.html

Status dieses Projekts und Beziehung zu Akka Actors Akka Type ist th Das Ergebnis jahrelanger Forschung und früherer Versuche (einschließlich Typed Channels in der 2.2.x-Serie) und es ist auf dem Weg zur Stabilisierung, aber eine derart tiefgreifende Veränderung des Kernkonzeptes von Akka zu reifen, wird noch lange dauern

Ein Nebeneffekt davon ist, dass Verhaltensweisen nun isoliert getestet werden können, ohne dass sie in einen Actor gepackt werden müssen. Tests können vollständig synchron ausgeführt werden, ohne sich um Timeouts und falsche Fehler kümmern zu müssen.Ein weiterer Nebeneffekt ist, dass Verhaltensweisen schön komponiert und dekoriert werden können

Composable application architecture with reasonably priced monads

Das Konzept der "Funktion Übertragungsstil" von Heather Miller könnte sein, Schlüssel zu einem verteilten funktionalen Programmiermodell.

SF Scala: Heather Miller, Function-Passing Style, A New Model for Distributed Programming

Quelle

2016-09-11 07:12:08 SemanticBeeng

Antwort

Verwandte Themen