[Haskell-cafe] Toy application advice wanted

[John Hughes]

> But Scheme lets you change things if you want to!  (The Haskell
> afficianados gasp).  Let's face it...in most long-running applications,
> data changes a lot during the lifetime of a program.  So somehow, you have
> to manage the repercussions of state changes.  Haskell does this with
> monads.  (I'm still wrapping my brain around them, but...)  Apparently
> monads plus some syntactic sugar are like functions that return a value
> and the next function, which in turn returns a value and the next
> function, etc. so that referential transparency is maintained.  This is a
> heckuva lot of work to do (set! foo 'bar).  I hope I'm not far off base
> with this.

Gosh, this sounds complicated! I think there's a much simpler way to see
it. In almost any language, some expressions have side-effects, and some
don't. Use expressions with side-effects carelessly, in the wrong place,
and you can screw up. In Haskell, expressions with side-effects have a
type that says so (IO <type>), and that in turn lets the type-checker
restrict where you use them (hence the many questions "How do I get an
<alpha> from an IO <alpha>?" -- the point is, you can't). So you avoid
screwing up. Not particularly complicated, not particularly costly.

   writeIORef foo Bar :: IO ()  -- empty result, with a side-effect.

OK, there's more to it than this, once you start using other monads than
IO or ST, and especially once you start overloading code on the underlying
monad. But as an initial understanding this is enough.

John Hughes