Re: [Haskell-cafe] Smarter do notation

On 5 September 2011 13:41, Sebastian Fischer wrote:

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

Will there also be an optimisation for some sort of simple patterns? I.e., where we could rewrite this to: liftA2 (\pa pb -> f ...) a b I think I remember someone saying that the one-at-a-time application of <*> inhibits certain optimisations.

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

I find (a << b) confusing. The intended semantics seem to be "effect a", then "effect b", return result of "a". That doesn't seem intuitive to me because it contradicts with the effect ordering of (=<<) which reverses the effect ordering of (>>=). We already have (<*) and (*>) for left-to-right effect ordering and pointed result selection. I understand that (>>) = (*>) apart from the Monad constraint, but I would prefer not to have (<<) = (<*).

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

-- Push the envelope. Watch it bend.