Make it possible to evaluate monadic actions when assigning record fields

[Simon Peyton-Jones]

| In the end, I think that applicatively used monads are the wrong
| abstraction. For occasional use, liftM2 and `ap` often suffice. If the
| applicative style becomes prevalent, then Applicative Functors are
| likely to be the conceptually better choice. This is especially true
| for
| MonadReader. Arithmetic expressions are a case for liftM, too. And an
| instance (Monad m, Num a) => Num (m a)  allows to keep infix (+) and
| (*).
|
| Put differently, I don't see a compelling use-case for the proposed
| syntax extension. But I've seen many misused monads.

Can you be more explicit?  Monadic code is often over-linearised.  I want to generate fresh names, say, and suddenly I have to name sub-expressions.  Not all sub-expressions, just the effectful ones.  It'a a pain to define liftM_yes_no_yes which takes an effectful argument in first and third position, and a non-effectful one as the second arg:
        liftM_yes_no_yes :: (a->b->c->m d)
                -> m a -> b -> m c -> m d

What a pain.  So we have either

        do { ...; va <- a; vc <- c; f va b vc; ... }

or
        do { ...; liftM_yes_no_yes f a b c; ...}

or, with some syntactic sugar...

        do { ...; f $(a) b $(c); ...}

The liftM solution is even more awkward if I want

        f (g $(a)) b c
for example.

I'm thinking of this as a very superficial piece of syntactic sugar, aimed at avoiding the excessive linearization of monadic code.  Nothing deep.

Of course adding more syntactic sugar has a cost; but this one looks like having a good power to weight ratio.

Simon