5 ms·

how often does it happen, that you'd want to swap effects without changing program code? I don't think it is a strong selling point. As someone who is interest

how often does it happen, that you'd want to swap effects without changing program code? I don't think it is a strong selling point. As someone who is interested in FP, but still at the beginning of the journey, I found the blog post interesting to read, especially intuition for every Monad.

mrkeen 7y ago
I replaced one type of Future for another in a large Java codebase. Not productive. I had a colleague who wanted to rewrite the same piece of code using Observables instead. Later in a different company I met someone who was working on the exact opposite, i.e. taking Observable code and rewriting it as Futures because "observables are confusing". Just extract these things behind an interface and call it a day.
- AzzieElbab 7y ago
  futures have a lot of gottyas that make them hard to replace. for example, where and how you initialize them matters
mundacho 7y ago
It's done a lot, it's used for mocking in FP. For example, I hace a monad that saves to a database using effects. I change the effect to update an array instead and I have code that I can use in a unit test.
joppy 7y ago
The example often used is something like the Reader monad, which is basically used like dependency injection. Run your code in an isolated environment to test, and connect it to the real application just by swapping the environment (effects/monad). A more interesting example could be monads as used in Haxl, which give an alternative monad in which to run database queries, which can perform complicated batching of requests behind the scenes with no change of business logic code.
coldtea 7y ago
>how often does it happen, that you'd want to swap effects without changing program code? Anytime you want to test (and e.g. don't perform the actual side effects but mock them)? Or change from e.g. logging to a file to logging to a DB or syslog? And lots of other cases!
- jakear 7y ago
  Is this fundamentally different from simply providing different implementations of a “Logger” or “Database” interface? Why does the involvement of side-effects result in the machinery being so different?
  - lonelappde 7y ago
    That's what the OP is about: hiding implementations behind an interface. Effects are different because side effects are impure which is not allowed by default in a pure language. Machinery is needed to hide the effects in effect-managing containers so they don't contaminate pure code.
    - jakear 7y ago
      I understand that, what I’m trying to understand is if there’s a claim being made that such machinery is especially desirable in this circumstance... is this claimed to be “the way you have to do it in pure languages” or “a really nice way of doing it, which is enabled by language purity”?
tel 7y ago
I'd argue this is incredibly common if you write a codebase without a specific, concrete effect stack. In Haskell, the mtl library offers constraints on types mandating that they support at least some effect. These compose together and then are executed by a custom effect "stack" that inhabits all of the constraints. So, you might have a piece of code which can fail at using some User properties to compute a score of some sort computeScore :: MonadError Error m => User -> m Score and also a piece of code that pulls a given user from a database getUser :: MonadDatabase m => UserID -> m User and we can compose them getAndComputeScore :: (MonadError Error m, MonadDatabase m) => UserID -> m Score getAndComputeScore id = do user <- getUser computeScore user In some sense, each of these three functions operates in a different (abstract) effect stack and the calls to getUser and computeScore were transparently "upgraded" to a more comprehensive effect stack when they were called in getAndComputeScore. This is the basis for "effect tracking" where each piece of code is written to the minimal, necessary effect specification. Their ability to compose and operate within other compatible (abstract) effect stacks is used regularly to compose small programs into bigger ones. Then, finally, you just make a big type data ConcreteEffects a = ConcreteEffects ... instance MonadError Error ConcreteEffects where ... instance MonadDatabase ConcreteEffects where ... which instantiates all of your abstract effects concretely. You might even make two, one for testing data ConcreteTestEffects a = ConcreteTestEffects ... instance MonadError Error ConcreteTestEffects where ... instance MonadDatabase ConcreteTestEffects where ... These will look like compositions of the basic effects from this article. For instance, if you imagine a type of DatabaseHandles, you might have data ConcreteEffects a = ConcreteEffects (DatabaseHandle -> Either Error a) which you can stare at and recognize to be Either and Reader combined together.

mrkeen 7y ago

I replaced one type of Future for another in a large Java codebase. Not productive. I had a colleague who wanted to rewrite the same piece of code using Observables instead. Later in a different company I met someone who was working on the exact opposite, i.e. taking Observable code and rewriting it as Futures because "observables are confusing". Just extract these things behind an interface and call it a day.

AzzieElbab 7y ago
futures have a lot of gottyas that make them hard to replace. for example, where and how you initialize them matters

mundacho 7y ago

It's done a lot, it's used for mocking in FP. For example, I hace a monad that saves to a database using effects. I change the effect to update an array instead and I have code that I can use in a unit test.

joppy 7y ago

The example often used is something like the Reader monad, which is basically used like dependency injection. Run your code in an isolated environment to test, and connect it to the real application just by swapping the environment (effects/monad). A more interesting example could be monads as used in Haxl, which give an alternative monad in which to run database queries, which can perform complicated batching of requests behind the scenes with no change of business logic code.

coldtea 7y ago

>how often does it happen, that you'd want to swap effects without changing program code? Anytime you want to test (and e.g. don't perform the actual side effects but mock them)? Or change from e.g. logging to a file to logging to a DB or syslog? And lots of other cases!

jakear 7y ago
Is this fundamentally different from simply providing different implementations of a “Logger” or “Database” interface? Why does the involvement of side-effects result in the machinery being so different?
- lonelappde 7y ago
  That's what the OP is about: hiding implementations behind an interface. Effects are different because side effects are impure which is not allowed by default in a pure language. Machinery is needed to hide the effects in effect-managing containers so they don't contaminate pure code.
  - jakear 7y ago
    I understand that, what I’m trying to understand is if there’s a claim being made that such machinery is especially desirable in this circumstance... is this claimed to be “the way you have to do it in pure languages” or “a really nice way of doing it, which is enabled by language purity”?

tel 7y ago

I'd argue this is incredibly common if you write a codebase without a specific, concrete effect stack. In Haskell, the mtl library offers constraints on types mandating that they support at least some effect. These compose together and then are executed by a custom effect "stack" that inhabits all of the constraints. So, you might have a piece of code which can fail at using some User properties to compute a score of some sort computeScore :: MonadError Error m => User -> m Score and also a piece of code that pulls a given user from a database getUser :: MonadDatabase m => UserID -> m User and we can compose them getAndComputeScore :: (MonadError Error m, MonadDatabase m) => UserID -> m Score getAndComputeScore id = do user <- getUser computeScore user In some sense, each of these three functions operates in a different (abstract) effect stack and the calls to getUser and computeScore were transparently "upgraded" to a more comprehensive effect stack when they were called in getAndComputeScore. This is the basis for "effect tracking" where each piece of code is written to the minimal, necessary effect specification. Their ability to compose and operate within other compatible (abstract) effect stacks is used regularly to compose small programs into bigger ones. Then, finally, you just make a big type data ConcreteEffects a = ConcreteEffects ... instance MonadError Error ConcreteEffects where ... instance MonadDatabase ConcreteEffects where ... which instantiates all of your abstract effects concretely. You might even make two, one for testing data ConcreteTestEffects a = ConcreteTestEffects ... instance MonadError Error ConcreteTestEffects where ... instance MonadDatabase ConcreteTestEffects where ... These will look like compositions of the basic effects from this article. For instance, if you imagine a type of DatabaseHandles, you might have data ConcreteEffects a = ConcreteEffects (DatabaseHandle -> Either Error a) which you can stare at and recognize to be Either and Reader combined together.