Am 07/27/2014 09:22 PM, schrieb Jochen Keil:

In case it's the Continuation monad Chris mentioned (and I think he's right)

I believe so too. But I still have trouble understanding it. Let's forget about this particular monad for a while and focus on intuition in general. I managed to dissect the continuation monad and write the bind operator correctly. But it took me hours and the train of thought is very elusive. I wouldn't call this "understanding". When I truly understand things I can come up with analogies, counter examples and the like. I can draw diagrams to visualize the thing. I can embed the new thing into a world of old things. But I cannot do any of these things with the Continuation Monad. Right now I am trying to get there by staring at it, asking myself questions, trying to write bind in different ways - hoping that one day it will click. Someone on the web said that this (hard work) is the only way. Douglas Crockford said that monads come with a curse, that is as soon as you understand them you loose the ability to explain them to anyone else. Someone else said, the way to a monad's heart is through its Kleisli arrow. So I wonder what you guys do to develop intuition about tricky haskell things, such as the Continuation monad.

Am 07/29/2014 11:09 AM, schrieb Chris Warburton:

Bind can often be a bit tricky. I usually find it easier to define bind as:

...

x >>= f = join (fmap f x)

Then ignore it and focus on fmap and join instead. This is a 'divide and conquer' approach.

So you're really throwing symbols around? When I do math, I do similar things. Particularly in algebra I don't ask myself what e.g. a cubic root does, because I know the laws of roots and I know what I can do with the symbols. However, for other things, like an integral or a gradient I have a strong intuition. I have intuition for some of the simpler things in haskell too. For functions, folds and functors I have some intuition. In math, the only ways I know of to get a better intuition is practice and a good teacher. Maybe it is the same in haskell?

On 14-07-30 02:00 PM, martin wrote:

When I do math, I do similar things. Particularly in algebra I don't ask myself what e.g. a cubic root does, because I know the laws of roots and I know what I can do with the symbols.

However, for other things, like an integral or a gradient I have a strong intuition. I have intuition for some of the simpler things in haskell too. For functions, folds and functors I have some intuition.

In math, the only ways I know of to get a better intuition is practice and a good teacher. Maybe it is the same in haskell?

What, exactly, is intuition? Or, ironically, we shouldn't be asking that, just like we shouldn't be asking "what, exactly, is a set, or a number, or a cubic root?". Perhaps we should be asking: Where, exactly, does intuition come from? http://www.vex.net/~trebla/weblog/intuitive.html It seems logically obvious to me: If you are learning something new to you, then by definition of "new to you", you are not supposed to have any intuition yet (any correct intuition anyway --- oh, the human brain is great at manufacturing all kinds of wrong intuitions). You are supposed to practice the rules a lot, and then you gain intuition. I am always fond of citing Chess as an example. I don't think any Chess teachers teach intuition first, rules later. I'm pretty sure it's the other way round. And most likely they don't even tell you the intuition "control the centre" until you've practiced a million hours or something. And then, I don't value intuition very highly, certainly not as highly as most other people. Intuition is a great accelerator when it's right, but you never know whether it's right a priori. Symbolic manipulation has the final say. And symbolic manipulation teaches you new, correct intuition sometimes. Regarding bind and join, I find bind more obvious for some examples, and join for some other examples. I'm sure it is subjective.

Benjamin Franksen writes:

martin wrote:

...

I am trying to understand the ideas of Koen Klaessen, published in Functional Pearls: "A poor man's concurrency" (1993).

[...]

m >>= k = \f -> m (\x -> k x f)

If you re-add the newtype wrapping and unwrapping, this is exactly the same as your definition above.

This is one answer to the question of how one can arrive at a suitable definition of >>= for the continuation monad. But it does not tell us anything about how to arrive at an intuition about what this implementation really does. Maybe someone else can explain this...

Values of `Cont a` are functions in continuation-passing style. That is, they are functions that hand their results to a continuation passing function, instead of returning. I think the trickiness of this stuff has more to do with continuation-passing style in general and less to do with any inherent abstruseness of monadic bind. With some CPS familiarity, you can see that `m` is just a function that accepts a continuation, and `k` is a function that accepts the intermediate result and the next continuation. We know that our new CPS function is going to accept a continuation argument. We also know -- by the semantics of CPS -- that this continuation will be handed to `k`. So this CPS function \f -> m (\x -> k x f) says: given a continuation `f`, invoke `m` with a continuation that hands the intermediate result to `k` with the continuation `f`. You can see how a chain like (given the actual Monad instance) do x <- m1 y <- m2 x m3 y will expand into a CPS function that passes along the continuation such that `m3` is finally invoked with the continuation of the entire block. And then, the presence of the Monad constraint just makes it obvious that this can be used as a monad transformer. -- Mikael Brockman mikael@silk.co