[Haskell-cafe] Sequencing Operations in a Monad

[Ronald Guida]

SevenThunders wrote:
> I have a matrix library written in C and interfaced into Haskell
> with a lot of additional Haskell support.

[snip]

> Unfortunately if I wrap my matrix references in the IO monad, then
> at best computations like S = A + B are themselves IO computations
> and thus whenever they are 'invoked' the computation ends up getting
> performed repeatedly contrary to my intentions.

Here's some thoughts:

First, the IO monad already does sequencing, and it already has the
ability to execute an action once only.

Let's look at an example:

> test1 = do
>   putStr "What is your name? "
>   n <- getLine
>   putStrLn $ "Hello, " ++ n ++ "!"
>   return n

> getName :: IO String -> IO String
> getName nameAction = do
>   n <- nameAction        -- execute the action
>   return n

> getNameLength :: IO String -> IO Int
> getNameLength nameAction = do
>   n <- nameAction        -- execute the action
>   return $ length n

> test2 = do
>   let nameAction = test1 in do
>     n <- getName nameAction
>     putStrLn $ "Name = " ++ n
>     len <- getNameLength nameAction
>     putStrLn $ "Length = " ++ show len

> test3 = do
>   n <- test1
>   putStrLn $ "Name = " ++ n
>   putStrLn $ "Length = " ++ show (length n)

> test4 = do
>   let nameAction = test1 in do
>     n <- nameAction
>     n' <- getName (return n)
>     putStrLn $ "Name = " ++ n'
>     len <- getNameLength (return n)
>     putStrLn $ "Length = " ++ show len

GHCi> test1
What is your name? Ron
Hello, Ron!
"Ron"

GHCi> test2
What is your name? Alice
Hello, Alice!
Name = Alice
What is your name? Bob
Hello, Bob!
Length = 3

GHCi> test3
What is your name? Ron
Hello, Ron!
Name = Ron
Length = 3

GHCi> test4
What is your name? Ron
Hello, Ron!
Name = Ron
Length = 3

Notice that in test2, I am asked for my name twice.  This behavior is
expected because the functions "GetName" and "getNameLength" each
accept an action and execute it to get a name.

In test3, I am only asked for my name once.  I only want to execute
the action once, so I have to code it that way.

Before I explain test4, let's look at your example code:

> let S = A += B in
>   do
>       (r,c) <-  size S
>       k  <- matindex S

If S is being executed twice, then clearly S is an action.  Perhaps
the type of S is "IO MatrixIO" ?  If that's true, then presumably the
functions "size" and "matindex" have signatures:

 size     :: IO MatrixIO -> IO (Int, Int)
 matindex :: IO MatrixIO -> IO Int

Each function takes an IO action as its first argument, executes that
action, and then computes a result.

My two functions "getName" and "getNameLength" are similar to "size"
and "matindex": each function takes an IO action, executes the action,
and computes a result.

Now, look at test4.  That's how I can work around the behaviour of
"getName" and "getNameLength" while ensuring that I am only asked for
my name one time.  This works because "return" creates an IO action
that does nothing and simply returns its argument.

I could translate your example to the following:

> let S = A += B in
>   do
>       s <- S
>       (r,c) <-  size (return s)
>       k  <- matindex (return s)

This should only perform action S one time.

In fact, functions like "getNameLength" are poorly designed functions
because they fail on "Separation of concerns".  The "getNameLength"
function is doing two different things: (1) it executes an IO action
to get a name, and then (2) it computes and returns the name's length.
In test4, I am bypassing the execution of an IO action by passing the
non-action "return n" to the getNameLength function.

A simple design rule would be: A function should not take an IO action
as an input if that action is to executed exactly once and only once.

Let's move on to chained binary operations.

> If you arrange the types to try to do all the operations inside the
> IO monad you can't chain together more than 1 binary operation.

Using your example, suppose I want to compute S := Q * (A + B), but I
don't have a function that computes A + B.  Instead, what I have is a
function that computes A += B by modifying A in place.

If I want to compute S, and I don't care about preserving A, then I
would perform the following steps:
 A += B;  S := Q * A

If I do want to preserve A, then I need to copy it first.
 A' := copy A; A' += B; S := Q * A'

No matter what, I cannot escape the need to explicitly sequence the
operations.

In C++, I could play some very sophisticated games with templates and
operator overloading to coax the C++ compiler to accept an expression
with chained operations like "S = Q * (A + B)" and do the right
thing.  In Haskell, I'm pretty sure the corresponding techniques
involve using arrows.

If you don't want that level of sophistication, then you are best off
coding what you mean, as in:

 do
     -- compute S := Q * (A + B)
     C <- A + B
     S <- Q * C

Now, there's just one more thing [emphasis added].

> Moreover I manage my matrices on a stack in C, since it makes it
> easy to handle memory allocation and deallocation.  *The stack*
> *configuration tends to be highly fluid so there are always side*
> *effects going on.*  Right now my Matrix type wraps the index from the
> bottom of the Matrix stack into the IO monad.

This brings us back to sequencing.  Your "highly fluid" stack
manipulations in C are exactly the thing that's bug-prone and anathema
to functional programming.  Here's what I think you should do:

1. Write a bunch of safe wrappers, as Ryan has described.

2. Test them thoroughly, and also *prove* that they are in fact safe.

3. Write your application-specific code and test it.  Do your best to
  get your application-specific matrix calculations correct.

4. If the code is too slow then profile it.  Remember, 80% of the time
  is usually spent in 20% of the code.  *IF* (and only if) the matrix
  code happens to take up that 80% of the time, then proceed.

5. You can move your application-specific matrix calculations from
  Haskell to C and put them behind an FFI interface.  Then, working
  in C, you can optimize out all the matrix copying that takes place
  behind safe wrappers.  The calculations will run faster without the
  overhead of Haskell.

-- Ron