[Haskell-beginners] clarification on IO

[Michael Easter]

Thanks Andrew, this is really great...

My main revelation here is that a "side-effect" in other monads is still
pure.  e.g. The Logger example in RWH builds up a list of log strings
"behind the scenes" but this is much different than writing to disk, or
launching missiles, to quote SP Jones.

'Revelation' is a good word.... The tectonic plates are coming together! I
needed this.

thanks!
Mike

ps. re: bind/hidden. Monads strike me as a glorious instance of
encapsulation that is not OO, which appropriated the term in the 1990s.

On Fri, Feb 27, 2009 at 9:30 PM, Andrew Wagner <wagner.andrew at gmail.com>wrote:

> I'll take a shot at answering some of your questions by explaining how I
> understand it, and we'll see if it helps or makes it worse.
>
> Let's talk about monads first. Monads can be thought of as a way of sort of
> hiding "side effects". That is, there is nothing inherently impure about
> monads. The "side effects" happen in the bind function, essentiall. For
> example, in the case of state, the state is carried from one function to
> another. The bind function actually says how to do this; You just don't
> usually see it because it's "hidden" in the do notation. In the Maybe
> function, the plumbing hides the fact that we quit at any point the
> computation fails, and so on. So while in an impure language, any statement
> can have any side effect, in haskell, if you know what monad you're in, you
> know exactly what the "side effect" will occur - which means, it's not
> really a side effect at all, but part of the actual intended effect.
>
> Now for IO. You can think of IO as being essentially State RealWorld. That
> is, every operation is dependent on the entire state of the world, including
> what you're thinking, and what kind of bug is crawling on the 18th blade of
> grass in your yard. If we could actually represent the whole world this way,
> Haskell would truly be a completely pure language. The only reason IO, and
> thus Haskell, is impure at all, is because we can't literally represent the
> whole world. EVERYTHING ELSE, INCLUDING EVERY OTHER TYPE OF MONADIC ACTION
> IN HASKELL, is completely pure.
>
> Ok, so let's address your questions a little more specifically.
>
> Q1: The web page mentions that normal Haskell functions cannot cause
>> side-effects, yet later talks about
>> side-effects with putStrLn. I assume the key point here that IO actions
>> are, by definition, _not_ normal functions?
>>
>
> Right, IO actions can have side effects because they can take into account,
> and modify, the RealWorld.
>
>
>> Q2: Is it true to say that *any* monadic action *could *cause
>> side-effects, depending on the design of that
>> monad? i.e. Does one generalize from the IO monad to (possibly) an
>> arbitrary monad? *Musing* This must be true as
>> using State must surely be considered a side-effect.
>>
>
> Again, yes, this is accurate, but it's different from most impure languages
> in that the side effect is completely baked in by the monad you're in, so
> that you can't really say that the effect is a "side effect" at all.
>
>
>> Q3: The web page mentions IO as being a baton, or token, that is used to
>> thread/order the actions. Is true
>> that this is merely one simple perspective, with respect to order of
>> evaluation? This is hard to articulate,
>> but it seems to me that "in the IO monad" there is a large subsystem of
>> (inaccessible) state, machinery, etc.
>> Is it really a token?
>>
>
> Again, in many ways, it's easier to think of the IO monad as a state monad.
> In that sense, the state of the world is indeed being passed from one action
> to the next, as defined by bind. That's the inaccessible state machinery I
> suspect you're sensing.
>
>
>> Q4: Is the following idea accurate: a Haskell program is partitioned into
>> 2 spaces. One is a sequence
>> of IO actions; the other is a space of pure functions and 'normal' Haskell
>> operations.  The execution of a
>> program begins with the main :: IO () action and, effectively, crosses
>> from one space to the other. In the
>> pure space, the math-like functions can be highly optimized but only
>> insofar as they do not disrupt the
>> implied order of the IO actions.  Because of the type system, the program
>> recognizes when it enters
>> "back" into the IO space and follows different, less optimized rules.
>>
>
> I think it would be easier to talk about haskell in terms of pure and
> impure code. All Haskell code is pure except for IO. Pure functions are
> easier to reason about and to optimize, because you don't have to take into
> account the RealWorld state, or other possible, REAL side effects..
>
>
>> My concern is that the above is *not* accurate, but I don't know why.
>>
>>
>> thanks so much for your help
>> Michael Easter
>>
>> --
>> ----------------------
>> Michael Easter
>> http://codetojoy.blogspot.com: Putting the thrill back in blog
>>
>> http://youtube.com/ocitv -> Fun people doing serious software engineering
>>
>> _______________________________________________
>> Beginners mailing list
>> Beginners at haskell.org
>> http://www.haskell.org/mailman/listinfo/beginners
>>
>>
>


-- 
----------------------
Michael Easter
http://codetojoy.blogspot.com: Putting the thrill back in blog

http://youtube.com/ocitv -> Fun people doing serious software engineering
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/beginners/attachments/20090227/662f4e97/attachment.htm