[Haskell-cafe] monad subexpressions
claus.reinke at talk21.com
Fri Aug 3 06:57:52 EDT 2007
> 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
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.
More information about the Haskell-Cafe