
Yep, I do this often and it's pretty nasty. It's especially
inconvenient that you don't have access to computations before the if,
for example:
do
x <- something
y <- something-else
case y of
Foo a -> do
.... <--- I want access to 'x' here
Bar b -> ...
-deech
On Wed, Jan 26, 2011 at 2:51 PM, Edward Amsden
Those functions are useful if I'm more interested in actions (for instance putStrLn) in IO, but they restrict the monad's return type to ().
I'm often writing code like the following:
do ... case ... of Foo x -> do ... ... return foobar Bar x -> do ... ... return foobar
or worse:
if cond then throwError "BBQ!" else do ... ... return ...
(which works btw because throwError is polymorphic in the return type)
So I end up with a nasty set of nested do statements for case expressions.
On Wed, Jan 26, 2011 at 3:32 PM, aditya siram
wrote: I think that for monads the cleanest way of doing conditional execution is using 'when' and 'unless' [1] and 'guard' if your type is a Monoid.
-deech
[1] http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.htm...
On Wed, Jan 26, 2011 at 2:22 PM, Edward Amsden
wrote: Inside a do block, I can very conveniently substitute
let x = <pure exp> <continued monadic code>
for either x <- return <pure exp> <continued monadic code>
or let x = <pure exp> in do <continued monadic code>
However, I can't do anything similar (that I know of) with if or case expressions. If I use if or case inside a do block, it's likely that I'm still using monadic expressions (at least in my experience). Is there some nasty semantic ambiguity that comes of this? Is it just not in the standard yet? Is there some extension that I'm not aware of?
-- Edward Amsden Undergraduate Computer Science Rochester Institute of Technology www.edwardamsden.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Edward Amsden Undergraduate Computer Science Rochester Institute of Technology www.edwardamsden.com