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