4 ms·

you might want to carry all of: - configuration applicable to this request (or global configuration) [...] Ok, this is super-interesting to me, as I'm curre

you might want to carry all of: - configuration applicable to this request (or global configuration) [...] Ok, this is super-interesting to me, as I'm currently dealing with the "configuration and interfaces as global state" pattern in a legacy application. Among other things, this makes it hell to test and refactor. Refactoring it into a functional abstraction like this seems like exactly what we need. But ... I'm kind of struggling to figure out what "global configuration as a monad" would look like (very much not a Haskell programmer). How would something like this work in practice?

cryptonector 2y ago
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.
- 12_throw_away 2y ago
  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?
  - cryptonector 2y ago
    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!
    - RandomThoughts3 2y ago
      > 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.
trealira 2y ago
"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).

cryptonector 2y ago

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.

12_throw_away 2y ago
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?
- cryptonector 2y ago
  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!
  - RandomThoughts3 2y ago
    > 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.

trealira 2y ago

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