Make it possible to evaluate monadic actions when assigningrecord fields

Claus Reinke claus.reinke at
Thu Jul 12 09:33:01 EDT 2007

>> 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:
> Look at coreSimplifyExprUniqueExt
>        -- helpers, ' is yes, _ is no
>        coreCase__ x y = f $ CoreCase x y coreCase_' x y = f . CoreCase x =<< y

hmm. i'd say that is a compelling misuse-case!-) although apfelmus
probably meant misuses in the sense that a different structure than
monads would often have been a better fit, i just mean readability.

why not simply define

    coreCaseM x y = f =<< liftM2 CoreCase x y

etc. then this

>        f (CoreApp (CoreLet bind xs) ys) = coreLet_' bind (coreApp__ xs ys)

would become somewhat lengthier, but much easier to read

         f (CoreApp (CoreLet bind xs) ys) = coreLetM (return bind) (coreAppM (return xs) (return 

in particular, there aren't 2^n variations of the functions, but simple
return-wrappers around parameters that immediately tell me what is
going on. if anything, i'd often like a quieter/shorter way to write
(return x) - since this pattern usually requires parentheses, some form
of semantic brackets would do nicely, to express lifting of pure values.
that would serve the same overall purpose, without semantic ambiguities,
wouldn't it?

btw, this half-implicit recursion via an f embedded in constructors
looks rather odd to me. why not separate rules and recursion?


More information about the Haskell-prime mailing list