| 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
|
Hi
Put differently, I don't see a compelling use-case for the proposed
syntax extension. But I've seen many misused monads.
A compelling use-case:
http://darcs.haskell.org/yhc/src/libraries/core/Yhc/Core/Simplify.hs
Look at coreSimplifyExprUniqueExt
And from that file:
-- helpers,
Hello Neil,
Thursday, July 12, 2007, 3:10:10 PM, you wrote:
This extension seems like a great idea - my only concern would be
about the order of computations. Clearly left-to-right makes sense,
but this may break some natural intuition in Haskell:
i think that undefined order will be a best
Hi
This extension seems like a great idea - my only concern would be
about the order of computations. Clearly left-to-right makes sense,
but this may break some natural intuition in Haskell:
i think that undefined order will be a best one
Using undefined does not make for great reading in
Put differently, I don't see a compelling use-case for the proposed
syntax extension. But I've seen many misused monads.
A compelling use-case:
http://darcs.haskell.org/yhc/src/libraries/core/Yhc/Core/Simplify.hs
Look at coreSimplifyExprUniqueExt
-- helpers, ' is yes, _ is no
apfelmus wrote:
In the end, I think that applicatively used monads are the wrong
abstraction.
Simon Peyton-Jones wrote:
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,
