[Haskell-cafe] Fwd: Smarter do notation

---------- Forwarded message ---------- From: Alberto G. Corona Date: 2011/9/5 Subject: Re: [Haskell-cafe] Smarter do notation To: Sebastian Fischer Cc: Max Bolingbroke , haskell-cafe@haskell.org The problem in the parallel distribution of monadic computations that may have been Applicative seems to be the >> operator But if Monad is defined as a subclass of applicative: http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal then ">>" can be defined as (>>) = (*>) and parallelization should be pòssible ? Alberto 2011/9/5 Sebastian Fischer

Hi again,

I think the following rules capture what Max's program does if applied after the usual desugaring of do-notation:

a >>= \p -> return b --> (\p -> b) <$> a

a >>= \p -> f <$> b -- 'free p' and 'free b' disjoint --> ((\p -> f) <$> a) <*> b

a >>= \p -> f <$> b -- 'free p' and 'free f' disjoint --> f <$> (a >>= \p -> b)

a >>= \p -> b <*> c -- 'free p' and 'free c' disjoint --> (a >>= \p -> b) <*> c

a >>= \p -> b >>= \q -> c -- 'free p' and 'free b' disjoint --> liftA2 (,) a b >>= \(p,q) -> c

a >>= \p -> b >> c -- 'free p' and 'free b' disjoint --> (a << b) >>= \p -> c

The second and third rule overlap and should be applied in this order. 'free' gives all free variables of a pattern 'p' or an expression 'a','b','c', or 'f'.

If return, >>, and << are defined in Applicative, I think the rules also achieve the minimal necessary class constraint for Thomas's examples that do not involve aliasing of return.

Sebastian

On Mon, Sep 5, 2011 at 5:37 PM, Sebastian Fischer wrote:

...

Hi Max,

thanks for you proposal!

Using the Applicative methods to optimise "do" desugaring is still

...

possible, it's just not that easy to have that weaken the generated constraint from Monad to Applicative since only degenerate programs like this one won't use a Monad method:

Is this still true, once Monad is a subclass of Applicative which defines return?

I'd still somewhat prefer if return get's merged with the preceding statement so sometimes only a Functor constraint is generated but I think, I should adjust your desugaring then..

Sebastian

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe