[Haskell-beginners] Re: clarification on IO

On Sun, Mar 1, 2009 at 4:28 AM, Will Ness wrote:

Michael Easter writes: ... After all, we can have a definition of such a value, and have it run multiple times for us, so _as definition_ it's no different than any other definition in Haskell. It's just that _its value_ can cause the system to actually perform these IO actions in some circumstances.

But it isn't a definition.  "Reference" would be better; "getChar" is a term

Gregg Reynolds writes: that references a value. Excuse me for being too brief. I was talking about the definitions of IO values, of type (IO a), viz. the do-block (or bind-chain) definitions, as in let v=do { getChar; putStrLn "12"; return 2 } that are just regular Haskell defintions, from inside the Haskell world POV. The IO-action functions involved here would be getChar (\_-> putStrLn "12") (\_-> return 2) These IO-action functions, chaind by IO bind, create a combined-actions IO value, in this case of type (:: Num a => IO a). The IO-action is not the I/O operation in the real world, but an action of recording a promise to perform it. Any IO primitive can be seen as latching this hidden promise onto its explicit return value, thus creating a monadic value (:: IO a), carrying along this hidden promise. IO bind combines these promises into a combined record, or log, of promises to perform actual I/O activity, if called upon by the system. That recording of a promise is the IO-action that IO monad is about, from pure Haskell standpoint. Another monad will have another meaning for its actions, latching another hidden data on their results, but they still can be seen as actions, in context of being sequenced and combined by that monad's bind. Haskell will also attempt to reduce and simplify this combined actions value, unlike in IO case where it can't do that because the values involved can change from one invocation to another. So seen from inside the pure Haskell world IO monad is just another Logging Monad, building logs of future activity to be performed. And it can be performed more than once, of course: Prelude> let v=do{ getChar; putStrLn "12"; return () } Prelude> [v] [<<IO action>>] :: [IO ()] Prelude> v c12 Prelude> v d12 Prelude>

As for terminology: we've got to have some special name for functions that are chainable by bind. Calling them actions confuses them with the real world actions performed by IO.

What I seek here is to demystify the monad, any monad, and IO monad in particular, and for that a clear and consisent terminology must be employed. We should be able to name things, in English, that we talk about - in English.

Correction:  special name for IO "functions" (actually "IO terms" would be better). 

The monad just organizes stuff, so the IO monad, as monad, is no different

Why? They are just fuctions, of type (Monad m => a -> m b). What I'm saying, they are of special type, chainable by the M monad, so it seems logical to have a special name for such M-chainable functions, e.g. "M-action functions" (whatever the M). The monad M is chaining and combining something. It is M-action functions, of type (a -> M b), that get chained by its bind, and their hidden data combined by it, behind the curtain. Usually when we have a name for some concept, it becomes clearer. And vice versa. than any other monad.

May be to call them "action functions"?

This was a big problem for me; I find terms

like "action", "computation", "function" completely misleading for IO terms/values.  Why? A function of type (a -> M b) is a function that returns a value, (:: M b), tagged with some monadic hidden data. In case of IO, it is a promise to perform some actual I/O that's passed around, hidden. But the M-action function itself is just a regular Haskell function. It can be defined elsewhere, anywhere. IO values themselves are no mystery too. They just carry along with them a log of promised I/O activity as specified at time of their creation (definition).

You might find ["Computation" considered harmful. "Value" not so hot either] useful; see also the comment "Another try at the key sentence".  There are a few other articles on the blog that address this terminology problem.

Thank you. Will do.