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 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.
