[Haskell-cafe] Re: monad subexpressions

Brandon Michael Moore brandon at heave.ugcs.caltech.edu
Fri Aug 3 20:48:18 EDT 2007


<much snipping>

> Also, note, if you use the operators in Control.Applicative, then:
> 
>   return $ foo $(bar1) $(bar2) $(bar3) ...
> 
> can be:
> 
>   return foo <*> bar1 <*> bar2 <*> bar3 ...
> 
> or:
> 
>   foo <$> bar1 <*> bar2 <*> bar3
> 
> I don't (personally) see how that's any more cryptic than placing brackets 
> around around the monadic values themselves. 
> ...

Seconded. The main difference with brackes is that the application to pure
values looks the same as normal application.

> 
> To get outside the scope of idiom brackets/applicative, you'd need a use case 
> like:
> 
>   if $(mexpr) then branch1 else branch2
> 
> or (lest that be to easy):
> 
>   case $(mexpr) of
>       p1 -> branch1
>       p2 -> branch2
>       ...
> 
> In other words, something where you're not simply applying a pure function to 
> a bunch of monadic arguments. I can't say I've run into such patterns much 
> myself, but I've been told they're common in xmonad, and may be elsewhere.

General purpose brackets are overkill here. I would really like a simple
monadic case. What's so bad about

caseM mexpr of
  p1 -> branch1
  p2 -> branch2

vvvv

(mexpr >>= \e -> case e of
  p1 -> branch1
  p2 -> branch2)

It's simple sugar for working with monadic code, much like do notation.
(indeed, it seems to plug a gap - we have do for sequencing, liftM and
so on for application, but no sugar for case discrimination)

It's a much simpler sort of thing than this fancy sugar for intermixing
code in various monads people have been talking about (so far it seems
assumed that one is just Identity...)

Brandon



More information about the Haskell-Cafe mailing list