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

Paulo Pocinho pocinho at gmail.com
Sat Jun 30 03:51:19 CEST 2012

On 29 June 2012 21:30, Matt Ford <matt at dancingfrog.co.uk> wrote:
> On 29 June 2012 19:52, Brent Yorgey <byorgey at seas.upenn.edu> 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".

sequence :: Monad m => [m a] -> m [a]

(...) It’s basically a convenient way to check a whole list of
computations for a failure.

More information about the Beginners mailing list