[Haskell-cafe] Explaining monads

[Derek Elkins]

On Mon, 2007-08-13 at 19:31 +0200, peterv wrote:
> When I read "side-effects", I understand it as "unwanted effects", like
> "aliasing", and "effects depending on the order of execution". I'm not sure
> if my understanding here is correct. I hope Haskell does not allow
> "side-effects" but only "effects", meaning the monads do not allow you to
> write the typical ill-behaving code you get when doing real imperative
> programming, enforcing a single wiring of execution, not allowing the
> capture of the RealWorld object. In Concurrent Clean special compiler
> support is present to enforce "uniqueness typing", and in Haskell special
> compiler support is available to make the RealWorld object not available at
> runtime (so e.g. you can't put the RealWorld object in a list). Is this
> correct? 

Monads certainly do allow "side-effects" in that way.  Heck, without
allowing aliasing there wouldn't be much to compel the use of
mutability.  Aliasing is the great boon and great curse of imperative
programming.  Order of execution issues are tricky.  On the one hand,
you must always (directly or indirectly) specify the order of execution,
so technically there's no uncertainty. On the other hand, there are two
distinct definitions of liftM2,
liftM2'1 f ma mb = do a <- ma; b <- mb; return (f a b) -- and
liftM2'2 f ma mb = do b <- mb; a <- ma; return (f a b)
Note that order of -evaluation- is moot (at least as much as it is for
any term).  Laziness does not come into it (unless you use lazy IO, in
which case you get what you deserve.)

> BTW: What is the correct word in Haskell for "object"? I mean the (lazy)
> value you get when evaluating a data constructor? 

What you said doesn't really make much sense, but I think the(/a) word you want is a "thunk".