Re: clarification on IO

Gregg Reynolds <dev <at> mobileink.com> writes:

> On Sun, Mar 1, 2009 at 4:28 AM, Will Ness <will_n48 <at> yahoo.com> wrote:
> 
> 
> Michael Easter <codetojoy <at> gmail.com> 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 
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).  

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.

> The monad just organizes stuff, so the IO monad, as monad, is no different 
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.