"Global configuration as a monad" is represented by the Reader monad, which is basically a wrapper over a function that takes a configuration/environment as a parameter and then returns something. It replaces a read-only global configuration.

This is Haskell, but here's a really simple example.

  -- As an ordinary function:
  foo :: Int -> Bool -> Int
  foo n shouldAdd = if shouldAdd then n + 1 else n - 1

  -- Exactly the same, but using the Reader monad
  foo :: Int -> Reader Bool Int
  foo n = do
    shouldAdd <- ask
    return (if shouldAdd then n + 1 else n - 1)

Here's the same thing, but with a record with one boolean in it:

  -- Config: a record with one boolean in it,
  -- and you access it with a function called `shouldAdd`
  data Config = MkConfig { shouldAdd :: Bool }

  foo :: Int -> Config -> Int
  foo n cfg = if shouldAdd cfg then n + 1 else n - 1

  foo :: Int -> Reader Config Int
  foo n = do
    mustAdd <- asks shouldAdd
    return (if mustAdd then n + 1 else n - 1)

It's basically a way to have implicit read-only parameters. You can call a bunch of functions that take a configuration parameter without having to actually pass the configuration as a parameter explicitly. In an object oriented language, you might use classes for this (if not global variables).

In Java or C++ or other OOPish languages, say, you might make all your classes be Configurable (unless they are Configuration), which means their constructors would take a Configuration in some way, possibly with an explicit Configuration argument or with a Configurable argument whose configuration to copy. This way all your objects will know how to find configuration information.

Sure, that makes sense, and is a go-to pattern for my own projects. But to map this onto FP, making classes Configurable feels like OO version of currying. I.e., I'm taking some parameters and baking them into methods that I will call later. But does this have anything to do with monads or some monadic version of state?

It's more like `Configured<T>` -- a Functor, something not too dissimilar to `List<T>`, but a) with just one `T` in it, b) with all your configuration things in the `Configured<T>` instance.

So everywhere you deal with a value that is of some type `Configured<T>` you can then refer to all the configuration methods you'd expect of you `Configuration` types. In Java you'd say something like `this.getConfigBlah()`, and it would just work.

> I'm taking some parameters and baking them into methods that I will call later.

Yes.

> But does this have anything to do with monads or some monadic version of state?

In languages that have monads: yes!

> In Java you'd say something like `this.getConfigBlah()`

No, the whole point is that it’s completely dissimilar to that.

> But does this have anything to do with monads or some monadic version of state?

There is no monadic version of state. The State monad is a way of chaining things together (not unlike shell pipes) which is nice in Haskell because it gives access to some of the language syntactic sugar (the do notation). There is nothing particularly special there otherwise.

The key takeaway here is that you can avoid littering your global scope by explicitly passing what’s shared as functions arguments and then remove side effects if you also pass by value.

Yes, it is this simple.