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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
