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
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
ys))
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?
claus
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
