[Haskell-cafe] monad subexpressions

[Claus Reinke]

> I've heard Simon (Peyton-Jones) twice now mention the desire to be able 
> to embed a monadic subexpression into a monad.  That would be 
> http://article.gmane.org/gmane.comp.lang.haskell.prime/2267 
>..
> Thoughts?

what is the problem you're trying to solve, and is it worth the 
complication in syntax? in previous threads, the answer to the
second questions seemed to be 'no', because there are easy 
workarounds (liftMn/return, or combinator-based lifting) and 
the extension would have non-local effects. 

what is particularly nasty about this extension is that it might be 
easy to add, but will interfere with just about everything else: it 
looks like an operator, and for tiny examples, it seems to have 
a local effect only, but it is really a piece of static syntax distributed 
widely over parts of a dynamic expression; the special quoting 
cannot be understood locally, as it is -namelessly- bound to the 
_next_ enclosing 'do', thereby complicating local program 
transformations, by tools or users. 

why is the syntax even bound to do (adding 'do's or switching 
from 'do' to '>>=' will change everything), and not to monadic 
operators (with lifting in place, there'd be more isolated monadic 
calls, without need for 'do')? wouldn't it be sufficient to lift the
parameter out of the next enclosing call (and isn't that what the
no-syntax alternatives already provide)? and what is the precise 
specification/what happens with more complex examples?

more helpful than an immediate implementation, imho, would be 
a wiki page formalising the proposed extension and discussing 
the alternatives with pros and cons. 

perhaps there are lifting operations that are missing (eg, liftMn 
lifts non-monadic functions, but how to lift monadic functions 
with non-monadic parameters?), or perhaps the combinators 
that enable lifting of complete calls (rather than functions) could 
be simplified; this issue trips up enough people that it is worth
investigating what the real show-stoppers are, or why the 
workarounds are not more widely used/known. but in the 
end,  i'd expect the no-syntax route to be just as convenient, 
and less problematic in this case.

claus