Async F # CCR vs. cadre

Question

Après avoir lu CCR: http://www.infoq.com/news/ 2008/12 / CCR J'ai l'impression qu'il fait à peu près exactement la même chose que F # async blocs?

Vous cédez port.Receive et port.Test afin de faire la même chose que « laisser! ».

Est-ce exact? Et ce qu'il ya des avantages à CCR que vous ne recevez pas avec F # async?

Answer 1

L'exemple dans l'article que vous avez mentionné ressemble vraiment comme let! de flux de travail asynchrones. En général, le mot-clé yield return en C # permet de motifs encodent similaires à F expressions # de calcul (d'une manière bizarre, car il a été conçu pour créer des agents recenseurs):

• Ceci est également utilisé par AsyncEnumerator , qui est (à mon humble avis ) plus simple que la CCR et un peu plus près de F # asynchrone des flux de travail
• J'ai écrit un article qui explique cette similartiy dans plus de détails.

Je pense que la principale différence entre CCR et F # workflows asynchrones est que CCR comprend également des bibliothèques pour concurrency passage de messages. Voir par exemple cet article - il utilise la classe Port (vous pouvez envoyer messages aux ports) et Arbiter.Receive, ce qui est une primitive qui vous permet d'attendre des messages de Port.

En F #, vous pouvez utiliser MailboxProcessor pour mettre en œuvre le même schéma de communication de passage de messages, mais ce n'est pas intégré dans une partie de F # workflows asynchrones -. MailboxProcessor est mis en œuvre avec flux de travail asynchrones

En résumé : Je pense que F # workflows asynchrones sont plus simples et plus clairs sur le plan conceptuel. Cependant, le CCR et les flux de travail asynchrones ensemble avec MailboxProcessor mettre en œuvre à peu près le même schéma de programmation.