mytransaction = foo `liftM` r xvar0 `ap` r xvar1 .. where r = readTVar
I really find it difficult to articulate why this isn't acceptable, because it seems so obvious to me! It's short yes, but I really don't think it's very clear...
if it is any consolation, i don't use that style myself (yet?-). but it is a useful stepping stone on a path that seems to go somewhat like this: - explicit do-notation with flattened parameters - explicitly defined lifted operations - liftMn, for on-the-spot lifting - liftM/ap (avoiding need for infinitely many liftMn) - idioms http://www.cs.nott.ac.uk/~ctm/Idiom.pdf - idiom brackets - .. ?-)
I have a hard time believing that anyone finds that natural. After lots and lots of mind-bending forays into various branches of mathematics, then yes maybe you can get used to it, but it's hardly as natural as saying "add this one symbol to your values to extract monadic values left-to-right".
what makes this unnatural to me is that it is built-in syntax, which not only interacts badly with haskell's general abstraction facilities, but is outside the programmers' control. once we've figured out what we want, programatically, then putting a nice syntax on top of it, that is syntactic sugar, but binding fairly complex syntax transformations to an innocent-looking syntax is not. perhaps a good start would be syntactic sugar for idiom brackets, to rescue them from the complexities of type-level programming? at least, that would be a local transformation with well-explored semantics, similar to do-notation on top of >>=/return. if that doesn't work out, one might take another look at (<-). claus