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

[Brent Yorgey]

On Fri, Jun 29, 2012 at 09:30:58PM +0100, Matt Ford wrote:
> On 29 June 2012 19:52, Brent Yorgey <byorgey at seas.upenn.edu> wrote:
> 
> >> "For a set A, we will define the set Pref(A) to be the set of functions
> >> from application settings to the set A. Now watch closely: a function in
> >> context from A to B is just an ordinary function from A to Pref(B). In
> >> other words, you give it a value from the set A, and it gives you back
> >> another function that maps from application settings to the set B."
> >>
> >> This is in the "functioning with dependency" section and is talking about a
> >> procedure that uses outside info from preferences or application settings.
> >>
> >> If I set my prefs as follows
> >>
> >> configvar = 3
> >>
> >> and define a function as follows
> >>
> >> add x = configvar + 6
> >>
> >> So add’s signature is
> >>
> >> add: int -> int
> >>
> >> What does prefs(int) look like? Is that even the right thing to ask?
> >
> > prefs(int) looks like  Config -> Int (in your example perhaps we
> > define  type Config = Int), so add should have type
> >
> >  Int -> (Config -> Int)
> >
> > The thing that is confusing the issue here is that you just made add
> > implicitly use the 'configvar' which is in scope, so it does not need
> > to take it as a parameter.
> 
> That's what I'm trying to understand, how we switch from "impure"
> functions to "pure" functions which don't rely on external state.
> 
> 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).

Well, in that case Pref would have to be some sort of record of all
the possible things it could depend on.

Note that Pref(A) does *not* mean "the set of functions from *whatever
application settings A happens to use* to A".  That would not be very
useful (and impossible to implement).  Rather, one must fix ahead of
time what counts as "application settings".  Then everything involving
Pref will have access to that fixed set of application settings.  Does
that help at all?

> 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 don't think I understand this.  Can you give an example?  There is
definitely something fundamental you are misunderstanding but I am not
quite sure what it is. Does my clarification above help at all?

-Brent