| > at least half of what you have written above is completely wrong. That's quite an assertion. > Scala has side effects everywhere, yet the Monad is extensively used in Scala programs. Monads have nothing to do with "effects". I didn't say monads weren't used outside of Haskell, I say that they are less useful. I haven't programmed in Scala before, I assume monads are used for their notation. They aren't required. > Monads are not used to decide the kind of "effects" you are allowed. By calling every Monad a kind of "effect", you are just begging the question. Monads are merely objects that follow 3 monad laws, no more no less. I don't know if you're familiar with group theory, but in group theory, every finite group is a specialization of the group of permutations. Groups are defined abstractly by the operations that they allow in the same way that monads are, but this definition for finite groups is as general as saying that every group is a subgroup of the group of permutations. It's the same for monads, they are defined abstractly, but the abstract definition is equivalent to saying monads are all of the things that you can create by a specific kind of specialization of the continuation monad. Continuations are an effect. Specializations of continuations are also effects. Monads define effects. What's really interesting is thinking about monads in terms of the Curry-Howard Isomorphism, on one end of the scale, the identity monad, you have constructive logic and at the other end, continuations, you have classical logic, what's in the middle? Does the list monad instance have an interesting associated logic? Which question am I begging? > How is this different from a C program? It's just a different way of looking at programs. The distinction is never drawn for C programs. > Haskell is pure in the presence of IO, because the type system tracks IO calls and forces any function that even indirectly refers to a quantity obtained via IO to modify its type signature to reflect the IO action. This is quite a shallow way of looking at it. > This can be done with/without Monads. Sure, you could use continuations or uniqueness types. > Haskell IO is a Monad, because it pretty much analogous to the State Monad AFAIK, that's not defined in the Haskell standard, but that is the way that GHC does it. > Haskell has special Monad syntax that lets you pass the World State implicitly and write imperative code in an imperative style. No, it's not syntax that's letting you pass the world state implicitly. In GHC: IO x = State RealWorld x = (RealWorld -> (RealWorld, x))
You can't get at this function and RealWorld doesn't have any constructors, so you can't call an IO operation or do other weird things. Anyway, it doesn't really matter how IO is actually defined. What matters is it's interface. |