---------- Forwarded message ---------- From: Alberto G. Corona <agocor...@gmail.com> Date: 2011/9/5 Subject: Re: [Haskell-cafe] Smarter do notation To: Sebastian Fischer <fisc...@nii.ac.jp> Cc: Max Bolingbroke <batterseapo...@hotmail.com>, 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 <fisc...@nii.ac.jp> > 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 <fisc...@nii.ac.jp>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 > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
