[E-Lang] I/O with monads

[Darius Bacon]

Jonathan Rees wrote, about monads:

>   if fragment1 is a function from values to extensions
>  and fragment1 [fragment2 actually] is a function from values to extensions
> then bind(fragment1, fragment2)
>        is a function from values to extensions

In the Haskell literature I've seen, fragment1 is a monad (i.e. an
extension) rather than a function from values to monads.

Here's another way of looking at monads and I/O, not really different
but maybe still illuminating:

In a purely functional language, functions return results, they don't
perform actions on the world.  So how to model actions?  You could
make up a domain-specific language for them -- say a language with
three operations, read, write, and sequence.  Then have your top-level
Haskell function return a `program' in that language (made up of some
sequencing of reads and writes) for a machine that is connected to the
world to run.  (The `program' can be evaluated lazily to interleave
running it and building it up, so we can still express interactive
processes this way.)

>From this point of view Jonathan's analogy between monads and
when-catch isn't so obvious, but I think it's a good analogy.

Should E use monads for I/O?  Even disregarding familiarity, it looks
like a security problem to me at first glance.  Right now you can pass
an object that may do I/O to another, untrusted object.  To get the
same result in a side-effect-free monadic style, the object you're
passing would return an I/O monad to its caller instead of just
performing an I/O action -- and then the untrusted caller can mess
with the returned monad.  We could seal it, but the caller could still
neglect to pass it back to where it's useful.  So we change our object
to send its monad directly where it's used -- but then it's looking
like side effects all over again, and what have we gained?

-- 
Darius Bacon    http://www.accesscom.com/~darius/    hacker for hire