Re: [Haskell-cafe] Toy application advice wanted

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
participants (1)
-
John Hughes