| 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
_______________________________________________
Haskell-prime mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-prime
