joashc / csharp-probability-monad

A probabilistic programming framework for C#
MIT License
96 stars 7 forks source link

Could you provide some reference articles? #1

Open sth4nth opened 8 years ago

sth4nth commented 8 years ago

Could you provide some reference articles on GADTs and free monad? I have basic knowledge with haskell and monad. But do not know what free monad is. Regarding the parallel and independent aspect, isn't it more nature to model independent distributions with Applicative? One more thing. For modeling the graphical model, it seems that arrow is a perfect choice, since it is designed to model DAG flow and has power of both applicative and monad, could you elaborate on that?

joashc commented 8 years ago

Free monads

In Haskell, you can define (>>=) like this:

(>>=) :: Monad m => m a -> (a -> m b) -> m b
m >>= f = join (fmap f m)

When wefmap f m, we substitute the a in m a with m b to get m (m b), then we renormalize by calling

join :: Monad m => m (m a) -> m a

This means the monadic bind operation can be viewed as "substitution followed by renormalization". A free monad in Haskell can be defined using the type:

data Free f a = Pure a | Free (f (Free f a))

This means the renormalization is done by definition. There's no need to write a join; we only need to be able to fmap, and we get >>= "for free". In other words, we can turn any functor into a monad "for free". That's a very brief overview; I wrote a blog post that gives a more category theoretic treatment.

Applicative

You are correct, it is very natural to model independent distributions with applicative functors. Unfortunately, it's much easier to work with monads than applicatives in C#. One of my later projects spends a great deal of effort attempting to extract applicative semantics from monadic syntax; that approach, which is detailed here, could be generalized to this project. This would enable us to automatically work out which distributions are independent and parallelize them, without requiring the user to write anything differently at all.

Arrows

Even in Haskell, where support for arrows is far better than C#, it's nearly always preferable to work with monads if we aren't using the additional generality that arrows provide. It's usually far more difficult to ensure your arrow instance satisfies all the arrow laws than the monad ones. In this case, we don't gain a great deal by using arrows; if we wanted further generality we should probably implement Category instead, as Category combined with Applicative gets us arrows anyway.