Access the configuration parameters through a monad?

Quote from here: http://www.haskell.org/haskellwiki/Global_variables

If you have a global environment, which various functions read from (and you might, for example, initialise from a configuration file) then you should thread that as a parameter to your functions (after having, very likely, set it up in your 'main' action). If the explicit parameter passing annoys you, then you can 'hide' it with a Monad.

Now I'm writing something that needs access to configuration parameters and I wonder if someone could point me to a tutorial or any other resource that describes how monads can be used for this purpose. Sorry if this question is stupid, I'm just starting to grok monads. Reading Mike Vainer's tutorial on th开发者_如何学运维em now.

---

The basic idea is that you write code like this:

main = do
   parameters <- readConfigurationParametersSomehow
   forever $ do
      myData <- readUserInput
      putStrLn $ bigComplicatedFunction myData parameters

bigComplicatedFunction d params = someFunction params x y z
   where x = function1 params d
         y = function2 params x d
         z = function3 params y

You read the parameters in the "main" function with an IO action, and then pass those parameters to your worker function(s) as an extra argument.

The trouble with this style is that the parameter block has to be passed down to every little function that needs to access it. This is a nuisance. You find that some function ten levels down in the call tree now needs some run-time parameter, and you have to add that run-time parameter as an argument to all the functions in between. This is known as tramp data.

The monad "solution" is to embed the run-time parameter in the Reader Monad, and make all your functions into monadic actions. This gets rid of the explicit tramp data parameter, but replaces it with a monadic type, and under the hood this monad is actually doing the data tramping for you.

The imperative world solves this problem with a global variable. In Haskell you can sort-of do the same thing like this:

parameters = unsafePerformIO readConfigurationParametersSomehow

The first time you use "parameters" the "readConfigurationParametersSomehow" gets executed, and from then on it behaves like a constant value, at least as long as your program is running. This is one of the few righteous uses for unsafePerformIO.

However if you find yourself needing such a solution then you really need to have a think about your design. Odds are you are not thinking hard enough about generalising your functions lower down; if some previously pure function suddenly needs a run-time parameter then look at the reason and see if you can exploit higher order functions in some way. For instance:

• Pass down a function built using the parameter rather than the parameter itself.
• Have the worker function at the bottom return a function as a result, which gets passed up to be composed with a parameter-based function at the higher level.
• Refactor your call stack so that fundamental operations are done by lower level primitives at the bottom which are composed in a parameter-dependent way at the top.

Either way is going to involve