4 ms·

Monads are not directly related to handling side effects. Or to the famous IO that you're refeering here. What a Monad does is to force sequencing by creating a

Monads are not directly related to handling side effects. Or to the famous IO that you're refeering here. What a Monad does is to force sequencing by creating a data dependency. Speaking of IO ... In an imperative program you get guaranteed ordering of those instructions, but that ordering is thread local, meaning that the compiler, the runtime, the kernel, the CPU are all free to reorder instructions for optimal execution and ordering between threads is forced via memory barriers, which is in fact incredibly error prone. In an FP language such as Haskell you get the extra problem that the compiler is even more free to rewrite and execute your code in any order it sees fit due to non-strictness and to referential transparency. What the IO monad does is to "suspend side effects" and to force ordering on evaluation. And guess what, the IO monad is useful even in your average imperative program for describing concurrent logic. Here are the implementations I contributed to: 1. https://monix.io/docs/2x/eval/task.html https://monix.io/docs/2x/eval/task.html (Scala) 2. https://github.com/typelevel/cats-effect https://github.com/typelevel/cats-effect (Scala) 3. https://funfix.org https://funfix.org (JavaScript) If you've ever worked with JS Promises, think of IO as a non-broken, pure, awesome alternative. And this is just IO. There are other monads as well. List is a monad, Option and Either are monads ;-) --- I recommend you let go of your misconceptions and do some learning because this is a freaking useful concept.

olavk 9y ago
> I recommend you let go of your misconceptions and do some learning Thank you for the advice! Monads seem to have some kind of smugness creation field. I know there are other monads beside State and IO, I was specifically referencing the argument in the linked article which was about using monads for mutable state, basically turning the code into imperative style.
- bad_user 9y ago
  That wasn’t smugness. I only replied to you because those were my thoughts from 5 years ago. And I was wrong. And yes, it’s a little troubling that such awesome concepts are not penetrating the mainstream, being so misunderstood. I blame the available leaning resources. It took the GC 30 years after invention to become mainstream. Functional programming, actual functional programming, apparently takes longer than that.
  - AnimalMuppet 9y ago
    > That wasn’t smugness. Maybe not. It was still condescending, though...
tome 9y ago
> What a Monad does is to force sequencing by creating a data dependency. Does it really? Maybe this is another one of those famous misconceptions! https://hackage.haskell.org/package/tardis-0.4.1.0/docs/Control-Monad-Tardis.html#g:3 https://hackage.haskell.org/package/tardis-0.4.1.0/docs/Cont...
- pdpi 9y ago
  Nah, it's not really "one of those famous misconceptions". The crucial detail is that TardisT must wrap a MonadFix, which is used for cyclical data structures. It effectively works not by making time go "backwards", but by making time loop around. It still creates a sequencing relationship.
  - tome 9y ago
    > The crucial detail is that TardisT must wrap a MonadFix So? The non-transformer version can still "read data before it's written". It's very hard to see any form of sequencing in that example. > It still creates a sequencing relationship. A sequencing relationship between what exactly?
    - bad_user 9y ago
      The sequencing is described precisely in the signature of bind. (>>=) :: Monad m => m a -- Left argument -> (a -> m b) -- Right argument -> m b You don’t need to explain an individual monad instance to notice that this signature requires “a” in order to generate “m b”.
      - tome 9y ago
        What about the Identity monad? Does that "force sequencing"? What "sequencing relationship" does it create? If you are convinced that the Identity monad does "force sequencing" then you are also convinced that lazy evaluation "forces sequencing" (because the Identity monad is just lazy evaluation). That would be a fairly controversion conviction. If you are not convinced that the Identity monad "forces sequencing" then can you explain in more detail the meaning of your claim "What a Monad does is to force sequencing by creating a data dependency.".

olavk 9y ago

> I recommend you let go of your misconceptions and do some learning Thank you for the advice! Monads seem to have some kind of smugness creation field. I know there are other monads beside State and IO, I was specifically referencing the argument in the linked article which was about using monads for mutable state, basically turning the code into imperative style.

bad_user 9y ago
That wasn’t smugness. I only replied to you because those were my thoughts from 5 years ago. And I was wrong. And yes, it’s a little troubling that such awesome concepts are not penetrating the mainstream, being so misunderstood. I blame the available leaning resources. It took the GC 30 years after invention to become mainstream. Functional programming, actual functional programming, apparently takes longer than that.
- AnimalMuppet 9y ago
  > That wasn’t smugness. Maybe not. It was still condescending, though...

tome 9y ago

> What a Monad does is to force sequencing by creating a data dependency. Does it really? Maybe this is another one of those famous misconceptions! https://hackage.haskell.org/package/tardis-0.4.1.0/docs/Control-Monad-Tardis.html#g:3 https://hackage.haskell.org/package/tardis-0.4.1.0/docs/Cont...

pdpi 9y ago
Nah, it's not really "one of those famous misconceptions". The crucial detail is that TardisT must wrap a MonadFix, which is used for cyclical data structures. It effectively works not by making time go "backwards", but by making time loop around. It still creates a sequencing relationship.
- tome 9y ago
  > The crucial detail is that TardisT must wrap a MonadFix So? The non-transformer version can still "read data before it's written". It's very hard to see any form of sequencing in that example. > It still creates a sequencing relationship. A sequencing relationship between what exactly?
  - bad_user 9y ago
    The sequencing is described precisely in the signature of bind. (>>=) :: Monad m => m a -- Left argument -> (a -> m b) -- Right argument -> m b You don’t need to explain an individual monad instance to notice that this signature requires “a” in order to generate “m b”.
    - tome 9y ago
      What about the Identity monad? Does that "force sequencing"? What "sequencing relationship" does it create? If you are convinced that the Identity monad does "force sequencing" then you are also convinced that lazy evaluation "forces sequencing" (because the Identity monad is just lazy evaluation). That would be a fairly controversion conviction. If you are not convinced that the Identity monad "forces sequencing" then can you explain in more detail the meaning of your claim "What a Monad does is to force sequencing by creating a data dependency.".