Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Immutable data

Name: Anonymous 2013-07-25 18:01

What kind of idiot needs to have his data kept constant to keep himself from breaking something? If you can't keep your shit in order without stupid artificial constraints, then you don't know shit about programming.

Name: Anonymous 2013-07-26 15:50

>>12

They are over-hyped imho. The structure of a monad is very simple. They are endofunctors with some extra structure. The only thing they work quite well, is that they can represent the idea of sequential computations. 

For example the free monad is a tree like structure, where the nodes are commands and the leaves are values. It is free, in the sense it is the most minimal definition, which follows the monad laws and thus is free of interpretation.

What is this structure? It is an abstract syntax tree. Thus an evaluator for a monad is an interpreter.  With monads we can model most imperative constructs. State? Coroutines? Logging? Exceptions? It is a monad. We can define it by adding structure to the free monad. 


A monad is easy to spot. If you find a functor, which has some operation: prob (prob a) -> prob a, you found yourself prob(ably) a monad.

Why does this all work. Two things. The join operation, allows the compiler to join two contexts together. This is effectively what bind does. It first maps the functor with some action: a -> m a. Thus we get m (m a). In m we can add a lot of extra structure (eg. state). This structure is then collapsed with join: m (m a) -> m a. This way we can hide a lot of effects in the structure of m.

Another reason is that they make code sequential, recall the third law:


(f a >>= g) >>= h = f a >>= (\b -> g b >>= h)


We can read the right side as, before calculating the next step we have to calculate the previous step. 

Monads are simple. This simplicity makes them stupid. It are not very interesting objects from my point of view. 

What is interesting is if their are other categories, which can model computations. Arrows are such a category, but these were a miss.

A lot of arrows are monads too. For example the state arrow:

newtype State a b = State ((s, a) -> (s, b))

is simple the kleisli arrow of the state monad.

Look at the state monad:

(s -> (s, a))

Now throw the kleisli transformer over it, which is an operation (a -> m b) -> (Kleisli m a b)

If we strip the last term we get:

(a -> s -> (s, b))

Which gives the arrow we already had:

(a,s) -> (s,b)

A lot of interesting arrows cannot be implemented, because they can't give arr.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List