[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".
[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]
More information about the Beginners
mailing list