[zohebv]

I don't know how else to put it, but at least half of what you have written above is completely wrong.

> but they're less useful in other languages where you already have effects everywhere.

Scala has side effects everywhere, yet the Monad is extensively used in Scala programs. Monads have nothing to do with "effects".

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.

> This is why Haskell is pure despite having effects. Haskell programs don't do IO, they yield control to the runtime environment whenever IO needs to be done.

How is this different from a C program? 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 can be done with/without Monads. Haskell IO is a Monad, because it pretty much analogous to the State Monad and Haskell has special Monad syntax that lets you pass the World State implicitly and write imperative code in an imperative style.

[eli_gottlieb]

He's not begging the question at all. In formal PL terms, a monad and a computational effect (which includes continuations, nondeterminism, and I/O, and loads more interesting stuff) are very strongly connected concepts. If I remember correctly, they may even be equivalent.

Monadic combinators are really just kind of type-sugar. Think: any ordering of computations can be expressed as a tree. However, the only ordering trees a pure-functional language must obey are call-trees (the parameters of a function must be computed before the results of a function, even after lazy-evaluation is taken into account). Monadic programming is a way to transform arbitrary ordering trees of possibly-dynamic depth and width into call trees while preserving the original ordering.

The really neat thing about monads is that they statically guarantee they'll preserve the original ordering, despite its being of dynamic width and depth.

[Peaker]

The RealWorld hack in GHC is not "passing the world state". It's just a hack/implementation detail to get evaluation order correctly. The RealWorld -> (RealWorld, x) view of IO is not a valid one.

[eli_gottlieb]

Quite correct. As I'm aware, when you call "main" in Haskell, you're actually building up a really gigantic curried function of type `IO x` (where x is your return type), and then the runtime system runs everything in the curried function all at once. The `RealWorld` symbol is more-or-less an existential type: we can't do anything with it, but it exists to make the type system acknowledge the monadic nature of IO so that we can use monadic combinators to order our curried I/O actions in preparation for their eventual run on real hardware.

[chousuke]

Haskell IO is pure because an IO action is basically just an "instruction". For example, one way to make a pure thing out of a side-effecting procedure is to wrap it in a lambda; it won't do anything until you actually call it, so you can use it as a value. The reason why IO is "separated" by the type system is the same as why Strings are "separated" from Ints: They are different.

The monad operations happen to be a convenient interface for combining IO values to form a composite value that is then called "main", and when the program is actually run, the value of main is executed to produce all the effects.

[Peaker]

"Pure" typically means referentially transparent. Wrapping a side-effecting procedure in a lambda does not make it referentially transparent, therefore it isn't pure.

[chousuke]

It is referentially transparent. The lambda (or thunk) itself can be used freely as a value. For example

  newtype PureIO a = PureIO (() -> a)
  print :: String -> PureIO ()
  print s = PureIO $ \_ -> unsafePrint s -- impure primitive

If the user only has access to the "print" variable, then they can only use it as a pure value. two applications of print "foo" would result in two thunks, either of which, when actually invoked, would cause the side-effect of printing "foo".

Invoking the pure IO values is something only the runtime can do, so referential transparency is not violated.

[Peaker]

The important thing here is not the wrapping with a lambda. That's not what made it pure.

The important thing here is the abstract type wrapper. You're exposing pure primitives that are implemented in terms of (hidden) impure ones.

That's why code that uses unsafePerformIO can be pure and referentially transparent, as long as the exposed primitives are pure and implementation details are hidden.

To demonstrate this, imagine that you did expose the PureIO data constructor -- then values of type PureIO would not be referentially transparent anymore.

[DanWaterworth]

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

[zohebv]

Reading your response, I think I need to read more on the topic. I haven't read Moggi's paper and I need to look up on the continuation Monad. You are probably correct and I am probably wrong. However, I will let my original post remain as a matter of historical record :-)