OK, just to prevent this getting side-tracked: I'm absolutely uninterested in the results of performActionA before determining if performActionB is permitted/possible/whatever.  Think more in terms of security permissions or resource availability/claiming than in terms of chaining results.  I want to know before I begin to collect the results of performAction* that I will actually stand a chance at getting results at all.

On Mon, 2007-25-06 at 10:58 +0200, peterv wrote: 
I'm baffled. So using the Arrow abstraction (which I don't know yet) would
solve this problem? How can (perfectActionB x) be checked with without ever
executing performActionA which evaluates to x? This can only be done when x
is a constant expression no?

-----Original Message-----
From: haskell-cafe-bounces@haskell.org
[mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Tomasz Zielonka
Sent: Monday, June 25, 2007 10:43 AM
To: Henning Thielemann
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Practical Haskell question.

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.

Best regards
Tomek
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Michael T. Richter <ttmrichter@gmail.com> (GoogleTalk: ttmrichter@gmail.com)
I'm not schooled in the science of human factors, but I suspect surprise is not an element of a robust user interface. (Chip Rosenthal)