Re: [Haskell-beginners] Help with Why Do Monads Matter blog post understanding

On 29 June 2012 21:30, Matt Ford wrote:

On 29 June 2012 19:52, Brent Yorgey wrote:

And I see that passing in functions that act on the state helps do this.  But I don't understand how, for a function that looks like A->B, that has a whole load dependencies on external variables and functions (of perhaps lot's of different types) all these variables and functions are captured by the definition of Pref(B).

And by changing the actual type of the result of A->B in this case from an Int to a function that returns an Int how can this hope to match the original intention of the impure A->B.  Say for example Pref(b) is the empty set as no functions map to from the config to B. Changing the range means we will never get a sensible result??

I feel as though I'm missing something.

That paragraph introduces the notion of currying. Fast forward - the objective is to test the returning function. Usually, with "maybe" result or "just" result. This is a way to isolate (the understanding of) what the code does from (side) effects that are not expected. Effects do happen. The idea is to restrict their "area of effect" inside a monad, so the code just does what we expect (machines are funny like that) and nothing else. "Abstraction Over Monads" introduces the advantage of having this abstraction in Haskell "by design". [quote] sequence :: Monad m => [m a] -> m [a] (...) It’s basically a convenient way to check a whole list of computations for a failure. [/quote]