Async F # vs. quadro CCR

Question

Dopo aver letto su CCR: http://www.infoq.com/news/ 2008/12 / CCR Ho l'impressione che fa più o meno esattamente lo stesso di F # async blocchi?

arrendi port.Receive e port.Test al fine di fare lo stesso di "lasciare!".

È corretto? E ci sono benefici in CCR che non si ottiene con F # async?

Answer 1

L'esempio in questo articolo lei ha citato sembra davvero come let! da flussi di lavoro asincroni. In generale, la parola chiave yield return in C # permette di codificare modelli simili a F # espressioni di calcolo (in un modo strano, perché è stato progettato per la creazione di enumeratori):

• Questo è utilizzato anche da AsyncEnumerator , che è (IMHO ) più semplice di CCR e un po 'più vicino a F # asincrona dei flussi di lavoro
• un articolo che spiega questo similartiy in ulteriori dettagli.

Credo che la differenza fondamentale tra CCR e F # workflow asincroni è che CCR include anche librerie per la concorrenza message-passing. Si veda ad esempio questo articolo - utilizza classe Port (è possibile inviare messaggi a porte) e Arbiter.Receive, che è una primitiva che permette di attendere i messaggi da Port.

In F #, è possibile utilizzare MailboxProcessor per l'attuazione lo stesso modello di comunicazione message-passing, ma questo non è un built-in parte di F # workflow asincroni -. MailboxProcessor è implementato con flussi di lavoro asincroni

In sintesi : Penso che F # workflow asincroni sono più semplici e concettualmente più chiara. Tuttavia, CCR e workflow asincroni assieme con MailboxProcessor attuare approssimativamente lo stesso modello di programmazione.