J'essaie de trouver tout ce qui discute lorsque vous devriez privilégier l'utilisation de monads sur des acteurs (dans des scénarios de concurrence), mais je n'ai rien trouvé. En particulier, je m'interroge sur l'utilisation des extensions réactives (Linq aux événements) contre la boîte aux lettres de la boîte aux lettres de F #. S'il vous plaît donner des exemples en plus de tout raisonnement philosophique que vous pourriez avoir.
Qu'est-ce que j'essaie de comprendre, c'est quand utiliser une monade (dans ce cas une monade de continuation) contre un modèle d'acteur à des fins de la concurrence. Où la monade (si je comprends) n'introduit pas l'état, l'acteur a son propre état interne modifié si nécessaire pour fournir un accès protégé.
J'ai vu un certain nombre d'exemples d'utiliser à la fois: Rx et Node.jode.js (CPS, pas vraiment la continuation de la MONAD) VS. F # 'S Cadre de messagerie et Scala's Akka Cadre. Je ne sais tout simplement pas pourquoi tu choisirais un sur l'autre.
4 Réponses :
S'il vous plaît excuser ma nouvelle-ness comme je vais juste apprendre f #.
Je suis intrigué pour voir l'utilisation de RX à la place d'un processeur de boîtes aux lettres, si vous avez des liens vers des matériaux pertinents.
avec ma compréhension limitée; Je choisirais que les MBP dans mon propre code, car les événements sont un peu désordonnés à installer en F # (de ce que je peux prendre de cet article: MSDN ). Et vous avez besoin d'événements pour RX pour accrocher à droite?
Où, comme avec un MBP, tout ce dont j'ai besoin, c'est une union discriminée de messages, une liste de fonctions que je souhaite être exécutée lorsqu'un message donné est reçu. Et le processeur de boîte aux lettres qui gère cela.
Tout cela a l'air assez soigné dans le code. Je peux regrouper mon MBP ensemble dans un module que mon module "objet" ressemble à
Pour moi, cela ressemble beaucoup à ce que ce serait si j'ai écrit mon code avec des événements comme décrit dans cet article de MSDN, je suis lié à.
Bien que je sois juste un f # junior, donc je suis peut-être miles avec mon compte et c'est un look - & - ressentez une chose plutôt que d'un choix de pertinence à l'intention (comme je ne suis pas qualifié pour faire cet appel , pourtant)
Selon la manière dont vous exposez vos événements, vous pouvez faire aussi peu que de déclarer un événement et de le renvoyer comme une méthode iobservable, avec la méthode de déclenchement () appelée à l'intérieur de la méthode de souscription, donc je ne pense pas que les événements sont aussi mauvais. Les MBP ont leur propre requête.
@JoDIG Ce que vous avez décrit est plus ou moins le modèle standard pour l'utilisation du MBP. Il existe différents exemples ici: FSSNIP.NET/TAGS/AGENT
Notez que vous pouvez même générer des observables à partir des différentes méthodes statiques intégrées. Je ne penserais pas que vous auriez besoin de configurer des événements du tout et le code serait plus idiomatique / fonctionnel Rx.
Je ne suis pas sûr que la question ait du sens, comme expressé, il existe de nombreuses monades différentes (par exemple, l'identité monade, la liste monade, l'option monade, ...), dont la plupart n'ont rien à voir avec la concurrence. En outre, il serait utile d'en savoir plus sur le scénario particulier que vous traitez - «Concurrence» est un peu un sujet nébuleux. En fonction de ce que vous essayez d'atteindre, f # 's Si vous utilisez F #, je recommanderais d'utiliser directement Linq-à-tout, car ces bibliothèques ont une sensation très étroite lorsqu'elles ont accès via F #. Vous pouvez cependant créer des wrappers F # agréables (tels que le async workflows (qui sont construits sur le async monad) pourraient être votre meilleur choix.
SEQ et observable modules). De plus, pour les types monadiques, vous pouvez créer un constructeur d'expression de calcul (par exemple, vous pouvez créer un constructeur à l'aide des extensions réactives, ce qui vous permettrait d'utiliser des expressions de calcul pour créer et composer iobservable s).
Je connais avec les options. Je suis curieux de savoir pourquoi et quand vous devez en choisir un sur l'autre. Cela peut être une chose de préférence, mais je pensais essayer de mieux comprendre. Pour certains emballages F # aux rx, consultez mon bitbucket repo: bitbucket.org/resser01/fsharp.reactive
On dirait que vous comparez un qui dispose d'un magasin de support qui peut être rempli de manière indépendante du calcul (MBP), contre celui qui ne le fait pas (SEQ / Observable). Ce sont des situations très différentes et seraient des applications spécifiques.
Je vais répondre à ma propre question et dire que vous devriez utiliser les deux. Ceci est basé sur POST DE DON SYME . Un MBP utilise le calcul ASYNC pour faire ses travaux et l'ASYNC est une continuation au fil monade. On dirait que vous pouvez l'utiliser seul pour certaines utilisations, mais le MBP l'exige certainement.
Je n'aime pas vraiment cette réponse, et je serais heureux que quelqu'un réponde avec une meilleure explication de quand utiliser chacun.
mis à jour:
voir minirx , qui est maintenant à part FSHARPX , pour une mise en œuvre d'une monade de style RX implémentées à l'aide de MailboxProcessor . Comme MailboxProcessor est en soi mis en œuvre à l'aide du async monade, ceux-ci ont pour effet de travailler ensemble. Ce sont juste des moyens différents d'abstraction.
Accepteriez-vous des réponses du monde Scala?
Si vous recherchez "une alternative purement fonctionnelle au modèle d'acteur", veuillez consulter cet excellent article du blog de Paul Chiusano
PCHIUSANO.Blogspot.ro/2010 /01/actors-are-not-good-concurrency-model.html (Archivé ici: http://archive.is/nxnlc )
et quelques références ci-dessous:
http: // noelwelsh. Com / Programmation / 2013/03/04 / Pourquoi-i-net-pas-a-akka-acteurs /
Les acteurs ne composent pas Les acteurs de Akka ne sont pas utilement typés Le système de type est la raison pour laquelle nous utilisons Scala.
https://opendedo.com/akka-typed/
Malheureusement, l'API actuelle souffre de quelques inconvénients, qui sont à un bon degré associé au manque de sécurité de type
http://doc.akka.io/docs/akka /snapshot/scala/typed.html
statut de ce projet et relation avec les acteurs AKKA Akka dactylographié est le résultat de nombreuses années de recherche et de tentatives précédentes (y compris des canaux dactylographiés dans la série 2.2.x) et il est sur le point de stabiliser, mais étant une modification aussi profonde du concept de base d'Akka prendra longtemps.
Un effet secondaire de ceci est que les comportements peuvent maintenant être testés isolément sans avoir à être emballé dans un acteur, les tests peuvent fonctionner de manière totalement synchrone sans avoir à se soucier des délais d'attente et des défaillances parasites. Un autre effet secondaire est que les comportements peuvent être joliment composés et décorés
Architecture de l'application composable avec des monads à prix raisonnable
- https://youtu.be/m258zvn4m2m?t=1955
- https://youtu.be/m258zvn4m2m?t=1986
Le concept de "mode de passage de la fonction" de Heather Miller pourrait être la clé d'un modèle de programmation fonctionnel distribué.
Ce sera probablement complètement inutile pour vous depuis que je ne connais pas F # et ne comprendra pas vraiment où votre question provient, mais j'ai écrit une implémentation de modèle d'acteur à Haskell qui utilise Monad Stack (un calcul de l'acteur est un lecteur / Io monade): Hackage.hakell.org/packages/archive/Simple-actors/0.1.0/doc / ...
Phil TRELFORD a également créé une implémentation de RX utilisant des acteurs , il semblerait donc que, selon ce que vous faites, vous pouvez mettre en œuvre des acteurs à l'aide de monads ou de monads utilisant des acteurs.
Un autre "pourrait ne pas être utile pour toi" pièce. J'ai déjà souligné que le but principal de RX n'est pas d'introduire une concurrence, mais de l'aborder. Tandis que l'on peut considérer que l'agent F # est un moyen approprié d'introduire une concurrence.