On Mon, Jun 25, 2007 at 10:58:16AM +0200, Henning Thielemann wrote:
On Mon, 25 Jun 2007, Tomasz Zielonka wrote:
On Mon, Jun 25, 2007 at 10:29:14AM +0200, Henning Thielemann wrote:
Imagine all performActions contain their checks somehow. Let performActionB take an argument.
do x <- performActionA y <- performActionB x z <- performActionC return $ calculateStuff x y z
Now performActionB and its included check depend on x. That is, the check relies formally on the result of performActionA and thus check B must be performed after performActionA.
IIUC, this limitation of Monads was one of the reasons why John Hughes introduced the new Arrow abstraction.
How would this problem be solved using Arrows?
Maybe it wouldn't. What I should say is that in a Monad the entire computation after "x <- performActionA" depends on x, even if it doesn't use it immediately. Let's expand the do-notation (for the earlier example): performActionA >>= \x -> performActionB >>= \y -> performActionC >>= \z -> return (calculateStuff x y z) If you wanted to analyze the computation without executing it, you would start at the top-level bind operator (>>=). performActionA >>= f and you would find it impossible to examine f without supplying it some argument. As a function, f is a black box. With Arrows it could be possible to inspect the structure of the computation without executing it, but it might be impossible to write some kinds of checks. Anyway, I have little experience with Arrows, so I can be wrong, and surely someone can explain it better. Best regards Tomek