views:

197

answers:

2
+2  Q: 

Monads and Actors

I've been trying to find anything that discusses when you should favor the use of monads over actors (in concurrency scenarios), but I've found nothing. In particular, I'm wondering about the use of the Reactive Extensions (LINQ to Events) vs. F#'s MailboxProcessor. Please give examples in addition to any philosophical reasoning you might have.

Update For better context, the Reactive Extensions implement the continuation monad in the form of IObservable/IObserver. I'm not necessarily saying I have to use F#, just that F# is a concrete "actor model" available in a .NET language.

What I'm trying to understand is when to use a monad (in this case a continuation monad) vs. an actor model for concurrency purposes. Where the monad (as I understand it) doesn't introduce state, the actor has its own internal state that is modified as necessary to provide protected access.

I've seen a number of examples of using both: Rx and node.js (CPS, not really the continuation monad) vs. F#'s MailboxProcessor and Scala's Akka framework. I just don't know why you would choose one over the other.

+1  A: 

Hi Ryan,

Please excuse my newbie-ness as I'm just learning F#.

I'm intrigued to see the use of RX in place of a MailboxProcessor, if you have any links to relevant materials.

With my limited understanding; I would choose MbP's in my own code as events are a bit messy to set up in F# (from what I can take from this article: MSDN). And you need events for RX to hook into right?

Where as with a MbP all I need is a discriminated union of messages, a list of functions I wish to be executed when a given message is received. And the mail box processor that handles this.

This all looks pretty neat in the code. I can bunch my MbP's together in a module then my "object" module looks like

  • Record
  • Message DU
  • Wrapper with some getters and setters that post data to the MbP

For me this looks a lot neater than it would If I wrote my code with events as described in that MSDN article I linked to.

Though I am just an F# junior so I may be a miles off with my reckoning and it is a look-&-feel thing rather than a suitability-for-purpose choice (as I'm not qualified to make that call, yet)

jdoig
Depending on how you expose your events, you can do as little as declaring an event and returning it as an IObservable, with the Trigger() method called inside the Subscribe method, so I don't think events are that bad. MbP's have their own req's.
Ryan Riley
+1  A: 

I'm not sure that the question makes sense as phrased - there are many different monads (e.g. the identity monad, the list monad, the option monad, ...), most of which have nothing to do with concurrency. Furthermore, it would be helpful to know more about the particular scenario that you're dealing with - "concurrency" is a bit of a nebulous topic. Depending on what you're trying to achieve, F#'s async workflows (which are built on the Async monad) might be your best bet.

If you're using F#, I'd recommend against using LINQ-to-anything directly, since those libraries have a very alien feel when accessed via F#. You could, however, create pleasant F# wrappers (such as the existing Seq and Observable modules). Additionally, for monadic types, you could create a computation expression builder (e.g. you could create a builder using the Reactive Extensions which would enable you to use computation expressions to build and compose IObservables).

kvb
I'm familiar with the options. I'm curious as to why and when you should choose one over the other. This may be a preference thing, but I thought I would try to get a better understanding.For some F# to Rx wrappers, check out my bitbucket repo: http://bitbucket.org/riles01/fsharp.reactive
Ryan Riley