Or what about a specialized Escape Continuation monad?  (Perhaps there is one on hackage, not sure).

Something that allows you to set up an continuation (for "escape") purposes, but does not allow you
to capture any more continuations after that, and call that escape cont w/in itself, supplying a "return" value.

i.e.

> run = do
>    result <- createEscape $ \escape ->
>        lengthyComputation1
>        inp <- askToContinue
>        if (not (continue inp))
>          then escape "They quit"
>          else lengthyComputation2
>    return result

Just thinking off the top of my head :).

However, if there are going to be multiple 'lengthy computations' then perhaps
MaybeT or EitherT would be better, b/c they allow the propagation of failure
across multiple actions, instead of cascading off to the right of the screen w/ 'if's or 'case's.

Cheers,
 - Tim

On Thu, Jun 10, 2010 at 3:21 PM, Ben Millwood <haskell@benmachine.co.uk> wrote:
On Thu, Jun 10, 2010 at 8:57 PM, Maciej Piechotka <uzytkownik2@gmail.com> wrote:
>
> Error monad seems not to be a semantic solution as we exit on success
> not failure.
>

Which is really why the Either monad should not necessarily have Error
associations :)
If you forget about the fail method, the Monad (Either e) instance
doesn't need the e to be an error type.

Alternatively, if even Error is more information than you need, you
could use MaybeT:

http://hackage.haskell.org/package/MaybeT

which allows you to just stop. Given you're using it with IO it'd be
easy to write a result to an IORef before terminating the computation,
so it's of equivalent power, if slightly less convenient.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe